里程碑与周版本
里程碑
游戏研发分为多个阶段，每个阶段都有比较重要的节点，这些节点被称之为「里程碑」。
在项目的MVP阶段，里程碑可能是关乎生死的MVP评审，通过就立项，不通过就砍掉。而在项目的运营期，里程碑可能是一个又一个的玩法版本和活动，为了拉新，为了促活，为了让游戏的生命周期得以不断延长。
因此，里程碑计划，是游戏生命周期里的一系列重要规划节点，是项目团队运作的一个个进度目标。
用文字描述研发全流程：项目通常从MVP阶段进入α开发、β开发，再走向渠道测试和产品上架；每个阶段都有不同的交付重点和评审门槛。
对于MVP阶段，里程碑计划需要着重打磨核心玩法，体现出游戏的特色。而对于α开发阶段，则应继续着力于提升核心玩法的完成度。而在β开发阶段，一般要开始玩法铺量、完善周边系统和增加新手引导。到了渠道测试和产品上架阶段时，需要开始考虑和发行、运营等部门的合作。
周版本
有了里程碑计划之后，在执行的过程中，还需要将里程碑计划细化到每一个周版本计划，即每周完成一个可以体验的无阻断游戏版本。
通常团队会将周中设置为版本日，这样能避免周末加班。到版本日时，当周版本的单子需要通过测试，才能实现我们定义的「可以体验的无阻断游戏版本」。
周版本流程可以概括为：确定当周范围、分配和开发任务、过程验收、集中测试，在版本日交付可体验版本；未通过测试的内容不能算作当周完成。
举一个里程碑计划转化成周版本计划的例子。
假设S项目需要在1月1日进行CE测试。
首先在研发侧，将本次测试的版本内容拆分为迭代功能和新增功能。获得这些信息需要和策划沟通，同时考虑开发人力，得出受到认可的版本内容。然后考虑合作部门的需求（如发行营销），最后增加一周组内体验的时间确保版本质量。
接着将里程碑范围拆分为一个个具体的任务，如里程碑范围其中之一为增加多人互动玩法，拆分后的任务为具体哪些玩法。
拆分出所有任务后，为每一个环节进行估时，这需要PM和每个负责制作的同学确认。
S项目总体计划密集，很多任务并行开发，PM在评估各时间节点后给出的大致开发排期为：
- 策划写PRD 1～2周
- PRD评审、UX、UI设计等1周
- 程序开发2～3周
- 测试1周
接下来需要观察每个环节的开始时间。特别是需要留给策划足够的时间写PRD，保证后续任务能顺利开始。
个人的高效不一定能带来团队的产出高效。PM在细化周版本计划的时候，不应局限在当周每个团队成员工作量是否饱和。而应该从里程碑计划目标出发，以能否达成最终目的为前提考虑问题。
制定开发计划
我们已经知道游戏研发有不同的阶段，虽然不同阶段的项目有很大的差异性，但制定计划的思路是一致的。包括：整理需求、拆分需求、排优先级、估工时、人员分工、确认上下游排期等。下面我们就以MVP阶段为例介绍制定开发计划的方法。
MVP阶段的特点是充满了不确定性和时间比较紧。不确定性是指需求可能频繁变更，技术实现方式也是一样。此外还有其他例如团队磨合不够和人力不足等。在这种人力不足、时间紧且需求未确定的情况下，做计划时需要有一个明确的最小需求范围。
比如，某个非对称竞技玩法游戏的MVP，最小需求范围是2个职业和对应的技能，1个场景，3种场景交互道具。
确定最小需求范围后，联系对应的美术、开发、QA等同学预估工作量，如果发现工作量超出可承受范围，则需要缩减范围或更改制作方式。在这个阶段可以多考虑使用公司美术库内风格接近的资源。
针对需求频繁变更而导致工期难以预估的情况，可以考虑将版本周期从通常的周版本缩减为双日版本或日版本。缩减版本周期能让版本内的需求进一步明确，有利于进行需求拆分和预估工作量。
日版本计划可以理解为把原本一周的范围继续缩短：每天明确当天必须完成和验证的最小任务，日末交付一次可运行结果，再根据反馈调整下一天的范围。
虽然MVP阶段需求和明确对标的产品还不确定，但是评审的时间是确定的，因此我们通过倒推的方法得到开发迭代的时间。在评审之前，最好提前一周停止新功能开发，用于回归测试和修bug，防止最后阶段出现严重阻断bug影响评审。
在游戏研发过程中，主要采用渐进明细的敏捷开发方式，根据需求灵活制定计划是关键。
AI时代怎么看这个方法
AI可以根据需求文档快速生成任务拆分初稿，结合历史数据提示可能遗漏的依赖，也能把里程碑继续细化成周版本或日版本草案。但计划不是把表格填满：需求是否稳定、估时是否可信、哪些范围能在评审前舍弃，都需要PM和执行者共同判断。AI更适合降低整理和推演成本，计划承诺仍应由真实负责交付的人确认。PM还要明确每轮验证失败后的调整空间。
观点溯源：《AI时代，游戏PM还剩下哪些不可替代的东西？》
如果你想继续系统梳理从执行到体系化管理的方法，可查看从执行者到架构师。