从 DOOM 启示录和戴森球游戏工作组中得到的启示

我在公司做业务分析，最头疼的就是在不同的组之间沟通。任何一个项目我都至少需要开三个会：第一个会是和游戏设计师和市场部门讨论 KPI 和监测指标；第二个会是和本组成员头脑风暴，确保没有漏下比较重要的东西；第三个会是在写下需求文档之后，和研发以及数据库组进行沟通，敲定所需要的 telemetry 和数据库表的结构。换句话说，我同时做需求分析和数据建模（之后还要做 ETL ）。也正是这些工作让我觉得自身在研发这块比较欠缺，所以目前在学校进修计算机科学的课程。

但是这三个会议仅仅代表我工作的一小部分。大部分时间其实都花在和研发的沟通上。鉴于我自己对编程知识并不了解，所以我的 telemetry 需求文档其实和研发的程序架构往往离得很远。比如说我们的游戏采用微服务结构，在我对我们是如何实现微服务完全不了解的时候，我其实是把它当作 Monolith 来看的。也就是说我的 telemetry 需要研发从很多个微服务中调取数据。然而研发采用微服务正是为了让各个部分之间相对独立，所以在一开始这对我造成了很大的困扰。等到现在稍微对研发的架构有所了解，我就逐渐注意到相关问题了。比如说我看研发对于某项目的文档，就能大致琢磨出来大概需要哪几个微服务之间互相调取数据，于是我可以在尽量符合架构的条件下提 telemetry 的需求。但是总体来说，和研发的沟通大致占我工作时间的八成——这里头还有一些其它的原因，比如说我们这边有时候考虑的不周到，会临时加需求，或者研发那边完全没有文档，于是我得找人一个个问下来。这些都太占时间了。

我因此感觉到，项目管理的确是个比较困难的事情。因为项目管理本质上就是在不同的组之间进行沟通，而沟通就必然带来信息的损耗。很多时候这种损耗是不可逆和很难察觉的。双方可能都觉得这次沟通非常完美，但是最后的结果却不尽然。我理想中的项目管理者，应该是个出身研发（因为最后需要研发落地，所以这块必须熟悉），但是对业务非常熟悉，又擅长向上管理的人。缺少任何一点都会有重大问题。如果出身不是研发，那么基本上没发和研发有效沟通，鸡同鸭讲；如果对业务不熟悉，那么做出来的东西业务根本看不上；如果不擅长向上管理，就很难在效率和质量之间做平衡。

说来说去回到标题。我读 DOOM 启示录的时候，对 ID Software 早中期这段经历（大致上是从尚未成立 ID Software 、还在原公司做大蓝碟，到 1997 年 Romero 离开这 7 年）尤其感兴趣。如果说我工作的感受是在泥泞中爬行，那么 ID Software 的这段经历给我的感受就是行云流水一般的顺畅。不断地有新作品、新技术涌现出来，每个人都尽情投入到工作之中，并且不断地给自己找事。我们当然可以说，这是因为他们是在给自己打工——但是我认为这并不能解释所有的事情——比如说你就无法解释为何在做蓝碟的那一年他们依然效率很高，创出了一年十几个游戏的纪录。你能感受到，这是一个特别有激情、特别有战斗力的一个小组。

时间转到前几天。V2 上正好有个关于戴森球的帖子。把戴森球小组和 ID Software 中早期一对比，就发现这两个小组之间的相似度很高：第一，双方人数都很少，但是经验都很丰富；第二，小组中所有人的兴趣高度一致；第三，小组做的是他们感兴趣的游戏。这就导致游戏开发上两者也有很多相似的地方。比方说两者在项目管理上都没有什么损耗——我甚至想说，其实那不是项目管理，而是大家把蓝图科学的勾画出来而已。这对个体的要求很高。如果每个开发人员没有相当的开发经验的话，就非常容易制定太高的目标，甚至随机行走，想到什么做什么。如果大家只是为了钱做游戏，那么也不可能有这么顺畅的沟通——你让一个经验丰富但是对科幻经营类游戏毫无兴趣的程序员去写代码，那他很可能就是仅仅根据需求给你 1 、2 、3 、4 、5 做出来就是了，不是说不好，但是想要做爆款我觉得可能性不高，更别说需求沟通也会带来困难，很多游戏术语都需要被再翻译。

说了半天，其实也都是大家知道的事情，只是有所感触罢了。能够看到有才能的人尽情挥洒才能，我们都应该为他们感到高兴。至于我自己，我想我得到的启示就是，我还得慢慢学编程，争取做到研发、数据、业务三栖。不敢说精通任何一块，但是至少能够在现有和将来的工作岗位上发挥更大的作用。成熟游戏公司和 Indie 开发组的玩法的确是不一样的。