團隊效率很大程度上受團隊管理者的影響：
1. 團隊管理者的能力決定了團隊成員的能力提升水平的上限。
2. 團隊管理者的管理方法決定了團隊整體運作的效率。
在互聯網、遊戲公司，更是這樣。這樣的公司和傳統的軟件公司相比，產品週期更短、變化更多、更新更快、團隊更小，但是在軟件質量上相應的要求會低一些。因此在管理上更是要求在保證質量的前提下，儘可能的提高效率。
在我的項目經驗中，感覺有一些好的方面是可重複的，技術出身，習慣性的叫它們“模式”了。我把這些模式的介紹，以GOF設計模式的形式進行組織。先提出模式的背景問題，再給出解決方案，最後說明使用此模式的效果。
另外，有模式，就有反模式。常見的錯誤做法，也應當列出來，讓每一個人，在試圖做類似的事情時，能更快的識別出來，不重蹈覆轍。
團隊效率模式
下屬培養
問題
團隊效率要提高，每個人都要能獨擋一面，關鍵時刻誰都能上前線。這就要求每一個人都具備比傳統軟件行業相對更高的技能水平。
在互聯網、遊戲行業，團隊的管理者往往是團隊中技能水平最高的，這一方面是由於管理者對整個技術方面把握比較好，能更快針對問題提出好的Solution；另一方面也是希望管理者能帶動團隊技能提高。
如果團隊中只有一個精英骨幹，其他人都能力差太遠，那麼，結果往往是以下幾種：
1. 隨着軟件規模變大，骨幹一個人力量支持不住，導致項目效率下降。
2. 隨着軟件趨於穩定，骨幹的工作趨於常規，如果骨幹換崗或離職，項目立即缺少能繼續維護的人，導致項目危機。
3. 隨着團隊變大，更多的人寫出有問題的代碼需要骨幹來調試和修正，項目效率將變低。
方案
骨幹或是管理者需要以下屬培養爲首要任務。
下屬培養可以有多種形式：
1. 多讓下屬分擔任務，並多加協助。初期可能效率會有下降，但當下屬技能提高，會帶來長期的效率提高。
2. 多進行技術交流，並帶動大家不斷提高自己技能。分享自己解決的問題，與大家一同討論自己的設計思想。讓團隊成員更多的是瞭解Why，而不是How。
3. 讓達到一定水平的下屬去帶動其他的團隊成員，或是作爲新員工的導師。教會別人，能讓自己已經掌握的知識更牢固，還可能在交流中形成新的知識提高自己。
4. 制定明確的考覈標準，以統一的質量要求考覈團隊中的每一個人的工作成果。
效果
在下屬培養初期，會有小量的效率降低。
但當所有下屬的提高的程度已經可以抵消管理者進行下屬培養所減少的的那份後，效率將開始提高，並會因爲下屬的能力提高而不斷提升。
另外，隨着下屬培養和技術交流成爲團隊成員的習慣，會對整個過程產生正反饋，讓團隊變的更加有效。
能讓新進入的團隊成員也很快加入這個過程中，團隊的成員變化和成員離開對項目的影響也會給團隊帶來更小的影響。
壓力傳遞
問題
產品的變化快，競爭對手跟進快，哪家的團隊稍有懈怠，就會被落在後面。而你的團隊中，似乎只有幾個核心成員急的火燒眉毛，其他同事好像沒有意識到項目的緊急程度。
原因往往很簡單：核心成員或是管理者沒有將壓力傳遞到下屬。
新提升上來的管理者往往會因爲人緣方面的考慮，而在壓力傳遞上有很多顧慮。怕自己對下屬說的多了會引來不滿，怕下屬壓力大了會有牴觸心理。於是就把壓力自己抗着，對下屬實行招安政策，甚至是對下屬的一些不職業化的做法和心態也採取縱容態度。時間越長，下屬對項目的敏感就越低，團隊的效率也就無可挽回的開始下降了。
方案
管理者應當及時的把壓力傳遞到下屬一層。讓下屬隨時瞭解到項目目前的情況；進度是怎樣的；競爭對手與我們的距離；我們產品的缺點在哪裏，如何改進；我們產品的長處在哪裏，如何長期保持。
如果在緊張的時候，下屬並沒有一起緊張起來，就需要提醒下屬目前是緊張時刻，更多的把時間放在可以立竿見影的工作上。
1. 完成還沒完成的需求
2. 修正產品BUG
3. 改進用戶體驗
4. 優化界面
5. 提高程序效率
6. 在儘可能少的時間裏完成必須的任務
7. 花更多的時間用於把自己負責的工作做的更好。
在並不是非常緊張的時候，也需要安排下屬爲後面可能的緊張時刻做好準備，打好提前量。
1. 把需要做的基礎工作做紮實
2. 把一些早晚要做的事情開始一件件作起來
3. 把產品可以優化的點繼續優化
4. 把相對領先的內容做的更好。
5. 將目前的技術實踐進行積累抽象，爲後面的工作或其它項目做些準備。
總之，不會有沒有事情做的情況，如果沒有事情做了，只能說，團隊冗餘太大了。要麼就是你的項目是非常重要的項目，需要做人才儲備；要麼就是需要減員精效了。
開始使用壓力傳遞時，會引來一些牴觸，這個是正常的情況，需要管理者與團隊成員進行有效溝通。其實大家都是做項目的，也許各人對從項目中能獲得的收穫的預期不同，但至少有一點是一定要一致的，那就是沒人希望項目失敗。所以做好每個人的工作，渡過壓力傳遞適應期後，會迎來一個好的結果。
效果
每個團隊成員在瞭解了項目的壓力後，可以感同身受，與項目節奏一起呼吸，步調也與項目同步。
在項目緊張時，每個人都能自發的開始緊張起來，爲項目做好自己負責的部分，並能儘可能的做好相關的一些額外內容。
在項目穩定時，每個人都能積極的進行優化，並能保持比較高的效率，把項目做的更好。
團隊效率反模式
救火隊員
問題
作爲一個團隊的管理者，或是團隊骨幹，所有的問題都自己解決。出發點往往有以下幾個：
1. 我做的更快
2. 我沒有時間來指導別人做
3. 這麼緊張，讓下屬做更緊張，給下屬壓力太大
4. 這個問題難度高，不好教會的
5. 這個技術很核心，教給別人，跑了就把技術帶走了
於是，越來越多的問題“只能”由管理者或是團隊骨幹來做，時間長了，管理者或骨幹成了整個團隊工作效率的“關鍵路徑”。而且隨着事情越來越多，這條路徑的效率越來越低下，導致團隊效率下降。
最後，管理者或骨幹撐不下去，走掉了。項目無以爲繼，出現問題無人能解決，核心技術真的Gone with the wind了。
方案
使用下屬培養和壓力傳遞兩個模式
效果
團隊中核心代碼有至少兩人瞭解，其它部分的功能有多人瞭解。查找修正問題的辦法團隊中每個人都瞭解。遇到問題時，大家任何一個人在場都能站出來解決。每一次解決問題，當事人的滿足感和責任感都進一步得到加強。更少的人會從團隊中流失，因爲這個團隊纔是他們想留下的地方，他們能從這個團隊得到更多。
下一篇《團隊效率模式（二）》提到：
郵件確認模式：確保工作中的每一環做的好壞就可以量化，並且在事後可以對結果進行評估，以便找出短板，進行效率上的改進。同時也避免了由於沒及時確認導致的時間浪費、工作反覆、計劃混亂。