为什么远程合作的游戏项目不好做(下篇):原因剖析与解决方案

发表于2017-11-17
评论0 1.5k浏览
文:顾煜

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

  信任感的缺失和文人相轻

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

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

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

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

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

  依赖关系

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

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

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

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

  目标不同

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

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

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

  解决方案在哪里?

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

  选择好的协作模式

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

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

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

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

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

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

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

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

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

  选择好的协作团队

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

  选择好的团队成员

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

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

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

  做好沟通

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

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

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

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

  Onsite,出现在现场

  常出差。

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

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

  更好的私交

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

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

  总结

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

  • 沟通很困难,信息沟通不全面,延时比较长
  • 团队彼此缺乏信任感
  • 更长的依赖关系,导致一旦出问题,影响环节非常多·多个团队可能有不同的目标

  解决方案并不好找,对可能有的坑,做一些针对性的弥补,是一个好办法,另外还可以做的是:

  • 选择更好的协作模式,参考各类游戏外包业务·选择好的协作团队
  • 找好的团队成员
  • 出差,一起工作
  • 私下交情也很重要

  愿天下没有难做的项目。

原文链接

著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台