理想中的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为自己安排所有事情。
本篇与其他的联系: