五個維度打造研發管理體系

背景

    技術管理者(技術總監/經理/CTO)期望通過體系化的管理方式建設，能夠在百人，千人以上的團隊中有效的構建聚焦目標，自我成長，高效能的研發作戰團隊，快速拿出成果，支撐業務的快速發展。

痛點

• 從小團隊人員快速擴張，團隊文化稀釋，人員效能下降，目標逐漸弱化。

• 各自團隊管理方式及標準不統一，人員管理及協同逐漸混亂。

• 組織擴大後，難以有效關注個人，無法準確評判個人的成長，貢獻等。

目標

    通過構建完整研發管理體系，建立管理機制，讓技術組織聚焦目標，高效運轉，同時激勵團隊不斷優化提升。

研發管理體系構建思考

    通過道，法，術，器，勢五個維度去思考整個管理體系的構建。

道: 在於文化，思維，準則，價值觀，領導力的構建，是思維和思想，它需要我們落到實處。

    通常團隊小的時候，leader 可以深入到日常的管理事務中，管理者的智慧和想法可以體現在明處並落到做事上。而當團隊規模過百人的時候，組織架構一般已拆分層級，各項目和人員已經聚焦於各自產線上，甚至人員都已經分佈在各個角落，新人的面孔逐漸陌生，此時我們也許需要構建文化，思維，基本準則，團隊的價值觀和管理者的領導力。

關注團隊文化

    文化在於使命，願景，價值觀的思考，這個也是企業需要思考並給與組織明確的目標。而技術管理者需要深刻理解組織的使命和未來需要解決的一些社會問題；也需要了解客戶的真正的痛點，努力達成美好又有價值的結果，以及在組織達成客戶目標過程中，需要遵守以及秉承基本準則和宗旨。管理者最基本的工作就是要親身踐行這些內容，並有意識的傳達給一起奮鬥的員工，而不是掛在牆上或寫在紙上；同時我們也會考慮將企業文化加入績效考覈和入職考試中，以強化團隊文化。

建立工作準則

    準則在於明確組織達成目標過程中最基本的工作原則。一些職能部門或者特定職業羣體會有自身工作的特殊原則和特性，比如技術部的一些工程師文化和思維方式，我們會將這些做爲基本的工作原則和獨有的組織文化。

    工程師文化可以包含有高效，守信，激情，創新，分享等工作原則，它來源於公司的文化，又包含技術組織的文化特性，技術管理者應該迎合這樣的羣體，建設這樣的團隊和氛圍。

• 高效: 更好更快速的拿出結果。

• 守信: 願意爲承諾的結果負責。

• 激情: 全身心的投入並感染別人。

• 創新: 敢於顛覆現有的模式並拿出結果。

• 分享: 將經驗賦能給團隊，與團隊一起成長。

做事的工作思維

    思維在於制定目標，完成目標過程中的做事思維方式。這個在建立和制定團隊或者項目的工作目標及關鍵性事務決策時非常有用，比如在制定 ocr,kpi,技術選型決策,人員安排等場景。以下幾種思維方式是我們可以參考的：用戶第一，奮鬥者優先，價值導向，財務思維。

• 用戶第一: 找到組織或者團隊服務面向的客戶對象,能夠對他們的痛點和爽點感同身受，並通過技術或者產品手段賦能並服務好用戶，最終體現產品或者解決方案的價值。

• 奮鬥者優先: 需要管理者識別並區分出團隊成員中不同類型的人（庸人，人手，人才，奮鬥者），要把機會和激勵留給敢於承擔，並和團隊一起成長的人，這樣的人成長會很快，潛力也往往很驚人。

• 價值導向: 定目標，做事要明確目標和事情本身的技術價值，產品價值和最終用戶可感知的業務價值，我們只做最有價值的工作目標，篩選掉找不到價值的工作內容；這是技術管理決策需要考慮的關鍵維度。

• 財務思維: 本質是成本思維; 定目標，做事要明確目標和事情本身的資源（人員，時間等）投入產出比。我們允許戰略性的投入，長遠性的收益，但是做事時我們需要預估，明確和關注；這也是技術管理決策需要考慮的關鍵維度。

關鍵崗位的領導力

    領導力是一種影響力，是成事的能力；管理者不僅僅侷限於管理事務本身，更要關注人，關注團隊，要以人爲本；技術管理者需要掌握領導力，指引團隊，去達成組織目標；可以從“找準目標”，“激勵團隊”，“影響他人”，“感同身受”這幾個維度培養自身的領導力。

• 找準目標：需要技術管理者一定的專業能力，幫助團隊梳理一個願景，制定一系列目標；也可以通過一定的感召力，幫助團隊成員發現自我成長的動力，制定個人發展的目標；而本質上是需要領導者能夠幫助團隊找到方向。

• 激勵團隊：管理者要激勵團隊，使衆人行，而激勵本身也是很大的話題；我們可以通過物質上的激勵，榮譽上的激勵，職位上的激勵，成長上的激勵等多種激勵方式，讓團隊不斷地小步成功→正向反饋→繼續成功→正向反饋...如此循環，打造不斷打勝仗的氛圍和團隊。

• 影響他人：領導者需要有一定的前瞻力，去指引團隊（它並不一定要體現在專業知識方面）。此時需要管理者擁有一定的學習力，給與團隊指導，輸出自身的觀點，影響他人，提升他人的認知。

• 感同身受：同理心不一定是領導者必備的素質，但這是管理者基本的能力素養。管理者要能夠感知他人的情感，團隊的氛圍，做到有效溝通；能夠爲團隊的成功而喝彩，爲團隊的失敗、自身的決策及相關的結果負責。

小結

    “有道無術術尚可求,有術無道止於術”，足以讓人明白管理之“道”的重要性。管理是“以人爲本”，核心在於目標和激勵，本質還是管理者對“人性”的透徹理解，管理的“法”，“術”，“器”的細節和實施最終都源於對管理之“道”的理解和落地。所以有些技術管理者空有方法論，最終實施結果並不理想，這時需要反思落地的管理手段是否真正對齊初心。

法：在於流程化，標準化，制度化的構建，是通過管理制度（法治）方式管理組織。

    一般來說小團隊人員在 50 人左右的時候，建立基本的研發項目流程就足夠滿足日常研發管理。而當團隊規模超過百人，千人的時候，研發組織也許已經拆分成很多小團隊，協作同時也會面臨遠程溝通的問題等，此時我們會考慮運用常見的流程，標準化的技術，規範化的制度去應對大型技術團隊管理的挑戰。

將研發協作流程化

    研發管理中通常會涉及項目管理和人事管理，所以管理流程一般會圍繞項目流程和人事流程去構建，而所有的流程化構建的目的是提升研發效率的效能，降低協作成本，這個也是判別一件事是否符合流程化的初心的重要標準。

• 流程化的構建工具: 考慮採用釘釘,飛書，OA 系統，TAPD 等等一些協同工具來定製流程解決。

• 項目流程構建: 由研發 PMO 等類似角色牽頭，在協助組長解決日常項目中遇到的溝通，協作等問題後進行復盤，統籌抽象分析，梳理構建標準化的流程建設；比如項目立項流程,項目迭代流程,項目發佈流程,緊急事故處理流程,研發資產申請流程等類似流程都會在這個過程中沉澱下來。

• 人事流程構建: 由研發 hrbp 牽頭，在協助組長解決日常項目中遇到的人員效率，狀態，成長，考覈，晉升，淘汰這類問題過程中，進行復盤，統籌歸納分析，梳理構建標準化的流程建設；比如試用期轉正流程，請假流程，人員晉升流程，招聘流程，面試流程等等。

將研發規範制度化

    研發管理會涉及項目管理和人事管理，同樣管理制度也會圍繞項目流程和人事流程去構建，同理所有規範制度化構建的目的是標準化操作，有法可依，減少或避免犯錯。

• 制度化的查詢工具: 考慮採用 wiki,confluence 等知識庫相關的工具。

• 項目制度構建: 由研發 PMO 等類似角色牽頭，在協助組長解決和覆盤日常項目問題的過程中，進行體系化解決方案的梳理，考慮從管理維度建立規範，制度等標準化的操作流程機制，避免重複犯錯；比如數據庫設計規範，分支管理規範，項目發佈規範，線上故障處理規範，網絡安全規範，項目流程規範，測試用例管理規範，項目性能標準規範等。

• 人事制度構建: 由研發 hrbp 牽頭，在協助組長解決人員相關問題的過程中，進行全局性體系化思考，協同 PMO 等類似角色共建研發相關人力制度。比如績效考覈評分規範，研發晉升制度，研發招聘制度，研發激勵體系等。

將研發技術標準化

    在構建整個研發體系的過程中，我們期望通過五個維度(技術一體化，業務一體化，監控一體化，運維一體化，管理一體化)進行體系化構建，其中技術一體化的核心是打造標準化的技術體系。

    技術標準化（技術一體化）包含技術/框架選型標準化，技術使用標準化，技術協議/工具標準化，技術結構標準化等。其中開源的bsf框架（基礎框架）解決選型和使用標準化的問題，business（業務框架）解決協議和工具標準化及技術選型兼容問題，demo 腳手架項目解決快速構建新項目和技術結構標準化問題。

    基於技術標準化的原則，我們也會關注運維標準化，監控標準化，測試標準化等涉及整個 devops 相關的標準化技術建設。

• 運維標準化（devops）: 通過構建 CICD 標準自動化流程, 通過 ops 自動化發佈，讓日常發佈交還開發，徹底解放運維工作量；通過構建運維標準化體系實現自動化運維。

• 監控標準化: 通過標準化的監控體系構建全維度性能監控和質量分析,通過 oms 自動化監控，讓日常問題排查更智能，秒級報警，秒級服務自愈，秒級報告項目質量。

• 測試標準化：通過標準化的測試管理體系，主流程自動化測試體系，自動化全鏈路壓測體系，解放測試部分工作量，保障線上性能和穩定性。

小結

    管理之法本質是從流程化，標準化，制度化等維度建立整個“管理機制”，最終的核心目標是通過管理的法治建立標準化的操作規範，再通過標準化的規範提升人員的協作效率、監督機制、系統穩定性/安全性等；技術管理者在實施時勿忘初心，切忌爲了管理而管理，一切儘可能從簡化人力管理，提升效率爲目標而設置管理機制。

術：在於通過招，用，養，留，去五個維度打造人員管理體系。

    通常團隊小的時候，人員的管理可以由核心管理者親自安排，所以總體可控。而組織規模稍微大一些，權責必然會下放，組織也拆分成多個業務線或者團隊。爲了保證組織規模成長過程中，人員基本管理方式一致，我們需要打造標準的人員管理體系輔助各級管理者，確保合適人員可以識別，引入，培養，不合適的人員可以淘汰；這個過程中技術管理者要和 hrbp，共同協作打造整個人員管理體系。

打造招聘體系（招）

    招聘體系是人事構建管理過程中非常專業的內容，而技術管理者可能關注工程師文化所帶來的不同特點，可以從招聘渠道，人員組織規劃和預算，面試流程標準化，試用期考覈制度等維度協助完善體系構建。

• 招聘渠道:可以從專業招聘渠道補充和人才引進激勵制度建設來完善。

      專業招聘渠道補充: 技術工程師常見的招聘渠道有 boss，獵聘，拉鉤等,招聘渠道選擇的過程中，垂直行業的招聘渠道特性會更明顯。高端或者一些合適的崗位，可以通過獵頭推薦，也可以通過熟人推薦，在實操過程中成功率和匹配率上會更高一些。

     人才引進激勵制度的建設: 需要公司內部建立完善內推渠道，相應的崗位激勵政策，顯式的成功案例，打動人心的招聘文案宣傳幾個方向努力才能略顯成效。當然曾經也見過一些公司的激勵政策很好，但是內部宣傳和成功案例，對內部員工的吸引和感知不夠。也見過一些公司將內部人員推薦面試人數指標納入技術部門各組績效考覈中，具體效果不得而知，也可以作爲參考。

• 招聘計劃: 可以從人員組織規劃和預算來確定年度招聘計劃和財務預算。

     人員組織規劃：技術管理者需要明確和對齊更高管理層年度的業務方向和期望，盤點自身組織最終需要達成技術目標，產品目標，業務目標，從而根據目標盤點現有技術人員，確定組織崗位規劃和相應的招聘計劃，協同相關的 hr 達成招聘目標。

     預算: 技術管理者要有一定的財務成本思維，做好人員的組織規劃後，確定相應研發組織的年度預算和部門預算，同時也要協同 hrbp 瞭解組織的投出產出比情況；如果中途有人員變動和額外新增人員，可以申請額外預算。

• 面試流程標準化:可以從梳理崗位模型，標準化面試，崗位勝任力模型 ，面試反饋，入職流程，試用期考覈制度等多個維度推進優化。

     崗位模型: 技術管理者需要協助招聘 hr，明確目標招聘崗位的人員畫像，包括相應的年齡要求，能力模型（技術能力要求），級別，崗位職責，薪酬範圍之外，也要特別關注技術崗位的能力，所需要的行業業務經驗和業務知識的掌握程度。

     標準化面試: 通過一定的標準化面試過程+標準化面試題庫+經驗交流，可以解決部分面試官的面試風格不一致導致面試結果不同的問題。但探其本質是應聘者能力是多維的，答案是多解的，需要規範性面試和麪試官主觀判斷給予相對準確崗位匹配度評價。所以技術標準題庫往往用於驗證通用性的基礎能力掌握是否全面，經驗交流用於突顯實戰解決能力和全方位問題解決思路評估。

     崗位勝任力模型：通過標準化多維度較爲精準的判定該應聘者是否符合當前崗位，一般會考慮從價值觀，年齡，穩定性，能力模型，薪酬等崗位匹配度模型建立崗位勝任力模型，這個對於招聘覆盤，轉正考覈都會有參考意義，這個需要招聘 hr 統籌體系化梳理，建立標準。比如一些技術工作，若非管理崗，會對年齡會有所要求和限制；若非相同工種，技術能力要求和評估都有所不同，這些都是需要在建立模型時需要考慮的。

     面試反饋：建立統一的面試反饋，讓面試參與者（特別是通過者）填寫反饋，關注面試過程和麪試感受，同時也是反向篩選面試官，改善面試質量的方法。因爲技術面試是專業性較強的面試過程，比如有些時候面試官的狀態不佳和經驗不足，在溝通過程的措辭和回答都要謹慎，否則容易引起應聘者反感，導致人才流失。

     入職流程：根據不同崗位職級，建立快速的入職流程審批和背調過程，是技術管理者和相關 hr 特別需要關注的。畢竟求職是一種雙向選擇，很多優秀的候選人的錯失，是因爲漫長等待 offer 流程過程中，有了其他的機會；特別是技術工作者，求職的行業範圍和機會也特別多。

• 試用期考覈制度：可以從新人入職文檔標準化，導師制度，試用期考覈標準等方向建立入職後考覈轉正體系。

     新人入職文檔標準化: 除基礎人事制度外，標準化運維環境，軟件基礎架構，項目流程規範，相關服務環境等軟件環境，梳理必備基礎信息文檔和開發文檔，最終整理新人入職文檔，可以快速幫助新人上手，進入業務開發支撐狀態；有效避免大部分重複性的一對一非業務基礎信息指導，減輕技術管理者的工作量。

     導師制度：爲入職新人指定轉正期間工作導師，協助入職工作環境熟悉，初期業務熟悉計劃及答疑，中後期轉正考覈目標制定與達成及期間團隊協作困難解決等；很多優秀技術人才在試用期後的離開，有些是因爲新環境的不適應，關注度不夠，目標不清晰導致，值得管理者反思。

     試用期考覈標準：幫助入職新人經歷初期熟悉和適應後，一般在 2 周左右協助新人指定試用期工作和考覈目標，導師需要協助指導期間遇到的難點和風險感知，幫助新人達成目標並對之進行考覈評估，最終考覈評估結果將直接關係試用期轉正。

打造組織體系（用）

    20~30 人左右的團隊，其實不必關注太多團隊組織問題，一個 leader 帶着幾個幹活的（可能是全棧），直接非常高效率的拿出結果。而當團隊成員達到 50 人左右的時候，技術管理者應該要關注和思考組織構建的問題了，我們可以從矩陣組織架構建設，人員梯隊建設兩個維度建立組織體系。

• 矩陣組織架構建設：從職能型組織，產品型組織，創新性組織三個維度構建混合型組織架構

     矩陣型組織架構圖

    職能型組織：按照前端，後端，測試，產品，架構，技術委員會等職能維度拆分組織，在 30 人以下的團隊中，人員的效能和複用性比較好，也非常適用。但是對於人員和產品的專業性深度及成長都會受限，適合業務探索初期。

    產品型組織：按照業務領域維度拆分多個業務項目團隊，在團隊人員超過 30 人以上，就可以考慮專業化分工，業務邊界明確，更聚焦本身業務價值和產品深度打磨，也更有利於績效考覈管理。

    創新型組織：在業務成熟後期，嘗試聚焦新業務創新，在探索初期召集 10 人左右小團隊進行快速業務驗證，快速迭代，快速體現價值，進行額外績效激勵。

    在技術組織實際發展過程中，團隊會根據本身的業務特性，團隊規模大小，不斷演進改變組織架構模式，以應對不同形態的挑戰。一般情況下在超過 100 人左右時，組織會呈現職能型，產品型，創新型等多組織共存的混合架構模式。

• 人員梯隊建設：從人員類型及梯隊，職責及職級劃分，AB 角色建設幾個維度考量

    人員類型及梯隊: 組織內技術管理者要識別庸人，人手，人才，奮鬥者不同人員類型，要區分普通員工，核心骨幹，管理幹部，儲備人才幾種人員類別，從而打造技術人員結構化梯隊；一般來說技術負責人，產品負責人，架構師及高級開發往往時團隊內最核心，最骨幹的人，同樣最終所有的激勵制度會集中優先考慮，貢獻最大，能力最大，承擔核心崗位的頭部員工。技術管理者要定期對骨幹成員要一對一形式溝通激勵，並形成機制規範。

    職責及職級劃分: 所有的員工都將歸屬到組織，歸屬到相應的崗位，明確相應的職責，權利和能力的邊界，這是管理者用人的基本。所以一般技術成員都會有明確的歸屬產品線，明確的技術職級/管理職級，明確的崗位類型和崗位職責，這也是我們常說的“一個蘿蔔一個坑”；然而公司規模較小或創新組織時，人員複用性較強，跨邊界和職責的工作會較多，職責和職級界限會相對模糊（比如說全棧工程師），這需要技術管理者權衡和區別。

    AB 角色建設: 作爲管理者最擔心的是人員離職或者其他變動，直接影響組織目標達成。特別是行業業務場景特殊，專業性較強的技術工程師市場流動性不強，合適的人員需要長期培養。在公司達到一定規模或有足夠預算時，應考慮全部核心崗位搭建明確 AB 角色制度，互相培養儲備人才；在實際場景中 AB 角色的實施，確實會大量減少人員流動帶來的業務風險；但是一些行業變動，管理能力問題，重大業務問題等導致的大範圍的人員流動，還是需要技術管理者更智慧的管理思考。

打造成長體系（養）

    30 人以下的團隊，成員的專業能力的成長才是最有價值的，所以一般考慮從實戰項目中提升能力。100 人以上的團隊，應該考慮體系化的建設，建立學習成長氛圍，培養出最符合公司價值觀的“腰部”和“頭部”力量。我們可以從技術能力模型構建，對內分享體系構建，對外交流體系構建，人員成長預算幾個維度打造成長體系。

• 技術能力模型構建：梳理明確的技術職級評級和能力要求。

     技術組織一般會分 P 偏技術路線，和 M 偏管理路線兩個維度構建整體的能力模型，再從專業能力，管理能力，業務能力等維度梳理公司級職級要求，從而打造專業技術能力模型。對招聘而言應用能力模型，對標技術人員應聘者能力評級；對員工個人成長而言，打造能力模型，幫助個人明確個人能力成長路徑和目標，激勵前行。對技術管理者而言，通過日常溝通接觸，對標能力模型，準確瞭解並給予管理成員明確的技術能力評估。一般來說，百人左右的技術組織就可以協同 hrbp 制定明確的能力職級劃分，小規模的技術團隊更多憑藉管理者的從業經驗主觀判斷，反而不太必要。

• 對內技術分享體系構建（走進來）：考慮內部建立分享激勵制度，建立虛擬技術組織等形式。

     核心目標是引導團隊學習文化和氛圍的建立，逐步形成學習型技術組織。可以從內部技術分享維度，建立技術內部分享制度和相關的激勵制度，比如有些公司會有量化技術分享指標落到各個技術團隊 kpi 考覈或轉正考覈期，也有公司會將分享次數均攤到個人分享考評或績效考覈中，用於年終晉升參考指標或現場的現金激勵，都是不錯的方式；

     在公司內部建立專業性的虛擬技術（偏職能更細化）組織，比如 VR 興趣組，React 興趣組，機器學習組等，用於交流專業深度的技術難題和新技術的發展方向，偶爾可以一起參加外部峯會，也是不錯的選擇。

• 對外技術交流體系構建（走出去）：考慮創建外部開源社區，參與開源社區和論壇交流，引入外部培訓交流資源等方式。

     創建外部開源社區：可以由公司技術管理者牽頭，通過創辦一些黑客馬拉松項目，小型的開源項目，公司級技術博客等方式，讓一些核心開發/有特長的開發人員，將日常項目中踩過的坑，優秀的解決方案，有價值的技術亮點，有意思的管理感悟沉澱到開放技術博客或者開源的項目框架中並分享給社區，一方面可以讓技術人員學會總結並沉澱自身的能力，另一方面可以提升公司級別的技術影響力和技術交流平臺。

     參與開源社區和論壇交流：開源社區論壇和一些技術峯會代表了行業內頂尖的技術高手的最新思維，最佳實踐，最新方向，對於個人技術視野和思路都會有較大提升。技術管理者應當關注同行業類似技術方案或解決方案，利用新技術新方案驅動業務提升，讓自身技術解決方案處於業內領先水平。同時爭取帶領相關技術人員，主動參與和分享自身業務技術優秀的成功案例，尋找技術同路人一起交流完善。

     引入外部交流和培訓：目前技術行業會有很多的諮詢和技術培訓公司，無論從項目管理還是新技術解決方案，都有一些最佳的實踐經驗，新的技術方法論，成熟的解決方案。技術管理者可以覆盤最新的一些技術難點或者關注最新的業內解決方案，邀請一些廠商、諮詢服務商或者高端技術人才進行一些技術交流或購買一些相關的服務降低公司技術開發的成本。

     人員成長預算：技術管理者需要協同 hrbp 一起努力制定整體的成長體系方案，併爲之提供一些技術交流經費和相關的激勵費用。比如培訓的門票，機構培訓費用，書籍費用，參與費用，茶談交流報銷等。

激勵體系（留）

    激勵體系的構建是人事非常專業和有深度的一塊內容，每家公司自身的業務特性和行業特性，激勵的方式，強度，員工主體都有所不同；無論公司規模大小，員工都需要激勵，而激勵體系由於技術工種的工程師文化特性，不應該着重負向激勵（懲罰機制），應該更加着重於物質和精神正向激勵（獎賞）兩大塊，從薪酬體系構建，團隊激勵體系構建，個人激勵體系構建，團建活動制度建設幾個維度打造激勵體系。

• 薪酬體系構建

     一般公司的薪酬體系只有基本薪資，爲了讓員工的發展和公司的發展能夠關聯一起，現在很多公司會將基本薪酬拆分爲月薪+績效+期權+年終+福利幾種方式，薪酬包也由月薪制轉年薪，實踐過程中這種方式在確實能夠有效的激勵員工。一般來說會將月薪的 20%左右浮動會額外作爲績效（績效考覈）和期權（公司股票價值）的激勵，年終會根據公司整體發展情況和相應部門發展情況做一定的比例浮動（部門年終獎金池）；但是對於技術人員來說，適當的控制或降低績效考覈的績效薪資比例，更有利於人員招聘（有些技術人員不太願意接受難以預知的績效薪資，即便人事承諾大部分情況下可以全額拿到）。推行薪酬體系變革，儘量不改變現有人員薪資體系，通過額外加薪和新進人員薪資調整逐步覆蓋全員。

• 部門激勵體系構建

     公司上一定規模會拆分多個部門，爲了凝聚部門最大團隊戰鬥力，會通過一定的金錢，榮譽等方式給予部門進行激勵和預算，而部門激勵一定要優先考慮物質激勵爲主。部門激勵的形式有很多，但都只是呈現方式，團隊性的活動必須要有經費。技術管理者要協同 hrbp 等角色，建立季度，月度等團隊預算標準，部門激勵考覈機制，相關的團建方案。

• 個人激勵體系構建

     對於管理者而言，管理要以人爲本，要懂人性，要了解不同員工真實的需求，這纔是個人激勵的關鍵。有時不必特別關注馬斯洛需求層次，技術人員是比較特殊的羣體，薪資起點比較高，工作內容具有一定的創造性，所以精神維度的激勵可能會比純物質上的激勵更適合。優秀的工程師的激勵應該來源於內在成就感，所以理想情況下安排一些具備一定挑戰性的工作，有效完成並得到認可，季度/月度的優秀榮譽獎項及部分物質鼓勵，優秀解決方案的技術分享等等方式都是技術管理者和 hrbp 可以考慮的。

• 團建活動制度建設

     團建活動是一個非常有效的構建團隊凝聚力活動，喫喝玩樂只是一種形式。很多公司可能會找一些專業公司做團建活動，中間會穿插很多的團建小活動，這種形式對於銷售類職業也許非常棒，但是對於技術類職業效果不是最佳。技術類職業人員大多因爲工種原因，缺少頻繁的口語溝通交流，性格大多內向，沉穩，專注，而且平常不定時加班較多，睡眠不足，體能上大多偏弱；所以休閒，遊玩，泡澡，慢運動類的活動更爲適合，或者喫飯喝酒吹牛逼也更爲接地氣。

     激勵來源於對需求的滿足

績效體系（去）

    30 人以內的技術團隊，談論績效的意義其實不是很大，管理者可以直接根據平常表現給出準確的評價。50 人以上的團隊，基本要開始考慮進行績效考覈，進行統籌性的人員優化機制建設；本質上是通過體系性的建設對人員優勝劣汰，讓優秀拔尖頭部人員晉升，讓墊底無能力的人員淘汰；通過貢獻模型構建，晉升體系構建，能效模型構建，績效考覈體系構建，人員淘汰機制構建等維度構建績效體系。

• 貢獻模型構建

     貢獻模型（考察工作過程）指個人或者團隊爲組織所做的整體工作過程貢獻衡量維度指標模型，核心考覈的是工作的可量化過程（工作量，質量，結果），是人力資源和技術管理者評估員工產出的重要參考指標。對於技術人員來說，參與的項目數量，參與的項目迭代數量，提交的任務數，出現的 bug 數，重大的故障數量，分享次數，代碼質量情況，價值達成情況（技術價值，業務價值，產品價值），360 度評價結果，上級評價結果等等都可以作爲貢獻模型的一些指標來源，最終量化的評價個人能力得分；對於技術管理人員來說，直接下屬的綜合平均得分是其綜合能力得分。

• 晉升體系構建

     一般來說公司每年會有指定的晉升時間窗口，技術人員根據自身意願或上級主管提名申請晉升或加薪機會。技術管理者需要協同 hrbp，構建晉升制度化和流程化，根據晉升人員的能力模型，貢獻模型，能效模型, 績效考覈結果（包含價值觀考覈）給予自動化的評估和參考，再根據晉升人員的面談結果，意願及個人未來成長規劃，最終評估晉升結果。特殊場景下晉升申請，需要額外特殊流程審批和考覈機制（比如考慮人員流失，破格提拔）。

• 能效模型構建

     能效指標即投入產出比，這個指標也是衡量組織健康工作狀態的一個重要參考指標。對於公司來說，定期評估組織/團隊的能效情況，是 hrbp 的日常工作，便於及時識別組織問題。而對於技術工作團隊來說，工作內容的創造性和複雜度（不像傳統行業可量化結果），是導致組織能效評估難以量化實施的本質因素。基於資源的評估模型，可以作爲其中一種可行評估的參考方式，通過梳理組織/個人的貢獻模型評定其產出價值，再通過組織/個人的資產和成本評定其投入價值，最終量化投入產出比；能效模型構建是比較大的課題，具體實操效果依然需要探索驗證。

• 績效考覈體系構建

     績效考覈（考察工作結果）指個人或者團隊制定和實現目標的最終結果完成度的指標量化模型。貢獻模型考覈的是目標達成過程細節爲主，可以作爲問題追溯和參考指標；績效考覈考的是目標實現結果爲主，可以作爲重要的激勵指標。技術管理者不光爲結果激勵，同樣給予過程優秀成長者獎勵。績效考覈應包含價值觀考覈和目標達成結果考覈兩塊，包含個人自評考覈和直屬主管考覈兩方面；自評和主管考覈結果指標相差較大者，hrbp 和直屬主管應及時約談，幫助考覈人認識目標預期期望和差異；考覈指標結果直接影響績效激勵，但不影響年終激勵。

• 人員淘汰機制構建

     人員淘汰機制是不斷優化團隊能力的一種方式，讓不合適的人離開或降級團隊是對團隊和公司最大的負責，但如何定義“不合適”需要技術管理者協同 hrbp 建立標準的制度和規則去識別。一般來說會根據公司的基本制度規定，績效考覈，主管淘汰權利三塊去定義人員淘汰或降級，比如違法基本保密協議等嚴重違規，在公司層面直接淘汰；績效考覈超過連續兩次不合格的員工，直接主管和 hrbp 會約談幫助，視情況再做決定；其他嚴重影響團隊的行爲，主管舉證後可以決定淘汰；年終整體績效過低的員工按照適當比例（按照公司發展情況），考慮予以一定幫助或者勸退處理。

小結

     一家優秀公司的成功往往包含優秀人才加組織的成功，管理之術致力於打造整個人才體系，激勵優秀的人最終帶領組織走向成功。然而對人的管理是複雜的，因爲每個人的訴求和期望都是不一樣的，管理者需要對人性有透徹的理解。而技術管理者尤其要理解管理之術終究是手段，是有了解工程師文化，真正的走進技術人員的內心纔能有效激勵，吾等共勉。

器：在於通過系統化，工具化體系整體提升工程效能，精細化管理。

     社會（農業，工業，現代化）發展至今，產能的提升本質上來源於工具的提升。無論團隊大小，工具對於研發效能的提升是顯而易見的，一些場景下也許可以帶來 5 倍，10 倍的提升。因此技術管理者必須關注技術行業內最新及最佳的一些實踐，及評估嘗試這些實踐所沉澱的一些平臺或者工具賦能整個技術團隊。我們在實踐從五個維度(技術一體化，業務一體化，監控一體化，運維一體化，管理一體化)構建研發體系，不斷在其中引入一些第三方的工具/平臺/開源/理念，和自研一些工具或者框架來提升整體研發體驗和效率。

• 雲平臺

     雲平臺的好處是按需使用，簡單方便。對於創業型的小公司，可以快速開發上線驗證商業模式，減少 IT 運維的很大工作量。當然雲平臺從原則上來說規模化會帶來成本的降低，實際情況並非如此，上一定規模以後可以適當考慮場景和成本自建服務器或搭建混合雲方式。國內考慮騰訊雲，阿里雲；國外考慮 aws 和 google 雲。與第三方雲廠商合作的時候，折扣可以談一談，爭取 2 折，5 折優惠。

• 雲原生

     Kubernetes 是最佳的實踐雲原生工具；在實踐過程中，雲原生帶來的服務器資源的減少約有 30%左右，特別是針對開發，測試，預發環境，使用人員不多不頻繁，雲原生帶來的資源複用，利用率還是很高的，成本降低也會很明顯。雲原生不僅僅是在服務上面的改造，也在基礎設施上考慮全部雲原生化，可以有效提升運維的效率和標準化的實踐。

• Devops

     市面上有很多 devops 商業解決方案，有一些都會和雲原生和各自雲平臺兼容或者結合。但是可惜的是解決方案做的比較深入，跟自身的一些方案結合比較緊密，反而通用性降低一些，而我們需要的更多是可插拔的定製化方式。自研 ops 自動化運維平臺，配合自定義的標準化 cicd 方式其實更適合自身場景（另外配套其他的解決方案），但是這個不是銀彈方案，究其本質目的是簡化運維，簡化發佈。

• 企業協同辦公溝通工具

     市面上企業協同辦公的工具有很多，而且很大部分都是免費的。比如企業微信，釘釘，飛書，從所有協同軟件使用的經歷來說，個人還是比較喜歡釘釘，當然飛書也還可以，企微最不喜歡。企業協同辦公工具，決定了分佈式遠程辦公，異地辦公的溝通效率問題，效能提升好幾倍；但是小團隊成員同辦公區域，一般感覺不出來，差異不明顯。

• 自研標準化框架

     技術選型基本上會考慮熱門的語言，主流的技術，畢竟這樣的人才會更多，比如 java。開源社區的活躍度，解決方案的成熟度和活躍度也都是考慮的範圍，比如 spring 框架體系。特有的一些技術標準的整合和技術工具的整合，比如自研 bsf 框架，business 業務框架，腳手架，可以幫助開發人員一分鐘快速上手進入開發，能效提升非常明顯。

• 自研效能平臺

     阿里，騰訊，百度等一些公司都在研發效能平臺，期望在研發整個鏈路上提升人員的投入產出比。同樣，我們也期望能夠有一個簡單有效的平臺，能夠將公司的文化，管理理念，制度，研發管理流程等沉澱到這樣的平臺中，能夠實時反饋發現人員，項目，組織的效能問題並及時根據問題思考並改進它；效能平臺本質的意義在於科學化，指標化，精細化的管理，將管理過程可量化，可追溯，可對比。這個也是研發體系管理一體化要做的，將管理的事情標準化，流程化；標準化，流程化的事情自動化，系統化；當然過程真正實操，其實挺難，但是團隊上規模後必須要做。

• 自研監控平臺 pms

     監控平臺是整個技術平臺和業務平臺穩定性的最後防線，而最快速度發現問題，解決問題，靠的是體系化的監控平臺建設。很多第三方也提供了商業化或者免費的，開源的監控解決方案，比如聽雲，skywalking，cat 等。大多數的解決方案其實並不能滿足需求，比如一些自定義的中間件，組件，標準化的技術方案，我們需要植入自有的監控，也有一些業務監控和埋點可能需要動態的配置，同時也有一些特有的報警和相關的監控策略及代碼質量情況都需要納入監控體系建設，最終需要公司基於業務場景和管理規範等梳理一套監控標準和經驗去幫助定級問題，及時發現問題，指導解決問題，甚至自愈服務。

• 自研全鏈路壓測平臺

     如果對公司的業務有性能要求並將性能指標作爲日常的技術標準及上線標準，我們可能需要全鏈路的壓測平臺，定時自動化的生成日常的性能報告及性能預測。其中會涉及流量的錄製和精準回放及生成壓測報告，最終讓壓測全自動化，解放測試人員的這塊精力和重複工作。

• 第三方工具

     業內最佳項目管理實踐有很多，而且很多管理者都有相關的新的和工具沉澱，這就給其他技術管理者很大的借鑑。比如 tapd,worktile 等都可以使用一下，但是要結合自身公司的實際情況和管理的側重點。

小結

    管理之器引入的是工具和自動化實踐所給予我們的效能提升，從而引爆整個技術生產力。然而管理者須知工具終究爲工具，真正能帶來改變的依然是人。不同人對同一個工具尚且能帶來不同的結果，那麼不同的管理方式帶領不同的人使用同一個工具最終的結果和效能也許也完全不同。所以技術管理者依然需要警醒，人和管理纔是需要長期關注的核心，最終工具才能帶來爆發式的提升。

勢：在於建立或者迎合公司和行業的形勢，懂戰略，明方向。

    這個時代有很多機會，整體的商業形勢及技術形勢都在不斷地變化着，單純的閉門造車去打造一個產品的時代已經過去了。這就要求技術管理者能夠對自身的行業商業形勢足夠敏感，對技術的更新迭代形勢足夠敏感，並做好提前的規劃，所以技術管理者需要掌握或建立內勢與外勢的變化。

• 外勢是外部行業的形勢和商業的形勢

     幾年之前互聯網高速發展，很多行業都處於行業的風口，雷軍說過一句話：“站在風口上，豬都能飛起來”，這句話是爲了說明創業成功的本質是找到風口，順勢而爲；源自於《孫子兵法·兵勢篇》，“故善戰人之勢，如轉圓石於千仞之山者，勢也”，意思是善於指揮打仗的人所造就的“勢”，就象讓圓石從極高極陡的山上滾下來一樣，來勢兇猛。而技術管理者需要去感知了解整體行業形勢的，及早的配合公司的戰略及時做業務的調整。特別是技術領域的變化，比如自然語言處理，人工智能，深度學習等一些新技術領域能夠給予業務的賦能和創新，也都是非常有價值和值得去嘗試的。一些業內的最佳實踐和第三方成熟的商業解決方案（比如藍鯨，聽雲，極光等），可以深入去接觸及評估，考量這些技術帶給業務的複用性，從而降低自研的成本。

• 內勢是建立內部的成事的基礎和必要條件（造勢）

     推進一些目標的執行和落地，要考慮天時，地利，人和等多方面的因素，天時指做事的時機是否合適，地利是指成事的資源條件是否具備，人和是指團隊的凝聚力和心態。優秀的技術管理者核心的工作內容是根據目標，建立內部這樣的成事條件（造勢），幫助團隊成員在一堆事務中，找準真正高價值痛點，集結優勢資源創造條件，推進並解決它。比如一些技術的變革和標準化的實施，可以根據當前已經發生的故障（某些重大服務不可用故障）和問題進行復盤（找準痛點單點突破），梳理體系化的解決方案，找技術高 P 進行逐步規劃落地。

小結

    管理之勢是需要讓管理者跳出事務執行本身，從整個大局看清楚事情成敗的主因，無論大到公司戰略，還是小到內部事務的推進，都需要管理者能夠深度思考本質，因勢利導。然後管理者依然需要警醒，形勢雖然能夠帶來振幅和機遇，但是優秀脫穎而出的產品和成果纔是帶領公司和組織走下去的真正實力，所以成事的關鍵依然來源於本身組織的優秀人才和團隊的執行力，才能最終拿出產品和成果。

總結

    研發管理體系的構建並沒有完整的最佳實踐可以直接複用，就如同世上沒有一樣的組織，一樣的心路經歷，所以需要技術管理者在不斷地感悟中沉澱自身的一些框架性方法論，去應對未來公司發展所面對的挑戰。我們依然需要學習，刷新，沉澱，分享，交流，與同路者砥礪前行！

 

by 車江毅

技術vp

2021-10-18

字數:13974