團隊管理基礎：3個要點讓團隊平衡發展
2020-09-02 17:09:18
和談戀愛一樣，痛過苦（哭）過，后來，我們才學會如何去愛。我們做項目、做產品、拼世界的同時，永遠需要另外一股力量，打造團隊更堅實的基礎，營造團隊更溫暖的港灣。這是產品老大們都要敬畏的生存現狀，是團隊都要注意的發展平衡，更是每個項目經理要固守的項目根本。
記憶里小說中的橋段：某潛力股青年，為了掙得讓女友幸福生活的家產，在外打拼多年，成功歸來卻發現物是人非。輸了你，贏了世界又如何，多么痛的感慨。
身邊不少新聞中的段子：某公司年輕高管，坐擁千萬乃至上億家產，終因勞累過度，意外猝死。輸了自己，贏了世界又如何，多么痛的領悟。
其實，我們做產品做項目的過程里也不乏這樣的經歷。
互聯網世界，瞬息萬變，每一個玩家都在玩命地快快快！每一塊業務都在飛速發展！當你在風口上的時候，即使你比豬還胖，你也必須要飛起來！
這時候，所有的眼睛都盯著業務，盯著KPI，盯著發展；所有的需求都只能應對最重要的業務功能或者運營活動，影響稍小點的用戶bug都只能靠邊站；各個版本只來得及實現需求中最最重要且緊急的，并且還不斷砍掉些看起來不那么重要的小點；運營也是忙得飛，用著虐心的后臺也得把長長的內容給錄入進去，還要上接用戶下接供應商攏起無數條線頭……加班，根本停不下來！~~~~>_<~~~~
有沒有感覺我們在拼世界的同時，似乎忽視了什么？
忽然有一天，線上開始連著出事故，一看原來都是以前欠下的債！然后團隊規模是之前的兩三倍，但產能似乎上不去，比以前多干不了多少事兒，而且成天對加班怨聲載道的。再然后，一個一個開始離職，核心功能開始無人能懂……
和談戀愛一樣，痛過苦（哭）過，后來，我們才學會如何去愛。我們做項目、做產品、拼世界的同時，永遠需要另外一股力量，打造團隊更堅實的基礎，營造團隊更溫暖的港灣。這是產品老大們都要敬畏的生存現狀，是團隊都要注意的發展平衡，更是每個項目經理要固守的項目根本。
從三個角度說說如何關注和打造這樣的基礎：
有關人
指標：新老員工比例不應超過1:1，其中新員工包括正職/借調+實習生……
原因：無人指導和關懷的新人就是添亂，除了搞亂那本已有點亂的代碼外，更容易造成老人煩躁，以及新人本身的諸多怨氣最終導致不穩定。另外，當新人從人數和文化氛圍上強過老人時，原有的文化會被顛覆，種種不和諧應運而生。
應對：不要在短期內招過多新人，招一批帶一批，成熟一批后再招一批；每個團隊都要建立自己的新人入門指南，每個新人要有正規的方式介紹給團隊；從了解公司到權限申請到各種規范，都要有培訓；每個新人都要確定一個導師，導師幫助新人制定上手計劃，每周至少一次深入溝通，建議新人每周簡單寫一下心得，作為個人積累和問題反饋。對了，讓新人成為導師所負責領域的backup，也是種不錯的梯隊培養方式。
有關事
指標1：研發規范的執行到位程度
原因：別以為上線申請或者更新交互稿少群發了一次不是什么大不了的事兒，也許正是因為一次少發，就會導致一個線上事故。千里之堤潰于蟻穴，研發規范執行的松散并非一日的倒退，緩慢而長期的倒退會造成團隊的散漫，同時又給產品埋下了無數的雷。
應對：言必行行必果，項目經理必須對日常研發規范的執行起到強力維護作用，并根據實際情況不斷優化。即便有某些做法已不再適合團隊，也要正式將其退役，而非不了了之。從站會的頻率和時長、周會周報的頻率和內容，從策劃交互稿的評審和群發，到提測和冒煙的執行、上線審批及效果追蹤，雖然繁復但需堅持。產品線上無小事，意識都是點滴培養積累的。
指標2：研發效率/產能，不是團隊負荷度，而是產能吞吐量。
不要在意每個人的負荷是不是滿的，而關注相同時間內我們完成了多少需求量，或者需求的平均響應時間。
原因：把所有人都塞滿的做法是不科學的，至少每個人都可以裝作被塞滿，這種非常被動不信任的執行方式副作用很多。產品真正需要的不是一堆加班的人，而是一堆好用的功能。所以，關注這些功能多久能被完成是更合適的。
應對：先記錄，就能發現團隊的問題。然后從流程優化、團隊培養、技術架構這些層面就會引發更多的思考和改良，自然開始有“還技術債”的需求進入視野。另外，關注產能，還可以幫我們更快地消化需求隊列。
指標3：版本中是否出現過技術優化需求
原因：沒有不欠債的技術團隊，但如果版本計劃里已長期無法排下技術優化需求，那也就意味著技術問題長期堆積，架構風險日益增高，遲早有一天以重大線上問題的方式集體爆發。
應對：在提升產能指標的過程中，重要且緊急需求的響應加快，逐步會有空間來做重要的架構優化；另一方面，架構優化中重要問題要提升優先級排上來，整體的架構優化要排計劃，并且獲得產品老大的支持。
有關結果
指標：線上事故頻率及嚴重度，修復速度。
如果說產能代表了速度，那么線上事故則體現了質量。兩者并舉才能做到又快又好。
原因：廢話，不多說。
應對：做好了1和2，線上事故整體上會下降。當然，也需要針對性做些提高，比如上線流程、線上事故應對預案等。對所有的線上事故都要做記錄、根源分析以及改進措施，當事故頻率顯著升高時，已經提示重大的研發過程問題了。
寫在最后
當人和事指標出現偏差時，往往是問題早期，要盡快采取措施進行糾正；而當結果指標報警時，團隊的健康程度已經發生了問題并導致了產品不良結果，更需要花大力氣來撥亂反正了。
對事的問題要防微杜漸，對人的問題要心存敬畏，帶著ta去打拼世界，才是長久之計！
?
作者：曹智清，網易杭研項目管理部總監。曾經感受過IBM的專業嚴謹，領略過ASK搜索的起起伏伏，體會過創業中的酸甜苦辣。目前致力于在線教育行業的探索，同時關注項目管理在互聯網產品全生命周期的應用，專注于敏捷精神的滲透和實踐。《網易一千零一夜》主要作者之一。
本文由 @網易杭研項目管理（微信公眾號：NetEasePM）授權發布
