团队管理中的第六人模式
? 喜歡玩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團隊也是需要監督的,我們在大行團隊建設的同時別忘了進行監督和反證明,否則損失的就是老板就是公司,傷的是程序員脆弱的心靈,”
?? 而且,執行力有時太高很可能意味著“無腦和魯莽”。
?
總結
以上是生活随笔為你收集整理的团队管理中的第六人模式的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 美格信-骨传导成品耳机测试
- 下一篇: 多台服务器之前免密复制