像CTO一样思考：如何高效管理30人的研发团队？
前言
今天是2022年國慶長期的最后一天，國慶回來后即將進入Q4第四季度。轉眼間，又快到了元旦和春節的時候。正所謂，“員工過節，老板過關”。今天繼續來分享一下，30人的研發團隊，如何管理更輕松、更高效、更成功。
管理原則
先來分享一下，我從事研發管理近十年的管理原則和心得總結，包括我自己總結的、或學習到的或別人提煉的。
原則1：管理，就是要越管越輕松。
原則2：我相信，但我要確認。
原則3：人可以犯錯，但流程制度不能。
原則4：盡早實現閉環管理，形成正反饋。
作為一名研發管理者，或者作為一名需要管理團隊的技術負責人，你需要掌握很多技能和多方位專業能力，譬如：技術能力、管理能力、統籌、溝通、產品業務能力、系統架構、人員招聘、甚至服務器運維能力。但這些都只是管理者基本的能力，而不應該成為你日常事務的核心和重點工作。
簡單來說，作為研發管理，要懂得分配、安排和統籌。要有自己的想法、規劃和整體的把控節奏。不管是以前管理10個人的團隊，還是現在帶領30人的隊伍，抑或是未來上百人規模的企業研發團隊，你都應該能輕松應對，要越管越輕松。好的研發團隊，應該撥高來用，即下級對上級進行向上管理；而不是反向而行，始終都是向下管理，甚至CTO干經理的活，經理做工程師的事，工程師最終還要被當作實習生來對待。如果是這樣，就會越管越累，不僅團隊得不到成長，而且團隊整天都很忙還效率不高、問題一堆。
有這么一個小故事，有位高級經理人上班后幫忙清倒了垃圾，卻被老板訓斥。這就好比如CTO做了實習生本身要做的事。事情本身不分對錯，只是站在不同的角度，有不同的解讀。
古人有云，“用人不疑，疑人不用”。在對待自己的研發團隊時，應該相信他們能把事情做好，并授權給一線的開發人員，讓他們得到充分的專業發揮，而不應該限制他們的工作。但在相信他們的同時，也要進行二次確認，始終秉持“我相信，但我要確認”的原則和嚴謹精神。因為每個人都會犯錯和疏忽，通過發揮團隊的智慧，團隊犯錯的機會將會大大減少。比如進行回歸測試、代碼review、開發演示、變更審批等。
前面有提到，每個人難免都會犯錯。但作為管理者，你所設計和同意的流程制度不能有紕漏。管理者所作的每一個決定、每一次溝通都應該深思熟慮。正如紅綠燈的交通設計一樣，某輛車可能會不小心闖了紅燈而扣分，但紅綠燈的設計一定要正確、人性化和統一化。好比如，某個開發人員可能會因為忽略大意而寫了一個Bug，但在研發流程和發布上線的流程設計上就不能有紕漏。因此，對于流程制度的設計，一方面要結合當前團隊的人員規模、業務特點和需要重點解決的問題來設計，另一方面也要在人員出錯的防范、效率提升、發揮團隊集體智慧等維度綜合考量。你應該站在一個更高更抽象的角度來思考，不斷思考一個倍受大家歡迎的公園應該是怎么設計的，思考一棟有活力、經典和永恒的建筑要遵循哪些模式，思考一個成功、優秀、卓越的研發團隊應該需要怎樣的流程和制度。
最后，反饋很重要。向上匯報很重要，向下反饋也很重要。能保持順暢的雙向反饋和閉環管理，對于研發團隊的協作和溝通都是非常明顯的積極作用。在向上匯報方面，要培養團隊在正式匯報、會議匯報、私下溝通、書面總結、非正式場合的溝通，提醒下屬既要報喜也要報憂。凡事，先記錄、后跟進、最后要反饋。反饋很重要，主動匯報更難得。
另一方面，同時也別忽略了要向下反饋。好的愛情，都是雙向的。團隊也一樣，沒有嚴格的上下等級，只是分工和角色不同。作為管理者，不一定要始終保持“神秘感”，讓人“捉摸不透”就是牛。當團隊做得好或者某人表現優秀時，記得在公開或私下場合，給予認可和贊同。當有業務增長和業績時，也別忘了給團隊一些鼓勵或安排一次下午茶或小飯局。在例會或正式會議上，也可以把一些重要的信息和高層指示同步給大家。“要想走得快，就一個人走；要想走得遠，就大家一起走。”
當向上匯報、向下反饋的溝通閉環形成后，同時結合前面研發流程的管理閉環，就能雙管齊下，形成正向循環。如此反復，持之以恒，優秀和卓越的研發團隊，將會得以呈現。
產能、產出和產效
接下來，繼續重復聊一下產能、產出和產效這幾個話題。
站在不同的角色角度，以及一家企業經營、生存和發展所需要的基礎，我把研發生產力分為三層，分別是：一線人員的研發產能、管理層的軟件產出和經營者關注的企業產效。簡單總結就是：既要把活干好，又要能出成績，還要能幫公司賺錢。
一線視角：研發產能可視化
作為基層的研發人員、工程師、技術人員和程序員，他們在工作上，關心的是具體能完成的事務、具體的工作項、以及在自己能力和專業領域內能完成的任務。
在IT互聯網行業，普遍有“內卷”、加班、996等文化。對于怎么讓研發團隊加班這個敏感話題，我的建議是不必太在乎和在意所謂的加班，更不要進行沒有意義的加班。軟件研發是一個需要高智力的工作，不同以往工業時間使用科學管理的方式就能提升程序員的工作效率和進度。很明顯，你不能按代碼行數的多少來衡量程序員的工作量。
但是，我們需要知道研發團隊每天都在做什么，以及他們本周和下周的工作計劃是什么。我們要共同看見研發人員的每天工作計劃。雖然登記每日工時是很常規的工作，但對于團隊管理和個人高效工作，都是有很重要的意義。對于工程師個人，他會清楚，自己接下來這周每天的工作計劃；對于項目經理，可以提前了解項目的排期計劃表和項目進度和延期風險；對于研發管理，可以實時掌握研發團隊的工作量飽和度和工作情況。堅持讓一線員工親自、如實地登記工時，實現研發產能的可視化，是我們后續研發效率提升的基礎和關鍵。
在進行工時登記前，需要先完成兩件重要的事情：第一件事是人才盤點；第二件事是梳理劃分核心域、支撐域和通用域。第一件人才盤點，是了解現有研發團隊的人員情況，例如前端、后端、產品、測試分別有多少人，每個人工作年限、入職時間和角色分別是什么，包括每個人的簡歷、過往晉升調薪情況等，這有助于管理者（特別是空降的管理層）快速掌握人員情況。這對于后續的人員分工、培養基層管理者、安排新人導師、挖掘KOL意見領袖以及人才培育方面都會有重要的信息參考價值。
第二件事是關于主營業務的識別和劃分。這點在DDD領域驅動設計一書中有專業的介紹。對于管理者，除了掌握團隊人員的情況，還要了解公司產品業務的特點和核心業務的劃分。從而進一步梳理和劃分支撐域和通用域。然后在這基礎上充分利用自研、外包開發、采購等模式，選擇合適的解決方案，發揮和使用外部力量的資源優勢，讓自主團隊更加專注于核心業務的研發和投入。此時，可以參考721原則，即70%以上的時間精力和研發資源投入到核心主營業務和主流程團隊；20%左右的資源配置到支撐域，剩下的10%則劃分給通用域。
結合YesDev研發協同工具的使用，我們可以更清楚地看到。任務登記在人員工時登記和項目進度兩方面發揮了很大的作用。
首先，對于個人、行政部門和虛擬的項目組，可以分別看到自己的、自己所在部門的、以及參與涉及的工作組的每周任務計劃和工時登記，可以分別滿足個人、技術TL管理者、項目經理等多種角色。
為此，結合團隊人員和核心域的劃分，可以在YesDev后臺配置好需要的工作組和產品線。
其次，對于項目側和交付側，任務和工時，可以關聯到需求，也可以歸集關聯到項目。在項目維度，我們可以看到項目匯總好的實時開發排期計劃表、項目每日燃盡圖、多個項目的宏觀七彩甘特圖，甚至還有研發的成本核算。
項目的開發排期計劃表，也可以分為兩個維度，為項目經理、技術管理者和老板提供不同視角的統計數據。如果你是項目經理或老板，更關心結果，那么可以查看項目開發計劃表，因為它會從項目到需求再到任務這樣的層級進行下鉆透析，還可以對比上一次發送和統計的結果變化。
如果你是實線管理的技術管理者，更加關心人員的任務完成情況和目前的工作計劃，則可以查看人員排期表。它會從人員出發，統計每個項目成員所需要的工作量，以及計劃開始時間和計劃完成時間，還有當前的實時完成進度。比如什么時候開發聯調，什么時候可以提測，什么時候可以上線等里程碑節點。
這就是研發產能可視化的作用和價值。
在此基礎上，我們可以引申和得到我們需要進行研發效率提升和工作計劃安排的基礎工時數據。再進一步，我們還可以圍繞任務和工時，完善閉環的協作和閉環反饋。例如，針對任務的延期設置任務延期提醒，同時進行釘釘群、郵件等同步和提醒，除了提醒開發者本人，還可讓團隊保持信息同步。
又如，當任務完成時，所關聯的需求，由YesDev系統自動發出和更新需求進度給到需求方和產品經理以及抄送給測試人員。形成需求進度的向上智能反饋。
除此之外，任務還有很多重要的實用的參數配置，可以結合自己團隊的管理和協作需要，進行配置。
前面所提及的項目燃盡圖、七彩甘特圖、項目腦圖等，也可以在YesDev的項目中即時獲得。不管是要用郵件匯報，還是要導出Excel附件，還是查看在線的圖表，都能隨時查看和下載。
最后，小結一下研發產能可視化的實施要點：
1）了解團隊人員情況，劃分業務的核心域；
2）建立工作組，由小組長或意見領袖人員負責督促和協調小組成員的任務工時；
3）每周或每雙周定時檢查和驗收任務的完成情況；
4）協作過程中，如有必要，可以結合每日站會進行當面溝通；
5）使用YesDev的每周工時登記或其他工具進行任務工時登記、統計和任務協作。
管理視角：軟件產出最大化
曾經我作為一名PHP開發工程師，在我看來，根據產品功能需求完成開發和上線是最基本的崗位職責；而以更高效率和更高質量地完成需求開發和上線交付，則是屬于良好的工作表現。那怎么才算是優秀的級別呢？
優秀員工的表現是，你不僅出色完成了代碼的編寫、功能的開發和上線，同時你還保證了100%通過的單元測試、遵循了合適的設計模式、在靜態代碼質量方面維持了較低的技術債務、在數據庫慢查詢和接口響應時間等性能方面有合適的解決方案和提前考慮、在文檔編寫和UML圖表設計有清晰的思路……也就是說，你不僅直接產出了代碼和軟件，還配套產出單元測試、文檔、代碼分析報告、UML架構設計、安全檢測報告等間接的產出，這些產出是可以量化的，是行業內的標準，是通過第三方來評定和認可的。
那么，何謂卓越的員工呢？卓越的員工不僅能出色把事情完成，而且這件事情本身也是很有價值的。例如，卓越的員工會主動發現問題、提出他的解決方案并在完成需求開發的同時主導或獨立落地實現，最后他還會給出優化后的效果對比和分析記錄對比總結和分享等。又如，卓越的員工都會超越自己去思考、負責和實現在他能力范圍外或在他職責以外的目標，幫助團隊或公司不斷解決別人解決不了的歷史難題，或是創造新的價值。
一開始，優秀或卓越的員工會快速學習，獨立完成任務；逐漸地，他會成為團隊內的意見領袖（雖然他還只是一名普通的開發人員），并持續給團隊帶來正能量和積極的促進；到后面，他會樂意接受不同的挑戰，帶領團隊完成一個又一個看似抽象、不可能完成或者別人不愿意接手的疑難雜癥。
所以，回到團隊管理者的視角。你覺得作為一名技術管理者，什么更重要？
作為一名管理者，有不同的管理風格和方式。有些以權威的方式進行推進，有的則以教練的身份和團隊共成長，有些會以“無為而治”得讓人看不透的方式進行團隊管理。不管何種管理風格，要想有出色的團隊，首先，你需要有出色的成員。結合20-80定律，在團隊員最為優秀的卓越的成員，一般情況下來源于三種途徑：第一個是從新人成長到獨擋一面的老員工，作為老員工，熟悉業務、熟悉團隊、熟悉歷史、熟悉各種坑；第二個是來自空降的技術人才或職業經理人，這些人有良好的背景或權威的專業知識和經驗，但要確保人才和當前團隊的匹配程度；第三個則是作為管理者，之前的老部下。
加班，只是在工時方面，粗糙地填補，即使你讓研發團隊每天都多干了幾個小時的活，但不一定就能提升團隊的軟件產出。軟件產出就是最終可正常工作的軟件，以及配套的中間輸出物、制品和統稱。即我們平時所提到的：源代碼、數據庫設計、上線的軟件系統/產品/App、文檔、單元測試用例、功能測試用例、測試報告、靜態代碼分析報告、構建的版本、PRD、設計稿等。
在軟件的課程里有一門課叫：算法。算法里面關于排序的算法有很多種，歸納為用時間換空間或用空間換時間。不同的場景，不同的排序算法有不同復雜度。但目的都是為了找到最短路徑或最優算法。既然明白了在軟件研發團隊，其效率和產出，可以通過量化最終能正常工作的軟件和中間的輸出物這一觀點，那么作為技術管理者，就可以圍繞這些流程，結合DevOps和需求業務的上下游進行聯動、整體性的規劃和統籌。
你要思考，當前你的研發團隊，最缺什么、更需要的是什么、亟待解決的問題又是什么。如何才能讓你的團隊持續、穩定、高效地交付有價值的軟件產品？
先來觀測一下，在DevOps流程過程中，行業內推薦的需要用到的工具有：
圖片來自于網絡
隨后，繼續觀測一下，軟件交付各個階段可能存在的度量指標。
圖片來自于網絡
你可以結合自己的研發團隊的協作流程，和目前使用的工具，進行流程上的梳理和關鍵節點的識別。
YesDev推薦的核心協作研發流程如下，以需求為起點，以上線交付為迭代終點，如此循環和敏捷開發。
緊接著，YesDev在敏捷開發的基礎上，結合融入了DevOps的持續集成、團隊人員、工具使用。由此有了以下的標準化研發流程圖：
從行業的最佳實踐、工具、指標到YesDev的工具使用，由大到小，從抽象到具體，我們推薦在需求維度，研發團隊要堅持良好的、統一的、可量化的交付標準。
概括來講，需求交付，可以從以下幾方面進行標準化和量化：
1）關聯Git代碼提交到YesDev需求，從而實時掌握和同步研發的真實情況；
2）根據需求，編寫開發文檔，針對復雜的、底層的、核心流程的、或工程量巨大的需求，建議進行技術評審；
3）進行Bug的記錄和關聯；
4）提交備注和需求有關的接口文檔、開發分支、測試環境賬號等；
5）進行測試用例的編寫和維護，以及重大需求的測試計劃、測試報告；
6）記錄需求有關的歷史操作、變更記錄和附件資料。
如果需要化繁為簡，在前期，你可以重要以需求上線為交付指標。為此，你可以使用以下幾個工具和模型。一個是，需求的每周排期，可以具體量化和跟進每周需求的計劃上線和發布情況。按每個產品線，進行分開管理和統計。
作為產品總監或產品總負責人，為了進行橫向的匯總和跟進，你可繼續使用需求周報。你可以在線搜索全部需求的進度，也可以導出Excel，還可在線編寫郵件和進行定時發送郵件通知。根據多年的經驗總結，我們把需求周報分了三大部分：最近完成的需求、當前進行中的需求，以及未關聯到項目的需求。
如是，在需求管理方面，你就能在團隊中，和上下游部門形成閉環和大聯動。
補充一點，在需求交付指標方面始之以恒，確實可以提升研發團隊的產出，滿足不同業務部門、最終客戶的需求，但同時也不要忘記要預留和計劃20%的時間、精力和人員，進行非功能性，即技術類的專項優化和系統架構規劃。“道路千萬條，維穩第一條”。
老板視角：企業產效利潤化
員工工作很賣力、團隊產出也很高效，但是，企業最終盈利了嗎，賺錢了嗎？團隊除了口頭上的認可和鼓勵，有物質上的獎勵和提升嗎？
我們不能為了寫代碼而寫代碼，不能為了創業而創業，在創造價值和利他的同時，作為企業，老板也要實現有收入、有盈利、有增長。
如果說員工的責任是把事情做正確，產品經理的責任是做正確的事情，那么老板或決策層的責任就是要確保前面這兩者都做對后是有生存空間、有市場空間和有利潤空間的。
關于創業的模型模式，也有很多種。而作為技術型創業，或以互聯網、軟件產品或數字化為主的創業，我們也要基于公司自己的業務、特點和客戶群體，以實現企業產效利潤化為目標，建立一套可量化的漏斗模型和跟蹤指標。
比如，如果是以外包項目為主和收入的研發團隊，可以在YesDev關注項目的研發成本投入和利潤的燃盡圖。
針對每一個項目，我們可以統計在每個成員投入工時背后的人力研發成本。
作為老板或者項目負責人，可以查看一段時間內，某些項目的研發成本投入情況，對于成本控制和后續同類項目的工時評估和方案報價都有重要的參考意義。
最后，老板還可以查看最終的利潤結果。比較好的狀態是，每個項目都能如期按時交付，項目成本可控，有一定的利潤空間，能及時收到項目尾款。
當需要查看更多指標和數據統計時，YesDev也為你和你的團隊提供更多有價值的分析報告和數據支撐。
如果你的團隊和企業，做的是ToC的產品，那么可以另外構建你的業務指標、業績體系。
小結
關于研發團隊的管理和規劃，應該適合采用Top Down的方式進行統籌、規劃和推進。
而在研發協同、個體扁平化協作、發揮團隊集體智慧方面，則應以Bottom Up的方式。
既要整體規劃，也要逐個擊破，執行到位，相信很快我們就能看到研發團隊明顯提升和充滿正能量的AHA時刻。
總結
以上是生活随笔為你收集整理的像CTO一样思考：如何高效管理30人的研发团队？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android常用的工具资料
- 下一篇： react+ts导入图片，找不到模块“.