#046 Netease Game Dev Series: Project Management - SEVEN KEY MODULES

02 产品PM的计划制定和进度管理

2.1 游戏行业的“计划”介绍

项目计划，对一个项目未来要做事情的一个规划集合。

产品PM在制作计划的过程中，需要适应快速变化的环境，计划的重点已经从做计划的结果转向计划的过程。做计划就是协助产品经理和团队确定产品设计思路的过程。

里程碑计划需要能结合变化的节奏和规律，并能预留出一定的缓冲，在不断的需求变化或者紧张的进度中能有制定细化并被能有效执行的里程碑计划。

2.2 里程碑与周版本

2.2.1 “里程碑”介绍

里程碑，是项目整个生命周期里一个又一个的比较重要的节点，是项目团队运作的连续刻度指标。

2.2.2 里程碑计划制定

• Demo期，里程碑计划一般着重于核心战斗的打磨，能够体现整个游戏核心玩法即可。
• Alpha开发第一阶段，着重于核心系统的完成以及核心战斗的继续打磨。
• Alpha二期，一般在工作室内测前，着重于开始玩法铺量，保证工作室内测玩法足够测试。
• Alpha三阶段，一般是公司内测或者小范围玩家测试阶段，此阶段开发主要着重于玩法铺量以及系统周边的完善、新手引导。
• 渠道测试阶段以及产品上架阶段，项目就开始需要考虑运营、营销等相关部门的需求。
• 运营期，产品更能制订出年度计划。两个参考维度，市场和产品本身。

倒推时间，提前几个月确定里程碑内容，“逼”产品经理更早思考产品未来设计方向。

2.2.3 周版本介绍

周版本，每周都完成一个通过验证的可以体验的游戏版本。一般团队每周会有固定一天为版本日，一般情况下，安排在周中比较合理，避免周末加班情况。

周版本通过工具记录任务，到版本日，在当周版本内的单子需要测试完成，才能达到我们定义的“通过验证的可以体验的游戏版本”。

因此当我们把里程碑计划细化到周版本时，需要观察，项目版本日具体是哪几天，然后把计划落在版本日当周。

2.2.4 周版本计划制定

周版本类似于里程碑计划的可执行细化，周版本计划服从里程碑计划。

周版本计划同样需要PM进行宏观的需求监控。当周版本需求锁定后，PM会依次与制作方确认当周的需求工作量是否合理，并做出相应的调整，然后反馈到产品经理。

必须着重强调，在到达里程碑时间节点时，里程碑计划内容必须完成。

周版本计划具有一定灵活性，不在里程碑的范围但是在团队开发能力范围内的内容，策划也可以在需求锁定前提出，前提是保证主干内容完成，进度不受到影响；在里程碑范围内但是当周被评估为完不成的任务，策划也可以进行延单操作，将任务单移到更加合适的周版本里。

观察任务每一个环节的分布是否有过于密集的问题。特别关注任务起始时间，即策划提单时间，要保证留足够文档时间给策划，保证任务能顺利开始。也要观察中间环节是否有某个版本任务过多，这样可能会产生任务阻碍。最后关注完成版本时间，尽量让收尾版本分布相对均匀，而且满足前紧后松。

一个团队的高效不是个人的高效，而是总体产出的高效。PM在细化周版本计划的时候，不要局限在当周策划是否工作量饱和，每个制作者是否工作饱和。而应该从里程碑计划目标出发，能不能达成最终目的为前提。

2.3 项目计划制定方法

2.3.1 倒推法介绍

适合使用倒推计划的前提条件：

1. 有明确的完成时间点要求；
2. 需求相对确定，对于任务开发的各环节时间有相对准确的预估。

从产品阶段来看，Alpha后期与运营期较为适合用倒推的方式来制订计划。

在跟进倒推完成的计划时，若在到期的当天或者前一天去确认进度，往往对于进度的延后没有太多办法。相比提早跟进确认进度，将每一环节时间点细化会是一种更好的办法。

2.3.2 什么情况下不适合用倒推来做计划

倒推完成的计划，其最关键的一点在于通过明确各个任务与环节的期限来给团队很强的计划执行约束力，若经常发生需求与计划的变更调整，无疑让执行的有效性受到影响。

2.3.3 正推与倒推法的结合应用

在产品Demo期或者Alpha初期，可以将正推与倒推的方式结合起来进行。在我们大概确定Demo的开发范围，也就是最小核心玩法的体验内容之后，可以通过渐进明细的方式来明确自己的计划。即首先明确并细化当前周版本的开发计划，根据当前周版本的计划完成情况，再制订下个周版本计划。

这是一种正推的计划方式。即开始不需要定大而全的计划，但是当前周版本计划相对准确而且可靠，可以根据当前版本的反馈，在需求和技术方式不断成熟的情况下，去细化后面的计划。

如何保证能够在期限之前完成所有内容？除确定当前周版本范围外，可以将当前进度与每个月进度目标进行对比，并对是否能完成月度目标进行预估。

同时，对于一些关键节点，比如回归测试的时间点，Demo最后资源整合的时间点，可以通过倒推的方式得到，因为这些工作需要的时间相对好预估，而且直接影响到Demo评审，是非常重要的期限。

正推与倒推的方式并不互斥，二者可以相互结合。适用场合并不绝对，更多是从需求特性角度考虑。

2.3.4 计划完成的标准

产品经理参考各方计划：

• 50%：完成完整功能，等待资源；
• 80%：完成功能，资源到位，待下个版本优化；
• 100%：完成资源与功能，且优化到玩家体验标准。

大玩法制作周期可能会跨越一个里程碑以上的时间，做计划时建议对于大的系统进行细致的拆分，区分子系统开发的优先级和范围。

2.4 不同阶段的开发计划制定

流程上包括：需求收集，需求拆分，优先级划分，工时预估，人员分工，划分版本，确认各环节期限等。

不同产品阶段，产品与团队的特性不同会让计划制定有不同的侧重点与注意点。

2.4.1 Demo阶段计划的制定

Demo阶段典型特点：

1. 时间紧
2. 不确定性高
   1. Demo期间需求变更大且频繁；
   2. 完成的标准与实现的标杆存在不确定性；
   3. 技术实现方式存在不确定性。

明确最小范围

制定最早Demo规划时，需要首先确立能够体现产品特色的最小范围。最小范围不是指具体的需求内容，而是能够满足产品核心玩法展现的最小需求范围。

迭代周期的调整

在敏捷开发中，整体需求的不确定性越高，对快速验证的需求越会增加。

在大致确定的范围内，可以通过适当增加迭代速率让产品经理或策划去印证想法的效果。

针对Demo期间需求变更频繁以及工期预估困难的问题，可以考虑缩短版本周期，将通常的周版本，加快到半周版本或者日版本。缩短版本周期需要对需求进行进一步的细化，这能够帮助团队更好地拆分需求并预估工期，同时缩短版本时间能够加快策划审核频率，更好地适应需求变化调整的环境。

版本体验与验收

在制订计划的时候，可以整理出阶段性的可体验目标，以便对于游戏进行体验与验收。

如何应对标杆不确定

1. 尽早确定相关标杆与标准。
2. 明确逻辑完成的时间节点。提前确认清楚功能逻辑开发完成的时间节点，保证该功能或者玩法是可以验证和测试的。
3. 预留迭代的时间，并倒推期限。

2.4.2 Alpha阶段计划的制定

Demo期确认标杆后，Alpha期主要以系统与玩法的铺量开发为主。通常Alpha期开发比较稳定，计划的调整与变更不如Demo期频繁，但持续时间较长。

产品与美术计划的配合

根据经验，产品的开发顺序一般按照玩家游戏体验顺序进行，优先新手教学与前期内容开发，后进行玩法副本铺量。而美术倾向于根据制作难度排序，即把要求更高、完成难度更高的资源，放到后期进行开发，这样前期有一定技术储备和经验后往往能产出更好的效果。

1. MMO类型产品：MMO产品对阶段性版本完整性体验的要求较高，因此开发过程中遵循产品优先级需求，先完成新手与前期美术资源开发。
2. ARPG：由于ARPG副本推图，其体验相较为独立，可以考虑将前期副本放到后期进行开发。

里程碑，周版本与美术计划的配合

1. 里程碑与美术计划的配合：对于次时代制作的产品，由于美术制作周期较长（场景与角色通常需要3个月周期），一般在当前里程碑开发过程中，就需要确认下个里程碑美术资源的优先级并提前开始开发。
2. 周版本与美术计划的配合：在制订每周版本计划时，需要提前确认美术资源到位的节点，及时调整产品周计划。另一方面，产品临时增补的美术需求，需要提前至少一周提出，以免打乱美术现有开发计划。

里程碑计划的制定——不确定性锥形、渐进明细与范围定义

不确定性锥形：不确定性锥形显示的是项目早期制定的计划偏差相当大，随着项目推进，计划偏差会越来越小。

不管制订里程碑计划还是制订具体周计划时，需求都未完全确定，对预估会造成很大困难。计划时间跨度越大，所制定的计划的准确性越低。

如何解决：

1. 渐进明细的计划过程：将大计划拆分为分层次的小计划，然后根据产品开发优先级逐步推进。
2. 范围定义：优先级。

2.4.3 测试期与上线期产品计划的制定

需求的控制，Bug修复与开发的平衡与提前规划上线期计划是在这个阶段制订计划中需要注意的点。

修复与开发的平衡

1. 产品计划中需要预留回归测试时间
2. Bug修复需要纳入产品的开发计划
3. 测试期间Bug修复与开发的平衡

提前规划运营期放出内容

1. 内容储备：运营期玩家消耗内容的速度，往往会超过产品开发内容的速度。
2. 开发周期：建议对于上线后放出的美术资源，最好能提前半年进行规划。

2.4.4 运营期产品计划的制定

运营期产品的计划制定主要有：日常周版本放出计划和资料片放出计划。

特点：

1. 放出内容直接面对玩家，有严格质量要求；
2. 重要的放出内容，如活动和资料片，有确定节点，产品无法接受延期带来的风险。

周版本测试放出流程

2.4.5 不同阶段计划制定总结

2.5 项目进度计划的执行

2.5.1 进度控制

团队约定

• 提升节点公信力
• 考虑各环依赖关系
• 加强审核
• 状态监控

2.5.2 趋势分析

客观分析：

• 进度表
• 燃尽图

主观感知

• 关注任务的连续性

2.5.3 采取行动

灵活调整

• 优先级调整

强制手段

• 交付节点提前
• 提前锁版本
• 加班

2.5.4 小结

计划制定之后，计划的执行过程依然需要PM时刻关注。PM可以通过流程手段加强团队对于计划执行的约束力，需要对计划的状态及时监控。客观的数据分析以及对团队的主观感知可以帮助PM及时发现计划执行中的风险。最后，在周版本的敏捷开发方式下，多从周版本和团队现状的关联入手，通过灵活调整和强制的手段及时调整计划的执行，是保证计划顺利完成的必要过程。