一文通晓游戏项目管理：从甘特图到版本管理（项目管理甘特图软件）

作者：Hao

️游戏策划→研发PM

8年从业经验，20 项目经历

游戏设计丨项目管理丨敏捷教练

知乎专栏丨小红书丨小宇宙

一、甘特图与里程碑规划

在游戏项目管理的过程中，随着团队人数的增加，这时需要引入一些工具提升团队工作效率，对齐目标，本文将介绍从如何使用Visio制作甘特图和里程碑规划图，帮助你高效管理项目。

Visio：WBS 及甘特图

我们使用的工具是 Visio。作为 Office 官方提供的图表工具，Visio 可以帮助我们轻松直观地创建甘特图、流程图、组织结构图等。

接下来，我们会从头开始，制作一份WBS 工作分解后的甘特图。

Step 1：选择并创建甘特图

在 Visio 中选择“新建”后，你就会看到各个类型的模板，你可以搜索或者直接选择甘特图。选择好样式之后，你就可以点击“创建”，获得模板。

创建完成后，你会得到一个标准的甘特图模板（以基本甘特图为例）。其中，横轴是分解的各个任务，纵轴是我们需要展示的属性。

Step 2：按照 WBS 工作分解，增 / 删任务

选中表区后，点击右键，就可以看到新建 / 删除任务的操作链接。这时，你需要逐条地录入 WBS 工作项。

Step 3：拆解子任务（升 / 降级）

对于小型项目来说，一个层级的任务就可以满足需求了。但对于比较复杂的项目来说，你还需要进行子任务的拆分。在 Visio 的甘特图中，你使用降级来完成把任务降为子任务的动作，用升级来完成把子任务转为任务的操作。

在具体操作时，选中任务之后（支持多选），点击右键，将其降级，这时，你选中的任务就会自动成为表格中上一级任务的子任务。子任务在格式上会有缩进，而主任务在右侧的日期区域会拥有标识。

Step 4：配置任务属性（如资源名称、持续时间等）

在完成任务拆解后，我们就可以开始配置任务属性了。

在制作甘特图时，我们希望重要的信息能够得到充分的体现。所以，除了基础的任务名称、开始时间、结束时间等，我们往往还会添加一些属性，比如资源名称、完成百分比、持续时间等。

另外，除了计划的时间，你还可以添加实际开始 / 结束 / 持续时间，来记录项目的完成情况。

在选中表区之后，可以点击右键，插入列并选择想要插入的列类型。Visio 也支持用户自定义的字段，还是比较灵活的。

Step 5：设置任务依赖关系

在项目规划中，我们需要厘清任务依赖关系，并借助链接任务功能，来完成在图上的展示。

在具体操作上时，你可以参考下表。在选中有依赖关系的两个任务之后，右键选择“链接任务”就可以了。如果你要取消依赖关系，可以点击“取消链接任务”，也可以在日期区域，直接选中任务间的连线并删除。

三个区域的配置完成后，我们的甘特图就比较完整地呈现出来了。其他几个甘特图模版的具体操作步骤也是类似的，只是最初的模板与样式有略微的不同，你可以根据自己的喜好进行挑选与调整。

到这里，一个甘特图就做好了：

Visio：里程碑规划

在任务规划期间，除了 WBS 工作分解及甘特图，我们还需要一个可以反映各个阶段时间节点的整体里程碑规划。

里程碑规划图的绘制也可以在 Visio 中轻松做到，同样也是 5 个步骤。

Step 1：选择并创建日程表

首先，你要搜索日程表模板，并且选择合适的日程表模板，然后就可以开始我们的里程碑制作了。

Visio 主要提供四种模板：日程表（空白画布提供日程表形状）、块状日程表、垂直块状日程表和展开的块状日程表（用于展示日程中某一部分的详细信息）。

Step 2：选择日程表形状，绘制时间线

需要注意的是，日程表的使用和甘特图有所区别，日程表主要是通过使用 Visio 工具中的日程表形状来完成展示。拖动下图中的形状到画布，并进行相应属性的配置。

除了模板中提供的时间线，我们还可以自行拖拽选择三种：圆柱形、线形和块状。

将图形拖拽到画布以后，会自动弹出配置日程表的选项。在这些选项中，你可以选择时间段与刻度，这时，基础的设置就完成了。

Step 3：设定里程碑时间

接下来，你需要将里程碑和间隔形状拖拽到画布上，进行日期的配置和形状的调整，以标记重要日期。

可选的里程碑形状有线形、菱形、针形、双三角形、X 形、三角形、圆形和正方形等，你可以根据自己的使用习惯与定义来进行使用。

当然，需要调整时，你可以右键配置里程碑的属性，更换里程碑类型。

Step 4：设定时间间隔

除了特殊的里程碑节点外，我们有时候还会标记一些重要的时间间隔。你可以选取左侧形状中的间隔，把它拖拽到时间线上，并进行间隔的属性设定，这时，就可以完成时间间隔的标注了。

Visio 提供的时间间隔类型有方括号间隔、花括号间隔和块状间隔。

Step 5：增加今日标记

在项目的进程中，今日标记也是一个非常实用的功能。你可以选择“自动描述位置”，在项目进度的查看中，也可以把它作为一个标签，来进行进度的观察与把控。

到这里，一个完整的里程碑规划图就做好了。

二、PMP认证攻略

要不要去考 PMP？PMP 认证的含金量怎么样？老实说，我一向认为，认证考级不是最终的目的，千万不要舍本逐末，为了证书去考试。让考级最大程度地帮助自己提升专业技能，才是最重要的。

为什么要考 PMP？

在决定投入精力考证之前，我们要先搞清楚，为什么要考 PMP？

PMP®认证近几年在国内的前沿行业很受欢迎。截至 2019 年 10 月，全球 PMP 有效认证人数为 99 万。其中，中国的 PMP 认证人数占总人数的三分之一。

PMI 的研究报告预测，2027 年，中国的项目管理职位空缺将达到 4600 万个。未来在中国，项目管理岗位将成为最热门的职业之一。

PMI 的中国代表曾经去过腾讯、网易等一线互联网公司访谈调研。他们想要了解，PMP 认证在中国推广了这么多年，它的价值到底在哪里。

调研小组从多个方面进行了探讨，最后得出的最重要的一条结论就是，PMP 认证的普及为我们创造了项目管理专业的共同语境。比如，我们会自然地讨论“根据当前的 WBS 工作分解，计划中的关键路径是什么”“风险管理计划要怎么做”，等等。

不要小看这个标准术语带来的好处，统一的共同语境为管理者正确地认知项目管理的作用、为项目运作建立良好的组织环境，都做了非常好的铺垫。

实际上，PMP 的认证过程也是我们学习并掌握一门项目管理的国际标准语言的过程，就好比是学会了另一门英语。

回到很多同学关心的问题上：“PMP 认证有用吗？值得考吗？”其实，这些问题背后的疑惑是：“考了这个证，会给我带来什么？升职加薪？还是增加面试和录用机会？”

我想说的是，对于想尝试转岗项目管理的同学来说，PMP 认证的确可以作为“敲门砖”，在一定程度上增加你获取专业面试的机会。但是，在大多数企业中，PMP 认证只是一个基础项，决定你是否被录取的，还是你的实战经验和实战水平。再进一步去看的话，还有建立在实战经验之上的、你对专业方法论的掌握和应用水平。

所以，学习中最怕的就是本末倒置。PMP 证书的含金量不在于证书本身，而是在这个准备考试的过程中你所付出的大量努力，以及你把理论框架和亲身实战融会贯通之后，你的自身能力得到的提升。

因此，我建议你在具备一定的实战经验之后再去系统化地学习这门课程。否则，对你来说，考这个证无异于超大浓度的理论灌输加知识记忆。如果大量的知识无法被消化和吸收，它们就会成为你的“知识障”，屏蔽你进行自我思考和尝试的动力。

如何有效备考 PMP？

如果你已经具备了实战经验，决定要考 PMP 了，就要提早了解一些 PMP 认证攻略，不打无准备之仗。

接下来，我会介绍一下备考 PMP 的几个关键步骤。

第一步：确定考试的目标时间

PMP 每年有 4 次考试，分别在 3 月、6 月、9 月和 12 月。确定要考之后，你要做的第一步就是安排合适的考试时间，给自己锚定一个目标点。

怎么确定什么是合适的时间阶段呢？

首先，你要确保至少完整地经历过两到三个项目周期，从启动、规划、执行、监控一直到收尾，自己有切身的实践体会。

其次，避开工作高峰期，选择自己相对空闲的季度。这是因为，要考 PMP 的话，你需要投入大量的时间和精力，至少要留出三个月的备考期。对于这一点，你要提前做好准备，因为它真的会占用你所有的业余时间。

必须要提醒你的是，你一定要提前确认 PMP 认证官方要求的报名条件。实际上，你并不一定需要有明确的项目经理岗位，只要有相应的项目经验，并且达到足够的时长积累，就可以报名了。

第二步：完成中英文报名

PMP 考试属于国际认证，报名需要两个步骤，先进行英文报名，后进行中文报名。确定好考试日期之后，你至少要提前 3 个月完成英文报名，提前 2 个月完成中文报名。

为什么我要把“报名”这条单独列出来呢？因为我想提醒你，英文申请全年都可以提交，没有时间限制，但是有 5——7 天的审核时间，审核成功后，账户有一年的有效期。如果英文申请没有通过，是不能完成中文报名的。所以，我建议你尽量在中文报名开始之前完成英文报名，以不耽误考试。

第三步：课程学习和备考

PMI 规定，报名考生需要具备 PMI 授权的培训机构所颁发的 35PDU 培训证书。一般来说，各类培训班的开班时间通常会至少提前三个月，分别在 12 月、3 月、6 月和 9 月。

总体来说，培训班通常分为线下和线上两种。线下培训的话，学习的互动感更强，建议你尽量挑选你所在城市的正规培训机构，线下组队形成学习小组，互相督促，一起学习，效果会更好。

时间受限的同学也可以选择线上培训的方式。我当时就是选择的线上培训，因为时间更灵活，随时可以补课，对于自律性好的同学来说，效果是一样的。

接下来，我们再聊聊备考 PMP 的学习材料，其实主要就是《PMBOK 指南》。这本书很经典，但即便我现在读起来，都感觉并不轻松。全书有 600 多页，而且大多是理论方法的描述说明，很容易让人望而生畏。

为了帮助你达到更好的学习效果，我结合我的经历，为你梳理、总结出了三步学习法。

1. 通读

对于十大知识领域五大过程组来说，不同阶段的各种方法浩如烟海，这第一步就好比是在知识的森林里，到处逛一圈，先做个路标。

第一次阅读时，你可以单纯地浏览一下，别求全部看懂，也不要追求速度。在读的过程中，建议你结合自己的项目经验，随时做批注，在书上画圈圈，把你感兴趣的内容或者暂时不理解的内容都先标记下来。

2. 精读

参加培训期间，你要根据老师的讲解和讲义，并结合自己的项目经验和问题，重新检视并深入理解每个概念，建立起对体系结构的清晰认知。

在这个阶段，我建议你跟着培训进度，逐个精读这本书的每个章节，特别要留心那些跟你在实际工作中差距比较大的部分，以及之前做好的路标。

要真正把培训老师当作你的资源，遇到问题多思考、抓住时机多提问，在弄懂方法原理的同时，更要去主动思考，你如何将这个学习引入自己的工作。只有这样去学的话，你才能把枯燥的考级过程变成一个很好的实战能力提升机会。

3. 记忆

在考试之前，你要按照老师划的重点和考点进行必要的记忆，并完成足量的刷题练习。一般来说，培训机构在考前都会为你准备包含记忆点及重点题型的小册子，内容每年会有一定的翻新。

这个阶段的重点是，多总结学习和做题过程中遇到的问题，回顾书上的常见考点，反复加深理解。对于那些重点、难点，你要刻意去背诵下来。在考试之前，你要对熟练掌握各个知识点，并达到融会贯通的效果。

以前，我自己在学习的过程中，往往会重理解、轻背诵，特别是对这种应试型的死记硬背，我一点也不“感冒”，不自觉地总会忽视。后来我发现，经典的背诵式学习也是一种科学的学习方法。

举个例子。小时候，我们总被要求背诵诗文，可我当时并不理解，甚至还有些抗拒。但是，那些反复背诵下来的诗就好像刻录进了我的深层意识。在我遇到某些情景时，它们就会自然地跑出来，时常让我觉得惊叹不已。从死记硬背到真正理解诗歌在表达什么，需要时间和阅历。

在 PMP 的学习中，有很多东西会超越你当前的经历。如果你实在无法理解，那就允许自己先囫囵吞枣，考前把它们先背下来，耐心地等待它们自己酝酿、发酵。总有一天，当你遇到合适的情景时，这些记忆就会跳出来，真正地在实战中帮助到你。

项目管理进阶之路

除了拿到 PMP 认证，有些同学还想在项目管理之路上继续进阶，甚至已经在考虑转型去做专业的项目经理了。这个时候，你需要考虑哪些因素呢？

首先，一旦涉及到职业选择，最关键的一点就是，尽可能不要让自己被很多外在的因素所左右。你要回归自己的内心，问问自己为什么要做项目管理。

不知道你是否有下面这两种心态。

心态一：

“Leader 安排我做项目管理，可能是看我能担事吧，就把越来越多的事，都往我这里塞。”

如果你当前处于这个阶段，我建议你先不要着急进阶，而是留些空间给自己，先想好，如果没有 Leader 的影响和要求，你自己个人的决定到底会是什么。

如果你发现自己的答案也是要做，那就调整心态，变被动为主动，为自己的职业道路负起责任；如果在尝试之后，你觉得自己确实不适合做项目管理，那就主动去和你的 Leader 沟通，把精力用在更适合你发挥专长的领域。这对公司来说，也是更好的选择。

心态二：

“程序员这个工种，可能没法干到老，我年纪也不小了，得提前为自己找条出路。”

主动为自己规划未来，这样的做法值得肯定。但是，这种心态最大的问题是，如果说程序员这个岗位不适合你一直干下去，那么，你如何确定项目经理就适合你呢？

实际上，想要确认这个职业与自己的匹配度，你需要注意的是，性格内向或外向并不是影响转型的决定性因素。外向者在信息获取上会更有优势，但内向者普遍拥有更加敏锐的感知能力。对成为项目经理而言，这两种性格各有优劣，不分伯仲。那么，到底该如何确认呢？

答案其实很简单，就是看这项工作是否能够激发你更大的热情。程序员和项目经理这两个职位的最大不同就在于，前者研究的是机器，后者研究的是人。如果说，程序员研究的是“一堆代码在一起，如何运行会更好”，那么项目经理研究的就是“一群人在一起共同做一件事，如何运作会更好”。

要想成为一名专业的项目经理，你需要对人有敏感度，并且要发自内心地认为研究人比研究代码更加有趣。这也是我自己虽然在这条路上遇到了很多挑战，但依然乐此不疲的原因。

除此之外，在拥有热情的前提下，经验背景的差异都是可以用时间弥补的。只要你坚持将学习与实战相结合，不断在实践中整合自己的经验，你就一定会不断精进。

总结

实战永远是我们不变的基调。只有你把 PMP 的认证过程当作对自己的一次系统化的理论充电，让实战经验与理论框架充分碰撞，你才能真正地吸取 PMP 给你带来的真正价值。

三、项目复盘

复盘原本是围棋术语，是指每次博弈结束之后，双方棋手把刚才的对局复演一遍，分析对局当中得失的关键，是提升自己棋力的好方法。其实，复盘是对思维的训练。通过复盘，当类似的局面再次出现在你面前的时候，你就能够快速地预测接下来的动态和走向，并且更好地应对。

而项目复盘会，可以说是项目团队有意识地向过去的行为经验学习的过程。在项目或里程碑完结之后，项目经理会组织召集项目成员，一起回顾一下，在项目的整个历程中，团队做对了哪些事，做错了哪些事，再来一次，如何做得更好，借此把项目行进过程中产生的集体智慧沉淀下来。

但是，现实情况经常是，项目一个接一个地做，忙上线、忙变更、忙返工，哪有时间坐下来复盘？又有多少复盘会，是为了复盘而复盘，逐渐地流于形式，成为了可有可无的摆设？除此之外，还有很多复盘会，成为了追责者的工具，除了锻炼出花样百出的各种甩锅技能之外，留下的只有“一地鸡毛”。

由此可见，要想做好项目复盘，并不是一件容易的事情。今天，我们来看一看，如何做好项目复盘，以及如何通过复盘去培养团队的持续改进能力。

复盘会的基调设定

我们都知道复盘很重要，但实际上，在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，其实更为重要。

我曾组织过一个复盘，叫作“坑爹功能”大搜罗。参与复盘的十多位同学，在现场写了好几页纸，满满当当地罗列着我们曾经做的、却没什么人用的功能。实际上，只有当大家真正摊开不太愿意面对的真相，去认真思考背后的深层原因时，我们才能共同进入真正的集体反思区。这样坦诚地直面问题的复盘，才能促发有意识的集体学习。

要想让参与者真正进入集体反思区，会前就要设定好开放的复盘基调。其实，我们每个人都可以在自己所处的环境中，看到各种各样的问题。如果复盘是出于追责，那么在会议刚开始时，大家就可以迅速地感受到，这样一来，每个人都会小心地避开自己的问题，转而去说别人的问题，这样的复盘就失去了意义。那么，如何设定开放的基调呢？

在会议刚开场，就要展示出自己的开放与坦诚，给复盘会奠定基调：这次复盘不是来挑问题的，而是为了找到问题的根源并改进的。在那次复盘会上，项目负责人特意讲了自己半年来的深刻反思，这就带动大家敞开心扉，直面问题。那次会上，大家自发地找到了在各个环节有效避免无用功能的方法。会议结束以后，这个部门还发起了一项“整风运动”，从增强用户意识的讲座，到用户调研方法的培训，再到激励与考核制度的挂钩，让复盘会反思的成果，逐渐渗透到了每个人的日常工作中。

复盘会的会前准备

除了设定基调，你还需要充分的会前准备。在复盘会之前，你要去梳理整个版本的历程，包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等，这些是客观数据的总结。同时，你还可以提前收集这个版本期间，团队满意度的问卷调查，为复盘会引入更多主观的输入。

其实，复盘会的基调设定，以及会前的准备工作，在开会之前，就很大程度地决定了复盘会的效果，你一定要特别留意。

了解了这些之后，我们就来看看复盘会的流程。

复盘会的流程

复盘会的流程，其实并不复杂。在实战中，我总结出了一套高效的复盘流程。

1. 现场回顾总结项目 / 里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录。
2. 与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。
3. 在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论。
4. 对大家总结出的好和不好的点，进行集体投票。
5. 由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案

我们来看看一次项目复盘会的投票结果：

无法促发行动的复盘，说得再好都是空谈！一开始开复盘会，大家会期待，解决的问题越多越好，但焦点增多之后，哪个都是蜻蜓点水地过一遍，哪个都没改彻底。下次再开会的时候，大家发现之前反馈的问题依然还在，那谁还有动力继续提问题呢？

所以，改进措施一定要落地，重点行动不要太多，一个就够了！如果每次复盘聚焦于改进项中的 Top 1，确保改进措施真正落地，长期坚持下去，就会促进持续的能力提升。同时，复盘的次数也不要太多，你并不需要每个版本、每个迭代都例行公事地去做一遍，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的。

打造团队持续改进能力

其实，项目复盘不只是一次会议，它更应该成为团队持续改进的推动力。那么，怎样才能让一次成功的复盘发展成为复盘文化，激发团队自主地持续精进呢？

实际上，想要让团队进入自发改进的正向循环，你需要更好地激发团队的主人翁意识，让团队成为复盘的主角，而不是你。最重要的是，你不仅要关注事，还要关注人。

另外，越是困难时期，越是塑造团队能力的大好机会。在团队遇到重大困难时，你也可以及时组织一场复盘会，深度关注和调整个人的状态。我就曾经试过让每个人画出自己进入这个项目组以后的状态变化曲线，跟大家分享自己的“高光时刻”和“至暗时刻”。在业务低落期，这样的复盘会会成为一个重要的转折点，让团队的力量得到深度聚合。

这些对人的关注，都会让复盘会超越问题解决的层面，在推进事的同时，促使团队自发地推进问题的解决，并把经验内化下来，从而不断提升团队的持续精进能力。

总结

好了，让我们对复盘做个小结。其实，当人们在说复盘时，往往会把焦点放在复盘会本身。但我却认为，决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节。

复盘会前，复盘基调的设定是否开放，复盘会前的各项准备是否充分，对于复盘会的效果非常关键。组织一个复盘会本身并不难，难的是在复盘会后，持续跟进这些反思，落地为切实的改进措施，让团队真正看到效果，从而打开团队持续改进的正向循环。

最后，我建议你认真地做好一次复盘，每次复盘后聚焦一个改进点。再提醒你一句：聚焦点别太多，一个就够了！

四、研发工作流

1.0——研发阶段

研发流程在游戏开发的过程中是非常重要的一环，游戏研发流程，可以简单拆解为三个子流程——内容生产工作流和美术需求工作流。

内容生产工作流

这里的内容生产工作流主要以玩法和功能产出为主。

游戏本身是一个个功能组成的产品，它之所以好玩，是因为有至少一个核心的玩法，但是一个玩法并不足以支撑起一款游戏，可以围绕玩法构建系统，多个系统结合起来，才能称之为游戏。

游戏和其他互联网产品一样，开发过程也是通过完成一个个功能需求而逐渐成型的，这里简单介绍单个功能需求的全生命周期：

功能需求生命周期流程图

PM参与其中的时间点标记了出来，可以看出一旦需求评审通过，PM就要参与到这个功能需求中去，直到ta被验收通过。

图中的每个环节虽然只有简单的几个字，背后都需要有一套完整的流程支撑，让每个团队成员知道在什么时候应该做什么事，最大地降低delay风险。

美术需求工作流

在功能开发的过程中，美术资源往往是没有全部到位的，这时可以使用尺寸相同（至少是接近）的白模代替。用来验证功能的完整性。

如果说单个需求主要是以程序视角出发的话，美术其实是在特定时间点加入进来的，往往玩法功能在设计的早期就需要美术协同参与，一方面是提供思路参考，另一方面也是提前思考概念设计方案，确保美术设计先于程序开发进行，在功能开发完成后替换成品美术资源，是比较合理的开发模型。通常美术需求的生命周期的流程图如下：

美术需求生命周期流程图

结合内容生产和美术需求，整理了一个简化版本的研发工作流：

2.0阶段——上线后

项目上线之后，通常会制定一系列更新计划，这时1.0模式的开发模型已经不能完全满足需求。

为了维护线上版本的稳定，通常只会在某个开发版本的功能全部测试通过后才会推至线上，所以此时需要至少两个开发分支——线上版本和开发版本。

最简双版本开发模型

上图是一个最简版双分支开发模型图，从图中可以看出，线上版本是最长那一条直线，在A点拉出一个资料片1的开发分支，在B点资料片1完成时合入线上版本。

需要注意的是在A→B阶段线上版本理论上是不更新的，期间如果有修复bug，则需要同步至资料片1的分支，确保在B点合入时不会出现冲突。资料片2阶段同理。

无论是研发中还是上线后，流程管理都是关键的一环，当中有很多坑，往往需要踩过一次之后才能有更深的感触，上面列出的都是最最简化版本的流程示意，仅仅是介绍全流程的概念。

更深的内容，需要在实际工作中逐渐摸索。

五、制定流程

PM在日常工作中最绕不开的话题，就是“流程”。

“做xxx的流程是什么样的？”、“怎么给xx提需求？”、“我提交了xxx之后还需要做什么吗？”…

其实大家工作一段时间之后，对常规工作流都会有一定的了解，你可能会通过观察或其他方式学习到公司的基本规则。但真正令人头疼的往往是基本规则之下的具体执行方式，因为其中可能有大量的模糊地带，这些模糊地带有时会造成一些跨部门间的矛盾。PM的重要职责之一就是消除这些模糊地带，让每个角色都明确知道自己的责任范围。

在上一篇文章中，我们讲了大致的研发工作流。今天我们尝试着把工作流中的每一步拆分得具体一些，明确每个角色在不同时间点应当承担的职责。

比如在内容生产工作流的第一步“需求设计”中，

看似简单的四个字，其实需要回答一系列问题：

• “它的设计目的是什么？”（如增加留存）
• “使用什么手段实现这个设计目的？”（如设计每日宝箱系统）
• “这个手段可以拆分成哪些子模块？”（如活跃可以提升宝箱奖励）
• “每个子模块的功能和作用是什么？”（简单的系统可能无需回答这个问题，比如上面举例的每日宝箱系统）
• “实现这些功能需要哪些角色支持？”（如需要UI设计领奖界面、需要前端实现xxx部分、后端实现xxx部分等）
• “如何验证功能上线后是否达到预期？”（如先灰度测试一部分用户，查看数据差异，没有灰度条件的也可以用埋点做）
• …

上述问题存在的意义其实是希望你真正想清楚自己的设计，最终达到自洽，自己信服的设计才有可能让别人信服，如果被程序/美术同学随便提几个问题就问住了，你的专业性会被怀疑。

但需求设计说白了是一件可以独立完成的任务，只需要一个文档模板就可以解答上面那些问题，更有挑战性的部分在于需要跨部门配合的任务中，接下来我们尝试以一个3D游戏的皮肤商城界面为例梳理其中可能涉及的流程。

假设皮肤商城界面开发需要四个模块：2D、3D、客户端和音效。

每个模块都有各自的开发流程，当需要跨部门协作时，PM需要统筹这几个部门的开发工作流，规划时间节点， 确保大家都在同一个轨道工作。

下图是一个可能的融合后跨部门开发流程图案例：

虽然流程图可以直观地看出各部门的工作顺序，但是每个节点工作的具体内容，则需要通过流程表格呈现，表格中需要明确各个时间节点，每个角色需要做什么事，结果是什么等等。可能是下图这样的表格：

UI流程表格

不过制定流程并不是越详细越好，找到适合自己团队的精细程度更重要。

制定流程本质上是为了明确每个角色的责任边界和解放PM的生产力，毕竟团队大了之后，可能会管不到每一个需求，白纸黑字的文档比口口相传的效率更高。

六、制定计划

里程碑与周版本

里程碑

游戏研发分为多个阶段，每个阶段都有比较重要的节点，这些节点被称之为“里程碑”。

在项目的MVP阶段，里程碑可能是关乎生死的MVP评审，通过就立项，不通过就砍掉。而在项目的运营期，里程碑可能是一个有一个的玩法版本和活动，为了拉新，为了促活，为了让游戏的生命周期得以不断延长。

因此，里程碑计划，是游戏生命周期里的一系列重要规划节点，是项目团队运作的一个个进度目标。

研发全流程

对于MVP阶段，里程碑计划需要着重打磨核心玩法，体现出游戏的特色。而对于α开发阶段，则应继续着力于提升核心玩法的完成度。而在β开发阶段，一般要开始玩法铺量、完善周边系统和增加新手引导。到了渠道测试和产品上架阶段时，需要开始考虑和发行、运营等部门的合作。

周版本

有了里程碑计划之后，在执行的过程中，还需要将里程碑计划细化到每一个周版本计划，即每周完成一个可以体验的无阻断游戏版本。

通常团队会将周中设置为版本日，这样能避免周末加班。到版本日时，当周版本的单子需要通过测试，才能实现我们定义的“可以体验的无阻断游戏版本”。

周版本流程

举一个里程碑计划转化成周版本计划的例子。

假设S项目需要在1月1日进行CE测试。

首先在研发侧，将本次测试的版本内容拆分为迭代功能和新增功能。获得这些信息需要和策划沟通，同时考虑开发人力，得出受到认可的版本内容。然后考虑合作部门的需求（如发行营销），最后增加一周组内体验的时间确保版本质量。

接着将里程碑范围拆分为一个个具体的任务，如里程碑范围其中之一为增加多人互动玩法，拆分后的任务为具体哪些玩法。如图所示

里程碑范围拆分

拆分出所有任务后，为每一个环节进行估时，这需要PM和每个负责制作的同学确认。

S项目总体计划密集，很多任务并行开发，PM在评估各时间节点后给出的大致开发排期为：

1. 策划写PRD 1——2周；
2. PRD评审、UX、UI设计等1周；
3. 程序开发2——3周；
4. 测试1周

接下来需要观察每个环节的开始时间。特别是需要留给策划足够的时间写PRD，保证后续任务能顺利开始。

个人的高效不一定能带来团队的产出高效。PM在细化周版本计划的时候，不应局限在当周每个团队成员工作量是否饱和。而应该从里程碑计划目标出发，以能否达成最终目的为前提考虑问题。

制定开发计划

我们已经知道游戏研发有不同的阶段，虽然不同阶段的项目有很大的差异性，但制定计划的思路是一致的。包括：整理需求、拆分需求、排优先级、估工时、人员分工、确认上下游排期等。下面我们就以MVP阶段为例介绍制定开发计划的方法。

MVP阶段的特点是充满了不确定性和时间比较紧。不确定性是指需求可能频繁变更，技术实现方式也是一样。此外还有其他例如团队磨合不够和人力不足等。在这种人力不足、时间紧且需求未确定的情况下，做计划时需要有一个明确的最小需求范围。

比如，某个非对称竞技玩法游戏的MVP，最小需求范围是2个职业和对应的技能，1个场景，3种场景交互道具。

确定最小需求范围后，联系对应的美术、开发、QA等同学预估工作量，如果发现工作量超出可承受范围，则需要缩减范围或更改制作方式。在这个阶段可以多考虑使用公司美术库内风格接近的资源。

针对需求频繁变更而导致工期难以预估的情况，可以考虑将版本周期从通常的周版本缩减为双日版本或日版本。缩减版本周期能让版本内的需求进一步明确，有利于进行需求拆分和预估工作量。

日版本计划图

虽然MVP阶段需求和明确对标的产品还不确定，但是评审的时间是确定的，因此我们通过倒推的方法得到开发迭代的时间。在评审之前，最好提前一周停止新功能开发，用于回归测试和修bug，防止最后阶段出现严重阻断bug影响评审。

在游戏研发过程中，主要采用渐进明细的敏捷开发方式，根据需求灵活制定计划是关键。

七、范围管理

游戏每次版本更新时，通常会对外发布一份版本更新文档，文档里描述了本次更新的变化，比如新增了某个玩法、修改了某个怪物的数值等。这一份文档的全部内容，就是这个版本所包含的“范围”。

项目范围是指为了交付产品必须完成的工作集合，包括具体的业务需求（比如游戏中有哪些功能玩法，包含哪些美术表现等）和交付承诺（比如交付时间，游戏完成度等）。

对范围的管理通常分为四步来做，如图所示：

范围管理

分析范围

分析范围是指确定项目要做什么，不要做什么，确认之后开始拆分需求，把所有想做的内容拆成一个个独立可落地的需求，然后进行优先级排序。每个需求都应该有具体的交付标准，用来定义这个需求“做完了”，比如游戏帧率达到xx帧、支持最大同屏人数xx人、特效数量xx个等。

确认需求之后，策划开始整理需求文档，需求文档的作用是对需求进行精准定义，其中部分内容需要和上下游环节的干系人讨论决定。一份合格的需求文档，至少需要回答这五个问题：

• 需求的使用场景：描述需求的具体使用场景，能够帮助相关方了解需求的背景和特点。如项目需要一批美术资源验证某个玩法是否可行，这些场景最终不会被使用，那么美术资源完成度过高反而浪费成本。
• 需求的功能描述：描述需求想要实现的效果。
• 需求的边界条件：特殊情况的说明，如弱网、顶号等。
• 需求涉及的部门：需求需要哪些部分支持，如UI、动作、特效等。
• 需求优先级

可以根据以下几点协助判断优先级。

• 投产比：低投入高产出的需求优先级更高
• 需求来源：来自高层管理者的需求需要重点考虑
• 需求依赖关系：主要考虑需求依赖的上下游能否提供足够的支持确保需求实现

定义范围

需求文档整理好后，接下来会通过需求宣讲会的形式来定义范围，参与者在宣讲会上对需求文档提出各自的疑问。宣讲会的目的是让所有参与者对需求的理解达成一致，最终策划将共识统一整理到需求文档中，产出最终版需求文档。

定义范围的核心是对需求进行拆解，目的是更准确的估算工作量。

常用的方式是按照需求环节拆分。以角色需求为例，可以拆分为概念原画、模型、动作等，如果还是难以估算工作量，就对其进一步拆分，模型拆出白模、高模等中间环节，直到能比较准确的估算工作量为止。

角色需求拆分

拆分需求时需要注意：

1. 每一个拆出来的需求节点，都要有明确的责任人；
2. 拆分的颗粒度根据需求具体情况决定，对于复杂、跨部门多的需求，需要拆的更细；
3. 渐进明细，对于即将要做的需求应该拆的更细一些，对于未来的需求，没有必要一上来就把它拆得很细；
4. 拆完检查确保没有遗漏。

控制范围

项目开发的过程中，不可避免的会遇到各种各样的变更情况，控制范围就是管理这些变更，确保所有变更都经过同意的变更流程，防止范围蔓延。

• 判断需求是否应该变更时，除了关注需求本身，也要关注与之相关联需求的情况，综合判断对项目的影响程度，再得出结论。
• 当需求发生变更时，也要给对应需求的干系人同步需求变更的原因和后续计划。
• 已确认的变更，对应的文档也应该更新。

验收范围

验收范围就是检查已完成的成果，目的是确保项目暗示保质保量完成，并获得重要干系人验收确认。

验收形式通常是周版本、sprint review、月版本等。

验收过程可以是展示资源、视频演示、真机体验等，过程中记录干系人的建议，验收会后，项目组成员统一评估哪些建议需要纳入后续版本计划中。

八、数据分析

在项目的整个生命周期中，风险无处不在，PM的重要职责之一就是对风险进行监控和处理，而数据分析就是一种项目监控的方式，它能帮助PM及时发现和应对风险。在和项目干系人沟通时，数据分析能帮助PM展示客观准确的项目信息，提升沟通效率。

在PM的日常数据分析中，主要关注项目管理四要素：范围、时间、成本和质量，这四者共同组成了项目管理铁三角

项目管理铁三角

具体可以分为以下几个方面：

1. 质量：如代码质量、包体质量等

这里的质量是指QA负责的代码包体质量，监控质量是通过尽可能暴露游戏中的潜在bug并修复，以此提升游戏的整体质量，因此单纯追求bug数量少是不可取的，因为bug少可能是因为缺陷没有被发现。

（ps.如果一段时间内质量标准相同且bug发现率一致，可以用bug数量多少代表整体质量好坏）

2. 范围：如开发的进度等

可以用分角色分阶段的统计方式来记录准确的进度，也可以按功能模块记录整体进展是否符合预期，这两者的颗粒度不同，实际运用时按需实施。

3. 时间：如开发的速率等

记录方式和楼上的范围一样，主要关注点在于团队开发进度是否按计划完成，团队整体效率是否正常。

4. 成本：如人力分布情况等

在人力资源中，PM需要对现有和未来视野内可能出现的人力风险进行及时的跟进和处理，主要关注：

• 目前总体人力是否足够完成里程碑目标
• 团队成员比例是否存在瓶颈，如某个角色人数过少导致上下游都得等的情况

接下来通过一些案例应用日常工作中记录的数据。

案例1 项目开发到了一半，加班严重，团队士气低落，每天都有人请病假或事假，你是PM，希望和团队leader沟通对应的解决方案，应该如何沟通？

回答1：“最近大家连续加班，士气低落，效率也不高，要不要考虑取消周日的加班计划？”

回答2：“根据最近的开发数据显示，虽然需求都进了周版本，但是和以往同期的版本相比，严重阻断bug增多，算下来，加班的时间基本都投入到修bug上了，整体进度和以前差不多，是否考虑减少加班，让团队调整好状态以提高效率，回到以前的状态？”

回答1的结论笼统和主观，缺乏说服力。

回答2中PM通过整理现有开发数据发现加班无法提高团队产能，向团队leader展示客观数据，提出适当减少加班调整团队状态，会更容易达到沟通的目的。

在和团队leader沟通类似问题时，需要站在对方立场思考“团队为什么要加班？团队leader的需求是什么？” 加班是为了加快产品进度，但是我们通过数据统计发现，加班带来的绝对效率并没有增加，甚至降低了，也就证明了目前通过加班无法实现预期。而且加班还会带来团队的负面情绪，对团队稳定性产生影响。

案例2 游戏下个月就要开启测试了，但是剩余的需求和bug数量还不少，团队leader比较关注这次测试，向你确认进度，你该如何回答？

回答1：“（我觉得）做不完，一直有临时需求加塞，原计划上周完成的单子也有delay，这次测试有风险。”

回答2：“从这次测试比较重要的两个模块：角色和副本的进度来看，开发预估还需要2个月才能全部完成，赶不上这次测试规划的时间节点，风险很大。”

回答3：“根据我们的测试计划，想要按时测试，需要提前2周给到QA进行测试，也就是说只剩2周的功能开发时间。从目前记录的开发数据来看，我们每周能完成80人天的需求，每周的临时需求大概是20人天。如果想要在2周后提交QA测试，需要将剩余需求控制在140——160人天。现在剩余需求是260人天，需要至少削减100人天的需求或至少延期2周。”

回答1的问题在于：

1. 结论偏主观，难以令人信服
2. 只提出了问题，但没有给相应的解决方案，PM应该站在“快速解决问题”的角度去处理工作，因此“问题”和“解决方案”往往是成对出现的

回答2比较接近日常工作中的实际场景，通过计算关键路径来估算项目里程碑的最后完成时间，但是在人力紧张时，可能会出现没有充分利用所有人力的情况。

回答3根据团队积累的历史数据，充分估算了所有人力情况，给出了具体的人力数据，还针对现状给出了对应的解决方案。是数据分析应用在项目管理中的最佳实践。

九、风险管理

“项目风险是一种不确定的事件或条件，一旦发生，就会对一个或多个项目目标的范围、进度、成本和质量造成影响。项目风险可能有一种或多种起因，一旦发生就可能造成一项或多项影响。我们认为项目风险源于任何项目中都存在不确定性。” ——PMBOK

风险管理是在这些不确定性事件发生或造成影响之前，对其进行识别、控制和处理的过程。对风险的管理贯穿整个项目生命周期中，在项目管理的各个模块都能看见风险管理的影子，对风险管理的好坏直接决定着项目能否平稳运转。

识别风险

风险是影响项目目标最终实现的各种不确定性因素。

对于已经发生或者一定会发生的，对实现项目目标有影响的事件，是问题而不是风险。可以通过发生概率和影响大小建议一个简单的风险识别图。

风险识别图

风险分为正面和负面的，正面的风险称为机会，负面的风险称为威胁。

我们遇到的风险，大部分情况下都是负面的。我们讨论的“风险管理”主要也是针对负面的风险。

案例1：

下一次上线计划定在9月30日，希望赶在十一之前完成，让项目组好好放个假。版本排期定下来后，所有人都对目前的排期表示认可，看起来非常顺利，可是真的是这样吗？

在拉会讨论各个重要feature的落地方案时，发现了好几个潜在风险：

某个重要功能涉及三部门联调，最终实现需要依赖A部门提供底层能力支持，B部门设计方案和实现功能，C部门负责接入并最终呈现给用户。

在聊详细方案时，发现目前的排期只考虑了A部门和B部门的开发时间，没有考虑C部门接入的时间。

同时，由于此功能在其他项目没有完整实现过，程序同学给的排期也是非常乐观的评估，无法保证按时完成。

发行同学已经订好了宣传物料的时间计划，但是美术同学还不知道提交资源的ddl和需要哪些物料以及对应的尺寸和格式要求。

看似没问题的计划下藏了这么多影响最终交付的“雷区”。

评估风险

识别到风险之后，需要进一步对风险进行评估，判断影响范围，通常把风险从上至下分为四种，分别是：企业级风险、业务级风险、部门级风险、岗位风险。

风险层级

上层风险发生时，往往伴随着下层风险。当下层风险没有得到妥善处理时，也可能引发风险升级，造成上层风险。

判断风险所处的层级后，需要调动对应层级的力量去推动解决。通常PM日常工作中遇到的风险都是部门级和岗位级的，可以通过建立标准流程规范、调整人员安排等一系列措施应对风险。

如果是业务级或企业级的风险，需要第一时间将信息传达给对应层级的管理层。

应对风险

通常有四种方式应对风险，规避、接受、减轻和转移。

规避：指改变项目计划，以排除风险。比如换一种实现方式，调整项目范围等。

接受：指接受风险和结果。比如核心人员可能出现离职而影响项目进展，可以主动接受并储备后备力量。

减轻：指设法把风险的后果减轻至可接受的范围内。比如游戏质量不稳定，bug多，可以通过每日测试前一天的版本，增加全员测试等方式暴露问题，集中修复。

转移：指设法将风险的后果连同应对的责任转移到第三方。比如项目合作的外包QA，可能在测试过程中毁约而影响项目进度。这时可以通过与外包代理公司合作，将潜在风险转移到外包代理公司。

在应对风险之前，首先对其进行拆分，根据具体风险事件，找到风险的原因，整理风险的后果；然后制定解决方案和后续跟进人。

风险应对

案例2：

日常工作中的非固定假期是容易忽视的风险。

公司每年下半年都会组织团建旅游，今年的时间安排在10月下旬，但是项目11月中旬会发布一个重要的大版本，加上十一假期的影响，团建旅游可能会对项目计划和进度带来风险。

为了应对版本发布，采取了一系列措施：

• 统计能参与旅游的人员名单（有加入时间要求）
• 团队规模很大的情况下，分部门分批参与旅游，确保关键岗位有人能响应问题（没有stand by的岗位需要带电脑旅游）
• 提前锁资源，为留下的同事提供稳定的工作环境
• 根据实际进度组织统一加班

最终避免了旅游带来的风险，确保版本按时发布。

不同职能对风险的评估角度不同，从某个视角看来不是问题，换一个视角可能就有较高的风险。大家可能更关注自己手上的工作，而没有关注整个任务的风险。PM作为有全局视角的角色，需要收集各个职能对风险的判断并进行整合汇总，综合考虑各个因素，从专业角度给出整体的项目管理判断。

最后，在项目管理中有两个不变的金科玉律：

• 所有计划都留好缓冲
• 永远都有Plan B

十、质量管理

质量管理是指建立质量标准，并通过策划、测试和改进等一系列动作实现的全部活动。

在游戏项目中，质量可以分为两部分

• 设计层面：游戏是否好玩，足够有吸引力让玩家持续玩下去
• 研发层面：游戏的bug数量如何，是否有影响游戏运行的严重bug存在

好玩且bug少的游戏才是一款好产品。下面也会以这两部分为例说明pm如何参与到质量管理的过程中去。

设计层面

“这游戏的画面很好，打击感还不错，运行起来也挺流畅，但是主线结束后的日常还是传统的一条龙模式，玩了两天就不想继续玩了，感觉就是什么都好，就是不好玩！“

——taptap中某游戏的玩家评论

对于一款游戏产品来说，“不好玩”就是原罪，没有人需要一个各方面都很完美但是不好玩的游戏。

质量管理在这个阶段承担两个职责，第一是让设计通过充分的评审，第二是确保最终做出来的内容和设计一致。

纸面评审

关于第一点，策划在设计新玩法时会有一系列天马行空的想法。在正式投入资源制作之前，需要有一套评审的规则，让其他策划、策划主管共同参与，对这些想法的可玩性、可操作性做充分评估，主要目的有三个：

1. 策划主管对方向进行把控
2. 设计优缺点头脑风暴
3. 熟悉自己和他人的开发内容

纸面评审

demo评审

纸面评审通过后，会留一段时间（1——4周）使用临时资源做demo，demo评审会是指策划主管或高层针对demo的表现决定是否进入后续开发环节。

demo评审

研发层面

研发层面的验收贯穿整个游戏制作的生命周期中，也是开发者对于自己制作内容质量和范围的基本保证。

和设计层面的验收相比，研发层面的验收更偏重于对游戏内每一个实现细节的打磨，在日常工作中，具体的执行方式通常是开发自测&策划验收、辅助性验收和Bug Bash。

开发自测&策划验收

1、前后端开发完没有联调，直接甩给测试，开始测试后，测试同学发现某个重点功能无法走通，开发回去修复；

2、提交了代码后，测试同学走主流程时发现另一个模块的交互出了问题，开发继续回去修复；

3、测了一半时，发现本次需求的一个重要的功能未能正确实现，需要重新设计，开发完需要全部重新回归测试。

——关于缺少开发自测的经典场景

开发自测是指在编码完成后，开发同学通过在本地或者开发环境进行接口调试、前后端联调、全流程验证等，确认本次新增功能都已实现，以及对原来主要功能没有影响，确保游戏流程能完整跑通。

开发自测在很大程度上决定了产品的质量和项目的进度，如果不重视自测甚至没有自测，测试同学将花费宝贵的测试时间进行主流程确认，开发来回提交代码，严重影响项目研发进度。

开发自测完成后，策划根据功能需求单逐个验收内容，确认制作内容覆盖所有需求点。

开发自测&策划验收

有同学可能会好奇为什么不是测试同学直接进行测试的效率会更高呢，专业的人做专业的事不是更好吗？

简单来说，预防胜于检查。原因涉及到产品质量成本的概念，产品质量成本通常分为两类：一致性成本和非一致性成本。

一致性成本是指为了预防质量问题付出的成本，如提交测试前的策划验收。

非一致性成本是指为了修复质量问题付出的成本，如修复测试过程中发现的bug。

辅助验收

辅助验收是指其他职能辅助策划进行需求质量、范围的验收，输出可供参考的信息。

需要进行辅助验收的原因是策划不一定具有全面的专业知识，需要依赖更专业的职能对于实现的需求给出其范围内的专业意见，协助策划共同验收需求的效果质量。辅助职能包含UE、UI、美术效果跑查等。

辅助验收

Bug Bash

Bug Bash是指所有团队成员在版本发布前，一起参与体验游戏找bug的过程，是QA的补充。

1. 团队集体试用，发现需求
2. 厘清发布前还有什么地方做的不够好
3. 游戏化激励团队（找bug竞赛）

Bug Bash的时间点需要格外关注，太早——系统不稳定，太晚——来不及修复，根据以往经验，在QA完成两轮测试之后进行Bug Bash比较合适。

Bug Bash

以上是关于质量管理概念的简单介绍，具体执行环节可以根据各个项目团队的实际情况探索合适的落地方案。

质量管理的核心在于 过程和结果的监控，强化评审和验收环节，辅助全民参与测试，尽可能打造出让团队成员满意的质量。

但是也要意识到，质量管理能尽可能规避风险，但不能百分百避免风险。因此PM同样要关注补救的方法，例如热更流程，这里就不详细描述了——

十一、版本管理

游戏版本管理在PM的日常工作中有着举足轻重的地位，开发者通过一个个游戏版本将内容带给玩家，本文将通过一个极简的版本模型介绍游戏版本管理的基本步骤。

版本管理，是对软件开发过程中特定功能的集合或特定代码构建结果进行管理，主要包括版本编号的管理、版本的前期规划、版本开发时的需求变更应对以及版本发布上线后的总结回顾等内容。

版本开发流程可以根据版本状态拆分为三个阶段，分别是“准备阶段”、“开发阶段”和“运营阶段”，我们再将这三个阶段拆分为一个个相对具体的节点，大致如下图

准备阶段

计划阶段的核心是确定版本的目标和发布策略，再根据实际情况（可能存在的各种限制）将目标和策略拆分为一个个具体的需求。

版本规划

常见的游戏版本目标大致分为四类：拉新、留存、促活和增收。

在实际场景中，大家自然是全都想要，但由于开发资源有限，一个版本能承载的需求量是有上限的，这时需要根据游戏当前的数据情况，制定符合长线发展的版本目标。因此通常会从中选择一到两个作为主要的版本目标，投入大部分开发带宽。

发布策略是指游戏版本开发完成后，投放给玩家的方式。通常会先在测试服发布，验证数值和暴露Bug，一段时间后再全量发布，这样做能降低风险，就算版本有严重恶性Bug，影响范围也相对可控。

如《英雄联盟》会在新英雄正式放出之前，先在测试服验证新英雄的表现；《梦幻西游》会动态挑选线上服务器作为新功能/玩法的试点，收集一线玩家的反馈并作出相应调整。

版本号也是版本规划中必不可少的一环，此时可以考虑使用业界通用的规范，关于版本号的使用说明网上已有大量介绍，可根据项目实际情况自行选择，这里贴一篇搜索引擎排名靠前的文章链接。

软件版本命名规则

cloud.tencent.com/developer/article/1834484

确认版本需求范围

版本规划完成之后，接下来需要探索实现目标路径。

当版本目标是提升留存时，有很多种方式看起来都能提升留存，比如增加游戏深度、增加运营活动、改善核心玩法体验、丰富外围系统等。此时团队需要选择具体的路径。

假设《代号C》是一款武侠游戏，新版本希望提升长线留存，团队认为需要继续打磨核心玩法，并将其和竞品做出明显的差异化，以此为卖点留住玩家。

对此，团队将“打磨核心玩法”拆分成了更具体的任务：

• 增加门派特色——门派专属技能
• 丰富战斗策略——添加更多增益减益类型
• 完善基础战斗体验——优化战斗表现和打击感
• …

通过不断拆分，最终将抽象的目标变为可落地的需求点。

开发阶段

在准备阶段产出了一批需求，我们将在开发阶段将它们逐一实现。

版本资源生产

版本资源可以分为文档资源和美术资源。

比较理想的情况是策划提前两个版本完成文档编写，美术提前一个版本完成美术资源制作，这样程序在开工时能拿到确定的方案和正式美术资源，能有效降低风险。

如下图所示，1.2版本的策划案是在1.0版本功能开发期间准备完成的。

一个理想情况

然而往往由于种种现实因素，无法实现上述这种理想情况。

因为游戏市场竞争激烈且外部环境变化较快，几个月前准备的策划案可能已经不适合当下的市场环境了，需要做出迭代或者推翻重新设计。如果是下游还没开工的策划案倒还好，影响相对有限，如果已经有美术/程序开始开发，则需要通过变更控制来确保整体风险可控。

变更控制流程值得单独写一篇文章，先挖个坑。

在策划案准备完成后，可以组织资源宣讲会，此时策划会和参与需求制作的美术描述需求详情。美术评估&拆解实现需求所需的素材清单。需求对清楚之后就可以排期制作了。

版本功能开发

到了这一步，程序将开始实现策划案里的功能。

这时PM需要对开发进度做整体把控，通过晨会、周会等各种正式&非正式渠道获得信息，了解开发过程中是否出现了阻塞或其他特殊情况（如请假、需求变更等），及时暴露风险并制定相应的后处理方案。

版本验收&测试

这里的版本验收&测试是指开发封版后的QA统一回归测试。

每个版本功能点的验收&测试应该是贯穿开发过程中始终需要策划/美术/程序密切配合的，并不是程序自己做完觉得没问题就结束了，而是整个功能点涉及的制作者都对效果验收通过才算结束，其中策划重点验收功能和各种边界条件，美术重点验收功能的表现效果。这里也非常考验团队配合，往往需要一段时间的合作才能把这一步跑顺。PM可以根据排期设置一些节点，提醒制作者参与到过程验收中来。同时也鼓励美术/程序将开发中的过程版本展示到开发群中，让大家了解功能目前的进展。

关于测试通过的标准，通常会有一些定量的指标，功能方面会有各类Bug率的指标，如

A类Bug=0，B类Bug<10等

性能方面也会有对应的要求，如

低端机帧率达到20

版本发布

当版本终于通过测试之后，这时可以进行版本发布的流程。过程中会有一些分支切换/合并的动作，完成后QA去线上服白名单跑回归，回归通过后版本就正式见玩家了。

版本发布流程还是比较复杂的，上面只是简单概括了下大致流程，PM需要提前和相关同事确认好发版过程中各种突发情况的处理方案，确保风险可控。

运营阶段

版本发布后，我们将能收到真实玩家的反馈，此时PM需要关注反馈问题跟踪和版本复盘。

反馈问题跟踪

玩家在进行游戏的过程中会通过客服或社区反馈遇到的问题；线上日志也会暴露一些测试环境很难发现的问题。

PM此时可以定期组织团队，对收集到的问题/反馈进行优先级排序，逐一处理。对于一些影响严重的问题，如大量crash、充值失败等，在收到问题的第一时间就需要采取行动，在最短时间内解决问题。

这里牵扯到线上反馈问题的分级处理，有机会开新坑。

版本复盘

复盘的重要性不言而喻，可以回顾下第三章-项目复盘。

至此，一个游戏版本的完整闭环就结束了。

和之前一样，上面描述的版本管理模式仅仅是一个极简模型，真实的项目可能比这个复杂得多，但整体思路框架是不变的，还是需要通过多实践掌握版本管理的精髓。

十二、过程管理

往往我们在做计划的时候，明明已经想的比较周全了，可当版本真正开始做之后会发现，很多事情没有那么简单。

这次我们以一个案例开场：（已做脱敏）

项目A是一个射击RPG游戏，计划在年底推出一部大的资料片，对游戏中的枪械体验做升级，希望与场景形成联动，在实战中衍生出更多策略选择，丰富玩家体验。

在版本规划时，相关研发同学对功能涉及的模块进行了拆分和估时，起初判断工作量虽然比较大，但是难度不高，努努力可以在版本节点之前交付。

但是真正开工之后却发现这个需求涉及的范围没有想象中简单，牵扯面很大，底层框架也比较老，盘根错节不好下手，目前看来工作量至少是原来的两倍，甚至更多！

这个资料片是年底版本最重要的卖点，如果延期，所有人的指标都完不成。。。

在项目管理的日常工作中，心态绝对是最需要修炼的技能之一。即使规划时做好了“万全”的准备，在项目实施的过程中，依然会遇到各种意料之外的情况，甚至是影响项目生死的突发事件，这时需要通过及时有效的沟通推进问题解决。

之前接触过的很多负责任的同事，当ta们在执行中遇到困难，往往习惯于自己消化，不到最后一刻绝不会暴露问题寻求帮助。这时的进度通常已经和预期偏差很大了。

承认自己遇到了问题需要帮助，其实是件非常困难的事情。毕竟，很多人都有“想要把事情做好，让老板有个好印象”的心态。

但是，作为项目管理人员，当事情已经超出了你的可控范围时，我们首先要做的，是第一时间直面问题，呈现事实和反馈遇到的困难。这种真实坦诚的态度，对于整个项目而言，反而是最有利的。

今天我们就来梳理一下项目管理日常做汇报的几个方法。

常规工作汇报

一份常见的项目周报可能长这样：

一个极简的版本

周报里记录了一些任务，但是项目整体的进展状态、风险情况等信息，周报里都没有体现，而这两者恰恰是周报最应该体现的内容。为了更直观地展示项目状态，我们可以尝试引入天气图标，把项目分成几个等级。

使用天气图标分级

加入天气图标展示项目整体进展，再结合风险分析，可以得出一份更清晰的周报：

需要注意控制下一份周报的长度，阅读量控制在5分钟以内，因此切忌事无巨细地罗列任务，关注重点即可。

紧急问题汇报

当项目遇到了影响范围很大的突发事件或者风险时，如上面说到的严重延期、线上事故、大客户投诉等，项目经理需要向全组或主要干系人第一时间同步项目的变化信息，以此协调应对方案。

对于汇报形式可以不用拘泥于模板，毕竟事出突然，言简意赅地传递信息并组织应对才是关键。一份紧急汇报可以包含几个基本元素：问题描述、影响结果、初步分析、处理方案、需要的支持。

以文章开头的例子来说，一份紧急汇报可以是这样的：

问题描述：资料片核心功能重大延期风险；

影响结果：该功能处在版本的关键路径上，可能会造成版本延期1个月；

初步分析：资料片中的枪械升级功能，部分代码和底层框架混在一起，需要重构，且最初负责该功能的开发已经离职。之前对这部分功能的拆分&评估不充分，改动风险较高，可能会影响局内战斗的稳定性，具体还需要详细评估；

处理方案：主程参与进行技术评估工作，本周四之前给出细化的拆分排期；主策介入评估方案调整的可行性，本周内给出结论；

需要的支持：版本结束后的大团建。

通过一份紧急汇报，制作人/老板会第一时间了解团队正在面临的问题和可能的后果，同事也会知道即将采取什么方案去处理。如果有条件，第一时间面对面沟通的效果会更好。

项目开发过程中的各种紧急情况，其实很考验项目经理的素养。项目经理自身不能着急，需要直面分体，在紧急时刻勇于承担责任，协助决策者选择更好的应对方式。

数据汇报

项目经理很容易陷入细节地工作中，今天催版本进度，明天推需求规划，可是却发现大家不配合你。事实上，预期每天挨个盯梢做一个监工，不如使用工具，把项目的状态展示在所有人面前。

在版本的关键阶段，定时在大群同步版本研发进展，慢慢就会发现，问题被处理的速度加快了。

Bug

开发进展

出了手动制作的开发进度图之外，Jira本身也提供了一些常见的项目仪表盘，用于展示项目进展和每位团队成员的工作安排情况，快速定位研发过程中的瓶颈。

项目仪表盘

工具千千万，适合最重要。在使用工具之前，项目经理需要结合当前团队需要重点改进的事项，选择合适的工具，将信息“透明”给大家。

项目进展汇报是项目经理面向所有干系人的重要沟通平台，使用得好则可以成为一个有力的杠杆，引用一位前辈的话：想要改善什么，就去透明什么！