重复沟通与内审：提升小微研发团队效率的方法
本文的讨论局限于 15 人以内的纯游戏研发团队。
日常游戏研发中，会出现研发结果与原始设计不一致的情况。尤其是对于休闲游戏「小步快跑」的情况，1-2 天出一个小的功能版本，紧赶慢赶做出来发现实现的效果居然不一样，返工就浪费时间了。
从这个意义上说：不返工，一次实现设计，就是效率提升。
撇开人员能力胜任不谈 ，本文讨论在沟通上如何提升效率。
遥远的偏差
在一个标准的功能开发循环中，流程如下图所示：
图像 1: 2809_cycling1.svg
这个流程可能导致如下问题：
美术、程序对文档产生不同的解读。
测试岗距离文档遥远，信息不足。
策划在产品最终输出后才看到成品。
验收距离文档生成时间久，文档的解读在四个不同岗位发生偏差的可能性大。
策划总是希望写出完美的文档。实际工作中，无论时间的要求，还是精力和能力的限制，都让文档不可能做到事无巨细。更何况，每个岗位都可能根据自己的岗位特点和经验先入为主，造成文档解读不力或者过度解读的现象。
当策划最终看到成品（或者半成品）的那一刻，再回炉重造已经晚了。消耗的时间可能只有一两天（或者一两周），但面对不可变化的版本发布时间，团队只能继续加班加点，试图通过增加工作时间来弥补由于沟通不利犯下的错误。
我们需要增加内审流程。
两次内审
Boehm在 1988 年就提出了螺旋式软件开发模型，这个模型坐标系的第一象限，是 识别和解决风险。
图像 2: spiral_model_boehm_1988
上图来自 Wikipedia: 软件开发的螺旋模型
( https://en.wikipedia.org/wiki/Spiral_model )
下面看看加入内审后的功能开发循环。
我们在美术动工之前，以及美术完工之后，加入两次内审，来降低研发工作中的风险性。
图像 3: 2809_cycling2.svg
第一次内审的目的是同步意图，需要策划、美术、程序、测试四个岗位的全部人员参加。
对于美术，需要确立功能的质量标准和工期，避免在艺术上过度追求完美。
对于程序，需要确定研发风险，判断功能难度，避免过度开发不必要的功能，也需要在这个阶段确定后续功能的延展性，让程序在系统研发上留好扩展位。
对于测试，需要了解整个设计和岗位合作的全貌，以便在功能完成后，进行针对性且不过度的测试。
第一次内审的这个过程，一定要 当面拉会。
根据我的经验，所有的研发团队都讨厌开会，但这个会是 一定要开的会。如果不开这个当面会议，各岗位就会按照自己对文档的理解直接开始工作，最终必然出现文章开头讲到的「遥远的偏差」。
第二次内审的目的是确定 美术的技术标准，需要该功能的策划、美术、程序的主要岗位参加，再由主要岗位传递给所有参与功能研发的岗位。如果传达错误或者传递不到位，就说明第二次内审是失败的。
同步美术的技术标准，实际要做的是下面几点：
确保美术按照策划需求完成了程序需要的所有资源；
确保这些资源都能按程序要求的格式和标准提供；
确保资源和技术能在文件大小，表现性能上达到最优；
重新梳理美术和程序的分工职责，保证工作效率最高。
程序岗位是最终产品搭建的执行者，但程序搭建使用的材料是其他岗位提供的。由于每个岗位对实现标准，最终效果都有自己的理解，本次内审就是要在程序动手干活之前，把这些标准和规则同步到一个最佳的状态。注意，不要最完美的状态，而要最合适的状态。
这次内审需要主要岗位参加，内审中要充分发挥主要职责人员的主观能动性，充分听取各方面的意见，策划也需要坚持自己的标准，并能适时根据开发周期和市场需求做出平衡调整。这对于策划的能力与经验的全面性要求很高，更考验的是产品策划人员的沟通能力。
三阶意向性
内审，本质上是一次多方沟通。多方沟通，尤其是不同岗位的多方沟通，涉及到唇枪舌战，涉及到意向性理解问题。
邓巴教授，也就是发现邓巴数150的那位人类学家，曾经提出过一个「意向性理论」，用来判断你猜测他人意图的能力。
一阶意向性：你能读懂自己的意图。比如，我知道自己喜欢吃苹果。
二阶意向性：你能读懂他人的意图。比如，我知道你也喜欢吃苹果。
三阶意向性：你能感受到他人对你的感知。比如，我知道你知道我喜欢吃苹果。
四阶意向性：你能感受到他人感受到的对你的感知。比如，我知道你知道我知道你喜欢吃苹果。
我们需要一种沟通方法，来解决研发团队沟通中的 三阶意向性 问题，也就是解决 「我以为你以为的就是我以为的」 问题。
X-Y 问题
多方沟通可能出现信息不对称，把手段当目的，舍本逐末等问题。这些其实都是 X-Y 问题 的变体。
X-Y Problem
via CoolShell( https://coolshell.cn/articles/10804.html )
有人想解决问题X
他觉得Y可能是解决X问题的方法
但是他不知道Y应该怎么做
于是他去问别人Y应该怎么做？
简而言之，没有去问怎么解决问题X，而是去问解决方案Y应该怎么去实现和操作。于是乎：
热心的人们帮助并告诉这个人Y应该怎么搞，但是大家都觉得Y这个方案有点怪异。
在经过大量地讨论和浪费了大量的时间后，热心的人终于明白了原始的问题X是怎么一回事。
于是大家都发现，Y根本就不是用来解决X的合适的方案。
X-Y Problem最大的严重的问题就是：在一个根本错误的方向上浪费他人大量的时间和精力！
有个介绍 X-Y Problem 的专门网站( https://xyproblem.info/ )，可以去看一看。
三步沟通法
沟通，尤其是多方沟通，就是保持大家的想法一致。
抛开通用的日常沟通技巧不谈，三步沟通法 就是要解决对方案理解不统一的现象，同时避免 X-Y Problem。
流程上也就是简单三步：
产品策划岗在准备充分，文档资料完整的前提下，详细阐述自己的设计思路和期待的结果。
程序岗和美术岗完整复述对于策划文档的理解，并分解成自己岗位的工作，进行详细阐述。
产品策划岗位再次根据第二步的结果进行补充。
说是三步沟通，实际上不止三步。因为第二步可能出现理解偏差，第三步又可能出现新的信息。第二步和第三步是一个无限循环，在持续沟通中，不断出现在文档中没有出现的新信息，产生新的需求，又由于资源和时间的限制不断调整，直到参加会议的多方都能达成一致为止。
研发团队是一个组合
我知道，在创意研发团队中，保证大家的想法一致非常难。优秀的研发团队是一个组合而不是一个圈子。组合就允许每个人能够保留不同的思想而不强求唯一。
研发团队应该允许个体保留个性、观点和做事风格，而且也只有这样，每个人才能对团队有独特的贡献。每个人有自己的特点，但是所有人又有一个共同点。
正所谓 「君子和而不同，小人同而不和。君子周而不比，小人比而不周」。
我们很难要求大家想法一致，但为了保持最终的产品质量，我们至少要保证团队能完整理解，并严格执行内审后的方案。
重复沟通，认真内审，这就是小微研发团队提升效率的方法。