喜歡玩dota的朋友一定知道它是乙個5對5的競戰遊戲，不光需要遊戲人員的操作，還需要團隊意識和團隊配合，往往這種遊戲的比賽中都會有乙個隊長或者指揮人員，高潮時期往往隊長乙個指令，大家都必須不折不扣的放大招或者進行**的殺戮。
這時如果隊長的決策是錯誤則會導致「團滅」。
回到我們it團隊中也是乙個道理，往往我們的專案leader就承擔著這種隊長的職責，當乙個專案需要決策時一般會出現如下情形：
1、大家七嘴八舌、各抒己見，往往會產生多個決策意見，leader會結合大家的想法和自己的意見最終大家一起討論出乙個共同決策，基準是少數服從多數
2、碰到**的leader會一拍腦門獨自下乙個決策強迫大家執行，尤其是當他很有阻力的上完大號回來後
3、還有一種討論是大家都拿不定主意，於是最終出來的決策也是「走一步看一步」
當然還有很多情形這裡就不一一枚舉，我們這裡要討論的是第一種情形：「少數服從多數」
少數服從多數是我們從古人開始就傳下來的行為習慣，不管是團隊甚至是立法都是少數服從多數，在it團隊中這很有可能帶來乙個弊端：「有時正確的決策掌握在少數人手裡」。
因為實行」少數服從多數「的做法，所以往往少數人員到最後也不得不被迫執行多數一方的決策，但是回過來想一下，很多專案做到一半時發現了當初決策時的錯誤性，於是就會導致返工、責任扯皮、部分人員引咎辭職，尤其是」扯皮「在我國專案團隊中是很多見的，專案損失不大無所謂，萬一當時錯誤的決策導致專案帶來巨大損失時，我想此時大部人首要考慮的是先撇清責任，因為在專案考評中不存在」坦白從寬「。
昨天看電視，看到了乙個關於介紹以色列的經典理論–叫做」第十人理論「，這條理論規定，如果有9個人看到同樣的資訊並作出同樣的判斷，那麼第十個人必須必須做出與那九個人相反的假設，並努力證明那九個人是錯的。
這個理論很經典，而且我認為非常適合用到我們的it團隊管理中，但是很少有團隊利用這個理論
對於利用這條理論的我的觀點：
這裡首先假設我們團隊有五個人，又譬如我們在討論某個專案是否要使用關係型資料庫還是使用nosql資料庫時。
這裡要注意的是：專案決策團隊人員數一定要是單數，雙數沒意思的，你們懂得。
1、如果5個人一致認為要使用關係型資料庫，那麼隨機選擇乙個隊友讓他承擔反方，也就是在專案建設中去努力證明使用nosql資料庫是更適合的（貫穿全期）
2、如果2個人認為要使用關係型資料庫，3個人認為要使用nosql資料庫，那麼乾坤反轉，讓這2個人強迫支援nosql資料庫，另外3個人反過來支援關係型資料庫，並在決策期努力互相證明對方是錯誤的（只在專案立項期）
3、如果是4v1的陣容，那麼應該再拉入乙個人臨時進入團隊，這就是」第六人模式「，讓這第六人努力去證明 這雙方都是有問題的。
使用上述理論進行團隊決策可能的結果是：
1、少數服從多數依然在執行，不影響執行力。但是少數派承擔著監督多數派的責任
2、讓團隊成員學會換位思考、換角度思考，甚至是換腦思考
3、扯皮現象木有了，因為你沒有機會扯皮。如果多數派是勝者，那麼不代表少數派是錯誤的；如果多數派是輸者，那麼少數派就是正確的，但是如果在過程中沒有證明多數派是錯誤的，那麼少數派就是失職的
4、團隊的決策權更加弱化，大家都有機會成為決策勝利者。策勝利的一方。專案團隊雖然像打仗，但它並不是真正的打仗，戰場上只能有乙個人說了算是並不適合專案leader的
最後：」其實，很多在非it領域使用的策略和手段都可以借鑑到團隊管理中去，it團隊也是需要監督的，我們在大行團隊建設的同時別忘了進行監督和反證明，否則損失的就是老闆就是公司，傷的是程式設計師脆弱的心靈，」
而且，執行力有時太高很可能意味著「無腦和魯莽」。
團隊衝刺 第六天
00 二 地點 基礎教學樓八樓大廳 三 工作認領 張雪晴編寫資料庫，實現各種比賽訊息及專案資訊的上傳功能 尤凱麗編寫資料庫，實現學生的問帖和相關負責人的回帖等功能 牛俊燕負責實現註冊介面，完成註冊時簡訊驗證碼回覆的功能 谷偉華實現登入介面，能夠解決登入時的使用者許可權問題。天 還剩 0天 牛俊燕的工...
團隊衝刺 第六天
今天八點半召開例會 會議主要進行收尾工作。大部分功能已實現。距離衝刺結束還剩4天。任務剩餘15 左右。會議內容 劉 今天把登入註冊介面和其他介面聯絡起來了，完成了我的發帖模組。遇到的困難是理解不到位導致浪費了很多時間在獲取使用者名稱上。明天任務完成我的回帖模組。徐 今天完善了登入註冊模組，出現的問題...
第六次作業 團隊作業
loading.需要按實際的八張 匯入，如計算機系應該有三張 計算機實驗班，計算機卓越班以及計算機系分別分開匯入。驗證驗收標準需要細化，考慮每個介面每項操作的情景。原型的圖示格式存在一些小問題。根據最新的需求分析會議更改了部分需求，更新用例圖及類圖。根據新需求更改原型，結合需求完善功能需求部分。細化...