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