程序員往往都是些很固執的傢伙。這很好理解：面對代碼，你不能簡單地說一句這裏錯了或者那裏錯了，你得把bug找出來，修改正確，那才能行。這是程序員的氣質。
問題是一個團隊裏面不可能大家總是英雄所見略同，有分歧是必然的；如果大家都很固執，誰也說服不了誰，那麼爭得不可開交是不是也就是必然的？
不會處理分歧的團隊很可能會這樣。要麼吵得不歡而散，甚至影響團結；要麼把爭議報給上級，或者大家都服氣的技術牛人，讓他來決定。
其實後面這種方式也是一種解決辦法，只是有兩個問題：
1) 用上級或者牛人的個人智慧代替了團隊的集體智慧，一兩次或許OK；但如果老是這樣，誰又能保證這個人不會出錯呢？
2) 當一個任務佈置給團隊，就類似於一次函數調用，上級想要的是獲得一個明確的輸出結果，然後對這個輸出結果進行評審，而不是參與到產生這個結果的過程中；否則這個函數調用的意義在哪裏呢？
所以研發團隊必須學會處理意見分歧，這是團隊合作必不可少的一環。
我忍不住吐槽一下我們的教育：貌似從小學開始我們就被教育要與別人合作，但貌似一直沒有哪門課教我們怎樣與別人合作，有哪些好的辦法。
其實處理分歧的辦法很簡單：制訂一些簡單的規則，大家都遵守就行了。
既然是寫給程序員的，我還是用一點程序員的語言。
一、最簡單的辦法叫做Random。隨機數程序員都懂噻。喜歡打牌的人可能會叫做“抓鬮”。
二、可能大家會說隨機數太兒戲了，那麼也有稍微不那麼兒戲的辦法，程序員把它叫“輪詢”，喜歡打牌的人可能會叫做“輪流坐莊”。我女兒也會有類似的煩惱，小朋友們在一起，對於玩什麼遊戲意見不統一。我正在嘗試教她和小朋友們協商：我們會一起玩很多次，這次聽你的，下次聽我的……
三、下面的辦法適合於更認真的程序員。以三個人的小團隊爲例，我們可以先建一個“三步走”的處理模型，如下圖：
這裏我們分了三個基本步驟：1) 提出多種解決方法建議；2) 從這些建議中選出一種最好的；3) 再審覈一下，這次選擇的結果是否真的合理。如果審覈通過，那麼這次這次選擇的結果就是最終的輸出結果，所有人都要按照這個結果去辦；如果審覈不通過，那麼回到第1步，重新來一次。
三個人的小團隊就類似於有三個處理器的系統，所以下面我們需要做的是把處理模型分擔到每個處理器上去。一種思路自然就是“流水線”處理方式：每個處理器承擔一個步驟，即一個人負責提出建議，一個人負責選擇，一個人負責審覈。
採用這種方式可能會出現這個問題：每次選擇都通不過審覈。這時我們可以交換一下每個人承擔的任務，看看會不會有改進。
劃分爲三個步驟，分別由不同的人負責，這就是研發團隊版的“三權分立”，以規則保證每個人的智慧都得到尊重和發揮。
這種方式還可以有各種派生版本：例如第一步提出建議可以是三個人一起提，但選擇和審覈都分別只是一個人的責任。
如果不是三個人，只有兩個人，怎麼辦？我們可以把模型簡化爲“兩步走”，比如去掉“審覈”。
如果超過三個人怎麼辦？可以多個人負責提出建議，一個人負責選擇，一個人負責審覈。顯然人比較多的時候，負責選擇或審覈的人權利與責任比較大，對於這一點我們就可以把“輪詢”又搬出來了。
這只是個處理分歧的基本方法，我們可以派生出各種各樣的其他版本。
總之，方法是很多的，重要的是團隊中每個人都要明白以下三點：
1、有分歧很正常。
2、有分歧不能擱置，不能推給其他人，必須解決。
3、一味爭執沒有用，要制訂出一個規則；只要保證規則對每個人都是公平的，那麼每個人都要遵守。
其實大多數時候，投票就OK了。
原創作品，允許轉載，轉載時請務必以超鏈接形式標明文章 原始出處 、作者信息和本聲明。否則將追究法律責任。http://yuesiyuewei.blog.51cto.com/4281387/1114477