1. 规划这件事到底在解决什么问题说句实在话我入行头两年对“项目管理”这四个字是有点抵触的。那时候我觉得游戏做得好不好取决于策划的玩法设计牛不牛、程序的技术功底硬不硬、美术的审美在不在线跟“规划”有什么关系后来真吃到亏了才明白一个项目死掉往往不是因为某个单点能力不行而是整个团队在错误的时间、用错误的方式做了一件从一开始就没想清楚的事。规划篇要解决的恰恰就是这个“一开始没想清楚”的问题。先说一个我印象特别深的反例。早年参与过一个休闲竞技项目立项的时候大家热血沸腾觉得玩法原型特别好玩老板拍板三个月出Demo六个月上线。结果呢原型阶段确实顺利但一进入量产问题全出来了。程序说底层网络框架当初没考虑多人在线的扩展性得重构策划说核心循环改了四版UI的交互稿跟着返工美术说场景风格定了两版第一版资源全部作废。六个月的排期表上写满了任务但每个人做的其实是自己心里猜的那个版本。最后项目延期了将近一倍上线后数据也不理想。回过头来复盘问题不出在执行而出在没人真正做过“规划”——目标、范围、里程碑、依赖关系、风险预案全部是模糊的。所以我在带项目的时候第一件事永远是跟团队说清楚规划不是做一张好看的甘特图也不是为了应付老板要的排期表。规划的本质是把一个模糊的想法变成团队每个人都看得懂、够得着、可执行的一连串共识。它是一张地图让所有人知道自己现在在哪、要去哪、走哪条路、路上哪里有坑。有了这张地图执行才有意义没有地图团队跑得越快可能偏得越远。这篇规划篇我就从目标定义、范围控制、里程碑拆分、资源估算、风险预案这几个核心模块展开讲。这些都是我在实际项目中反复用过、踩过坑、也验证过有效的方法。适合刚开始带项目的新手PM、想建立规范化流程的制作人也包括每个想搞明白“项目为什么总延期”的团队成员。内容会偏实操尽量不给空泛的理论每个点我都会告诉你当时我是怎么做的、为什么这么做、出过什么问题。2. 规划之前先把这四件事聊透很多人一上来就排期这是最大的误区。排期是规划的最后一步不是第一步。在打开Excel或者任何项目管理工具之前团队核心成员需要先坐在一起把下面四件事聊透。聊不透后面所有计划都是空中楼阁。2.1 目标到底是什么成功长什么样你可能会觉得目标还不简单不就是“做一款好玩的游戏”吗问题就出在这。什么叫“好玩”是次留要到多少是评分到多少是DAU峰值到多少还是说只要项目组自己觉得开心就行没有量化标准的目标在遇到取舍的时候毫无指导意义。我现在的习惯是立项之初就跟制作人、主策、主程、主美一起定三个数字目标次留、目标人均时长、目标付费率如果是商业化游戏。这三个数字不是为了KPI考核而是为了在后续每一次取舍时有一个共同的判断基准。比如某个系统做起来要花两周但对次留的贡献可能只有0.1%那就可以砍掉或延后。没有明确目标每个人都会觉得自己负责的内容最重要最后谁也不敢砍项目越来越臃肿。定目标的时候还要区分“北极星指标”和“辅助指标”。北极星指标只能有一个它代表玩家体验的核心价值辅助指标可以有多个但它们的存在是为了支撑北极星。最怕的是目标列表写得密密麻麻优先级完全没有最后团队做的不是同一个游戏。2.2 范围边界我们必须做什么更重要的是不做什么规划中最难的不是做加法而是做减法。游戏行业尤其如此因为创意类工作的边界天然模糊策划脑内永远有一个“如果再加一个系统会更好玩”的念头。作为PM你的职责就是帮团队守住范围明确告诉所有人这一期不做什么比这一期做什么更重要。我在每个项目启动时都会推动团队写一份一页纸的范围说明书核心就两部分包含的核心功能列表和明确不做的功能列表。后者往往更关键。比如一个卡牌项目我们明确这一期不做竞技场、不做好友系统、不做聊天频道。这些功能不是不好而是它们不属于当前阶段的里程碑目标。写下来之后所有人都有了说“不”的依据。策划再提要加功能的时候不用你一个人顶着压力拒绝而是可以指着说明书说“这个可以记入下一期不在当前范围内。”范围的边界还需要考虑技术方面的约束。程序团队需要确认现有引擎和框架支不支持某些设计。我曾经遇到过一次策划设计了一个全场景动态破坏的玩法审核排期的时候程序没吭声等到开发第三周才发现引擎的物理系统根本撑不住最后整个玩法重做。这就是范围评审时技术验证缺失的教训。所以范围说明书在定稿之前一定要让主程和主美签字确认技术可行性和资源可行性。2.3 质量基线做到什么程度算“完成”游戏项目里有一个最常见的坑功能明明做完了但谁也不敢说“完成”了。策划觉得手感还要调程序觉得性能还能优化美术觉得特效还可以再改一版。在无限调优面前排期就是个笑话。所以我特别强调“完成”的定义——在一个项目里“完成”不等于“完美”而是等于“达到约定的质量基线”。质量基线要细化到什么程度呢拿一个技能特效举例你不能只说“视觉效果要好”要定义清楚几点——特效时长不超过多少帧、同屏最多出现多少个粒子、在最低端配置设备上帧率不能低于多少、与角色动作是否对齐。这些标准在规划阶段就要定下来而不是等开发到一半才讨论。每一条都对应测试的验收依据也是做的过程中自我检查的清单。质量基线通常由主策、主程、主美共同制定但PM要负责把它们写进文档并监督执行。没有质量基线的排期本质上就是赌运气。团队速度快可能靠的是牺牲质量团队慢慢打磨可能靠的是大量加班这两种都不是健康的项目状态。定好基线开发和测试才有了共同的尺子验收的时候也能少吵很多架。2.4 依赖关系谁等着谁谁在前面开路游戏开发里最典型的依赖关系就是玩法设计依赖策划案UI界面依赖交互稿交互稿依赖玩法逻辑UI资源依赖界面风格定义程序功能依赖网络协议定义……这些依赖关系如果没有在规划阶段理清楚执行阶段就会出现大量等待和返工。我的习惯是在规划阶段拉着各端负责人把核心玩法的链路从头到尾走一遍。以新手引导为例策划先出引导流程图程序确认引导触发机制的技术方案UI出界面草图美术出关键帧音频配合音效测试出验收用例。这一步走下来你会清楚地看到哪几个环节在关键路径上哪些任务有浮动时间谁必须先动谁可以等。依赖关系理清之后排期的时候还要特别关注一个现象叫“资源争抢”。比如三四个系统都需要同一个程序大牛支持或者不同系统都需要唯一一个TA技术美术做效果。表面上看起来每个任务的排期都合理但落到具体的人身上时间是冲突的。所以在规划阶段除了看任务本身还要做一层“人员维度”的排期检查。一个人在同一时间段内不能排两个关键任务这是铁律。3. 里程碑拆分把大目标切成能落地的一块块里程碑目标、范围、质量、依赖这四件事聊清楚之后才开始进入真正的排期规划。排期规划的第一步不是逐任务排时间而是设计里程碑。里程碑是项目管理中最容易被误解的概念。很多人把它理解为“一个阶段的结束”但在实际操作中里程碑应该是一系列可验证的、有明确交付物的时间节点。3.1 从上线日期倒推版本节奏设计的思路我排里程碑的习惯只有一个永远是先定终点再往回倒推。比如项目定在某个财年节点上线那上线前的最后一版提审、封包测试、公测预热、内容填充、Alpha测试、核心玩法完整闭环全部从上线日期往前倒排。倒推的好处是它逼迫你面对现实——如果从今天到上线只剩八个月而倒推出来的工作量需要十个月你必须在当下就发现这个矛盾而不是等到第八个月才承认。倒推的时候我会把里程碑分成三层外层是版本级里程碑像Alpha版、Beta版、Release候选版这是给制作人和老板看的中层是内容级里程碑比如“完整可玩的三章关卡内容”“全部商业化系统接入完毕”这是给各职能负责人对齐用的内层是迭代级里程碑多数时候是一个到一个半月的开发周期配合内部可玩的版本节点。这里有个很实用的原则迭代周期要相对固定。我习惯用一个月到一个半月为一个内部迭代。为什么要固定周期因为固定周期才能形成节奏有了节奏团队才知道什么时候松什么时候紧。如果每期时间忽长忽短大家就很难建立对“一个迭代能产出多少内容”的稳定预期。稳定预期是做估算的基础。3.2 关键里程碑的检查标准每个里程碑光定日期没用还得写清楚“到这一天我们能看到什么、摸到什么”。我常用一个方法叫“可演示的成果”意思是每个里程碑结束的时候必须有一个能跑起来的东西可以给团队演示而不是一堆文档和半成品资源。举个例子Alpha版里程碑的验收标准我会写成核心玩法闭环完成玩家可以完整体验从新手到单局结束的流程主要系统UI全部连通允许数值不平衡但功能不能缺美术资源可以有一部分临时资源但表现风格方向已锁定性能达到某基准线比如主流机型上稳定30帧。Beta版的标准则更严格所有内容功能完成美术资源全部替换为正式资源数值完成第一轮平衡性调整性能达到上线标准如主流机型60帧。Release候选版就是纯粹的bug修复和合规审查阶段。每个里程碑都对应一个“过关”的评审会议。评审不是走形式而是要拿着验收清单一条一条打勾。如果哪一条没过就要当场讨论是延期这个里程碑还是砍掉这条标准对应的内容还是增加资源投入。三选一但绝不能选“假装通过了”这第四种选项。这正是我跟很多新手PM强调的点——里程碑评审就是对范围说明书和质量基线的兑现兑现不了就要重新谈判而不是糊弄过去。3.3 关键路径与缓冲时间不要把事情排得太满排里程碑的时候理论上每个节点都有倒推出来的完成时间但实际操作中必须给关键路径预留缓冲。关键路径就是那条一旦延误就会拖垮整个项目日期的任务链。游戏项目的关键路径通常存在于核心玩法的程序底层→核心循环实现→内容量产工具的完善→内容批量填充→上线前测试。这条链上的任何一个环节延误都会产生连锁反应。我在关键路径上预留缓冲的经验值是15%到20%。也就是说如果一个任务你评估需要十周排期上就要留到十二周左右。有人可能会说我这是注水。但我想说的是真正干过项目的人都知道人的估算是乐观的各种意外才是常态。如果在规划阶段就一点缓冲不留后面每一周都会在紧张中度过一旦遇到任何意外就只能砍需求或者掉质量这是最糟糕的应对方式。还要注意一个反直觉的规律关键路径上的任务不应该以“人的工作量”来估算而应该以“系统联调”的时间来估算。很多时候开发本身只花三周但三周之后发现A模块和B模块对接不上联调又花了一个月。这种联调时间在规划阶段最容易被忽略。我吃过一次大亏之后现在的习惯是凡是涉及两个以上模块对接的任务在估时中额外加20%的联调缓冲。4. 资源规划算清楚人力、预算和外包这几笔账游戏项目管理里资源规划往往是最后才被人想起、却最致命的一环。很多项目延期说到底不是计划不合理而是资源压根不够。做规划的时候不把资源账算透后面就只能一直救火。4.1 人力产能估算别拿“满负荷”当“可用负荷”算人力产能的时候新人PM经常犯一个错误团队十个人一个月二十个工作日于是这个月产能就是两百人日。这个账忽略了三个事实人不是机器不可能八小时全程高产出团队有会议、评审、技术分享等各种集体活动还有年假、病假、临时支援其他项目等不可控因素。我自己常用的估算系数是0.6到0.7。也就是说一个研发人员一个月二十二个工作日真正能投入到项目开发上的有效产出大约是13到15天。听起来很保守但实际跑下来这个系数已经算是比较乐观的了。如果团队里新人比例高或者项目协调成本特别大比如跨地区协作这个系数我还会往下调。基于有效产能再反推每个里程碑需要多少人、需要什么角色配置。打个比方一个需要三个月完成的里程碑总工作量评估是600人日那平均每个月需要200人日的有效产能按照0.65的系数至少要10到11个人。如果手头只有8个人那就面临两个选择要么延长里程碑周期要么缩减范围。在这个问题上我现在的原则非常简单——先定范围和质量再配资源和时间三者缺一不可。任何一方被压缩其他两方必须同步调整。4.2 预算与成本人力之外还有哪些必须算的账预算是规划阶段另一个容易被低估的模块。狭义上游戏项目的预算主要包括人力成本、外包成本、软件许可费、硬件设备费、测试设备费、本地化翻译费、市场预热费用等。人力成本是最直观的大头但外包和软硬件这两块往往会在执行中冒出超支。外包我还得多说两句。国内游戏项目用外包资源是常态美术尤其如此。规划阶段必须明确定义外包的交付标准、验收流程和版权归属否则后期扯皮会消耗大量时间。我建议在外包启动前准备一个详细的发包文档包含参考图、规格说明、技术限制、交付格式、验收标准。发包文档写得好不好直接决定外包交付的质量。外包不是“把活扔出去就完了”而是“把标准定清楚再扔出去”。测试设备也是一项容易被忽略的预算。如果是手机游戏需要覆盖主流iOS和Android设备光是真机测试机型的采购就是一笔不小的开支。规划阶段如果不把这笔钱算进去到测试阶段才发现设备不够要么抢来抢去排长队要么漏测大量机型的兼容性问题最后上线被玩过骂。这笔钱省不得。4.3 外包管理的第一条铁律不要压缩发包文档的时间外包和内部开发的区别在于内部团队可以通过会议和面对面沟通来弥补文档的不足而外包几乎完全依赖文档。我在早期吃过亏——为了赶进度花三天时间草草写了个发包文档就发给外包公司。结果对方做回来的东西风格、比例、层级结构全都不对反工耗费的时间远远超过了写文档的时间。从那之后我定了一条规矩发包文档的撰写时间不得低于内部开发同类需求前期准备的70%。比如内部做一个角色原画前期风格调研和概念稿可能需要两天那发包文档至少也需要一天半的打磨时间。这类文档需要包含风格参考图越具体越好、同类型游戏竞品图、规格尺寸、输出格式、命名规范、图层命名规范、动画骨骼绑定要求、迭代次数上限。写得越细后期沟通成本越低。外包管理的另一个要点是设置“中间检查点”。不要等外包交付日才去看成果而是在计划周期内安排1到2次阶段性检查要求外包团队提交半成品或进度截图。这样就算方向错了也能在早期发现并纠偏而不是等到最后一刻收到完全错误的东西再来一场鸡飞狗跳的返工。5. 风险管理规划阶段就为意外准备好预案说个扎心的事实游戏行业里的项目延期不是例外而是常态。所以规划阶段最应该做的不是制定一个完美无暇的计划而是提前预判“哪里会出幺蛾子”并且想好应对方案。风险管理不是大公司流程里的形式主义文档它是保项目命的护身符。5.1 识别风险从哪些维度去排查风险识别最怕的就是没有框架地瞎想。我习惯把风险分成四类技术风险、内容风险、流程风险和人员风险然后带着团队一个一个过。技术风险关注引擎、框架、服务器架构、第三方SDK这些底层能力。比如团队从来没做过大规模同屏战斗那同屏性能和命名网络同步就是技术风险。内容风险关注玩法验证和量产效率。比如玩法原型没经过充分测试就进入量产或者量产工具没准备好就大量铺量都是典型的内容风险。流程风险关注决策效率和协作机制。比如拍板的人太多、需求频繁变更、跨部门沟通没有固定节奏都属于流程风险。人员风险则关注核心成员稳定性和技能匹配度。比如某个关键技术岗位只有一个人会他一旦请假或离职整个模块就停摆。每次做风险识别我都会要求各端负责人在会议上至少提出三条自己领域的风险然后大家一起评估概率和影响等级。这个动作看起来简单但价值很大——它迫使每个人在动手之前认真想一遍“哪里可能出问题”。很多问题其实团队心里早就隐隐有数只是没人摊开来说。风险会就是要把这些问题放到桌面上。5.2 风险应对四个策略选定就要执行识别出风险之后应对策略无外乎四种规避、减轻、转移、接受。规避是改变计划让风险不可能发生。比如某个玩法依赖还没验证的技术方案那就先在原型阶段做技术验证验证不通过就不进入量产。减轻是降低风险发生的概率或影响。比如关键岗位只有一个人会某项技术那就安排一个助手跟着学形成AB角。转移是把风险转给第三方。比如把多语言本地化交给专业翻译公司签合同约定质量和交期。接受是明确知道有风险但权衡之后决定承担。比如评估某功能延期概率很高但为了保留它带来的体验价值决定接受延期风险同时提前和上层沟通好预期。这四个策略本身不难理解难的是选定之后的执行。你经常会看到项目组开会时识别了风险也选了策略但会开完就完了没人跟进。所以我在每次风险会上都会做一张风险登记表列清楚每个风险对应的负责人、应对策略、检查节点。下一次开会第一件事就是逐条更新状态直到风险关闭。风险登记表不是一次性文档它应该活在整个项目生命周期里。5.3 风险预算给意外留一笔看不见的钱风险应对还有一个很实用的概念叫风险预算不是钱而是时间。我在排里程碑的时候每个大的阶段都会预留一小段没有具体任务安排的“空白时间”。这段空白时间就是“风险预算”专门用来吸收意外状况。举个例子一个三个月的里程碑我可能会在最末段留出一周时间不安排任何新任务只用来处理bug、联调问题、突发的资源返工等。团队看到这段空白就会心安项目节奏也更健康。最怕的是把时间排得一天不剩看起来抓得很紧实际上任何风吹草动都会引发连锁延期。这个做法在向上汇报的时候也需要一定的沟通技巧。有些老板看到空白时间会认为你在偷工减料。我的做法是在排期文档里把这段时间命名为“集成与稳定期”给它一个正式的身份——它确实是有用的、必要的是用来保证交付质量的。当团队最终按时交付的时候这段“空白”的价值自然就不需要解释了。6. 规划落地文档、工具与会议节奏规划阶段讲了一堆理念最后还是要回到落地。怎么把规划文档写清楚、用什么工具管理、开什么样的会议这些都是决定规划能不能执行到位的关键。6.1 一页纸规划先写出来再分细案我坚持一个原则任何项目规划都先要能写进一页纸里。一页纸包含五个要素核心目标三个数字、范围列表做什么、不做什么、里程碑节点4到5个时间节点及交付物、团队分工谁负责什么、主要风险及应对。这页纸写不出来说明你对项目的理解还不够清晰。一页纸规划不是全部它只是一个总纲。在这个总纲之下各功能模块还需要有自己的细案美术风格规范、技术架构文档、玩法设计案、商业化数值框架、测试策略文档。这些细案不要求在规划阶段全部完成但每一份都要有明确的负责人在规划阶段启动并在第一个里程碑之前完成初稿。文档是规划的载体但文档本身不是目的。很多人把写文档当成任务来完成写完就锁进网盘里再也不看。我的习惯是每次周会打开一页纸规划逐条过一遍当前进度和它的差距。规划文档只有在被频繁引用、被不断更新的时候才有价值否则它就是一张美丽的废纸。6.2 任务拆解与排期从里程碑到人日里程碑定好之后还要继续往下拆直到拆到“一个人一周内可以完成”的颗粒度。这个颗粒度我称之为可执行任务。任务太粗比如“完成新手引导系统”没有拆分到具体实现步骤排期就是拍脑袋。任务太细比如“写一个函数”管理成本又太高了。我的经验是一般的任务控制在3到5天最长不超过两周。任务拆解的过程中最好是由负责人自己来拆而不是PM一个人关起门来把任务分配下去。PM可以给框架和方向但具体到实现步骤只有做这个工作的人最清楚。从规划到执行有个很重要的心理学规律人对自己参与制定的计划更有责任感。如果任务全是PM硬派的执行者容易缺乏主动意识如果是自己拆的出问题的时候他会更多从自身找原因。排期工具方面我个人用过Excel、Jira、飞书项目、Trello等好几套。工具没有绝对的好坏关键是团队习惯和项目复杂度。小团队用轻量工具就够了复杂项目需要能管理依赖关系和资源负载的工具。但工具只是辅助你换一百个工具也救不了一个不健康的管理机制。真正起决定作用的还是前面聊的这些方法是否做到位。6.3 会议节奏日常同步、周度评审、月度复盘规划不是一次性动作它需要在执行中不断被检查和修正。这需要固定的会议节奏来支撑。我的习惯是三层会议体系每日站会、周度进度会、月度复盘会。每日站会控制在15分钟以内每人只说三件事昨天做了什么、今天打算做什么、遇到什么阻碍。站会的目的是暴露问题而不是解决问题。解决问题应该放到会后再找人单独聊如果在站会上深入讨论其他人的时间就被浪费了。周度进度会主要过每一块工作的实际完成率对照里程碑计划看是否偏离如果有偏差就讨论调整方案。月度复盘会则会花更多时间做深度回顾目标有没有变化流程哪里卡顿哪些风险开始冒头会议要短要有结论这是我一直对团队强调的。每场会结束之前必须明确得出三个结论谁在什么时间之前完成什么事、需要谁配合什么、当前计划是否需要调整。没有结论的会等于白开浪费时间不说还会消磨团队对管理的信任。6.4 变更管理规划的唯一确定性就是它一定会变最后聊一个很多PM不愿意面对的事实——再完美的计划也会变。市场变了、老板的想法变了、测试数据反馈不理想、关键技术方案被推翻这些都会导致计划调整。所以规划不只是制定计划还要包含变更管理的机制。变更管理的核心是变可以但不能无声无息地变。所有影响范围、进度、成本、质量四要素中任意一项的变更都必须在团队内同步并记录。我会要求任何需求变更都提交一个简短的变更申请内容包括变更原因、影响范围、工作量评估、对里程碑的影响。然后由项目经理和相关负责人评估决定接受、拒绝还是调整后接受。很多人在这一点上觉得我太死板说团队就几个人搞这套流程多累。但我经历过的真实情况是今天策划在聊天里跟程序说“这个数值换一下”明天美术在群里说“这个界面重新设计一下”后天测试跟策划说“这轮需求改完我们之前写的用例全废了”——然后所有人都在抱怨项目乱。百分之八十的失控都来自于一个个没有记录的微小变更。做变更记录不是不相信人而是为了让每个人都能看到自己在做的事是如何影响别人的。7. 规划阶段的一些个人体会写到这里规划篇的主体内容差不多讲完了。最后想分享几点个人体会算是这些年带项目攒下来的碎碎念。规划这件事最重要的不是你用了什么方法论、买了什么工具、填了多少表格。规划的本质是让一群聪明的、有创造力的、但习惯各自为战的人在动手之前达成共识。共识才是规划的最终产物文档和排期表只是共识的载体。我见过很多团队把规划做成了“上面要的作业”或者“项目启动的形式”开过几次会之后就再也没人翻过规划文档。那是最可惜的。规划真正的价值要从执行的第一天开始才算数——每当你犹豫要不要加需求、要不要延期、资源要怎么分配的时候回头看一页纸规划里的目标和边界它能帮你省掉无数纠结和争吵。还要记住一件事规划做得好不代表项目一定成功。游戏行业终究是产品说话玩法不好玩、市场不接受计划再完美也白搭。但是规划做不好项目失败的概率会急剧上升——不是败在点子不够好而是败在团队连试错的余地都没给自己留。如果你正准备启动一个新项目我建议从写完一页纸规划开始。把目标数字写下来把不做的事情写下来把里程碑和风险写下来然后对照这篇规划篇里的要点逐条检查一遍。不用追求完美先让它跑起来再在执行中不断修正。项目管理说到底是一个持续纠偏的过程而规划就是这个过程的第一块基石。