團隊管理基礎：3個要點讓團隊平衡發展

作者：網易杭研項目管理/曹智清（本篇文章僅限知乎內部分享，如需轉載，請取得作者同意授權。）

本文作者將從三個角度說說如何關注和打造團隊發展平衡的基礎。

和談戀愛一樣，痛過苦（哭）過，後來，我們才學會如何去愛。我們做項目、做產品、拼世界的同時，永遠需要另外一股力量，打造團隊更堅實的基礎，營造團隊更溫暖的港灣。這是產品老大們都要敬畏的生存現狀，是團隊都要注意的發展平衡，更是每個項目經理要固守的項目根本。

記憶里小說中的橋段：某潛力股青年，為了掙得讓女友幸福生活的家產，在外打拚多年，成功歸來卻發現物是人非。輸了你，贏了世界又如何，多麼痛的感慨。

身邊不少新聞中的段子：某公司年輕高管，坐擁千萬乃至上億家產，終因勞累過度，意外猝死。輸了自己，贏了世界又如何，多麼痛的領悟。

其實，我們做產品做項目的過程里也不乏這樣的經歷。

互聯網世界，瞬息萬變，每一個玩家都在玩命地快快快！每一塊業務都在飛速發展！當你在風口上的時候，即使你比豬還胖，你也必須要飛起來！

這時候，所有的眼睛都盯著業務，盯著KPI，盯著發展；所有的需求都只能應對最重要的業務功能或者運營活動，影響稍小點的用戶bug都只能靠邊站；各個版本只來得及實現需求中最最重要且緊急的，並且還不斷砍掉些看起來不那麼重要的小點；運營也是忙得飛，用著虐心的後台也得把長長的內容給錄入進去，還要上接用戶下接供應商攏起無數條線頭……加班，根本停不下來！~~~~>_<~~~~

有沒有感覺我們在拼世界的同時，似乎忽視了什麼？

忽然有一天，線上開始連著出事故，一看原來都是以前欠下的債！然後團隊規模是之前的兩三倍，但產能似乎上不去，比以前多幹不了多少事兒，而且成天對加班怨聲載道的。再然後，一個一個開始離職，核心功能開始無人能懂……

和談戀愛一樣，痛過苦（哭）過，後來，我們才學會如何去愛。我們做項目、做產品、拼世界的同時，永遠需要另外一股力量，打造團隊更堅實的基礎，營造團隊更溫暖的港灣。這是產品老大們都要敬畏的生存現狀，是團隊都要注意的發展平衡，更是每個項目經理要固守的項目根本。

從三個角度說說如何關注和打造這樣的基礎：

有關人

指標：新老員工比例不應超過1:1，其中新員工包括正職/借調+實習生……

原因：無人指導和關懷的新人就是添亂，除了搞亂那本已有點亂的代碼外，更容易造成老人煩躁，以及新人本身的諸多怨氣最終導致不穩定。另外，當新人從人數和文化氛圍上強過老人時，原有的文化會被顛覆，種種不和諧應運而生。

應對：不要在短期內招過多新人，招一批帶一批，成熟一批後再招一批；每個團隊都要建立自己的新人入門指南，每個新人要有正規的方式介紹給團隊；從了解公司到許可權申請到各種規範，都要有培訓；每個新人都要確定一個導師，導師幫助新人制定上手計劃，每周至少一次深入溝通，建議新人每周簡單寫一下心得，作為個人積累和問題反饋。對了，讓新人成為導師所負責領域的backup，也是種不錯的梯隊培養方式。

有關事

指標1：研發規範的執行到位程度。

原因：別以為上線申請或者更新交互稿少群發了一次不是什麼大不了的事兒，也許正是因為一次少發，就會導致一個線上事故。千里之堤潰於蟻穴，研發規範執行的鬆散並非一日的倒退，緩慢而長期的倒退會造成團隊的散漫，同時又給產品埋下了無數的雷。

應對：言必行行必果，項目經理必須對日常研發規範的執行起到強力維護作用，並根據實際情況不斷優化。即便有某些做法已不再適合團隊，也要正式將其退役，而非不了了之。從站會的頻率和時長、周會周報的頻率和內容，從策劃交互稿的評審和群發，到提測和冒煙的執行、上線審批及效果追蹤，雖然繁複但需堅持。產品線上無小事，意識都是點滴培養積累的。

指標2：研發效率/產能，不是團隊負荷度，而是產能吞吐量。

不要在意每個人的負荷是不是滿的，而關注相同時間內我們完成了多少需求量，或者需求的平均響應時間。

原因：把所有人都塞滿的做法是不科學的，至少每個人都可以裝作被塞滿，這種非常被動不信任的執行方式副作用很多。產品真正需要的不是一堆加班的人，而是一堆好用的功能。所以，關注這些功能多久能被完成是更合適的。

應對：先記錄，就能發現團隊的問題。然後從流程優化、團隊培養、技術架構這些層面就會引發更多的思考和改良，自然開始有「還技術債」的需求進入視野。另外，關注產能，還可以幫我們更快地消化需求隊列。

指標3：版本中是否出現過技術優化需求。

原因：沒有不欠債的技術團隊，但如果版本計劃里已長期無法排下技術優化需求，那也就意味著技術問題長期堆積，架構風險日益增高，遲早有一天以重大線上問題的方式集體爆發。

應對：在提升產能指標的過程中，重要且緊急需求的響應加快，逐步會有空間來做重要的架構優化；另一方面，架構優化中重要問題要提升優先順序排上來，整體的架構優化要排計劃，並且獲得產品老大的支持。

有關結果

指標：線上事故頻率及嚴重度，修復速度。

如果說產能代表了速度，那麼線上事故則體現了質量。兩者並舉才能做到又快又好。

原因：廢話，不多說。

應對：做好了1和2，線上事故整體上會下降。當然，也需要針對性做些提高，比如上線流程、線上事故應對預案等。對所有的線上事故都要做記錄、根源分析以及改進措施，當事故頻率顯著升高時，已經提示重大的研發過程問題了。

寫在最後

當人和事指標出現偏差時，往往是問題早期，要儘快採取措施進行糾正；而當結果指標報警時，團隊的健康程度已經發生了問題並導致了產品不良結果，更需要花大力氣來撥亂反正了。

對事的問題要防微杜漸，對人的問題要心存敬畏，帶著ta去打拚世界，才是長久之計！

喜歡我們的文章也歡迎看看我們的書《網易一千零一夜》，並關注公眾號：NetEasePM，還有我們的課程: