游戏开发团队并非蚂蚁协作（1）：PM与单子

理想中的PM与单子

在大型团队做大型游戏，因为有许多事情要做，而事情之间又存在着各自的优先级和相互依赖关系，所以这就需要一个群体去作为团队的“大脑”，来协调各种事情的处理。这个群体就是 PM（Project Manager，项目经理）。

理想情况下，PM对项目中所有要做的事情有一个全局的视角。这意味着它们要从上到下推导出所有要做的事情，很显然，最上层要做的事情是“开发完成这个游戏”，再往下呢，就是开发好具体的几个模块，再往下就是每个模块中具体的子任务等等。这个过程也可以借助具体开发者来完成对任务的拆分。而最终，PM应该能知晓项目中所有具体的任务，它们相关的开发者，开发耗时，相互之间的依赖关系，各自的优先级等等。接着，它们就可以按照各个任务的情况去推动任务，并发现那些不符合预期的任务从而及时调整。

这些信息是大量的，PM当然需要借助类似Jira的工具来管理。而刚才所说的“具体的任务”，就需要明确地由一个个“单子”来表现出来，在Jira中叫 事务(issue)：

当然，项目不一定是用Jira的。但是类似的“单子”的概念却很常见，毕竟你总需要一个东西来记录任务。

有了单子后，PM就可以每过一个周期（比如一周或两周）去审视自己所负责的所有开发者身上的单子。

我想，如果单子真能如理想中那样，能真实而公正地反映所有任务的执行状况，并足够细节，那很多流程都会得到简化，比如你无须进行太复杂的汇报，因为领导通过你完成的单子就可以评估出你工作的情况。

我想，如果PM真能如理想中那样，事无巨细地管理好每个人当下该做的每件事，那么开发者每天都只需听从PM的，专注于自己要做的事情就行。

但很显然，无论是“单子”还是“PM”，都无法成为理想中的模样。而接下来我想根据我的经历，来讨论有哪些问题造成了阻碍。

问题1. 单子的状态并非只有“已完成”和“未完成”

理想情况下，单子创建出来后是“未完成”的状态，当开发者做完后，就将他标记为“已完成”。但实际的情况远非这么简单。

举个例子，对于“开发一个美术效果”这个任务：

• 当程序员开发好时，对于他来说已经完成了他的事情。但事情不算完，因为美术师可能还要验收。所以单子上还要有个 “验收状态”。
• 当美术师也验收好后，虽然他确认了程序员开发的效果是符合预期的。但是他可能仅仅是在开发环境中验收的。要想真正确认效果没问题，其实要等这个效果进入了包体里，由QA运行最终打包出的游戏里去测试没有问题。所以单子上还要有个 “测试状态”。
• 也许，由于这个效果改动到了较为底层的代码，所以不得不在另一个分支去做。所以单子上还需要有个状态，注明这个效果当前是在 “哪个分支” 上开发和验收的。
• 。。。

这些状态是不能被无视的。否则如果仅将“所有要做的事情全部都做完”才视为是“已完成”，其余都是“未完成”。那么PM会发现有太多的单子处于“未完成”状态，而这也让它们无法把握更准确的进度。同时也会对开发者的汇报造成困难，可能它们明明已经把这周要做的任务都做好了，但是所有单子都显示“未完成”。

所以最好还是要显示这些状态并建立对应流程来推进，这就增加了每个单子上的信息量。此外，这又可能导致另一个问题：有些任务它确实并不需要验收和测试，或者说开发者已经对此负责过了。这样就导致了对于某些任务，流程是冗余的。

问题2. 任务在完成之前本来就有不确定因素

单子的 “子项拆分”、“耗时”、“依赖关系” 是在任务完成之前评估的。但矛盾的是，一个任务只有完成后才能真正回答清楚这些问题。

所以，在处理一个单子的过程中可能会出现：

• 发现实际耗费的时间要多于或少于估时。
• 发现有个问题需要别人解决才能继续推进。
• 发现它会造成新的问题需要解决。
• 发现它其实不需要解决的
• 发现它是理论上不能被解决的
• 发现有更好的解决方法
• 。。。

这些意外，让“依照单子所作的计划”变得不准确。

我想，只有在团队对相关任务有经验的情况下，才能减少这些意外的发生。

问题3. 过小的任务 & 写不成单子的事情

“花费几天开发一个效果” 算是一个单子，那么“花费十分钟改一个配置” 要开一个单子吗？
如果你选择不开单子，那必然会“丢失”一些体现不出产出的时间。如果选择开单子，那么这无足轻重的事情又可能会被卷入冗长的流程。这是两难的抉择。

此外，还有一些写不成单子的事情。这其中最常见的事情就是“与同事沟通”。如果你正在处理一个单子，那么你为这个单子的事情去沟通是完全没问题的，算作是处理这个单子的耗时。但更可能的情况是，你很久前就做好了某个事情，相关单子已经被标记为“已完成”了，但是别人正好在处理相关的问题，需要问你那件事情相关的细节，这时候你是不得不配合的。我觉得“认为别人浪费了自己的时间” 的想法是不公平的，毕竟你在处理你的单子的时候也会有需要别人配合沟通的时候。

所有这些没有体现在单子中的事情，如果只是偶尔出现并且时间较短，那完全没问题，毕竟单子估时总不会那么精确，每天上厕所都可能会消耗几分钟嘛。但如果这些事情总计积累到了较长的时间，那就会比较麻烦，汇报时你会有凭空消失的一两天说不出自己在干什么，要不然就只能坚称一些单子花费了更长的时间。当然你可以真的实事求是把那些时间在做什么说出来（如果你真的记得的话），但由于那些只是鸡毛蒜皮的小事，也算不上你的产出，所以也不会对你有什么好处。

问题4. 任务的并行性

理想中，PM会期望你按照单子的优先级去做事。比如第一天去做什么，做完后再做什么。
但实际情况大多不会这样（至少对我来说）。原因很大在于任务的 “并行性”。比如：

• 当我在做一个任务时，需要在我本地执行一个命令来验证我刚刚改动的代码是否有问题，而这个命令需要耗费1小时才能跑完。那么在执行时，我肯定不会在电脑前啥也不做，我肯定会在这个时间去研究一下我身上的其他任务。
• 当我在做一个任务时，突然发现需要别人配合做一个事情才能继续推进，那么我就只能停下来去做别的任务，等别人做好后才能继续这个任务。
• 。。。

这让单子的执行顺序被打乱，让“耗时”就算在任务完成时也不好准确界定。这些都让PM更难把握任务的推进情况。

问题5. PM缺少对相关概念的理解

如前一篇所说，大型游戏往往有更多的“概念”，这些“概念”之间有各种各样的关系。而PM不是开发者，必然会缺少对一些概念的理解。虽然PM团体也倾向于招收有开发者背景的PM。但相对来说，一个开发中的大型游戏中的各种“概念”确实太多了，连每个开发者都有很多事情是不清楚的，更别提PM了。

这就让PM和开发者就单子的细节进行沟通时，会多一些成本。比如：

对于“开发岩石表面材质在下雨时的效果”这个任务，当程序员开发完时，会告诉PM：“你好，我已经开发好了，麻烦找相关美术同学去验收这个材质效果”。而如果PM对相关概念不清楚，那就会有疑问：找哪个美术？材质是什么意思？怎么验收？

因此，很多时候开发者都不得不自己去推动任务的解决，比如自己去找负责的美术师是谁，然后告诉美术师该怎么样去验收效果。这在我看来算是开发者承担了部分PM的职责了，但却是没办法的事情。

此外，对于一些任务的优先级，也让开发者有了很大的发言权，因为PM对事情具体是指什么并不理解。

实际情况

我相信，关于“单子”和“PM”的问题，并不止上面所讨论的那些（也许之后我再想到什么关键的会回来补充），但我想说的情况很明确了：
单子包含信息的数据量之大，状况变化之快，是PM很难及时地、准确地、完整地、把握的。也就是说，PM无法像理想中那样掌握所有事情。开发者没办法期望PM为自己安排所有事情。

这也就意味着，开发者对自己的任务拥有一定程度的 “自主性”，PM的掌控度越低，这个 “自主性” 越高。

听起来，“自主性” 代表了更多的自由，是件好事。但在我看来，这个 “自主性” 是我后续将会讨论的很多问题的元凶，同时也可能反而给开发者带来了 “焦虑”。试想，如果PM真能妥善安排了所有的事情，那么站在更高视角的他们肯定会做出更有利于整个团队的选择，同时也让每个开发者不用花费时间与精力去思考每天要做什么。

（但最后还是需要指出，尽管单子所描述的内容并不准确，但我们还是需要它们，它们的作用是明确了一个任务的存在，并且给开发者有导向的作用）

总结

单子包含信息的数据量之大，状况变化之快，是PM很难及时地、准确地、完整地、把握的。也就是说，PM无法像理想中那样掌握所有事情。开发者没办法期望PM为自己安排所有事情。

本篇与其他的联系：