注：本文是對雲栖大會何勉分享内容的整理，稍有删減，點選文末下方連結觀看完整視
雲效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實踐體系，賦能數字化時代的組織，加速業務發展和創新。
以上是我的分享，謝謝大家。