注：本文是對雲棲大會何勉分享內容的整理，稍有刪減，點選下方連結觀看完整視
雲效BizDevOps論壇：https://yunqi.aliyun.com/2021/agenda/session173

這幾年“研發效能”一直是熱詞，很多組織都會啟動研發效能提升專項。我與其中的很多有過深入的交流，他們中達成最終目標的並不多，經常是高調開始，草草收尾。為什麼什會這樣呢？

提升研發效能，首先要弄清楚要解決的問題是什麼，然後才是落地解決問題的實踐方法。否則問題沒定義清楚，就很難有好的結果。

那提升研發效能究竟要解決什麼問題？

我將提升效能要解決的問題，歸納為3個效能不等式。

三個不等式揭祕研發效能的本質

第一個不等式，區域性效率不等於高效交付？

這一點，大家應該會感同身受。當我們去問各個部門或者個人時，都覺得他們很忙，效率很高。但是，我們去問業務部門或使用者，卻是另外一回事，他們會抱怨產品研發響應慢、交付遲、質量也不好。

這就是組織內部視角的區域性效率並不等於使用者視角的高效交付。這個是提升研發效能要面對的首要問題。解決它需要更有效的組織協同、更合理的交付模式，和更好的過程質量。

接下來的問題是，高效交付就夠了嗎？這就引出了第二個效能不等式。

第二不等式，高效交付能不等於持續高效

有的時候，為了高效的交付，我們可以採取臨時動作，比如把一群人關在一起，成立一個臨時專案，這樣溝通協作會更便捷，這可能會達成一時的高效。但是，如果缺乏長期質量思維，當我們在做下一個專案，往往會發現問題，之前的程式碼和設計存在各種問題，比如可修改、可複用性很差，它們成為後續專案的負債而不是資產，長期的效率無法維持。

如何從高效交付轉變成持續的高效，這是研發效能要解決的第2個問題。它對我們的工程和技術能力和實踐都提出了要求。

第三個不等式，高效交付不等於業務成功

產品交付的目的是支援業務發展和業務創新。我們必須保證交付的東西，能解決使用者問題，並構建可持續的商業模式，否則交付再多也沒有意義。

今天，市場和使用者的不確定持續增加，破解這一問題不容易。它需要整個組織能夠聚焦使用者問題，快速交付和試錯，並形成有效反饋調整的閉環。做到這三點才能讓高效交付轉化為業務成功，這是提升研發效能要解決的第三個核心問題。

我們認為，研發效能提升的本質就是要解化解上面的三個不等式，從而把組織內的區域性效率轉化為使用者可感知的高效交付，並保障持續的高效和帶來業務的成功。最終實現：“持續地順暢高質量交付有效的價值”。這是效能提升的根本目標。

研發效能提升實踐體系

明確問題是開始，解決它們需要系統的實踐方法。接下來，我們分享這些實踐方法，它是我們對過去的實踐的提煉和總結，並概括為這個圖。

整個圖分為三個模組：

左側是協作和需求實踐。左上方我們稱之為業務驅動需求的協作模式和產品導向的互動模式，下邊是以終為始的需求分析和設計。左側這部分實踐解決的是區域性效率如何帶來高效的交付。

右側是工程與技術實踐。右上方我們稱為領域驅動的架構和實現，中間是標準化的工程基礎設施，下面是應用為中心的持續交付，這部分實踐解決的問題是如何讓我們高效交付帶來持續。

中間這部分是創新實踐。它包含：如何高效探索業務、如何持續快速地完成業務交付，並形成有效的反饋和調整的閉環。創新實踐要解決的問題就是高效交付如何帶來業務的成功。

接下來，我們一步步展開，看一下各部分的關鍵效能提升實踐。

協作和需求實踐

首先我們來看協作需求實踐。

在介紹協作之前，我們需要弄清楚協作的上下文——也就是當我們談協作時，我們在談什麼。

讓我們先從梳理需求交付的內在結構開始。

首先，產品交付都是源於目標，有可能是使用者目標，如：更高效的完成某項工作；也有可能是業務目標，如：實現業務的增長，提高使用者的黏性等。我們基於使用者目標和業務目標規劃業務需求。除了業務目標外，客戶的具體訴求也會轉化為業務需求。

業務需求的實現需要落地到產品中，它會被分解為一個個的產品需求。產品需求會進一步被分解為技術任務，通過實現技術任務來交付產品需求，最終實現對應的業務需求。

當然，產品需求並不一定都直接來自業務需求，產品也會做出自己的規劃，包括架構的升級和技術重構，或者面向未來的前瞻性技術佈局，如AI演算法、區塊鏈平臺等。這部分產品需求，雖然不來自當下的業務需求，但它同樣服務於業務目標，只不過是長期和未來的業務目標。

瞭解了產品交付的結構之後，接下來，我們看在這樣的結構下，如何實現團隊的高效協同。

業務驅動的協作模式

首先，我們協同的結構應該和前面的產品交付需求層次結構一致。業務需求、產品需求和技術任務由不同的職能的人來負責，例如業務人員負責建立業務需求，業務人員和產品經理一起把業務需求規劃分解為產品需求。

業務需求、產品需求、技術任務，這是交付需求過程中的基本價值單元。而文件、程式碼、測試、資料等都是為它們服務的，與應該向它們關聯，並沉澱為資產。

業務需要被收集、管理、規劃和交付，完成這些工作需要有獨立的空間,它對應研發協同工具中的“業務空間”。在業務空間中，還要能看到業務需求是如何拆分為產品需求的。我們稱之為管一層也要向下看一層，這樣才能保證業務需求交付。

業務需求交付是一個動態的過程，需要清晰的工作流，它定義了業務需求從提出、接收、規劃，直到釋出、驗收的整個過程。順暢高質量地交付就是要讓這個工作流更加順暢，減少過程中的阻礙和等待。

與業務需求一樣，產品需求也需要被收集、管理、規劃和交付，研發管理工具，同樣要為產品人員提供專屬的產品交付空間，並定義產品交付的工作流。技術開發者也需要對他們友好的工作臺。在這裡，他們接受、管理、計劃和完成技術工作。

更重要的是，我們需要讓這三個層次三者變成有機的整體，讓大家真正的協同起來，順暢的交付業務需求。這三個層次的工作流是相互關聯，業務需求規劃後被拆分為產品需求，產品需求會被進一步拆分為任務，這些是自上而下的。

再看自下而上的，下層的工作完成後，它的狀態要能夠被自動卷積上去，比如產品需求下所有的任務完成後，對應的產品需求進入待測試狀態。業務需求所有產品需求完成後，業務需求的狀態也需要自動變更。

這三個層次的聯動和透明，讓問題和阻礙更容易被識別，比如業務需求交付延期或者出現問題時，能清晰的看到是哪一個產品造成的，應該在哪裡採取動作。

我們把這稱為業務驅動的協作模式。組織中不同的職能和團隊，必須相互協同完成業務交付，達成使用者或者業務的目標，業務驅動的協作模式，讓這一過程更加透明和高效。

產品導向的交付模式

前面講的是協作模式，企業的業務需求最終還是要到落實到產品交付團隊中交付的。以前我們更多把IT交付團隊看成成本中心，先確定需求範圍，再確定時間，然後分配資源、成立專案、完成交付這也被稱為專案導向的交付模式。

專案導向的交付本質是把人作為資源分配到事情上。其背後的假設是未來是確定的，在確定的時間內交付確定的內容。它強調計劃和執行，追求交付的確定性。

確定性今天已經越來越不現實，組織必須學會與變化共舞。另外，專案導向的交付導致短期思維，缺乏工程、技術長期改進意識。同時，因為團隊的臨時性，也無法持續團隊的交付效能。

數字化時代，我們需要從專案導向的交付模式向產品導向的交付模式遷移。產品導向的交付模式本質是把事情交給跨功能的特性團隊，由相對穩定的特性團隊持續的接受並完成需求的交付。

特性團隊對產品的迭代負責，他們擁抱業務的不確定性，併為此不斷演進產品。特性團隊要維護產品，必須建立長期思維，注重程式碼資產和工程資產，並持續改進團隊交付能力和交付流程，提升交付效能。

但這還不夠，因為如果各個產品各自為政，任何特性團隊的需求過載都會讓它成為整個業務瓶頸，解決辦法是，同一業務領域的多個特性團隊，共享同一需求列表。這就讓一個團隊出現資源瓶頸時，需求可以分配到另一個團隊，這與今天很多服務行業中實行的，“一個佇列多個服務窗”的本質是一致的。

以終為始的需求分析和設計

前面，我們講了，企業的協同模式應該是業務驅動的，團隊的交付模式應該是產品導向的，它們解決協同流程的問題，但光有流程是不夠的，我們還必須保證輸入的質量。

IT行業有一句著名的話：“輸入的是垃圾，輸出的也會是垃圾“ 。需求的輸入，是交付過程是源頭，也是最關鍵的部分。如果輸入的有問題，交付的中間過程也不可能順暢。那我們應該怎麼做呢？

“輸入垃圾，輸出垃圾”的反面是以終為始，——也就是在需求輸入的時候，團隊要知道最終要做成什麼樣子，並在業務、產品和技術之間達成一致。

那麼，怎樣才叫以終為始呢？以終為始分為3個方面：

第一，對於業務需求，要有明確的業務目標，並基於目標定義清晰的業務流程，確保業務流程可以支援業務目標的實現，這是業務分析要完成的工作。

第二，對於產品需求，它要能支援業務流程的實現，為此我們要基於業務流程，明確定義產品的功能，對於每一個產品功能，首先要明確使用者使用的互動流程，並在互動流程的基礎上，明確驗收標準。

第三，明確業務需求、產品需求之間的結構，也就是業務需求和產品需求之間的層級關係。這對後面的團隊協作都很重要，我們協作交付的目標不是產品需求而是業務需求，只有結構清晰，協作的時才知道這些產品需求如何協同向業務對齊，完成快速交付業務需求。

總結一下，業務分析和產品設計分是一個金字塔的結構：

需求永遠源自業務目標，基於業務目標分析業務流程，基於業務流程分解產品需求，並對產品需求進行設計。

金字塔的上面兩層：是業務分析關注的。我們引入了“事件驅動的分析”方法，——基於目標和業務事件分析業務流程，並基於業務流程拆分定義產品需求，並劃分最小可行產品（MVP）。

金字塔的下面兩層：是產品設計所關注的。在業務流程設計的基礎上，分解出產品需求，並對產品需求進行澄清。澄清和設計需求最好的方式是以使用者使用例項來說明操作流程、驗收規則是什麼樣，也就是使用者在什麼情況下，做什麼操作，將得到什麼結果。我們引入了“例項化需求”分析方法來支援這一過程。

通過系統的業務分析和產品設計方法，在需求上從GIGO轉變為以終為始，這是區域性效率轉化為高效交付的重要一環。

下面，讓我們在從另一維度，解釋一下協作和需求實踐，以上圖的產品截圖為例，總結一下，我們在協作部分要做到的三點：

第一點，我們要看到並且要管理端到端的業務需求的交付過程，我們稱之為前後職能拉通。這些職能可能是業務、產品、開發、測試，部署和運維。我們要拉通這些職能，讓他們更高效的配合，讓業務需求從左到右順暢的流動和交付。

第二點，左右模組對齊。一個業務需求可能會分解到不同的產品裡面，每個產品都有自己的工作流，產品的交付要向業務的交付對齊。

我們的目標不是讓某一個產品忙起來，而是讓業務需求的交付更順暢。所以各個產品都要向業務需求的交付對齊。研發管理工具上也要能實現這一點，包括，規劃上對齊產品和業務需求，以及在執行過程中對齊產品和業務，並即時發現因無法對齊帶來的阻礙和等待。

第三點，內建過程質量。需求在每個階段應該有明確的質量標準並執行到位，例如需求輸入的質量要做到以終為始，需求測試的質量、測試轉發布等都應該有明確的標準。質量應該建立在每個需求的每個階段之上，而不是成批的依賴於最後的檢測階段。

我們要做到前後職能拉通，左右模組對齊，內建過程質量。最終形成這樣下圖所示的協作模式。

圖中每個節點都是一個具體活動，這些活動有它的節奏、負責人、輸入輸出，以及實踐方法的支援，如前面提到的事件驅動的業務分析和例項化需求等，這樣才能讓業務、產品、技術真正形成一個整體，做到這樣順暢和高質量的交付業務需求。

技術和工程實踐

技術和工程部分，我們究竟要解決什麼問題呢？我們先看一幅圖。

上圖橫軸是時間，縱軸是生產效率。我們希望效率是沿著綠色線一路向上的，但是現實中可能隨著時間的推移、產品變得複雜、團隊規模變大，而效率反而降低。

區分這兩條線的核心就是在工程和技術實踐上，它決定我們積累的到底是資產還是債務，也最終決定了長期的效率。

領域驅動的架構和實現

在技術方面，我們要持續積累並維護好領域資產，讓它易於理解、擴充套件、維護和複用，今天業界普遍都認識到領域驅動設計的重要性，也願意投入精力。然而，領域驅動設計要發揮作用並不容易。

領域驅動設計不僅僅是設計的問題，它是涉及需求、架構和實現的系統工程。需求和業務是源頭，架構是樞紐，而他們都需要落地到現實當中。最重要的是如何把需求、架構和實踐真正連線起來，連線他們的是領域模型。

如上圖所示，我們從業務需求開始去分析業務流程，基於業務流程分解和設計產品需求，通過例項化需求定義驗收測試，澄清和細化產品需求。更重要的是，在整個的需求分析的階段中，我們要不斷地提取和精化領域模型。因為對領域的認識和抽象來自於每個具體的業務、具體的需求，所以被稱為“業務引領的領域建模”。

領域模型應該成為應用架構設計的基礎。我們基於領域模型去劃分子域，設定子域的上下文，基於領域模型去定義介面的設計契約，劃分子域和限界上下文，並約束微服務的邊界，讓微服務成為可複用的領域資產。限界上下文和服務契約最終保障領域資產的可複用。所以我們稱為“領域引領的微服務架構”。

在實現上，領域模型、驗收測試、服務設計契約都是高質量程式碼的約束和指導。我們的程式碼要體現領域模型，與架構和介面契約一致，並符合相關驗收標準。

同時，測試先行的方式，讓我們有更靠譜的自動化測試，而自動化測試會讓我們的重構更有保障。持續的重構又保證程式碼資產不會快速腐化，維持系統健康。

今天分享的更多還停留在概念層面，但是我希望能在思考規劃上給大家帶來啟發。除非你認為你可以犧牲長期的質量，你不需要積累一個長期可重複的資產，那麼上述這些都是不可或缺的。

標準化的工程基礎設施

接下來我們看工程部分。今天比較幸運的是，我們看到工程部分的技術趨勢正在收斂。

我們看到基於容器管理和分發製品，基於k8s編排環境資源,這一部分已成為了一個事實，大家都不再考慮要不要做，而是什麼時間做，或者怎麼做的問題。這個方向大概率不會改變。但問題是，我們講容器，更多還是站在資源的視角去看，即站在運維的視角，但是在開發視角，看到的是程式碼，程式碼對應的是應用。如果僅做到這一點，開發和運維之間還是有隔閡，他們所面對的物件就不同。

今天我們看到另外一個趨勢，是基於OAM的標準去做應用管理。OAM的標準是阿里和微軟共同提出的叫做開放應用模型，基於OAM可以管理應用的開發、編排和運維。OAM是一個標準，基於這個標準，開發可以宣告式地編排應用，運維也可以基於已有的宣告進行自動化的運維。

OAM 面向應用的部署和運維的終態，統一了應用開發和運維的基本模型。它首先提出了應用描述的基本模型，包括應用的拓撲、資源依賴、部署方式、運維方式等，然後定義宣告式的應用編排、部署和運維方式。OAM基於應用，統一了開發和運維的基本語言，讓應用成為開發和運維共同的關注和操作的基本物件，解決了技術基礎實施的問題，讓真正的DevOps 成為可能。

但是這個離真正的DevOps還差一點，我們剛才講的只是我們有了DevOps的基礎，我們從部署這個階段基於這樣的標準，但是我們還沒有定義我們的應用是怎麼交付的。如果把應用和交付這一部分也包含進去，就會實現真正的DevOps。

我們看這樣一幅圖，如下圖所示，我們這樣定義應用的變更流程

首先，我們要解耦部署和釋出，部署是技術行為，釋出是業務行為。我們希望每一個應用可以單獨部署，所以我們要解耦部署釋出，以應用為單元，持續的整合和部署。

但是這還不夠，應用的變更從哪裡來？應用來自於業務需求，業務需求拆解為產品需求，產品需求對應一系列應用的變更。

每個應用的變更都有自己的流程。當這個業務需求對應所有的應用變更部署完成之後，這個業務需求也應該能夠完成釋出。

我們的工具、流程、操作要能夠連線起這些應用的變更和產品需求，直至業務需求。這樣我們就能夠做到以業務需求為單位釋出——當一個業務需求下所有的變更都部署完成後，業務需求可以隨時釋出。

我們認為持續交付的最佳形態是以單應用為單位變更部署，以單需求為單位，需要的時候就去釋出，在此基礎上，我們就有機會建立起最快速的業務閉環。

以上是我們看到雲原生持續交付的形態，也就是以應用為單位的持續部署，業務為需求單元的持續釋出，前提是，我們以應用統一了開發和運維的基本單元。

總結一下，我們認為雲原生下的BizDevOps的形態是什麼？有三點：

• 面向終態，基於開放應用模型OAM，形成運維和開發底層模型的一致化和標準化。
  
  
• 以應用為核心，連通應用的開發、整合過程和部署運維過程，實現雲原生時代的DevOps。
  
  
• 連線並對齊業務需求與應用變更，並完善反饋閉環，實現真正意義上的BizDevOps 。
  

總結

效能提升，必須從清晰定義問題開始。

我將提升研發效能要解決的根本問題總結為三個效能不等式。化解這三個效能不等式，需要系統的實踐。

第一，讓區域性效率轉化為高效的交付。為此，我們需要落地業務驅動的協作模式和產品導向的交付，同時在需求上要做到真正的以終為始。

第二，讓高效交付可以持續，為此，在技術上要做到領域驅動的架構和實現，不斷積累和優化領域技術資產。在工程上，要建設雲原生的標準化基礎設施，並以應用中心打通開發運維和連線業務的需求，最終實現以應用中心的持續部署和以業務需求為中心的持續釋出。

第三，讓高效交付帶來業務成功。為此，需要建立業務探索和持續交付之間的快速執行和反饋的閉環。

以上3點的共性是，它們都以業務為起點。比如：以業務需求驅動組織中各個環節和部門的高效協同；從業務目標開始，分析業務流程，並分解設計產品；連線業務需求和產品應用變更，實現業務需求的持續釋出；建立業務探索和持續交付之間的快速閉環。

落地這些實踐，必須打通業務（ Biz）、開發（Dev）和運維（Ops），讓他們成為一個高效運作的整體，建設BizDevOps實踐體系，賦能數字化時代的組織，加速業務發展和創新。

以上是我的分享，謝謝大家。

​關於我們

瞭解更多關於雲效DevOps的最新動態，可微信搜尋關注【雲效】公眾號；

彩蛋：公眾號後臺回覆【指南】，可獲得《阿里巴巴DevOps實踐指南》&《10倍研發效能提升案例集》；

看完覺得對您有所幫助別忘記點贊、收藏和關注呦；