為了有效應對當前充滿易變性、不確定性、復雜性與模糊性的互聯(lián)網(wǎng)大環(huán)境，今年年初京東提出了數(shù)字化管理的戰(zhàn)略方向，通過數(shù)字化的技術和管理模式提升組織績效。在這個背景下，研發(fā)效能的提升就成為了很多產(chǎn)品技術部門今年的重要目標，有些部門專門成立了相應的工程效率團隊，期望從組織、文化、技術、流程等方面的優(yōu)化來促進研發(fā)效能的整體提升。
然而，究竟什么是好的研發(fā)效能？我們如何定義它？其實很少有人能夠表達清楚。雖然本質上都是通過一定的工作來生產(chǎn)（研發(fā)）產(chǎn)品，但不同于生產(chǎn)制造行業(yè)，軟件研發(fā)效能的度量其實是相對困難的，原因有以下三個：
1.研發(fā)過程中的可視性差
涉及到業(yè)務、產(chǎn)品、研發(fā)、運維等不同職能，多個團隊多種角色協(xié)作時，任務處理的進度、隊列、瓶頸可能很難清晰觀察到，以至于項目管理軟件中很多任務的進度百分比可能只有參考意義，實際并不準確。
2. 工作切分的隨意性
有時管理者會制定一些KPI來度量團隊績效，但就像那句名言所說：你度量什么，就會得到什么。其實這句話只說了一半，另一半是：只是不一定是用你所期待的方式得到。所謂上有政策、下有對策，由于軟件工作切分的隨意性，也許把一個需求拆成多個小需求，一行代碼拆成多行來寫，某些KPI指標就被用非預期的方式完成了。
3. 敏捷研發(fā)過程中工作是并行的
隨著公司敏捷研發(fā)模式的持續(xù)推進，我們很難再像傳統(tǒng)項目管理模式一樣清晰界定軟件研發(fā)的各個階段，很多情況下不同需求所對應的開發(fā)/測試工作都是并行的，產(chǎn)品也是不斷迭代、持續(xù)演進的，這也對準確度量造成了一定困難。
隨著公司日益發(fā)展壯大，各體系加起來已經(jīng)有數(shù)萬人的研發(fā)隊伍，在過往的實踐過程中，也逐步積累了一些研發(fā)效能度量的習慣和指標，但是這些指標從今天的角度來看，似乎存在一些限制和弊端。
1. 以打卡或工時數(shù)據(jù)進行度量
在缺少其他度量手段或有效度量指標的情況下，把工作時長作為度量指標似乎是順其自然的。度量團隊成員是否按時在項目中開展工作、工作量是否飽滿，其實是從人力資源利用率的角度來看待問題的。而實際上，當局部人力資源過度地優(yōu)化，會造成大量排隊、等待以及頻繁的工作任務切換，看上去很高的資源利用率不但無法轉化為真實的生產(chǎn)力，反而會傷害端到端的生產(chǎn)效率。
2. 以局部產(chǎn)出（代碼行或缺陷數(shù)）進行度量
代碼行或缺陷數(shù)其實是對開發(fā)、測試崗位很常見的度量方式。而實際上，如果將代碼行的產(chǎn)出作為考核KPI，除了會得到一堆臃腫、難以維護的代碼之外沒有任何好處；如果將研發(fā)過程中發(fā)現(xiàn)的缺陷數(shù)作為考核KPI，自然會形成開發(fā)與測試團隊之間的『混亂之墻』，除了增加團隊之間的隔閡也沒有其他好處。
3. 以敏捷研發(fā)過程中的一些概念（如故事點數(shù)）進行度量
有些采用敏捷研發(fā)模式的團隊，在使用每個迭代能完成的故事點數(shù)或迭代速率來進行度量和考核，而實際上這只是一種容量規(guī)劃工具(推測需要多久完成工作)，絕對數(shù)值跟團隊緊密相關，但無法進行橫向比較，否則又會導致大家玩起數(shù)字游戲了。
通過以上分析可以得知，我們對軟件研發(fā)效能的度量，應當遵從以下兩個基本原則：
1. 聚焦在全局指標而不是局部指標
我們要促進跨越職能和功能，在團隊內、團隊間彼此高效協(xié)作。
2. 聚焦在結果產(chǎn)出而不是某階段工作輸出
我們不應對那些看似繁忙但只產(chǎn)出了一大堆無效工作輸出的團隊或人員進行獎勵，而是引導到那些對促進組織達成目標有實際幫助的工作上去。
根據(jù)以上原則，我們確定了從全局性出發(fā)，以結果產(chǎn)出為牽引的一系列研發(fā)效能度量指標。這些指標也反映出了研發(fā)效能改進的關鍵點，即以端到端的流動效率（而非資源效率）為核心。這里的流動效率是指需求（或用戶價值）在整個系統(tǒng)中跨越不同職能和團隊流動的速度，速度越快則需求交付的效率越高、交付時長越短。當然這并不是只關注流動效率、不關注資源效率（如工時、資源利用率等），而是在確保前者效率足夠高的情況下再逐步提升后者，最終追求的是二者的協(xié)同優(yōu)化。
我們把研發(fā)效能度量指標分為三個維度，分別是交付效率、交付質量和交付能力。這些指標的提升需要組織進行管理、技術、協(xié)作等多方面的系統(tǒng)性改進。
1. 交付效率
目標是促進端到端、及早的交付，用最短的時間順暢地交付用戶價值。具體可細分為以下指標：
● 需求交付周期：從需求提出，到完成開發(fā)、測試、上線，最終驗收通過的時間周期。反映了整個團隊（包含業(yè)務、產(chǎn)品、開發(fā)、測試、運維等職能）對客戶問題或業(yè)務機會的交付速度，依賴整個組織各職能和部門的協(xié)調一致和緊密協(xié)作；
● 開發(fā)交付周期：從需求被研發(fā)團隊確認，到完成開發(fā)、測試，達到可上線狀態(tài)的時間周期。反映了研發(fā)技術團隊的交付速度，依賴需求的拆分和管理，開發(fā)團隊的分工協(xié)作；
● 交付吞吐量：統(tǒng)計周期內交付的需求個數(shù) / 統(tǒng)計周期，即單位時間交付的需求個數(shù)。需要注意的是，需求顆粒度要保持一定規(guī)則，避免需求大小不統(tǒng)一導致的數(shù)據(jù)偏差；
2. 交付質量
目標是促進端到端高質量交付，避免不必要的錯誤和返工。具體可細分為以下指標：
● 線上缺陷密度：統(tǒng)計周期內線上或單個版本嚴重級別Bug數(shù)量 / 需求個數(shù)；
● 故障恢復時間：線上系統(tǒng)和應用如果發(fā)生故障，多長時間可以進行恢復；
● 上線成功率：上線部署成功，上線沒有導致服務受損、降級或需要事后補救的比例；
3. 交付能力
目標是建設卓越工程能力，實現(xiàn)持續(xù)交付。具體可細分為以下指標：
● 發(fā)布頻率：單位時間內的有效發(fā)布次數(shù)。團隊對外響應的速度不會大于其發(fā)布頻率，發(fā)布頻率約束了團隊對外響應和價值的流動速度；
● 發(fā)布前置時間：代碼提交到功能上線的時長。反映了團隊的工程技術能力，依賴交付過程中高度自動化以及架構支撐能力；
度量指標詳細定義及計算邏輯如下表所示：
目前京東在研發(fā)基礎設施的相關工具平臺中（包括項目管理、敏捷協(xié)作、代碼托管、持續(xù)集成、部署發(fā)布、異常監(jiān)控等）已經(jīng)沉淀了大量的研發(fā)過程數(shù)據(jù)信息，我們將會通過以上指標的整合/分析，呈現(xiàn)給團隊和管理者更真實有效的研發(fā)效能數(shù)據(jù)，促進研發(fā)更有針對性的改進提升。
本文從軟件研發(fā)效能度量的難點出發(fā)，指出了一些現(xiàn)有度量方式的限制和弊端，進而提出軟件研發(fā)效能度量的正確姿勢，即遵循 全局指標 > 局部指標、結果產(chǎn)出 > 工作輸出 的基本原則。最后，文章給出了交付效率、交付質量和交付能力三個維度的度量指標集合及計算邏輯。
為了提升公司各職能部門協(xié)調一致，持續(xù)、快速、高質量交付需求或用戶價值的能力，我們需要從當前關注資源效率為主的管理思路，轉變?yōu)橐粤鲃有蕿楹诵摹⒓骖欃Y源效率的管理模式。以上的研發(fā)效能結果性指標可以看做量化診斷問題和有針對性進行改進的抓手，這些都是研發(fā)效能提升的基礎。當然，在結果性指標的牽引下，還需要一系列更為細節(jié)的過程性指標，覆蓋研發(fā)活動各個階段的微觀度量，這些指標我們將會持續(xù)梳理并與大家探討。
后續(xù)還將結合具體的研發(fā)管理實踐（如敏捷研發(fā)和看板方法）與工程實踐（代碼評審、持續(xù)集成和持續(xù)交付、部署模式等），配合工具平臺的固化和落地，進一步整合研發(fā)效能提升的方法、技術和實施路徑，也歡迎大家與我們共同探討并開展合作，共同促進研發(fā)效能的提升。
