團隊效率很大程度上受團隊管理者的影響：
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
了。方案
使用下屬培養和壓力傳遞兩個模式
效果
團隊中核心**有至少兩人了解，其它部分的功能有多人了解。查詢修正問題的辦法團隊中每個人都了解。遇到問題時，大家任何乙個人在場都能站出來解決。每一次解決問題，當事人的滿足感和責任感都進一步得到加強。更少的人會從團隊中流失，因為這個團隊才是他們想留下的地方，他們能從這個團隊得到更多。
：郵件確認模式：確保工作中的每一環做的好壞就可以量化，並且在事後可以對結果進行評估，以便找出短板，進行效率上的改進。同時也避免了由於沒及時確認導致的時間浪費、工作反覆、計畫混亂。
聊一聊如何提公升團隊開發效率
又是一年年底了，又到了忙著總結，忙計畫的時間了，相信每年的總結計畫裡，大家都有提高團隊開發效率的計畫。列了一大堆提公升計畫和目標。然而，這些計畫真的執行了嗎？這些目標都完成了嗎？過去的一段時間我一有機會就跟其他開發人員交流，並去試著從開發人員自身的角度去發現一些痛。有的開發人員抱怨限制太多，沒有意義...
聊一聊如何提公升團隊開發效率
又是一年年底了，又到了忙著總結，忙計畫的時間了，相信每年的總結計畫裡，大家都有提高團隊開發效率的計畫。列了一大堆提公升計畫和目標。然而，這些計畫真的執行了嗎？這些目標都完成了嗎？過去的一段時間我一有機會就跟其他開發人員交流，並去試著從開發人員自身的角度去發現一些痛。有的開發人員抱怨限制太多，沒有意義...
技術團隊的情緒與效率
原文 引 為什麼工程師的效率有那麼明顯的波峰波谷？負面情緒與工作效率有什麼關係？團隊 leader 應該怎樣保證整體的效率輸出與大家的成長？為什麼醉心於技術的同學做專案總是虎頭蛇尾？對工程師來說經常會有明顯的效率差異，有時一天能搞定好幾個模組，順帶加了好幾個新的技能點，而有時乙個簡單的功能投入了兩三...