簡介： 簡介： 作者：何勉，阿里巴巴研發效能部資深技術專家，因為身處研發效能部，我接觸了公司很多產品技術團隊，他們幾乎都把研發效能提升列為了本財年的重要目標，大部分還為此成立專項，如此我們又如何去提升它呢？ 阿里云云效效能洞察產品正在灰度測驗中，立即測驗體驗 作者：何勉，阿里云云效資深技術專家 因為身處研發效能部，我接觸了公司很多產品技術團隊，他們幾乎都把研發效能提升列為了本財年的重要目標，大部分還為此成立專項，然而，對于什么是好的研發效能，卻很少能被清晰定義，如此，我們又如何去提升它呢？ 針對這個問題，本文將明確定義研發效能，并提供度量它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小時內完成發布，
達成“2-1-1”的愿景并不容易，1小時的發布前置時間，需要持續交付流水線，產品架構體系和自動測驗、自動部署等能力的提升，1周的開發周期，涉及更多的能力和實踐，如：需求的拆分和管理，開發團隊的分工協作模式，以及持續集成和持續測驗實踐；最困難的則是2周的交付周期，首先它要以另外兩個指標為基礎，同時還涉及整個組織各職能和部門的協調一致和緊密協作；
“2-1-1”的目標都是關于流動效率的，你可能會問，那資源效率和質量呢？我們專注于流動效率，是因為它是組織效能改進的抓手，能夠觸發深層次的和系統性的改進，就像上面分析的，為達成“2-1-1”目標，團隊需要技術、管理、協作等方面的全面實踐升級，而這些實踐的落地，必然會帶來資源效率和質量的提升，并體現到相應的度量指標上，
當然，“2-1-1”是源自特定的團隊，并非所有團隊都要使用同樣的值，比如對于涉及硬體開發的團隊，兩周的交付周期通常過于挑戰，組織應根據自己的背景關系設定恰當的目標，重要的是，它要指明改進的方向，
總結
本文定義了研發效能，它指的是一個組織持續快速交付價值的能力，可以從流動效率、資源效率和質量三個方面來衡量，其中流動效率是改進研發效能的核心抓手，它帶來系統和全域的改進， 如上圖所示，研發效能最終為組織效能服務，必須體現到利潤、增長、客戶滿意度等組織效能上；同時，研發效能的提升要落實到具體技術和管理的實踐中，才可能發生， 定義和度量是提升研發效能的基礎，相信你更關心提升研發的具體實踐和方法，后續我將綜合多個團隊的實踐，介紹可操作的實踐體系和落地方法，轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/303445.html
標籤：其他