为什么远程合作的游戏项目难以成功：原因剖析与解决方案

2016-06-01

GameRes游资网授权发布文 / 顾煜

前面说到缺乏沟通是首要的原因，其实，还有一些原因也导致远程合作的项目难以成功。

信任感的缺失和文人相轻

随着沟通信息的缺失，两个团队会越来越认为，对方不值得信任，是一个很弱的团队。大家本能认为，自己身边团队是最棒的，原因是受到认知偏见的影响，自己是团队一部分，参与了大量决定过程，自然就认为自己是对的。

一旦我们团队做出一个保守的技术决定，那是小心谨慎，是对项目负责。如果是远程团队做同样的决策，那自然是保守落后不思进取。
一旦我们团队作出激进的技术决定，那是锐意进取，挑战极限。如果远程团队做同样的决策，那是不尊重软件开发的客观规律，没有常识和智商。
当我们的技术决策成功，那是高歌猛进，用一个成功替代另一个成功，为建设四个现代化添砖加瓦。当对方成功，那一定是开发内容太简单，对方合作中总是挑简单的工作做。
当我们的技术决策失败，那就是小步迭代，顺应变化，勇敢跨出舒适区，拨乱反正，为下一个成功打好基础。当对方技术决策失败，大家哈哈大笑说你看我早就说过这样不行，他们不听我的。

距离产生美，也产生怀疑，当沟通恶化，任何对决策的不解，无法及时通过沟通来化解，那就会淤积，就会发酵，就会爆发。

《三体-黑暗森林》作了非常好的诠释，当宇宙中两个文明，无法沟通，那么任何哪怕是善意的举动，都可能被过度解读，最稳妥的方法，就是往那个黑暗中发出异响的方向开一枪。

加强团队凝聚力的好办法，往往是树立一个共同的敌人，比如紧张的deadline，比如凶残的竞品，比如不合理的流程。但很不幸的，在合作项目，大家往往认为远端那个团队造成了所有的不幸。远程团队不给力，那我们自然不能把死活押宝在对方身上，我们要发奋，我们要图强，我们要改变。在职业化的团队，造反的欲望会被压制，最后大家都消极没动力；在叛逆的团队，团队会分化，一样没高效产出。

依赖关系

罗马不是一天建成的，就像项目不是一天做成的。在项目开发中，有各种协作和依赖。越大型的项目越难做，其深层原因就是随着项目增大，内部的工作、资源和流程依赖，迅速膨胀，大大超过了要做的具体工作。

依赖关系是最难处理的事情之一，比依赖关系更难处理的是远程依赖关系。由于远程的局限性，大家无法频繁沟通，所以一般的做法就是约定一些重要的节点，双方同步工作，让那些有依赖关系的项目能够推进。本质上，这就是在团队这里设了一些节点，节点内可以独立做，然后准时交付即可。可是你有做过可以准时交付的项目吗？准时交付是多么难的一件事啊？

准时交付还有一个变种，就是按时不按量交付，就是时间是挺准时的，但是质量就很一般，这样远程团队交付的工作，在另一边往往没有办法好好使用，增加了非常多的沟通交流成本。

当产生了延误，依赖关系不能被满足，就会引发更可怕的事情，我称它为Cascaded Delay。一个延误会引发另一个延误，冲击蔓延到整个项目，即使只在本团队扩散冲击也是一件非常可怕的事情了，更不要说会扩散到另一个团队。

目标不同

两个不同团队有可能有不一样的目标。

某个团队也许是发起方，更希望把产品做好，而另一个团队只是被拖上凑数的。那么双方的合作意愿，kpi目标，是完全不对等的。

一边是主力团队拼命推进，谈着milestone和deadline，另一边是配合团队拖延敷衍，谈着vacation和beach，这明显没法谈到一起去啊。欠债的是孙子，拖进度是大爷，在一起合作是种缘分，不坑你还能坑谁。

解决方案在哪里？

虽然说了这么多问题，但远程协作并不是一件完全不可行的事情。大致上，我们有这些手段可以提高协作质量：

选择好的协作模式

在我看来，运作的比较良好的远程合作模式，大约有下列几种·外包模式，也包括公司集团内部的内包模式。外包模式的本质，就是让一部分的内容，能被不同团队高效开发。这个模式已经被业界广为使用，美术外包、音频外包等等都是非常常见的外包方式，而最近也会有一些新的形态兴起，比如测试外包，用户研究外包等等，都极大提高了生产力。

相对来说，这些可以外包的模式，共同特点如下：

有良好清晰的边界：美术外包只要做好模型即可，每个单独的模型就是自包含的，不会影响太多其他模块。测试外包的目的就是单独做好一个游戏版本的测试，没有太多和开发团队的交流。（其实这一点我有一定的保留，我们使用的最顺手的测试模式，一般都是dev tester模式，这个无法体现在外包测试中。）o产出时间相对可控或是可预期：美术资源，包括模型贴图等等，相对容易标准化，容易定时定量，不会有太大的偏差，所以大量美术外包的业务模式就是根据不同外包人员的能力，来单纯的计时定价。

一般不是游戏开发中最核心的内容，能够很好的把决策和执行解耦合。对于像核心玩法、关卡设计等等内容，必须通过多团队来协作开发的，不停迭代调整和改进的，它们的决策和执行是一体的，离得越近效率越高，所以很少有外包。

还有些更高端的外包，其实是整包，把整个游戏开发外包出去，原公司只需要有少量人跟进和监督即可，比如在上海的日本东星，就常年扮演很多游戏的幕后英雄，完成全部开发，贴个别的游戏公司的牌就出去卖了。
独立开发，把工作边界划分在自然边界所谓的自然边界，是指在这样一个地方切分开以后，两个团队的开发，互相影响很少，基本可以独立进行，定期在同步点整合即可。听上去非常美好，但似乎很多时候并不容易找到这样的独立无依赖模块。不过也不是绝无可能做到，以前做主机游戏的时候有过这样的案例：

一些游戏的单机和联网模式根本就是两个游戏，只是共享了接近的美术资源。于是公司就把单人模式和多人模式交给成两个独立团队负责开发，大家只需要遵守同一个deadline，做完以后做个launcher一整合，烧到同一张光盘上即可。玩家买一张盘，得到了两个游戏，实在是多赢局面。

另外的一些例子，包括做出比较通用的组件，组件完全可以是独立开发，有相对固定的接口，到时候替换成新版本即可。当然这种神奇的替换，猫腻也不少，组件和主游戏关联越少，越容易实现无缝替换。

听说过的最夸张的近乎骗局的案例，是有个外部团队说，你们团队在某个引擎上开发游戏吧，我们外面有一个团队来做高级引擎，到时候我们一起biu的一下就把你的引擎替换到我的引擎上了。biu一下谈何容易，欺负我没读过书呢？我们身处在改一行代码都会踩到10个臭虫的游戏开发领域，容不下你的理想主义。

可以看出，这两个模式，本质都是通过合理的管理，来降低各个开发模块之间的依赖关系，从而达成目的。

选择好的协作团队

远程团队要和你有一样的kpi目标，最好两个团队不是完全对等，而是主从关系。如果是都汇报给一个制作人，则更好，这意味着任何时候，只有一个项目，一个梦想。控制力是关键，对于项目来说，虽然人多力量大，但力量是矢量，如果有着不同的用力方向就不是什么好事了，一定程度上的整体控制是非常有效的。

选择好的团队成员

不要情商低的，他会和远程团队闹僵，给你添堵，让你忙着处理人事，而不是业务。

不要不守纪律的，远程团队本就不容易沟通，一举一动都不在眼皮底下，信任已经很难建立，别让情况变得更糟。

不要表达能力不够且没有沟通意愿的，沟通本就是远程协作中的大问题，怎么强调都不为过。

做好沟通

说来容易做到难，既要事无巨细沟通项目决策上下文，及时全面精确，又要控制沟通成本，不能整天开会同步信息无法推进具体工作。

你还要对沟通辞令非常敏感，听懂复杂沟通中的潜台词。是的，我们活在一个温情脉脉的世界，人们用隐喻来交流，智商不够是无法识破种种含蓄的表达方式的。

当对方说资源不足，可能是对方工作室不再重视项目，抽调人手；
当对方说进度来不及了，无法交付，可能是对方团队要去团建休假的婉转说法；
当对方说今天太忙无法回复,可能是说今天我不想理你。

不管多难，努力去做。那是真正重要的事情。

Onsite，出现在现场

常出差。

冲刺攻关时甚至可以考虑让两个团队在一起工作。但如果两个团队关系已经有裂痕的话，可能会适得其反。

更好的方法是在项目启动早期就安排团队一起工作一段时间，至少leader级别同事要一起有深入的合作。然后定期有一些见面。

更好的私交

职业化从来和私交不矛盾，更好的私人交情，是工作中的良好润滑剂。有可能的话，需要让协作团队培养更好的感情，这样大家就不会轻易觉得对方是SB了。

该团建就团建，该旅游就旅游，多出差，多吃饭，在不让人反感的情况下，多挖掘远程合作团队和个人的优点，告诉大家对方是多么靠谱，在一起是缘分，错过他们是你们一辈子的损失。

总结

远程合作的游戏项目，有大量的坑，主要体现在：