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

[levelworm]

我在公司做业务分析，最头疼的就是在不同的组之间沟通。任何一个项目我都至少需要开三个会：第一个会是和游戏设计师和市场部门讨论 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 开发组的玩法的确是不一样的。

[happinessnch]

你想要造一艘船，你不需要去指挥他人去购买工具，也不需要给人安排任务，你只需要激发他们对大海的渴望。

这是一种很理想，且可遇不可求的状态，一般情况下都不建议这么做。

[EvanG]

没得比啊 ID_Soft 初期团队里哪一个不是大神，卡马克这种级别的人才你能招到么。。。

[skyworker]

大部分上班只是为了一份薪水而已, 对业务或者编程本身可能不感兴趣, 只对薪资和是否 996 感兴趣

[sillydaddy]

> “第三个会是在写下需求文档之后，和研发以及数据库组进行沟通，敲定所需要的 telemetry 和数据库表的结构”
很好奇为什么需要你做这件事。做项目管理的为何要关心数据库表的结构呢？这就是导致你“大部分时间其实都花在和研发的沟通上”的缘由吧。需求表达清楚了，自然由研发来设计相应的框架，难道还要根据研发使用的框架来修改需求吗？即使需要这样，也应该与一个研发的代表来讨论沟通啊。

[levelworm]

@happinessnch 的确，感觉都是可望不可求。这两家公司的模式都是志同道合者联盟。

[levelworm]

@EvanG 卡马克成就 ID, ID 我觉得也成就卡马克。当然这种大神的确罕有。

[levelworm]

@sillydaddy 你说的很好。因为数据组不做，所以只有我做。不过我之后就去数据组了，所以也算是数据组做了，大家也都觉得还是数据组做而不是分析师做比较符合常理。严格来说我也不是做项目管理，而是做业务分析。项目经理仅仅负责协调大家开会，所以具体的组之间的沟通是我来做。最早的时候，其实也没有我这么做的，但是那时候就特别混乱，我觉得得做点改变所以就揽下来了。

不过这个并不是占时很多的（全部）原因。我进行沟通时间最多的还是研发，而不是数据组。就我个人的体会来说，有几个原因，一个是需求会有变动，这个是我们这边的问题；一个是研发那边赶进度，所以没办法同时照顾游戏设计的需求，和数据分析的需求，所以很多时候出来的 telemetry 和我的需求是完全两样。我需要不断地盯着每个研发，否则到最后就完全走样了。但是我觉得这也有我的问题，因为我不了解研发的架构，所以我提的需求可能本身也不靠谱；一个就是你说的，研发那边没有对等的人，所以我必须和所有研发进行沟通。

我其实一直觉得，研发所需要的需求文档，不应该由分析师来做，应该是研发自己那边有类似职位的人来做。因为作为分析师，我不可能了解程序的架构，怎么能指望我写出来的文档研发可以照套呢？

这是我准备在今年解决的一系列问题。我去计算机系进修也是因为此。如果今年内解决不了，我就觉得我的工作没有什么很大价值了，就准备专心做数据这块（这块其实才是我真正的兴趣所在，我其实也不喜欢到处找人沟通），甚至跳槽也有可能。

[sillydaddy]

@levelworm #7 >

不懂游戏这块，你说的数据建模，是针对的游戏本身的数值平衡，还是针对的游戏玩家数据呢？
做业务分析的话，懂一些程序肯定能有所帮助。不过我觉得，大部分时候，知道大概就足够了吧。比如我的业务需要保存这块、这块和这块的数据，在需要的时候能把这些数据调出来以供分析。至于研发用什么框架用什么数据库，我不需要关心啊。难道研发能说，你这个需求不合理，这 3 种数据不能一起拿，会影响效率？？也就是说，提靠谱的需求，需要了解研发的架构吗？？
你说的这些给我的感觉是，你因为感觉无法亲手控制研发的工作，又感觉没办法给研发解释清楚自己所理解的东西，以至于他们没办法充分配合，当然也可能因为研发本身就没有什么积极性，所以，你想要自己去学习一下程序世界里的概念，然后用这些概念去和开发人员沟通。

[sillydaddy]

@levelworm #7 >
问题是，你这是在迁就研发啊，效率的瓶颈不在你这里。研发为什么不能理解你说的需求呢？是他们不上心，还是说你没有解释的很清晰？ 我觉得不论是哪个，解决的的根本之道都不在于你是否去进修计算机。

可能问题还在于项目的流程吧。你自己也提到过之前的项目流程比较乱。有没有了解过“敏捷开发”这种项目流程，它跟你理想中的项目小组挺像——每个成员都充分参与项目的讨论，充分理解需求，充分沟通。你一直在说的“需求文档”，在这种项目流程里面，根本没有那么重要。贴一下敏捷宣言：

“个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，
我们更重视左项的价值。”

[levelworm]

@sillydaddy 数据建模我指的是数据库里头的 data modelling，不是数据平衡。比如说 telemetry 从 Kafka 进来，需要丢到 Vertica 里，这个表应该是什么样的？ telemetry 里哪些部分需要进什么表，表和表之间关系是什么的，等等。

你的感觉十分正确啊，我觉得我说的不是很清楚，但是你理解的很对。另外研发的确是可以拒绝需求的（我觉得这也很正常）。所以就像你说的，我觉得我得至少了解研发的工作，才能给他们提需求。

我举个例子，比如说某个游戏里头的某一场战斗总共有创建、开始、作战、奖励 4 个设计师设计好的阶段，对于分析师来说，我不需要细节，我只要汇总，所以我最早提的需求完全是根据分析师的需求来的，表的每个字段都是汇总，比如说战斗中总共杀死了多少敌人，总共获取了多少金币，等等。但是后来去看研发自己的文档，发现不对，他们做不了这个，他们只能按照游戏设计师的 4 个阶段来输出数据，于是我就改成 4 个 telemetry 。后来又发现有些数据服务器端拿不到，只有客户端才有，或者是有些数据某些微服务才能输出但是这个战斗的程序不需要这个微服务，所以就没有相关数据。所以最后我还得把需求拆成几个需求，分别给不同的程序员，又放弃了几个特别困难的，最后才算是凑齐了大部分的需求。

[levelworm]

@sillydaddy 我们其实就是这么做的。每个大项目都有个 task force，每个成员参与讨论，我的这几个会议也是讨论的一部分。至于为什么不是那么有效，除了我说的那些，我也不知道还缺点什么了。

我有一点不理解，如果没有完整的文档的话，程序员怎么知道该怎么写输出 telemetry 的代码呢？数据组怎么知道数据库的表是什么样子的呢？难道这些不都是事先要说好的吗？

如果我完全按照分析师的要求说给研发听的话，我觉得就是鸡同鸭讲了，因为我们只会说，“我们想做什么分析”，问题是程序员如何把问题变成我们需要的数据？他们不做分析啊，所以最后还是得我和他们说，我们做分析，需要如下这么多字段，且在某个时刻输出，这时候程序员就会说，OK，这里头 ABCD 等等我们做不到，因为框架不支持，然后我再进行修改，等等。

[sillydaddy]

@levelworm #11
嗯，数据相关的文档肯定是不能省的。我上面指的需求文档主要是程序逻辑相关的，比如业务逻辑。

至于你说的程序不支持相关的数据，按照我的理解，没有什么不支持的数据吧：
>表的每个字段都是汇总
为什么开发人员不能提供汇总后的数据，而需要你去拆分数据？
>有些数据服务器端拿不到，只有客户端才有
既然数据分析需要这些数据，为什么拿不到？如果要拿到，需要哪些工作？
>有些数据某些微服务才能输出但是这个战斗的程序不需要这个微服务，所以就没有相关数据
数据分析需要这些数据，这个问题不能够被技术解决吗？
>最后我还得把需求拆成几个需求，分别给不同的程序员，又放弃了几个特别困难的，最后才算是凑齐了大部分的需求
感觉你太委屈了。
作为一个开发，虽然我不懂具体你说的这些技术，但我能相当肯定，这些数据来源的问题是可以用技术解决的。可能你跟具体的开发人员中间，少了一个沟通的渠道，比如对接的人，或者说是一个对接的机制(比如敏捷会议)，以至于额外的工作都被你负担了。但你不懂开发啊，这些技术细节交给你处理就不合理。

另外，友情提醒一下啊：
> 比如说 telemetry 从 Kafka 进来，需要丢到 Vertica 里，这个表应该是什么样的？ telemetry 里哪些部分需要进什么表，表和表之间关系是什么
从这句话，可以发现你的表达方式是可以改进的。因为这里面的几个名词，甚至对于一般开发人员来说，都是无法理解的，如果把它们换成可以被理解的概念，是不是好一些？ 这就引申出一点： 如果你与你们公司的开发沟通，能不能采用一种大家都可以理解的中间语言，来避免“鸡同鸭讲”的现象？你也就不用去学习那么多开发的东西了。

[yxysnao]

其实就是菜，有卡马克的公司 管它是 id 还是 oculus，有可能不成功吗，卡马克也不是科班，卡马克也爱玩游戏，卡马克在商场上和市场营销上还很不成熟，卡马克还很不会沟通，一言不合就开人。但他是卡马克，这就足够了，仅凭一人的技术力洗牌游戏市场的人

[levelworm]

@sillydaddy 多谢多谢，多谢理解。不过目前的确没什么很好的办法了，可能还是得就这样下去。不过我觉得我可以想办法找个接头的人，虽然不乐观，毕竟这活又烦又没实际功效。

另外关于表达方式，这句话的确是不好的，也不够精确。我和研发表达就是直接一个个列出来，他们也说这样最好（省心嘛）。不过你说的也对，如果我能把需求用这么一种中间语言描述一下，而不是用试图模仿程序员代码的形式描述出来，可能更好。问题就是怎么用。。。毕竟英文是我的外语，呆了这么久还是不够利索呀～

[levelworm]

@yxysnao 对。。。ID 明确技术优先的确是走对了，卡马克的确牛，不服不行。无论是头脑还是效率都是一顶一的。就像你说的他也没怎么上过大学。

[Justin13]

你说的三个点，核心就一点，良好的沟通能力
至于技术，产品，向上管理，其实都是领域知识，能锦上添花，无法雪中送炭。沟通能力不行，技术，产品等再熟悉也没用
再一个，领域知识绝非沟通的必要条件，良好的倾听理解能力才是，因为作为各方交汇的岗位，理解偏差是最要命的
如果觉得不了解领域知识就沟通不了，那说明双方都应该学习增强沟通能力，而非去了解领域知识。

[BeautifulSoap]

@Justin13 最近学领域驱动设计，有点自己拙见

你说的沟通能力，不同团队不同人的沟通能力都不一样，领域驱动开发里就是为了减少不同人团队之间的沟通障碍，才不厌其烦地(甚至到了啰嗦的地步)强调开发中必须坚持使用领域模型和通用语言进行交流(UBIQUITOUS LANGUAGE)

因为领域模型和通用语言是领域专家和开发人员共同制定的，本身就自带了领域知识，并且坚持使用它们能大幅减少不同团队和人之间的沟通成本，减少误解


戴森球团队之所以开发如此顺畅，我觉得一个解释是因为他们大部分人都经验非常丰富，甚至可能团队中很多人都算是领域专家。他们都了解这个领域也了解程序开发，领域知识无需过度沟通。自己即是设计者又是开发者（虽然各有分工），因此团队内就很轻松地能统一领域模型和通用语言，从而提高开发效率

[Justin13]

@BeautifulSoap
拥有相同的故事上下文和背景知识可以大幅度降低沟通的门槛
在同一个团队里面可以搞，也很有意义，因为大家做的事件是同样的，比如开发内部沟通。
但是对于管理，这不现实，再怎么学习领域知识，
也不可能接近开发的程度，更何况还有可能出现领悟知识的偏差，在对方看来，这变成外行指挥内行的。
至于不同团队间努力构建相同的故事上下文，这当然有用，但是显然难度远大于增强自己的沟通能力

[zj9495]

"你让一个经验丰富但是对科幻经营类游戏毫无兴趣的程序员去写代码，那他很可能就是仅仅根据需求给你 1 、2 、3 、4 、5 做出来就是了，不是说不好，但是想要做爆款我觉得可能性不高"
工作中遇到过很多产品经理，自己对需求都不够了解，还不清楚到底想要什么，就想让研发奇迹般掏出一个让领导客户都满意的核弹级产品，想一想这也不可能

[yxysnao]

还有些写的没续上。所以这本书会受美国推崇，卡马克本人的所体现出的个人英雄主义，比虚构的都还要夸张，就像没人能写好盖茨或巴菲特的故事，能力太强的人成功得很是枯燥乏味，卡马特至少还有个升级的过程。不是卡马克选择了技术优先，是 ID 的发展不得不让步于卡马克的技术，你罗梅罗能力爆表设计的游戏一顶一的爆款，那 ID 也许就成为第二个任天堂了，但这种事情没发生吧 。另外说一句任天堂的技术力可一点都不拉跨，看跟谁比。那本书要效果写了一波人，实际上那拨人在现实中也就打了个酱油，出了 ID 也没掀起任何风雨，所以看懂这本书的小扎深谙此道，合伙人不合格立马出局，公司成就了你，分一杯羹很客气了。