導讀：新的一年，相信很多産品技術團隊把研發效能提升列為重要的目标，甚至還有團隊為此專門成立了項目組。然而，到底什麼是好的研發效能，卻很少有人能夠表達清楚。标準不清晰，又何談提升？
今天，阿裡研發效能部資深技術專家何勉老師，将與大家分享他多年的思考與觀點，希望對你有所啟發。
本文将明确定義研發效能，并提供度量的五大名額，為研發效能的提升指明目标，并衡量提升的效果。本文也是關于研發效能提升及産品傳遞方法系列文章的開篇，為之後介紹的産品傳遞方法是否有效設立了标準。
效率豎井是研發效能改進的最大問題
産品傳遞需要前後職能（如：産品、開發、測試等）和平行部門（如：前端、後端、算法等）的協作。傳統方法更多關注各個職能和部門的獨立改進。然而，過度局部優化，往往導緻效率豎井，反而損害整體效率。
什麼是效率豎井呢？上圖描述了傳統開發方式下，産品傳遞面臨的普遍困境——各職能和部門局部優化帶來一系列問題，如：
基于局部資訊的工作優先級安排，造成不同部門和職能間互相等待，讓需求無法順暢流動。比如前、中、背景對工作的優先處理不一緻，進度無法對齊，讓已經開始的需求不能及時傳遞。
批量式的工作移交，帶來進一步等待。為了最大化單個環節的效率，各職能往往傾向于批量接受和移交工作，如批量的內建，批量的轉測等。進一步造成需求在過程中的積壓和等待。
跨部門的問題，經常得不到及時和有效的處理。公共環境的維護，就是一個典型的問題，是影響使用者需求的順暢傳遞。過程中需求跨部門的有效澄清、接口對齊、問題排查是另一些常見的公共問題，它們都會造成需求無法順暢進展。
以上隻是一部分問題，它們共同作用，結果是：站在各自的視角，每個部門都覺得自己繁忙且“高效”；然而，站在全局和業務的視角，系統對外的反應卻非常遲緩。這就是所謂效率豎井。
效率豎井：由局部優化導緻，表現為：各個環節和部門繁忙而“高效”，但總體的效率和響應速度卻很低。它是研發效能提升的普遍症結所在。
上圖的折線反映了效率豎井下，單個需求的傳遞過程。綠色線表示需求正在被處理，紅色線則表示需求在等待中。工作量不大的需求，傳遞周期卻很長。因為大部分時間需求都處于等待狀态。各個局部一片繁忙，外部卻抱怨連連，相信很多人會感同身受。
“持續快速傳遞價值的能力”是效能改進的核心目标
要改進研發效能，我們必須走出效率豎井。為此組織必須把改進的焦點從關注各個資源環節，轉向關注整個系統。
上圖反映了效能改進的關鍵——從以局部資源效率為核心，轉變為價值流動效率為核心的改進。
資源效率指的是，各環節的資源使用率和産出情況，如：資源的忙閑程度、使用率、代碼産出和測試執行速度等。流動效率指的是，使用者價值在系統中的流動速度，如：使用者需求從提出到傳遞的時長，它越短越好；或者是過程中等待時間的占比，它越小越好。
使用者價值的流動是串起整個系統，促進整體優化的不二選擇。為了提高價值的流動效率，組織就必須關注使用者價值在系統中端到端的流動過程，改進整個系統，而不僅僅是局部環節。以此為基礎，效能改進的目标是：持續快速傳遞價值的能力。這也是對研發效能的基本定義。
持續快速傳遞價值的能力，是研發效能的核心定義。為此我們必須把改進的焦點從局部資源效率，轉向價值流動效率，以保證全局和系統的優化。
研發效能的度量——五組名額回答研發效能的根本問題
以上定性的定義了研發效能。管理學之父德魯克說：“如果你不能度量它，就無法改進它”。度量幫助我們更深刻認識研發效能，設定改進方向，并衡量改進效果。
産品開發過程中會産生大量的資料，但資料不是度量。好的度量的标準是：它要為回答一個根本的問題講述完整的故事。效能度量要回答的根本問題就是：一個組織“持續快速傳遞價值的能力”怎麼樣？
為回答這個問題，應該提供怎樣的一個完整故事呢？基于在天貓新零售、閑魚、優酷、阿裡健康、研發中台、阿裡雲等部門持續實踐和探索，我們發展并驗證了系統的研發效能名額體系。如上圖所示，它由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”是源自特定的團隊，并非所有團隊都要使用同樣的值，比如對于涉及硬體開發的團隊，兩周的傳遞周期通常過于挑戰。組織應根據自己的上下文設定恰當的目标，重要的是，它要指明改進的方向。
總結
本文定義了研發效能，它指的是一個組織持續快速傳遞價值的能力，可以從流動效率、資源效率和品質三個方面來衡量。其中流動效率是改進研發效能的核心抓手，它帶來系統和全局的改進。
如上圖所示，研發效能最終為組織效能服務，必須展現到利潤、增長、客戶滿意度等組織效能上；同時，研發效能的提升要落實到具體技術和管理的實踐中，才可能發生。
定義和度量是提升研發效能的基礎，相信你更關心提升研發的具體實踐和方法。
3月16日-17日，何勉老師将和阿裡研發效能其他講師一起，在上海為我們分享《企業數字化轉型面臨的研發效能挑戰—阿裡DevOps體系和實踐》課程，有關于阿裡DevOps體系知識都可以從他們那裡得到答案。 報名位址： https://jinshuju.net/f/yPY1u1?from=singlemessage&isappinstalled=0 亮點&收獲 亮點：- 阿裡DevOps體系化方法和實踐，集阿裡巴巴多年先進的管理理念和工程實踐。
- 高比對度的客戶案例，分享案例來自阿裡内部産品線和行業标杆客戶案。
- DevOps沙盤實戰，利用工具實戰一站式研發生命周期管理服務，體驗阿裡巴巴傳遞方式。
收獲：本課程從一個完備的精益和靈活産品創新和傳遞方法體系，幫助學員掌握和系統應用，提升組織“順暢、高品質傳遞有用價值的能力”，助力企業數字化轉型和業務成功。
日程&嘉賓3月16日AM
靈活産品創新和傳遞方法體系
何勉 阿裡巴巴集團研發效能事業部資深解決方案架構師
3月16日PM
阿裡雲效的靈活方法項目實戰
苗媛媛 阿裡巴巴研發效能事業部解決方案工程師
3月17日AM
數字化時代，企業研發效能提升的挑戰與展望
章屹 阿裡巴巴研發效能事業部資深解決方案架構師
3月17日PM
阿裡研發效能提升實踐之路
面向人群&教育訓練環境
面向人群：
- 網際網路行業：研發中心CTO、技術經理 、架構師
- 數字化轉型類的企業：研發中心CTO、技術經理 、架構師
- 中台業務建設的企業：研發中心CTO、技術經理 、架構師
教育訓練環境：
| 機器要求 | 計算機 | 1台 | 1人 |
| 軟體要求 | Windows7以上系統，Chrome浏覽器 | ||
| 硬體要求 | RAM：4G以上 CPU：主流即可 | ||
| 教學環境 | 區域網路、按島嶼方式5人一桌、投影儀、翻頁筆、白闆、白闆紙、馬克筆、報事貼、美紋紙、水筆、籌碼遊戲需要的籌碼，計時器 |
注:
【1】最早雲零售部門（天貓新零售的前身）提出的目标是2-1-3，前面的“2”和“1”的含義相同，不同的是最後一個“3”指30分鐘——30分總完成釋出前的回歸測試，但不包含釋出過程。天貓新零售的2-1-3是這一願景的最初版本，後來阿裡其他團隊（最早是閑魚）将30分鐘改為了1小時，并包含了釋出在内，這就是“2-1-1”目标的由來。
更多内幕知曉可報名參加線下教育訓練
：