上周有个朋友找我吐槽。
他在一家中型游戏公司做PM，带一个40多人的项目组，正在做一款开放世界动作游戏。最近项目进入量产期，他说自己每天的状态是这样的：
早上9点到公司，先处理昨晚美术外包发来的一批角色模型，发现有3个面数超标，赶紧拉群让TA和美术主管看；10点策划周会，发现上周定好的关卡流程又改了，程序那边已经按老方案开始做了，得赶紧对齐；11点刚想喘口气，制作人叫他去开紧急会——海外发行那边反馈了一批本地化问题，要在这个版本修掉；下午测试报了个严重bug，影响核心战斗手感，他得协调程序和策划一起排查；晚上7点，他还在帮一个新来的策划改需求文档格式，因为程序看不懂……
「我感觉自己每天都在救火，」他说，「灭了一个又冒出三个。最可怕的是，这些火我去年也救过，前年也救过。问题一模一样，只是换了个版本号。」
我问他：你有没有想过，为什么同样的问题会反复出现？
他沉默了一会儿说：「我知道你想说什么，应该建流程、建机制。但我真的没时间啊，每天光处理眼前的事就忙不过来了。」
这句话我太熟悉了。因为我自己也说过。
这恰恰是大多数游戏PM面临的最核心困境——你越忙于救火，就越没时间建消防系统；越没有消防系统，火就越多。
今天这篇文章，我想聊一个我认为是PM成长过程中最关键的认知转变：从「解决问题」到「改进系统」。
这不是什么新鲜概念。但在游戏行业，真正做到的PM少之又少。
一、一个场景，两种PM
先来看一个游戏项目中非常典型的场景。
某个Sprint评审会上，制作人发现一个已经做完的关卡，战斗节奏和设计预期差距很大。敌人配置太密集，难度曲线不对，玩家体验很差。
PM甲的反应：
赶紧把关卡策划和战斗策划拉到一起开会，现场讨论怎么改。改完之后盯着他们执行，验收，确认结果符合预期。问题解决了，松了口气。
PM乙的反应：
也会先推动当前的问题解决。但在这之后，PM乙会多想一步：这个关卡策划为什么会做出一个节奏不对的关卡？
是他能力不行？还是他做关卡的时候压根就没有参考战斗节奏的标准？是不是我们的关卡设计流程里就缺了一个「战斗体验预审」的环节——导致所有关卡策划都是凭个人感觉在做，做完了才发现不对？
如果是流程缺失，那PM乙要做的不是盯着一个人改一个关卡，而是在关卡制作管线中增加一个验证节点，定义清楚战斗节奏的评估标准，确保后续每个关卡在进入正式制作之前都经过这道检查。
同一个问题，PM甲解决了一次，PM乙让它不再出现。
这就是「解决问题」和「改进系统」的区别。
二、游戏项目为什么特别容易陷入「单点救火」？
不是只有游戏PM才会陷在单点问题里。但游戏行业有几个特殊性，让这个陷阱比其他行业更深。
第一，游戏开发的不确定性极高。
做一款互联网产品，需求相对明确，技术路线相对成熟。但游戏不一样——一个玩法到底好不好玩，在做出来之前谁也说不准。这意味着游戏项目天然就会频繁遭遇「做了才发现不对、推翻重来」的情况。每次推翻，都是一轮新的问题爆发。PM如果只会跟着问题跑，永远跑不过来。
第二，跨职能协作链条极长。
一个游戏功能从需求到交付，可能要经过策划、原画、模型、动画、特效、程序、音效、QA八九个环节。链条越长，每个环节出问题的概率越高，信息丢失和理解偏差的可能性越大。PM每天面对的不是一两个问题，而是几十个不同环节上的不同问题。光是应对这些单点问题，就足以把一个PM的时间和精力吃得干干净净。
第三，「能者多劳」的隐形陷阱。
游戏行业的PM有一个特殊处境：你的价值很难被量化。项目成功了，功劳是制作人的、是策划的、是美术的；但出了问题，大家第一个想到的就是「PM怎么没协调好」。这种「价值隐性、责任显性」的特点，会让PM不自觉地用「我解决了多少问题」来证明自己的价值。
解决的问题越多，越有成就感，越觉得自己重要。但这种成就感是一个陷阱——它让你把时间花在了「灭火」上，而不是「防火」上。
三、一个真实案例：从「每天催进度」到「进度自己跑」
我讲一个我自己经历的例子。
刚到一个新项目的时候，团队之前没有专职PM，协作方式比较原始。每个职能组自己管自己的进度，跨组的依赖靠口头约定，没有统一的项目管理工具，也没有明确的版本节奏。
我入职后第一个月做的事情，跟大多数PM一样：每天早上挨个组问进度，发现谁卡住了就去帮忙协调，有什么需要对齐的信息就拉个群传达一下。纯粹的「人肉路由器」模式。
问题很快就暴露了。
有一次我发现，程序组有两个功能被策划组的一个需求文档卡了三周——策划说「还在细化」，程序就一直等着。但这个信息从来没有出现在任何正式的沟通场合，我是在跟程序闲聊的时候偶然知道的。
三周。足够导致后续排期全部延后。
更让我警觉的是，类似的情况不止这一个。很多跨组的依赖项都在「静默等待」状态——被阻塞了，大家的反应就是先做别的，等对方给了再回来。没有人上报，没有人预警，直到最后兜不住了才爆发。
如果我继续用「每天问进度、逐个协调」的方式，这种事永远不会消失。因为问题的根源不在于「我问得够不够勤」，而在于这个团队没有一套让信息自动流动、让风险自动暴露的机制。
于是我开始搭系统。
第一步，让风险可见。
我推动团队统一使用项目管理工具，所有功能需求必须建单子，标注依赖关系和交付日期。最关键的一条规则：任何跨组依赖项，如果超过三天没有进展，单子状态自动变成「阻塞」，会出现在每周主管会的风险看板上。
这条规则的意义在于：以前一个功能卡住了，只有当事人自己知道。现在，卡住三天，全体主管都能看到。
第二步，用正式场合制造承诺。
光让风险可见还不够。可见了之后，谁来推动解决？靠PM逐个去催吗？还是那个老问题，催不过来。
我的做法是：所有阻塞项汇总到每周主管会上，当着制作人和所有职能主管的面，让阻塞方给出明确的交付节点。
当众给出的承诺，天然带有社交压力——你说了一个日期，所有人都听到了，下周会上大家都会看你做到没有。这比PM私下催十次都有效。
第三步，让标准代替个人判断。
最费我精力的事情之一，是反复审核各职能的产出质量。策划的需求文档写得够不够清楚？美术的资产规格对不对？程序的功能实现是不是符合设计预期？
以前这些全靠我凭经验判断，逐个看、逐个反馈。效率极低，而且我不可能覆盖所有产出。
后来我做了一件事：把每类产出最常见的问题整理成检查清单——需求文档的自检清单、美术资产的验收标准、功能交付的DoD（Definition of Done）。这些清单不是给我用的，是给团队自己用的。
策划写完需求文档，对照清单自检一遍：目标人群写了没有？关键数值标了没有？异常情况处理写了没有？如果清单里的项都打了勾，程序那边基本不会再有「需求看不懂」的问题。
美术也一样。模型面数、贴图精度、命名规范、UV规格——这些验收标准写成文档，美术自己做完检查一遍，提交的时候大部分质量问题就已经被拦住了，不需要等到我或者主管去审的时候才发现。
三个月之后，效果开始显现。
我每天花在「问进度、催交付」上的时间减少了超过一半。不是因为问题变少了，而是因为很多问题在到达我之前，就已经被系统拦截了——要么被工具自动标记，要么被标准文档过滤，要么在周会上被公开讨论解决。
更重要的变化是团队的状态。以前大家遇到问题的第一反应是「找PM」，现在越来越多的人会自己看看风险看板、查查标准文档、在周会上主动提出阻塞项。不是因为他们突然变主动了，而是因为系统让「主动」这件事变得更容易了。
四、为什么大多数PM做不到？因为建系统太「反人性」
道理说出来都不复杂。但为什么大多数PM——包括曾经的我——还是陷在单点救火里出不来？
因为从「解决问题」切换到「建系统」，需要对抗三个非常强烈的人性本能。
反人性挑战一：即时满足的诱惑。
看到一个问题摆在眼前——策划和程序又吵起来了、外包交付的模型又不达标了——你的第一本能是什么？是赶紧冲上去把它解决掉。因为解决一个问题的即时快感是非常强的：你拉了个会，双方握手言和，事情往前推进了，你感觉自己很有价值。
但如果你选择不立刻上手，而是退后一步思考「为什么策划和程序总是在这个环节吵架」——这个过程没有即时反馈，只有漫长的分析、设计、沟通、推动、等待。对于每天都在高压环境中工作的游戏PM来说，放弃即时满足，选择延迟回报，太难了。
反人性挑战二：系统见效慢。
你直接拍个方案，今天就能往前走。但如果你要建一套机制让团队以后能自己处理这类问题，从设计到推行到磨合到见效，可能需要一两个月甚至更久。这中间你还得忍受「机制推行了但大家不按照执行」的挫败感，以及「问题还在发生但我不能亲自上手」的焦虑。
在游戏项目节奏这么紧的环境下，很少有PM能承受这种「短期看起来更慢」的方案。
反人性挑战三：被需要的成就感。
这一点最隐蔽，也最致命。
当你是那个所有人遇到问题都来找的人，你会不自觉地享受这种「被需要」的感觉。项目组40个人，每天有20个人来找你——这说明你重要啊，说明你不可替代啊。
但你有没有想过：如果你建好了系统，让大部分问题不再需要经过你就能解决——你是不是就没那么「被需要」了？这种「自己让自己变得不重要」的感觉，对很多PM来说是非常恐惧的。
尤其在游戏行业，PM的价值本来就难以量化。当你不再每天忙碌地穿梭在各种问题之间，当你看起来「很闲」的时候，你怕不怕制作人觉得「这个PM好像没什么事做」？
这个心理障碍不解决，再好的方法论也落不了地。
五、具体怎么建？四步构建你的项目管理系统
好，说了这么多「为什么」，聊点「怎么做」。
我自己的实践加上和其他项目PM的交流，总结了四个步骤。不一定适合所有项目，但背后的逻辑是通用的。
第一步：搞清楚你每天在重复什么。
拿出一周的时间，记录你每天处理的所有事项。不是写日报那种粗线条的，而是尽可能详细——跟谁开了什么会、处理了什么问题、做了什么决策、花了多长时间。
一周记完之后，你大概率会发现一个让你沮丧的事实：你花的时间里，有超过一半是在处理重复出现的同类问题。
需求文档不清楚导致程序理解偏差——这个月出过三次了。美术资产命名不规范导致资源管理混乱——每次版本提交都会出现。跨组依赖信息不同步导致进度延迟——几乎每个Sprint都有。
这些重复出现的问题，就是你构建系统的突破口。
第二步：找到每个重复问题的「机制根源」。
拿「需求文档不清楚」这个问题来说。你不能简单归结为「这个策划写文档的能力不行」。因为如果团队里不止一个策划出这种问题，那大概率不是个人能力的问题，而是系统没有提供足够的支撑来帮助策划把文档写清楚。
你要问的是：是不是没有一个标准的需求文档模板，让策划知道必须写哪些内容？是不是策划写完之后没有一个正式的评审环节，导致有问题的文档直接流入了下游？是不是策划和程序之间缺少一个「需求确认」的节点，导致程序拿到文档就开始做，有疑问也不问？
通常你会发现，一个反复出现的问题背后，不是一个原因，而是流程中多个环节的缺失共同导致的。
第三步：设计机制，而不是依赖自己。
找到根源之后，设计解决方案。这里有一个关键原则：你设计的任何机制，都不应该以「需要你个人持续关注」为前提。
以刚才的需求文档问题为例，一个好的机制可能是这样的：制定一套需求文档模板，明确必填字段（目标人群、核心交互、异常处理、关键数值范围）；在程序拿到需求之前，设置一个「需求技术对焦」的环节，由程序接口人确认需求可执行再开工；对焦完毕后双方签字确认，这份确认过的文档才是正式的开发依据。
这套流程一旦跑起来，你不需要亲自审每一份需求文档，也不需要每次都协调策划和程序的分歧。模板帮策划想清楚该写什么，对焦环节帮策划和程序达成共识，签字确认让双方都有据可依。
第四步：找一个人替你「看着」。
这是很多PM忽略的一步，但我认为是最关键的。
建系统不是写个文档发个邮件就完事了。任何新机制在推行初期都需要有人盯着——有人不按规矩来怎么办？新同学不知道规则怎么办？执行过程中发现规则不合理怎么调整？
如果这些全靠你自己盯，你很快就会发现：盯着机制运行所花的精力，并不比直接解决问题少多少。
所以你需要找到一个人（或一个角色）来承担这个「机制运行保障」的职责。在有些项目里，这个角色可能是一个助理PM；在另一些项目里，可能是各职能组的负责人。关键是把「确保机制正常运行」这件事从你的大脑里转移到别人的大脑里，让它成为某个人的明确职责，而不是你的额外操心。
有人帮你看着机制在跑，你才有真正的精力去思考更重要的事——比如下一个需要解决的系统性问题是什么。
六、一个容易被忽视的问题：建系统的副作用
聊到这里，你可能觉得「建系统」就是完美答案。但我想说一个很多人不提的问题：系统也有代价。
代价一：团队会觉得「多了很多流程」。
这是建系统过程中最常见的阻力。你加了需求评审环节，策划会觉得「以前直接跟程序说一声就行了，现在还要走流程，太慢了」。你加了验收标准，美术会觉得「我做了这么多年美术，还需要对着清单打勾？」
这种抵触几乎是必然的。应对的方式不是强推，而是让大家先看到痛点，再接受方案。
我的经验是：不要在没有痛感的时候推流程。等问题真的发生了——比如程序因为需求不清楚返工了一周，全组加班——这时候再提「我们是不是应该加个需求对焦环节」，大家的接受度会高得多。
代价二：系统本身会变成新的问题。
系统一旦建起来，它也需要维护和迭代。你半年前定的验收标准，可能在新的技术方案下已经不适用了。你设置的评审流程，可能在团队规模翻倍之后变成了效率瓶颈。
如果你建了系统之后就不管了，那这个系统迟早会变成团队的枷锁。你需要定期审视：这个机制还有效吗？它解决的问题还存在吗？它有没有制造新的问题？
好的系统不是一成不变的规则，而是一个持续进化的有机体。
代价三：你会变得「看起来不那么忙」。
前面说过了。当系统运转良好，你不再需要每天冲在第一线救火。你可能有时间参加用户访谈、有时间做行业调研、有时间思考项目长期的风险和机会。
但在一些团队文化里，「不忙」等于「不重要」。你可能需要主动管理制作人和团队对你的预期——让他们理解你的价值不是「解决了多少个问题」，而是「让多少问题不再需要你来解决」。
七、补一个反面案例：过度系统化的PM
为了平衡，我再说一个反面的例子。
我认识一个PM，到新项目之后非常热衷于建流程。入职第一个月就搞了一套极其完整的制度：需求评审有三轮、代码提交有五步审核、美术资产验收有二十几条标准……整个团队被流程裹得密不透风。
结果呢？团队的迭代速度反而变慢了。一个简单的bug修复，走完整个流程要两天。策划想做个小实验验证一下手感，发现走完审批流程的时间比实验本身还长。更糟糕的是，团队开始抱怨PM「不懂业务只会搞流程」，对PM的信任急剧下降。
这个案例说明一个重要的原则：系统是为了解决问题而存在的，不是为了让PM显得专业。
在建任何机制之前，先问自己两个问题：这个机制解决的是一个真实存在的、反复出现的问题吗？还是我为了「看起来有章法」而设计的？这个机制的成本（时间、沟通、团队情绪）是否低于它解决的问题的成本？
如果答案不确定，那就先别建。等问题真的来了再建也不迟。
所有好的系统，都是被真实的痛点「逼」出来的，而不是在办公室里「想」出来的。
八、最后一件事：你不需要一步到位
写到这里，我想做一个预防性的说明。
这篇文章讲的是「系统思维」，但我绝不是在说每个PM都应该立刻停下手头的工作，去搞什么「项目管理体系大升级」。
事实上，对于工作一到四年的游戏PM来说，能解决好单点问题本身就是一种重要的能力。 你得先能灭火，才有资格谈怎么建消防系统。
我想传递的是一个思维习惯的转变：当你下次成功解决了一个问题的时候，多问自己一句——
「这个问题，下次还会出现吗？如果会，我能做什么让它不再出现？」
你不需要每次都想到答案。但只要你开始问这个问题，你就已经在从「问题解决者」向「体系架构师」的方向迈步了。
一个月解决一个系统性的问题，一年下来就是十二个。两三年后回头看，你会发现你管理的项目，越来越多的事情不需要你亲自介入就能运转良好。
那时候你就会理解：PM的终极产品不是某个版本的按时交付，而是一套能让版本持续按时交付的系统。
🎙️ 本文有播客版：小宇宙链接
如果你想继续系统梳理从执行到体系化管理的方法，可查看从执行者到架构师。