如何衡量研發效能?阿里資深技術專家提出了5組指標
阿里妹導讀:新的一年,相信很多產品技術團隊把研發效能提升列為重要的目標,甚至還有團隊為此專門成立了專案組。然而,到底什麼是好的研發效能,卻很少有人能夠表達清楚。標準不清晰,又何談提升?
今天,阿里研發效能部資深技術專家何勉老師,將與大家分享他多年的思考與觀點,希望對你有所啟發。
本文將明確定義研發效能,並提供度量的五大指標,為研發效能的提升指明目標,並衡量提升的效果。本文也是關於研發效能提升及產品交付方法系列文章的開篇,為之後介紹的產品交付方法是否有效設立了標準。
效率豎井是研發效能改進的最大問題
產品交付需要前後職能(如:產品、開發、測試等)和平行部門(如:前端、後端、演算法等)的協作。傳統方法更多關注各個職能和部門的獨立改進。然而,過度區域性優化,往往導致效率豎井,反而損害整體效率。
什麼是效率豎井呢?上圖描述了傳統開發方式下,產品交付面臨的普遍困境——各職能和部門區域性優化帶來一系列問題,如:
基於區域性資訊的工作優先順序安排,造成不同部門和職能間相互等待,讓需求無法順暢流動。比如前、中、後臺對工作的優先處理不一致,進度無法對齊,讓已經開始的需求不能及時交付。
批量式的工作移交,帶來進一步等待。為了最大化單個環節的效率,各職能往往傾向於批量接受和移交工作,如批量的整合,批量的轉測等。進一步造成需求在過程中的積壓和等待。
跨部門的問題,經常得不到及時和有效的處理。公共環境的維護,就是一個典型的問題,是影響使用者需求的順暢交付。過程中需求跨部門的有效澄清、介面對齊、問題排查是另一些常見的公共問題,它們都會造成需求無法順暢進展。
以上只是一部分問題,它們共同作用,結果是:站在各自的視角,每個部門都覺得自己繁忙且“高效”;然而,站在全域性和業務的視角,系統對外的反應卻非常遲緩。這就是所謂效率豎井。
效率豎井:由區域性優化導致,表現為:各個環節和部門繁忙而“高效”,但總體的效率和響應速度卻很低。它是研發效能提升的普遍癥結所在。
上圖的折線反映了效率豎井下,單個需求的交付過程。綠色線表示需求正在被處理,紅色線則表示需求在等待中。工作量不大的需求,交付週期卻很長。因為大部分時間需求都處於等待狀態。各個區域性一片繁忙,外部卻抱怨連連,相信很多人會感同身受。
“持續快速交付價值的能力”是效能改進的核心目標
要改進研發效能,我們必須走出效率豎井。為此組織必須把改進的焦點從關注各個資源環節,轉向關注整個系統。
上圖反映了效能改進的關鍵——從以區域性資源效率為核心,轉變為價值流動效率為核心的改進。
資源效率指的是,各環節的資源利用率和產出情況,如:資源的忙閒程度、使用率、程式碼產出和測試執行速度等。流動效率指的是,使用者價值在系統中的流動速度,如:使用者需求從提出到交付的時長,它越短越好;或者是過程中等待時間的佔比,它越小越好。
使用者價值的流動是串起整個系統,促進整體優化的不二選擇。為了提高價值的流動效率,組織就必須關注使用者價值在系統中端到端的流動過程,改進整個系統,而不僅僅是區域性環節。以此為基礎,效能改進的目標是:持續快速交付價值的能力。這也是對研發效能的基本定義。
持續快速交付價值的能力,是研發效能的核心定義。為此我們必須把改進的焦點從區域性資源效率,轉向價值流動效率,以保證全域性和系統的優化。
研發效能的度量——五組指標回答研發效能的根本問題
以上定性的定義了研發效能。管理學之父德魯克說:“如果你不能度量它,就無法改進它”。度量幫助我們更深刻認識研發效能,設定改進方向,並衡量改進效果。
產品開發過程中會產生大量的資料,但資料不是度量。好的度量的標準是:它要為回答一個根本的問題講述完整的故事。效能度量要回答的根本問題就是:一個組織“持續快速交付價值的能力”怎麼樣?
為回答這個問題,應該提供怎樣的一個完整故事呢?基於在天貓新零售、閒魚、優酷、阿里健康、研發中臺、阿里雲等部門持續實踐和探索,我們發展並驗證了系統的研發效能指標體系。如上圖所示,它由5組指標構成,分別是:
第一:持續釋出能力。具體包含兩個細分指標,分別是:
釋出頻率。 團隊對外響應的速度不會大於其交付頻率,釋出頻率約束團隊對外響應和價值的流動速度。它的衡量標準是單位時間內的有效釋出次數。
釋出前置時間(也被稱為變更前置時間),也就是從程式碼提交到功能上線花費的時間,它體現了團隊釋出的基本能力。如果時間開銷很大,就不合適加大發版頻率。
第二:需求響應週期。具體包含兩個細分的指標,分別是:
交付週期時間。指的是從確認使用者提出的需求開始,到需求上線所經歷的平均時長。它反映團隊(包含業務、開發、運營等職能)對客戶問題或業務機會的響應速度;
開發週期時間。指的是從開發團隊理解需求開始,到需求可以上線所經歷的平均時長。它反映技術團隊的響應能力。
區分交付週期和開發週期,是為了解耦並明確問題,以做出針對性的改進。其中,交付週期是最終的目標和檢驗標準。
第三:交付吞吐率。指的是單位時間內交付需求的數量。關於這一點,常見的問題是,個數能準確反映交付效率嗎?這是個問題。所以,我們更多強調單個團隊的需求吞吐率的前後對比,統計意義上它足以反映趨勢和問題。
第四:交付過程質量。它包含兩個細分的指標,分別是:
開發過程中缺陷的建立和修復時間分佈。我們希望缺陷能夠持續和及時地被發現,並且在發現後儘快修復;
缺陷庫存。我們希望在整個開發過程中控制缺陷庫存量,讓產品始終處於接近可釋出狀態,奠定持續交付的基礎。
交付過程質量的核心是內建質量,也就是全過程和全時段的質量。而非依賴特定的階段,如測試階段;或特定的時段,如專案後期。內建質量是持續交付的基礎,關於其具體度量方法,下文會給出詳細例項。
第五:對外交付質量。 它包含兩個細分的指標,分別是:1)單位時間的故障(線上問題)數;2)故障平均解決時長。這兩者共同決定了系統的可用性。
如上圖所示,這5組指標,從流動效率、資源效率和質量三個方面講述了一個完整的故事,回答了組織持續交付價值的能力如何這個核心問題。其中,持續釋出能力和需求響應週期這兩組指標反映價值的流動效率;吞吐率反映資源效率;交付過程質量和對外交付質量這兩組指標共同反映質量水平。
一個度量指標例項:缺陷趨勢圖
針對這些指標,雲效提供了豐富的度量圖表,後續雲效產品團隊還會進行場景化的梳理,提高其可用性。我會及時跟進,用專門的文章介紹雲效的完整度量方案。在這裡我先介紹一個例子——關於過程質量的度量圖表。
“缺陷趨勢圖”是雲效新設計的度量圖表,它反映交付過程中缺陷發現和移除的時間分佈,以及缺陷的庫存趨勢。
如上圖所示,圖形的橫座標是日期,橫座標上方紅色豎條代表這一天發現缺陷數量;橫座標下方綠色豎條代表當天解決的缺陷數量;橙色曲線代表缺陷存量。圖中左右兩個部分比較了兩種交付模式。
左半部分,團隊屬於小瀑布的開發模式。“迭代”前期,團隊集中設計、編碼,引入缺陷,但並未即時地整合和驗證。缺陷一直掩藏在系統中,直到專案後期,團隊才開始整合和測試,缺陷集中爆發。
小瀑布模式下,過程質量差,帶來大量的返工、延期和交付質量問題。該模式下,產品的交付時間依賴於何時缺陷能被充分移除,當然不能做到持續交付,也無法快速響應外部的需求和變化。並且,這一模式通常都導致後期的趕工,埋下交付質量隱患。
右半部分,團隊開始向持續交付模式演進。在整個迭代過程中,團隊以小粒度的需求為單位開發,持續地整合和測試它們,即時發現和解決問題。缺陷庫存得到控制,系統始終處於接近可釋出狀態。這一模式更接近持續釋出狀態,團隊對外的響應能力隨之增強。
缺陷趨勢圖從一個側面反映了團隊的開發和交付模式。它引導團隊持續且儘早發現缺陷並及時移除它們。控制缺陷庫存,讓系統始終處於接近可釋出狀態,保障了持續交付能力和對外響應能力。
缺陷趨勢圖是雲效研發效能度量圖表中的一個。後面,我會用專門的文章系統地解讀這些圖表的使用。
效能改進的目標設定:部分團隊的2-1-1願景
以上,我們介紹了研發效能度量。基於這樣的度量體系,應該設定怎樣的目標呢?我們在多個團隊的實施過程中,逐漸沉澱出了可供參考的目標體系,它可以總結為三個數字——“2-1-1”。
“2-1-1”最初來自天貓新零售,其後在閒魚和研發中臺、阿里雲等團隊完善和採用。什麼是“2-1-1”呢?
“2"指的2周的交付週期,85%以上的需求可以在2周內交付;
第一個“1”指的是1周的開發週期,85%以上的需求可以在1周內開發完成;
第二個“1”指的是1小時的釋出前置時間 - -提交程式碼後可以在1小時內完成釋出。[1]
達成“2-1-1”的願景並不容易。1小時的釋出前置時間,需要持續交付流水線,產品架構體系和自動測試、自動部署等能力的提升。1周的開發週期,涉及更多的能力和實踐,如:需求的拆分和管理,開發團隊的分工協作模式,以及持續整合和持續測試實踐;最困難的則是2周的交付週期,首先它要以另外兩個指標為基礎,同時還涉及整個組織各職能和部門的協調一致和緊密協作;
“2-1-1”的目標都是關於流動效率的,你可能會問,那資源效率和質量呢?我們專注於流動效率,是因為它是組織效能改進的抓手,能夠觸發深層次的和系統性的改進。就像上面分析的,為達成“2-1-1”目標,團隊需要技術、管理、協作等方面的全面實踐升級,而這些實踐的落地,必然會帶來資源效率和質量的提升,並體現到相應的度量指標上。
當然,“2-1-1”是源自特定的團隊,並非所有團隊都要使用同樣的值,比如對於涉及硬體開發的團隊,兩週的交付週期通常過於挑戰。組織應根據自己的上下文設定恰當的目標,重要的是,它要指明改進的方向。
總結
本文定義了研發效能,它指的是一個組織持續快速交付價值的能力,可以從流動效率、資源效率和質量三個方面來衡量。其中流動效率是改進研發效能的核心抓手,它帶來系統和全域性的改進。
如上圖所示,研發效能最終為組織效能服務,必須體現到利潤、增長、客戶滿意度等組織效能上;同時,研發效能的提升要落實到具體技術和管理的實踐中,才可能發生。
定義和度量是提升研發效能的基礎,相信你更關心提升研發的具體實踐和方法。後續,何勉老師將綜合多個團隊的實踐,介紹可操作的實踐體系和落地方法,還請持續關注“阿里技術”公眾號,我們將盡快為你送上。
注:
【1】最早雲零售部門(天貓新零售的前身)提出的目標是2-1-3,前面的“2”和“1”的含義相同,不同的是最後一個“3”指30分鐘——30分總完成釋出前的迴歸測試,但不包含釋出過程。天貓新零售的2-1-3是這一願景的最初版本,後來阿里其他團隊(最早是閒魚)將30分鐘改為了1小時,幷包含了釋出在內,這就是“2-1-1”目標的由來。
你可能還喜歡
點選下方圖片即可閱讀
終於等到你!阿里正式向 Apache Flink 貢獻 Blink 原始碼
關注「阿里技術」
把握前沿技術脈搏
相關文章
- DevOps 與研發效能資深技術專家張樂:研發效能的升維思考與降維執行dev
- GPU效能衡量指標GPU指標
- 機器學習效能衡量指標機器學習指標
- 如何快速成長為技術大牛?阿里資深技術專家的總結亮了阿里
- 乾貨分享 | 阿里專家親授如何提升研發效能阿里
- DevOps|研發效能價值如何衡量dev
- 如何在團隊建設工程師文化?阿里資深技術專家這麼做工程師阿里
- 什麼是真正的敏捷開發?阿里資深技術專家內部分享公開敏捷阿里
- 8月8日雲棲精選夜讀|阿里資深技術專家林軒:雲時代軟體研發的終局猜想阿里
- 阿里資深專家面試問題收集阿里面試
- 衡量資料管理價值的指標如何定義指標
- 軟體研發效能的一些指標指標
- 【IO】IO系統效能之一:衡量效能的幾個指標指標
- 學霸——科學家——海龜學霸,阿里雲資深技術專家文鎮的進階人生阿里
- 觀點|阿里資深技術專家:優秀的資料庫儲存引擎應具備哪些能力?阿里資料庫儲存引擎
- 前沿分享|阿里雲資料庫資深技術專家 姚奕瑋:AnalyticDB MySQL離線上一體化技術揭祕阿里資料庫MySql
- 阿里資深技術專家總結:要怎樣努力才可以成為公司主力架構師阿里架構
- 【高併發】面試官:效能優化有哪些衡量指標?需要注意什麼?面試優化指標
- 阿里技術專家詳解 DDD 系列- Domain Primitive阿里AIMIT
- 衡量好男人的幾項指標指標
- 預算指標 技術指標 操作引數指標
- 阿里產品專家:高情商的技術人,如何做溝通?阿里
- 阿里高階技術專家:如何結構化地思考、做事、成長?阿里
- 阿里巴巴資深技術專家雷卷:值得開發者關注的 Java 8 後時代的語言特性阿里Java
- 阿里巴巴資深技術專家無相:我們能從 InteliJ IDEA 中學到什麼?阿里IntelIdea
- 阿里媽媽資深技術專家劉凱鵬解讀基於深度學習的智慧搜尋營銷阿里深度學習
- 【北京】【雲聯萬維】-招聘後端研發工程師/技術專家後端工程師
- 如何使用預測性指標衡量敏捷轉型的成功?指標敏捷
- 阿里巴巴研發效能資料知多少阿里
- 1269道Java技術答疑,阿里技術專家幫你Java技術進階Java阿里
- 中國5G關鍵技術已通過驗證7家公司參與技術研發
- [已結束] [專題講座] 反向思維,資深專家指導你如何將網站變慢網站
- 雲棲大會SaaS加速器專場 | 阿里雲資深技術專家黃省江:讓天下沒有難做的SaaS阿里
- 阿里雲技術專家解讀:2021 年六大容器技術發展趨勢阿里
- 【技術乾貨】聽阿里雲CDN安防技術專家金九講tengine+lua開發阿里
- 阿里雲高階技術專家空見: CDN的資料化之路阿里
- 電腦科學與技術專業教指委將成立“物聯網工程專業教學研究專家組”
- 企業衡量內容營銷是否有效的5個關鍵指標指標