也談團隊管理-如何打造有戰斗力的團隊
最近中生代技術群發起北京閉門會議，主要的討論議題就是如何做團隊管理，本人有幸參加這個閉門會議并且做了一些粗淺的分享，這里給做一個總結和回顧。
從3年前離開亞馬遜到現在，也在不同的公司混了一圈，雖然本人自詡為程序員老司機，但是由于工作的需要，從2014年開始就開始從事管理工作，雖然之前也帶團隊，但是一直不是管理的title。做管理兩年以來，有很多的心得和體會，經常反思之前作為團隊成員的一些想法和做法，發現，其實管理是一門很深的學問，以前沒做管理，不太理解的一些事情，現在也能慢慢理解了。
言歸正傳，我們還是談回這篇文章的主題——管理。
首先，我們來談談什么是管理。
國內大多數公司的中層乃至高層的技術管理，一般都是技術出身，基本是程序寫的好就去帶團隊，但是，想想管理的本質是什么?個人愚見，管理就是管人，帶人就是帶人心。右軍大神曾經有一篇談論軟件質量的文章，其中提到一個理念，就是“團隊的leader不重視質量，你的團隊就不會重視質量”，這個道理其實也適用于管理團隊——“你希望你的團隊是什么樣子，你的團隊就是什么樣子”，正所謂“兵慫慫一個，將慫慫一窩”。那么，各位看官可能就會問了，我當然希望我的團隊是富有戰斗力的強大的團隊，你說的這些我也都懂，但是到底應該如何做呢?
我們在帶團隊尤其是技術團隊的過程中，都會遇到各種各樣的問題，比如說缺乏組織，缺少溝通，角色和職責劃分不明確等等，也有些人會抱怨說團隊里面沒有一流的人才，沒有能獨擋一面的人，但是，我認為這都不是團隊效率低下的根本原因，與其他原因比較，最大的原因是團隊缺少正能量，缺少領導力。那么我們來看看什么是領導力。
培養團隊成員的領導力
領導力有很多方面，根據十幾年的混跡于大公司和創業公司的經驗，我把領導力總結為如下幾個方面：
- 責任感、主人翁意識
- 執行力、崇尚行動
- 創新力、化繁為簡
- 勤回顧、自我批評
- 多付出、贏得信任
- 肯鉆研、刨根問底
- 有氣量、選賢育能
- 重交付、達成業績
下面，我們就這幾個方面來做一一的解讀：
責任感、主人翁意識
所謂主人翁意識，就是他們會從長遠考慮，不會為了短期業績而犧牲長期價值，他們不僅僅代表自己的團隊，而是代表整個公司行事;他們從不說“那不是我的工作”。他們往往以一腔熱忱維護自己的主張，為他們認為有益于業務發展的理念而努力。公司的成功需要領導者長期傾注大量心血，是他們責無旁貸的利益所在。
有些人可能會說，我非常符合上面所描述的情形，我做事親力親為事無巨細，我為團隊和公司嘔心瀝血，但是，團隊還是沒有起色，大家好像都無所事事，或者小心翼翼。其實，這是對主人翁意識的過度運用，他們在工作中投入了大量的心血，以至于剝奪了他人的發展機會，事無巨細，一管到底，往往會在團隊合作的過程中起到相反的作用。而沒有責任心和主人翁意識的人，對有些事，“事不關己，高高掛起”。完全就是上班掙錢;如果看到有任務需要完成或者有不足之處可以改進，他們就想當然地認為會有其他人來管。
因此，團隊管理就是要努力地培養大家的責任感，主人翁意識，想做到這一點，就需要增強團隊成員的參與感，讓他們知曉并理解所做事情的價值、來龍去脈，不斷地強化使命感。具體的做法有一下幾點：
構建全棧小團隊
現在很多公司和團隊強調全棧工程師，這固然好，但是對于初創團隊或者說非知名的公司，這一點很難做到，公司的背景和經濟能力都不足以支撐招聘全棧工程師的成本(全棧工程師大家的理解不同，這里不做糾結，因為筆者曾經服務于亞馬遜，因此心中的全棧工程師還是非常牛X的)，這就需要我們退而求其次，沒有全棧工程師，就打造全棧團隊，進而努力培養自己團隊的全棧工程師。
全棧小團隊
根據“康威定律”，軟件架構是由組織的架構決定的，因此按照貝索斯“two-pizza”團隊的理論和敏捷方法，構建小的團隊有利于團隊的自治，我們通過讓一個小的團隊有比較全面的建制，Leader(往往是團隊的架構，熟悉業務和技術)+ 前端工程師 + 后端工程師，往往可以能夠比較獨立地承接一個或者幾個業務silo的工作，這樣，團隊成員整體負責一個或者幾個業務模塊，可以極大地提高團隊成員的參與感、使命感和責任感，團隊成員相互幫助，高度自治，形成一個具有共同利益的小團體，大家要么一起成功，要么一起失敗，正如下圖所示，我們團隊的劃分，是按照業務線劃分的。
按業務劃分團隊
當然，隨著業務的復雜度的增加，可以按照業務/子業務線的方式來劃分團隊，我們并不是絕對的扁平化，而是嚴格遵循two-pizza原則。
大團隊的拆分方式
崇尚行動，執行力
執行力和行動力是一個團隊是否能夠獲得成功的必要條件，因此，必須在團隊中樹立行動的意識，所謂“停止空談，馬上行動”。
執行力
我們的團隊沒有大多數公司的所謂架構師、測試、和運維的角色，通過為團隊提供自動化運維和自動化測試的平臺和工具，讓開發人員負責軟件開發生命全周期;事實上，只有研發才真正知道系統如何部署、如何調試、如何監控;我們的架構師也是開發人員，大部分都assign到了各個業務團隊，我們更加崇尚“開發參與架構設計，而不是架構師參與開發”的理念。“吃自己的狗糧”也是我們比較推崇的文化，全團隊構建運維的意識，避免開發完功能就萬事大吉的思想;另外，引入了Amazon的”臭名昭著“的On-Call制度，從而讓團隊所有人能夠比較全面的了解系統的各個部分，能夠做到相互補位，避免”這不是我的事情“的情形發生。
回顧、自我批評
做的越多，可能錯的也越多，回顧不是找責任，復盤的目的是為了找到切實可行的解決方案，避免再犯。
贏得信任
團隊成員彼此信任是非常重要的，尤其是團隊中比較資深的人。由于按照業務和two-pizza原則切分團隊之后，隨著系統復雜度的增加，跨團隊的溝通越來越多，因此，成員對于事情的推動力就顯得非常重要;另外，一旦涉及到系統間、服務間以及團隊間的合作，問題就會復雜起來，因此，將復雜的問題分解，簡化，用簡單直接的方法解決復雜問題的能力，也就變得尤為重要，我們要幫助大家建立這種能力，避免過度設計或者過度承諾。團隊的領導者要作為團隊的標桿，鼓勵團隊知識分享，建立學習型團隊
交付、達成業績
對于團隊來講，對于目標的強烈關注，可以讓成員更加的專注結果，通過過程的可視化，讓研發過程對于團隊成員整體可見，有利于控制項目風險，通過可量化的指標對過程和結果進行有效地評估，可以有效地降低產品和項目交付的風險，再輔以進度的合理追蹤和結果的定期回顧，讓團隊意識到自己的問題，在未來的過程中持續改進。
選賢育能
領導力準則不光要在團隊中塑造，也需要應用到日常的招聘當中，在招聘新人的過程中，不能夠只盯著候選人有什么經驗，會什么框架，也需要著重考量他們的綜合素質，一個領導力好的候選人，能夠非常快速地融入團隊，也能夠非常快的學習一些知識。我們鼓勵團隊中資深的成員帶新人，這樣有利于知識的分享以及風險的降低，我們還逐步建立導師制度，而導師制度是團隊中資深人員進一步晉升的重要量化考核指標。
任職資格
任職資格的理論我就不講了，也不是這塊的專家，當時，我們還是在逐步建立自己的任職資格體系，一方面，幫助HR和用人部門在招聘以及晉升的工作中建立一個明確的標準，另一方面，也希望團隊成員明確自己在團隊中的位置，明確如果希望晉升，團隊對個人的要求以及個人需要對團隊做出怎樣的貢獻。
下面這個模型參考了《技術管理之巔》這本書中的內容。
任職資格模型
總體來說，任職分為專業序列和管理序列，這里我只列出了技術序列的職級列表和能力級別。根據不同的職級范圍，我們總結了每個職級的具體要求以及如何做，才能晉升到下一個級別，這里主要都是軟實力和交付的體現，因為我們認為，必要的架構能力、設計能力以及編程能力，是每個級別的成員都應該具備的，這里，我列舉一下SDEIII(P7)的職級要求以及晉升標準。
任職資格要求
人才盤點
隨著團隊的規模的擴大，團隊中的成員一定需要區分梯度，下面引用業界比較流行的"人才九宮格“并根據自己的實際情況，總結了我們自己的人才九宮格：
人才九宮格
圖中，按照潛力和業績兩個維度，將人才進行了不同維度的區分，其目的是找到團隊中績效好，有潛力的成員，著重培養，也就是所謂的核心人才;對于潛力和業績低于預期的成員，加以督促改進甚至淘汰并維護好穩定性人才，保持團隊穩定性，而對于明星人才，需要加以晉升。
對應策略
員工激勵
最后，我們來談談人員激勵。對于激勵，其實有很多的討論，那么到底如何激勵員工呢?靠薪酬和股票?不然，對于公司尤其是創業公司來講，不可能為人才付出絕對數值的薪水，至于期權，我只能呵呵了。
那么，到底如何做呢?也就是在資源有限的情況下，如何激勵團隊成員呢?我認為建立具有正能量的團隊氛圍尤為重要。
建立團隊文化
建立團隊文化
一般而言，企業需要盈利，一定是業務導向的，很少有工程師決定一切的企業文化，因此建立所謂的工程師文化太過理想化，但是，建立”尊重工程師文化“的團隊確實是切實可行的。
首先，我們鼓勵團隊的Leader和領導跟下屬定期進行一對一的溝通，稱之為1:1 talk，從而確保團隊成員尤其是核心成員的想法和訴求得到一定程度的滿足;
其次，給每個成員充分的授權，也就是管理者要充分地相信自己的團隊，如果大方向沒有問題，即使有一點繞路，也不要過分的干預，防止”微觀管理“，事無巨細(還記得主人翁意識的過度運用么?)
第三，團隊成員要盡可能地分享自己的知識和想法，大家互相學習，也通過分享能夠總結自己學習過程中零散的知識點。
第四，團隊的管理者在遇到問題的時候，要聚焦答案，就是論事，不要過分詰責，要與團隊一起找到問題的解決方案，不要過分的糾結事情是如何發生的。
第五，也是最重要的，要傳遞正能量，有效地解決團隊成員以及團隊之間的分歧，而不是制造矛盾，可以參考關系階梯法。
績效考核
賞罰分明，避免大鍋飯，非常有必要。績效考核有多種方法，可以是KPI也可以是OKR，但是不要太過追求形式，主要的目的還是幫助團隊成員成長。下圖為我們簡化過的團隊KPI的考核方式，明年隨著團隊業務逐漸穩定，我們會逐步用OKR的考核方式替換KPI。
KPI列表
末位淘汰
對于績效不好的員工，而且無法有效改進的，需要進行末位淘汰，防止帶來團隊負能量。
總結
【本文為51CTO專欄作者“王東”的原創稿件，轉載可通過作者簡書(krisdwang)獲取聯系】
