#045 Netease Game Dev Series: Project Management - THE BASICS OF PROJECT MANAGEMENT

01 产品PM的日常

1.1 计划制定

以Demo阶段作为例子：手游整个研发过程的缩影，时间短，人力有限，压力大。

计划就是要找出一条路，靠它来引领我们，在有限资源和沉重压力下，一步步把产品做出来。

1.1.1 可执行

计划首先要做到落地，即可执行。

怎样算落地：

• 每一项内容的每一个工序都有人负责
• 知道每项内容在哪个版本可以完成

1.1.2 渐进明细

渐进明细：做计划的时候，重点关注眼前计划的细化和落地，同时，要推动长远的规划，在远处立好灯塔。

只针对最近的里程碑做详细的计划。一般一到一个半月，4到6个周版本的时间。

对于最近的里程碑，为每一项任务，确定具体负责的策划人。在这个基础上，再进一步细化到具体的设计、开发和资源制作等各环节工作，对应到负责这些工作的策划、UI、程序、美术、QA等同学。

1.1.3 可衡量

计划本身要具有可衡量性：这样才能知道是否偏离方向，是否能及时完成。

要明确工作怎样才算完成，要求要细节、具体。

1.2 有效沟通五要素

1. 要明确沟通目的：沟通前，需要清楚自己的目标是什么，是已达成共识需要对方最后确认，还是需要就相关问题和对方展开讨论？
2. 信息表达要精准：避免理解偏差，避免误会。
3. 站在对方角度：PM要接触不同职能不同部门的同学，大家的思维模式、做事方法、看问题的立场，都各不相同，所以，PM要多换位思考，三思而行，先想想沟通的初衷是什么，我们这么说，对方会有什么感受。
4. 有效倾听：很多时候沟通是“你说我听”或者“我说你听”，没有中间反馈，这样容易误解对方的意思。反馈可以是正面的，也可以是建设性的。正面的反馈会使沟通氛围更加融洽，建设性的反馈可以引起对方思考，提高沟通质量。
5. 适时切换更高效的方式：不行就人肉解决。

1.3 风险识别

1.3.1 关于风险的第六感

对风险的第六感可以认为是一种敏感度。当觉得有什么东西隐隐不对劲，或者心里没底的时候，抓住这种不确定性，进一步探究分析，很可能就识别了一个风险。

1.3.2 风险识别的重要性

风险识别，不像其他工作内容，有比较明确的完成标准，可以评估具体工作量，也有对应期限，所以往往容易被忽略。

发现一个风险，通常代表可以少踩一个坑，是体现和量化PM价值的非常重要的方面。对付风险的第一步，就是要先把风险找出来。在给自己做时间规划的时候，要划出一块时间，用来思考、感知和识别风险，哪怕每周只花5分钟。作为PM，需要保有一颗寻找风险的心。

1.3.3 风险识别关注四个方面

依赖关系

• 外部依赖：指影响项目的外部环境因素，比如获得游戏版号依赖版署审核通过，与美术外包、计费、网站这些跨公司跨部门合作相关的，也属于外部依赖。
• 内部依赖：下游的工作自然依赖上游，比如程序开发依赖策划文档。

外部依赖往往需要更多关注。其他部门的工作安排、资源调配等各方面决策有自己的立场和考量，在可控范围之外。遇上外部依赖项，可以先把它列为疑似风险，考虑它的延期会不会给项目带来影响，同时，积极与外部沟通，进一步分析风险是否真的存在。

关于内部依赖，可以重点关注那些关键环节，即只有一个人负责且没有人可以取代的。比如主策审核文档，UI、GUI也通常只有1个人，甚至跟其他项目共用1个人，如果这个人休假，出差时，就要考虑，这是不是一个风险。

团队氛围 当遇到一个冲突的时候，可以想想是个例，还是有什么潜在的风险。

程序吐槽游戏的设计：如果是当着策划的面说并且没有打起来的话，可以当成是表达爱的一种独特方式。如果是背着策划，要了解程序和策划之间是不是出现了隔阂，可以多跟他们聊聊，了解具体情况，判断是不是一个风险。团队方面的风险，通常是高级别风险，一旦爆发，影响面会很大。

新鲜“人”“事” 新人、新技术、新流程

新人一开始还在边学边做，出问题的可能性会比较高，所以要特别关注。新技术、新流程等也一样，对于新东西我们通常是缺乏经验的，需要尝试和磨合，所以要提前考虑容易踩到什么坑，这些坑就是风险，提前找出来，规划怎么去应对。

主观因素 主观因素，一般带有不确定性，容易出现偏差。

工作量的预估，有时候会出现预估不准的情况，特别是经验不足的同学，预估不准的可能性相对比较大。还有一些代码优化或重构的工作，常会出现工作量大于预期导致延期的情况，这类没有参考标准，拍脑袋成分比较多的，通常是个风险项。

1.3.4 风险识别的两个方法

找到并具象化不确定因素 风险是和不确定相关的，要找风险，就相当于要找出项目中不确定的点。

程序说：“下周四应该可以开发完吧”。虽然是肯定句，但可以听出其中带有那么一些不确定，这时候，可以进一步问他是不是有什么难点或依赖，深度挖掘他没说出口的不确定因素是什么，来确定这因素是不是个风险项。

团队的“晴雨表” 团队中通常有那么一两个人，喜怒哀乐都写在脸上。如果一直情绪不太好，可以多跟他聊聊，看看是什么原因，是不是团队有什么隐患。

1.3.5 开启自身“雷达”，发展下线“雷达”

总结：要把自己探测风险的“雷达”开起来，和团队中尽量多的伙伴合作，让他们成为我们的下线“雷达”，提升探知风险的范围。

要让团队的成员都知道，风险是PM在管理的，是PM负责的，有风险找PM。

1.4 变更控制

市场环境和玩家需求变更飞快，要敢于拥抱变化，迎合玩家的需求和市场变化。

1.4.1 变更的六何分析法（5W1H）

提出六个问题来帮助重要干系人、团队理清思路。围绕以下六个问题，组织重要干系人进行充分沟通，达成共识，然后，进行灵活调整，尽量降低变更带来的影响。

WHY变更原因 需要和各位重要干系人说明变更的原因，推动大家充分沟通，对变更达成共识，明确变更的目的。

WHAT变更范围 沟通清楚要做什么。提前列出有哪些制约条件（时间、资源）。

做好对干系人的期望管理，把现状和制约说出来，推动大家充分沟通，做取舍，做决策，最后，确定范围。

WHEN&WHERE发布时间和发布地域 如果是相对远期的目标，可以先确定放在哪个里程碑，再渐进明细。如果是比较临近的情况，可以把发布目标细化到周版本。

如果来不及做出来，就回到前面的问题“做什么”，去取舍，重新确定范围。

不管过程怎么样，一定要达成共识，要有明确的结论。

WHO&HOW负责人和详细计划&风险管理 要跟各主管确定负责人，只有聊到具体谁来做这个问题，才能确定具体的影响是什么。

在定详细计划的过程，同时考虑有什么风险项，定好应对的计划。变更计划的周知和风险反馈也需要做到位，需要及时同步给相关干系人。

1.4.2 变更对团队士气的影响

在确定要变更之后，我们需要考虑对团队士气的影响，安抚大家，变更的初衷是为了更好，而不是否定大家之前的劳动成果，必要的时候，可以一对一进行正式的沟通，说明我们决策的依据。

1.5 团队建设

1.5.1 非常规的团建

开会 在会议之前给出一些发言内容的建议：针对性地讲一讲，当前的开发方向是什么，是怎么定出来的，考虑了哪些方面，这样可以消除团队疑虑，建立团队信心。

练级竞赛活动与颁奖礼 让每个人对项目提高投入度。

活跃团队氛围

1. 保证参与度
2. 有独特创意
3. 引起热点话题
4. 留下经典瞬间

1.5.2 PM组织团建的价值

做团建，最主要是找到初衷，想解决什么问题，想达到什么效果。

把注意力更多地放在“量身定做”上。相对于楼层秘书，PM更熟悉项目团队，了解团队的运作情况，一旦出现什么问题也能第一时间知道，所以确定团建的初衷后，就可以针对性的，量身定制合适的团建方案。

1.6 日常修炼

PM的日常修炼，应该是在日复一日的繁忙工作中适时停顿，停下来想一想每一件工作的初衷和目标，打开脑洞怎么做得更好。