產研指南針的量化指標實踐筆記

在公司和業務發展到一定階段，高層管理者會逐步期望從直覺化的管理逐步轉向量化的關鍵指標管理；同時從hr層面okr和kpi的考核逐步從直覺化的定性考核，轉變為資料化指標考核為主做評估和分析。此時中層管理者要實踐關鍵指標讀取和分析，及對團隊成員從長期關注，變成短期快速反饋並推進績效改進。

1. 研發成果難以評估：研發屬於研究性的腦力輸出,不同能力輸出的結果是不一樣的，難以通過可見性的指標精準評估成果的好壞。

2. 研發指標容易作弊：研發指標難以通過自動化的標準準確輸出可靠，諸如程式碼質量只能是相對的。特定的指標容易通過作弊的方式達成（比如程式碼行數）。

3. 大量重複性的統計：量化指標需要大量研發過程性資料的統計，需要打通多種過程工具，按照多維度產出報表，對於管理者耗時耗力。

4. 過度的透明化，造成目標轉移：定性考核往往以結果為目標（雖然容易造成大鍋飯），結果目標明確。量化考核往往以人和團隊為衡量，量化結果容易造成團隊內卷，變成指標為目標，而非業務為目標(而個人成果難以量化對齊業務結果)。

1. 研發應當以多個指標考核結果,分別從使用者的反饋，運營的結果，過程的量化，質量情況(故障率)，hr的統一管理標準，360評價，目標的kpi/okr的綜合結果，計算比較合理的權重分值(可以自動化算出合理權重)。

而實際落地需要根據實際業務的場景，團隊的規模情況及公司的管理策略及文化價值觀決定，定義核心的幾個關鍵指標（畢竟每家公司和管理的方法論都是不一樣的，比如高效能研發體系建設闡述的管理一體化的實踐）為佳，過於全面反而耗時耗力。通過多維指標綜合判定和行政管理，可以解決單一指標作弊和不準的問題。

2. 研發的體系，人員組成，架構方案在不同公司，不同業務場景，包括管理工具肯定都是不一樣的。即便管理者的方法論或許一樣，但是過程性的資料來源肯定是不一樣的。重複性的統計輸出，肯定會造成重複性的勞動，所以同樣指標的分析和統計肯定要系統化和工具化，去解決重複性的問題。通過自研投入（非開源）來解決實際方案和資料來源不一樣的等問題。

3. 研發的指標不應當過度透明化公開（對個人透明），但是要體現團隊優秀人員的指標，讓個人瞭解差距和問題，激勵個人成長。團隊管理最終應該以人為本，考慮人本身管理的差異和定位，而量化指標應當是結合實際情況，去分析管理問題的依據和問題點，反推管理的不足和問題的本質因素，從而推進個人效能提升和改進。所以量化指標應該重視並分析（應該作為微管理的輔助參考資料），但不應過於倡導造成團隊內卷(對於沒有實在無法對齊業務目標結果的同學可以考慮直接優化，而非通過指標去過度評判)。

 

不同公司的研發管理工具和資料分析工具都是不一樣的，諸如結合小型研發團隊（50人以內），採用飛書協同，禪道管理，sonar質量分析，gitlab管理程式碼，java/react開發及標準化的研發體系的基礎上，我們自研自己的指南針量化指標小工具（榮譽榜），去解決人員管理對於快速覆盤效能情況，快速發現管理問題，快速反饋人員狀態，量化資料考核指標的問題。我們提出幾個關鍵研發指標去參考和衡量研發個人的產出和狀態，分別為平均工作時長，累計加班時長，遲到/缺卡次數，任務數，任務工時，製造Bug數，發現Bug數，程式碼提交數，程式碼不合格(未解決數量)，效能差介面數,故障數。在這些指標量化的基礎上，通過同型別研發角色（測試，前端，後端）的多維度對比，去思考研發人員優良差的情況和原因。

平均工作時長：系統打通飛書api，獲取飛書每日的打卡時間，排除請假，缺卡，遲到等因素外的正常上班的時長為準。

累計加班時長：系統打通飛書api，獲取飛書每日正常下班之後，24點之前的加班時長為累計。

遲到/缺卡次數：系統打通飛書api，獲取飛書每日遲到和缺卡的次數（排除請假）。

上班時長是一些基礎性的資料，也是hr比較關注的核心資料指標。管理者一般也期望通過上班時長去了解團隊成員和整體的激情和狀態。

任務數：系統打通禪道，獲取禪道每人的工作任務明細，並統計數量，包括任務的分佈甘特圖等情況。

任務工時：系統打通禪道，獲取禪道每人的任務的開始和完成時間（預估時間），包括統計每人的工作整體飽和度和每日的飽和度情況。

製造bug數：系統打通禪道，獲取禪道每人的bug數的情況和每日分佈情況。

發現bug數：系統打通禪道，獲取禪道提交bug數量，主要統計分析測試人員的工作情況。

程式碼提交數：系統打通gitlab，獲取每個人的gitlab程式碼提交的數量，主要是統計分析每個人的程式碼新增的程式碼數量減去刪除程式碼數量。實操過程中我們發現一些異常的程式碼管理會造成資料差異過大的情況。諸如刪除專案紀錄檔（已進入倉庫）,新建專案時候的腳手架程式碼數，格式化程式碼等問題。

日常的專案溝通到立項階段，以飛書協同檔案為主（多維表格專案管理模板），在專案管理之外所有已確定的工作任務錄入禪道，以禪道做專案管理模板，進行統一的集中式管理，這個也是目前公司要求的通用管理模式。但無論何種模式下，管理者在這個階段比較關注的是人員的工作飽和度和過程質量兩個關鍵問題及相應的關鍵指標。

程式碼不合格（未解決數量）：系統打通sonar，獲取sonar程式碼分析之後的質量情況，統計到每個人的程式碼異常情況。比如java會按照阿里巴巴的程式碼編寫規範做標準分析。

故障數：系統打通飛書檔案，我們通過故障群統一接收線上故障資訊，通過機器人自動錄入到飛書檔案進行歸檔，我們通過2週一次覆盤故障的責任人，級別，類別，時長（故障等級標準），超過一定級別的故障需要有故障報告並通知關鍵成員；而故障數是最重要的質量參考指標。

效能差介面數: 系統打通「全鏈路自動化壓測平臺」,通過錄制和回訪模式,自動化統計效能差的介面並歸類到具體研發。

程式碼實際設計情況一般來說很難通過自動化的方式去量化去判別，人工codereview也難以精準判別；在人員有限的資源下，通過真實的質量反饋和程式碼規範是關鍵質量考核參考。

 

主要有兩個功能：榮譽排行榜和多維分析報告。

榮譽排行榜：面向普通開發人員，去公開最近兩週優秀的指標排行榜，去讓成員瞭解自身在團隊內的表現情況，瞭解並分析差距的因素。

多維分析報告：面向管理人員，對同型別團隊成員對比表現情況，實時分析每週（近期）的真實表現情況，去了解和分析量化資料背後的真實因素。將定性管理轉變為資料管理模式，將直覺管理轉化量化管理模式；從而快速，及時，有效的分析專案問題和人員情況，儘快介入解決管理問題。

 

如圖：

 

萬位數位CTO分享他們的量化指標維度實踐,並將之作為量化考核。如圖:

 

 

搜狐社交總經理分享他們的六象限雷達圖，將之作為量化結果管理輔助參考。如圖:

 

作為管理者，我們需要思考雖然管理方法，指標及工具能夠帶給我們的一些便利性和實踐，但是我們也謹慎的意識到工具和方法終究在管理之術的範疇，管理本身面對的是人，最終要以人為本，核心關鍵在於目標和激勵（五個維度構建研發管理體系闡述了研發管理整體性的思考）。同時管理者也要清晰，管理的職能僅僅是達成目標的手段和過程，而我們最終要以業務和結果為目標！！！

 

以上心得，多做反思，勤做筆記，與君共勉~

 

by 車江毅

2022-11-10