程序员往往都是些很固执的家伙。这很好理解：面对代码，你不能简单地说一句这里错了或者那里错了，你得把bug找出来，修改正确，那才能行。这是程序员的气质。

问题是一个团队里面不可能大家总是英雄所见略同，有分歧是必然的；如果大家都很固执，谁也说服不了谁，那么争得不可开交是不是也就是必然的？

不会处理分歧的团队很可能会这样。要么吵得不欢而散，甚至影响团结；要么把争议报给上级，或者大家都服气的技术牛人，让他来决定。

其实后面这种方式也是一种解决办法，只是有两个问题：

1) 用上级或者牛人的个人智慧代替了团队的集体智慧，一两次或许OK；但如果老是这样，谁又能保证这个人不会出错呢？

2) 当一个任务布置给团队，就类似于一次函数调用，上级想要的是获得一个明确的输出结果，然后对这个输出结果进行评审，而不是参与到产生这个结果的过程中；否则这个函数调用的意义在哪里呢？

所以研发团队必须学会处理意见分歧，这是团队合作必不可少的一环。

我忍不住吐槽一下我们的教育：貌似从小学开始我们就被教育要与别人合作，但貌似一直没有哪门课教我们怎样与别人合作，有哪些好的办法。

其实处理分歧的办法很简单：制订一些简单的规则，大家都遵守就行了。

既然是写给程序员的，我还是用一点程序员的语言。

一、最简单的办法叫做Random。随机数程序员都懂噻。喜欢打牌的人可能会叫做“抓阄”。

二、可能大家会说随机数太儿戏了，那么也有稍微不那么儿戏的办法，程序员把它叫“轮询”，喜欢打牌的人可能会叫做“轮流坐庄”。我女儿也会有类似的烦恼，小朋友们在一起，对于玩什么游戏意见不统一。我正在尝试教她和小朋友们协商：我们会一起玩很多次，这次听你的，下次听我的……

三、下面的办法适合于更认真的程序员。以三个人的小团队为例，我们可以先建一个“三步走”的处理模型，如下图：

这里我们分了三个基本步骤：1) 提出多种解决方法建议；2) 从这些建议中选出一种最好的；3) 再审核一下，这次选择的结果是否真的合理。如果审核通过，那么这次这次选择的结果就是最终的输出结果，所有人都要按照这个结果去办；如果审核不通过，那么回到第1步，重新来一次。

三个人的小团队就类似于有三个处理器的系统，所以下面我们需要做的是把处理模型分担到每个处理器上去。一种思路自然就是“流水线”处理方式：每个处理器承担一个步骤，即一个人负责提出建议，一个人负责选择，一个人负责审核。

采用这种方式可能会出现这个问题：每次选择都通不过审核。这时我们可以交换一下每个人承担的任务，看看会不会有改进。

划分为三个步骤，分别由不同的人负责，这就是研发团队版的“三权分立”，以规则保证每个人的智慧都得到尊重和发挥。

这种方式还可以有各种派生版本：例如第一步提出建议可以是三个人一起提，但选择和审核都分别只是一个人的责任。

如果不是三个人，只有两个人，怎么办？我们可以把模型简化为“两步走”，比如去掉“审核”。

如果超过三个人怎么办？可以多个人负责提出建议，一个人负责选择，一个人负责审核。显然人比较多的时候，负责选择或审核的人权利与责任比较大，对于这一点我们就可以把“轮询”又搬出来了。

这只是个处理分歧的基本方法，我们可以派生出各种各样的其他版本。

总之，方法是很多的，重要的是团队中每个人都要明白以下三点：

1、有分歧很正常。

2、有分歧不能搁置，不能推给其他人，必须解决。

3、一味争执没有用，要制订出一个规则；只要保证规则对每个人都是公平的，那么每个人都要遵守。

其实大多数时候，投票就OK了。