新的一年，相信很多產(chǎn)品技術(shù)團隊把研發(fā)效能提升列為重要的目標，甚至還有團隊為此專門成立了項目組。然而，到底什么是好的研發(fā)效能，卻很少有人能夠表達清楚。標準不清晰，又何談提升？

阿里研發(fā)效能部資深技術(shù)專家何勉老師，將與大家分享他多年的思考與觀點，希望對你有所啟發(fā)。

本文將明確定義研發(fā)效能，并提供度量的五大指標，為研發(fā)效能的提升指明目標，并衡量提升的效果。本文也是關(guān)于研發(fā)效能提升及產(chǎn)品交付方法系列文章的開篇，為之后介紹的產(chǎn)品交付方法是否有效設(shè)立了標準。

效率豎井是研發(fā)效能改進的一大問題

產(chǎn)品交付需要前后職能（如：產(chǎn)品、開發(fā)、測試等）和平行部門（如：前端、后端、算法等）的協(xié)作。傳統(tǒng)方法更多關(guān)注各個職能和部門的獨立改進。然而，過度局部優(yōu)化，往往導(dǎo)致效率豎井，反而損害整體效率。

什么是效率豎井呢？上圖描述了傳統(tǒng)開發(fā)方式下，產(chǎn)品交付面臨的普遍困境——各職能和部門局部優(yōu)化帶來一系列問題，如：

基于局部信息的工作優(yōu)先級安排，造成不同部門和職能間相互等待，讓需求無法順暢流動。比如前、中、后臺對工作的優(yōu)先處理不一致，進度無法對齊，讓已經(jīng)開始的需求不能及時交付。

批量式的工作移交，帶來進一步等待。為了優(yōu)化單個環(huán)節(jié)的效率，各職能往往傾向于批量接受和移交工作，如批量的集成，批量的轉(zhuǎn)測等。進一步造成需求在過程中的積壓和等待。

跨部門的問題，經(jīng)常得不到及時和有效的處理。公共環(huán)境的維護，就是一個典型的問題，是影響用戶需求的順暢交付。過程中需求跨部門的有效澄清、接口對齊、問題排查是另一些常見的公共問題，它們都會造成需求無法順暢進展。

以上只是一部分問題，它們共同作用，結(jié)果是：站在各自的視角，每個部門都覺得自己繁忙且“高效”；然而，站在全局和業(yè)務(wù)的視角，系統(tǒng)對外的反應(yīng)卻非常遲緩。這就是所謂效率豎井。

效率豎井：由局部優(yōu)化導(dǎo)致，表現(xiàn)為：各個環(huán)節(jié)和部門繁忙而“高效”，但總體的效率和響應(yīng)速度卻很低。它是研發(fā)效能提升的普遍癥結(jié)所在。

上圖的折線反映了效率豎井下，單個需求的交付過程。綠色線表示需求正在被處理，紅色線則表示需求在等待中。工作量不大的需求，交付周期卻很長。因為大部分時間需求都處于等待狀態(tài)。各個局部一片繁忙，外部卻抱怨連連，相信很多人會感同身受。

“持續(xù)快速交付價值的能力”是效能改進的核心目標

要改進研發(fā)效能，我們必須走出效率豎井。為此組織必須把改進的焦點從關(guān)注各個資源環(huán)節(jié)，轉(zhuǎn)向關(guān)注整個系統(tǒng)。

上圖反映了效能改進的關(guān)鍵——從以局部資源效率為核心，轉(zhuǎn)變?yōu)閮r值流動效率為核心的改進。

資源效率指的是，各環(huán)節(jié)的資源利用率和產(chǎn)出情況，如：資源的忙閑程度、使用率、代碼產(chǎn)出和測試執(zhí)行速度等。流動效率指的是，用戶價值在系統(tǒng)中的流動速度，如：用戶需求從提出到交付的時長，它越短越好；或者是過程中等待時間的占比，它越小越好。

用戶價值的流動是串起整個系統(tǒng)，促進整體優(yōu)化的不二選擇。為了提高價值的流動效率，組織就必須關(guān)注用戶價值在系統(tǒng)中端到端的流動過程，改進整個系統(tǒng)，而不僅僅是局部環(huán)節(jié)。以此為基礎(chǔ)，效能改進的目標是：持續(xù)快速交付價值的能力。這也是對研發(fā)效能的基本定義。

持續(xù)快速交付價值的能力，是研發(fā)效能的核心定義。為此我們必須把改進的焦點從局部資源效率，轉(zhuǎn)向價值流動效率，以保證全局和系統(tǒng)的優(yōu)化。

研發(fā)效能的度量——五組指標回答研發(fā)效能的根本問題

以上定性的定義了研發(fā)效能。管理學(xué)之父德魯克說：“如果你不能度量它，就無法改進它”。度量幫助我們更深刻認識研發(fā)效能，設(shè)定改進方向，并衡量改進效果。

產(chǎn)品開發(fā)過程中會產(chǎn)生大量的數(shù)據(jù)，但數(shù)據(jù)不是度量。好的度量的標準是：它要為回答一個根本的問題講述完整的故事。效能度量要回答的根本問題就是：一個組織“持續(xù)快速交付價值的能力”怎么樣？

為回答這個問題，應(yīng)該提供怎樣的一個完整故事呢？基于在天貓新零售、閑魚、優(yōu)酷、阿里健康、研發(fā)中臺、阿里云等部門持續(xù)實踐和探索，我們發(fā)展并驗證了系統(tǒng)的研發(fā)效能指標體系。如上圖所示，它由5組指標構(gòu)成，分別是：

第一：持續(xù)發(fā)布能力。具體包含兩個細分指標，分別是：

發(fā)布頻率。 團隊對外響應(yīng)的速度不會大于其交付頻率，發(fā)布頻率約束團隊對外響應(yīng)和價值的流動速度。它的衡量標準是單位時間內(nèi)的有效發(fā)布次數(shù)。

發(fā)布前置時間（也被稱為變更前置時間），也就是從代碼提交到功能上線花費的時間，它體現(xiàn)了團隊發(fā)布的基本能力。如果時間開銷很大，就不合適加大發(fā)版頻率。

第二：需求響應(yīng)周期。具體包含兩個細分的指標，分別是：

交付周期時間。指的是從確認用戶提出的需求開始，到需求上線所經(jīng)歷的平均時長。它反映團隊（包含業(yè)務(wù)、開發(fā)、運營等職能）對客戶問題或業(yè)務(wù)機會的響應(yīng)速度；

開發(fā)周期時間。指的是從開發(fā)團隊理解需求開始，到需求可以上線所經(jīng)歷的平均時長。它反映技術(shù)團隊的響應(yīng)能力。

區(qū)分交付周期和開發(fā)周期，是為了解耦并明確問題，以做出針對性的改進。其中，交付周期是最終的目標和檢驗標準。

第三：交付吞吐率。指的是單位時間內(nèi)交付需求的數(shù)量。關(guān)于這一點，常見的問題是，個數(shù)能準確反映交付效率嗎？這是個問題。所以，我們更多強調(diào)單個團隊的需求吞吐率的前后對比，統(tǒng)計意義上它足以反映趨勢和問題。

第四：交付過程質(zhì)量。它包含兩個細分的指標，分別是：

開發(fā)過程中缺陷的創(chuàng)建和修復(fù)時間分布。我們希望缺陷能夠持續(xù)和及時地被發(fā)現(xiàn)，并且在發(fā)現(xiàn)后盡快修復(fù)；

缺陷庫存。我們希望在整個開發(fā)過程中控制缺陷庫存量，讓產(chǎn)品始終處于接近可發(fā)布狀態(tài)，奠定持續(xù)交付的基礎(chǔ)。

交付過程質(zhì)量的核心是內(nèi)建質(zhì)量，也就是全過程和全時段的質(zhì)量。而非依賴特定的階段，如測試階段；或特定的時段，如項目后期。內(nèi)建質(zhì)量是持續(xù)交付的基礎(chǔ)，關(guān)于其具體度量方法，下文會給出詳細實例。

第五：對外交付質(zhì)量。 它包含兩個細分的指標，分別是：1)單位時間的故障（線上問題）數(shù)；2）故障平均解決時長。這兩者共同決定了系統(tǒng)的可用性。

如上圖所示，這5組指標，從流動效率、資源效率和質(zhì)量三個方面講述了一個完整的故事，回答了組織持續(xù)交付價值的能力如何這個核心問題。其中，持續(xù)發(fā)布能力和需求響應(yīng)周期這兩組指標反映價值的流動效率；吞吐率反映資源效率；交付過程質(zhì)量和對外交付質(zhì)量這兩組指標共同反映質(zhì)量水平。

一個度量指標實例：缺陷趨勢圖

針對這些指標，云效提供了豐富的度量圖表，后續(xù)云效產(chǎn)品團隊還會進行場景化的梳理，提高其可用性。我會及時跟進，用專門的文章介紹云效的完整度量方案。在這里我先介紹一個例子——關(guān)于過程質(zhì)量的度量圖表。

“缺陷趨勢圖”是云效新設(shè)計的度量圖表，它反映交付過程中缺陷發(fā)現(xiàn)和移除的時間分布，以及缺陷的庫存趨勢。

如上圖所示，圖形的橫坐標是日期，橫坐標上方紅色豎條代表這一天發(fā)現(xiàn)缺陷數(shù)量；橫坐標下方綠色豎條代表當天解決的缺陷數(shù)量；橙色曲線代表缺陷存量。圖中左右兩個部分比較了兩種交付模式。

左半部分，團隊屬于小瀑布的開發(fā)模式。“迭代”前期，團隊集中設(shè)計、編碼，引入缺陷，但并未即時地集成和驗證。缺陷一直掩藏在系統(tǒng)中，直到項目后期，團隊才開始集成和測試，缺陷集中爆發(fā)。

小瀑布模式下，過程質(zhì)量差，帶來大量的返工、延期和交付質(zhì)量問題。該模式下，產(chǎn)品的交付時間依賴于何時缺陷能被充分移除，當然不能做到持續(xù)交付，也無法快速響應(yīng)外部的需求和變化。并且，這一模式通常都導(dǎo)致后期的趕工，埋下交付質(zhì)量隱患。

右半部分，團隊開始向持續(xù)交付模式演進。在整個迭代過程中，團隊以小粒度的需求為單位開發(fā)，持續(xù)地集成和測試它們，即時發(fā)現(xiàn)和解決問題。缺陷庫存得到控制，系統(tǒng)始終處于接近可發(fā)布狀態(tài)。這一模式更接近持續(xù)發(fā)布狀態(tài)，團隊對外的響應(yīng)能力隨之增強。

缺陷趨勢圖從一個側(cè)面反映了團隊的開發(fā)和交付模式。它引導(dǎo)團隊持續(xù)且盡早發(fā)現(xiàn)缺陷并及時移除它們。控制缺陷庫存，讓系統(tǒng)始終處于接近可發(fā)布狀態(tài)，保障了持續(xù)交付能力和對外響應(yīng)能力。

缺陷趨勢圖是云效研發(fā)效能度量圖表中的一個。后面，我會用專門的文章系統(tǒng)地解讀這些圖表的使用。

效能改進的目標設(shè)定：部分團隊的2-1-1愿景

以上，我們介紹了研發(fā)效能度量。基于這樣的度量體系，應(yīng)該設(shè)定怎樣的目標呢？我們在多個團隊的實施過程中，逐漸沉淀出了可供參考的目標體系，它可以總結(jié)為三個數(shù)字——“2-1-1”。

“2-1-1”最初來自天貓新零售，其后在閑魚和研發(fā)中臺、阿里云等團隊完善和采用。什么是“2-1-1”呢？

“2"指的2周的交付周期，85%以上的需求可以在2周內(nèi)交付；

第一個“1”指的是1周的開發(fā)周期，85%以上的需求可以在1周內(nèi)開發(fā)完成；

第二個“1”指的是1小時的發(fā)布前置時間 - -提交代碼后可以在1小時內(nèi)完成發(fā)布。[1]

達成“2-1-1”的愿景并不容易。1小時的發(fā)布前置時間，需要持續(xù)交付流水線，產(chǎn)品架構(gòu)體系和自動測試、自動部署等能力的提升。1周的開發(fā)周期，涉及更多的能力和實踐，如：需求的拆分和管理，開發(fā)團隊的分工協(xié)作模式，以及持續(xù)集成和持續(xù)測試實踐；最困難的則是2周的交付周期，首先它要以另外兩個指標為基礎(chǔ)，同時還涉及整個組織各職能和部門的協(xié)調(diào)一致和緊密協(xié)作；

“2-1-1”的目標都是關(guān)于流動效率的，你可能會問，那資源效率和質(zhì)量呢？我們專注于流動效率，是因為它是組織效能改進的抓手，能夠觸發(fā)深層次的和系統(tǒng)性的改進。就像上面分析的，為達成“2-1-1”目標，團隊需要技術(shù)、管理、協(xié)作等方面的全面實踐升級，而這些實踐的落地，必然會帶來資源效率和質(zhì)量的提升，并體現(xiàn)到相應(yīng)的度量指標上。

當然，“2-1-1”是源自特定的團隊，并非所有團隊都要使用同樣的值，比如對于涉及硬件開發(fā)的團隊，兩周的交付周期通常過于挑戰(zhàn)。組織應(yīng)根據(jù)自己的上下文設(shè)定恰當?shù)哪繕?，重要的是，它要指明改進的方向。

總結(jié)

本文定義了研發(fā)效能，它指的是一個組織持續(xù)快速交付價值的能力，可以從流動效率、資源效率和質(zhì)量三個方面來衡量。其中流動效率是改進研發(fā)效能的核心抓手，它帶來系統(tǒng)和全局的改進。

如上圖所示，研發(fā)效能最終為組織效能服務(wù)，必須體現(xiàn)到利潤、增長、客戶滿意度等組織效能上；同時，研發(fā)效能的提升要落實到具體技術(shù)和管理的實踐中，才可能發(fā)生。

定義和度量是提升研發(fā)效能的基礎(chǔ)，相信你更關(guān)心提升研發(fā)的具體實踐和方法。