隨著公司日益發(fā)展壯大，各體系加起來已經(jīng)有數(shù)萬人的研發(fā)隊(duì)伍，在過往的實(shí)踐過程中，也逐步積累了一些研發(fā)效能度量的習(xí)慣和指標(biāo)，但是這些指標(biāo)從今天的角度來看，似乎存在一些限制和弊端。

1. 以打卡或工時(shí)數(shù)據(jù)進(jìn)行度量

在缺少其他度量手段或有效度量指標(biāo)的情況下，把工作時(shí)長作為度量指標(biāo)似乎是順其自然的。度量團(tuán)隊(duì)成員是否按時(shí)在項(xiàng)目中開展工作、工作量是否飽滿，其實(shí)是從人力資源利用率的角度來看待問題的。而實(shí)際上，當(dāng)局部人力資源過度地優(yōu)化，會(huì)造成大量排隊(duì)、等待以及頻繁的工作任務(wù)切換，看上去很高的資源利用率不但無法轉(zhuǎn)化為真實(shí)的生產(chǎn)力，反而會(huì)傷害端到端的生產(chǎn)效率。

2. 以局部產(chǎn)出（代碼行或缺陷數(shù)）進(jìn)行度量

代碼行或缺陷數(shù)其實(shí)是對(duì)開發(fā)、測試崗位很常見的度量方式。而實(shí)際上，如果將代碼行的產(chǎn)出作為考核KPI，除了會(huì)得到一堆臃腫、難以維護(hù)的代碼之外沒有任何好處；如果將研發(fā)過程中發(fā)現(xiàn)的缺陷數(shù)作為考核KPI，自然會(huì)形成開發(fā)與測試團(tuán)隊(duì)之間的『混亂之墻』，除了增加團(tuán)隊(duì)之間的隔閡也沒有其他好處。

3. 以敏捷研發(fā)過程中的一些概念（如故事點(diǎn)數(shù)）進(jìn)行度量

有些采用敏捷研發(fā)模式的團(tuán)隊(duì)，在使用每個(gè)迭代能完成的故事點(diǎn)數(shù)或迭代速率來進(jìn)行度量和考核，而實(shí)際上這只是一種容量規(guī)劃工具(推測需要多久完成工作)，絕對(duì)數(shù)值跟團(tuán)隊(duì)緊密相關(guān)，但無法進(jìn)行橫向比較，否則又會(huì)導(dǎo)致大家玩起數(shù)字游戲了。

通過以上分析可以得知，我們對(duì)軟件研發(fā)效能的度量，應(yīng)當(dāng)遵從以下兩個(gè)基本原則：

1. 聚焦在全局指標(biāo)而不是局部指標(biāo)

我們要促進(jìn)跨越職能和功能，在團(tuán)隊(duì)內(nèi)、團(tuán)隊(duì)間彼此高效協(xié)作。

2. 聚焦在結(jié)果產(chǎn)出而不是某階段工作輸出

我們不應(yīng)對(duì)那些看似繁忙但只產(chǎn)出了一大堆無效工作輸出的團(tuán)隊(duì)或人員進(jìn)行獎(jiǎng)勵(lì)，而是引導(dǎo)到那些對(duì)促進(jìn)組織達(dá)成目標(biāo)有實(shí)際幫助的工作上去。

根據(jù)以上原則，我們確定了從全局性出發(fā)，以結(jié)果產(chǎn)出為牽引的一系列研發(fā)效能度量指標(biāo)。這些指標(biāo)也反映出了研發(fā)效能改進(jìn)的關(guān)鍵點(diǎn)，即以端到端的流動(dòng)效率（而非資源效率）為核心。這里的流動(dòng)效率是指需求（或用戶價(jià)值）在整個(gè)系統(tǒng)中跨越不同職能和團(tuán)隊(duì)流動(dòng)的速度，速度越快則需求交付的效率越高、交付時(shí)長越短。當(dāng)然這并不是只關(guān)注流動(dòng)效率、不關(guān)注資源效率（如工時(shí)、資源利用率等），而是在確保前者效率足夠高的情況下再逐步提升后者，最終追求的是二者的協(xié)同優(yōu)化。

我們把研發(fā)效能度量指標(biāo)分為三個(gè)維度，分別是交付效率、交付質(zhì)量和交付能力。這些指標(biāo)的提升需要組織進(jìn)行管理、技術(shù)、協(xié)作等多方面的系統(tǒng)性改進(jìn)。

1. 交付效率

目標(biāo)是促進(jìn)端到端、及早的交付，用最短的時(shí)間順暢地交付用戶價(jià)值。具體可細(xì)分為以下指標(biāo)：

●    需求交付周期：從需求提出，到完成開發(fā)、測試、上線，最終驗(yàn)收通過的時(shí)間周期。反映了整個(gè)團(tuán)隊(duì)（包含業(yè)務(wù)、產(chǎn)品、開發(fā)、測試、運(yùn)維等職能）對(duì)客戶問題或業(yè)務(wù)機(jī)會(huì)的交付速度，依賴整個(gè)組織各職能和部門的協(xié)調(diào)一致和緊密協(xié)作；

●    開發(fā)交付周期：從需求被研發(fā)團(tuán)隊(duì)確認(rèn)，到完成開發(fā)、測試，達(dá)到可上線狀態(tài)的時(shí)間周期。反映了研發(fā)技術(shù)團(tuán)隊(duì)的交付速度，依賴需求的拆分和管理，開發(fā)團(tuán)隊(duì)的分工協(xié)作；

●    交付吞吐量：統(tǒng)計(jì)周期內(nèi)交付的需求個(gè)數(shù) / 統(tǒng)計(jì)周期，即單位時(shí)間交付的需求個(gè)數(shù)。需要注意的是，需求顆粒度要保持一定規(guī)則，避免需求大小不統(tǒng)一導(dǎo)致的數(shù)據(jù)偏差；

2. 交付質(zhì)量

目標(biāo)是促進(jìn)端到端高質(zhì)量交付，避免不必要的錯(cuò)誤和返工。具體可細(xì)分為以下指標(biāo)：

●    線上缺陷密度：統(tǒng)計(jì)周期內(nèi)線上或單個(gè)版本嚴(yán)重級(jí)別Bug數(shù)量 / 需求個(gè)數(shù)；

●    故障恢復(fù)時(shí)間：線上系統(tǒng)和應(yīng)用如果發(fā)生故障，多長時(shí)間可以進(jìn)行恢復(fù)；

●    上線成功率：上線部署成功，上線沒有導(dǎo)致服務(wù)受損、降級(jí)或需要事后補(bǔ)救的比例；

3. 交付能力

目標(biāo)是建設(shè)卓越工程能力，實(shí)現(xiàn)持續(xù)交付。具體可細(xì)分為以下指標(biāo)：

●    發(fā)布頻率：單位時(shí)間內(nèi)的有效發(fā)布次數(shù)。團(tuán)隊(duì)對(duì)外響應(yīng)的速度不會(huì)大于其發(fā)布頻率，發(fā)布頻率約束了團(tuán)隊(duì)對(duì)外響應(yīng)和價(jià)值的流動(dòng)速度；

●    發(fā)布前置時(shí)間：代碼提交到功能上線的時(shí)長。反映了團(tuán)隊(duì)的工程技術(shù)能力，依賴交付過程中高度自動(dòng)化以及架構(gòu)支撐能力；

度量指標(biāo)詳細(xì)定義及計(jì)算邏輯如下表所示：

目前京東在研發(fā)基礎(chǔ)設(shè)施的相關(guān)工具平臺(tái)中（包括項(xiàng)目管理、敏捷協(xié)作、代碼托管、持續(xù)集成、部署發(fā)布、異常監(jiān)控等）已經(jīng)沉淀了大量的研發(fā)過程數(shù)據(jù)信息，我們將會(huì)通過以上指標(biāo)的整合/分析，呈現(xiàn)給團(tuán)隊(duì)和管理者更真實(shí)有效的研發(fā)效能數(shù)據(jù)，促進(jìn)研發(fā)更有針對(duì)性的改進(jìn)提升。

本文從軟件研發(fā)效能度量的難點(diǎn)出發(fā)，指出了一些現(xiàn)有度量方式的限制和弊端，進(jìn)而提出軟件研發(fā)效能度量的正確姿勢，即遵循 全局指標(biāo) > 局部指標(biāo)、結(jié)果產(chǎn)出 > 工作輸出 的基本原則。最后，文章給出了交付效率、交付質(zhì)量和交付能力三個(gè)維度的度量指標(biāo)集合及計(jì)算邏輯。

為了提升公司各職能部門協(xié)調(diào)一致，持續(xù)、快速、高質(zhì)量交付需求或用戶價(jià)值的能力，我們需要從當(dāng)前關(guān)注資源效率為主的管理思路，轉(zhuǎn)變?yōu)橐粤鲃?dòng)效率為核心、兼顧資源效率的管理模式。以上的研發(fā)效能結(jié)果性指標(biāo)可以看做量化診斷問題和有針對(duì)性進(jìn)行改進(jìn)的抓手，這些都是研發(fā)效能提升的基礎(chǔ)。當(dāng)然，在結(jié)果性指標(biāo)的牽引下，還需要一系列更為細(xì)節(jié)的過程性指標(biāo)，覆蓋研發(fā)活動(dòng)各個(gè)階段的微觀度量，這些指標(biāo)我們將會(huì)持續(xù)梳理并與大家探討。

后續(xù)還將結(jié)合具體的研發(fā)管理實(shí)踐（如敏捷研發(fā)和看板方法）與工程實(shí)踐（代碼評(píng)審、持續(xù)集成和持續(xù)交付、部署模式等），配合工具平臺(tái)的固化和落地，進(jìn)一步整合研發(fā)效能提升的方法、技術(shù)和實(shí)施路徑，也歡迎大家與我們共同探討并開展合作，共同促進(jìn)研發(fā)效能的提升。