背景
在公司和業務發展到一定階段，高層管理者會逐步期望從直徑訓的管理逐步轉向量化的關鍵指標管理；同時從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 開源是一種態度，分享是一種精神，學習仍需堅持，進步仍需努力，.net生態圈因你我更加美好，轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/543468.html
標籤：其他
上一篇：TFS2015遷移到新服務器
下一篇：TFS2015遷移到新服務器