簡介： ALPD及雲效DevOps平台在超大規模中台型團隊如何進行研發效能提升
中台型團隊效能提升遇到的挑戰及應對策略
“數字供應鏈中台”支撐了阿里巴巴旗經濟體30余個“大業務”，100余個“二級業務”；該中台團隊由1000多人組成，分為26個域；來自不同行業的需求會被不同的行業PD（產品經理）拆解為不同的子需求，協同不同行業或中台團隊一起才能完成交付，生產關系錯綜復雜。如何在這種業務優先級高、團隊規模大、協作關系復雜的團隊里提效，是我們遇到最大的挑戰。
在這樣大規模大中台團隊里提效，首先要面對的一個“靈魂拷問”是：中台團隊是先做好平台沉淀，還是先支撐好業務發展？阿里巴巴有一句土話叫做：既要、又要、還要。所以我們對這個問題的回答也是：既要沉淀中台服務化能力，又要快速響應業務。 中台的服務化能力是一個基礎，只有基礎打牢，才能更快地響應業務。基於這個思考，核心TL一起共創，並確定願景：打造世界最先進的軟件交付供應鏈，賦能經濟體業務發展和高效創新。為此，制定了兩個目標： 一、加速各行業需求的交付速度：需要做到將業務需求平均交付周期縮短到21天；其中7天內完成需求分析，14天內完成需求交付。 二、持續提高中台的服務化能力：拆解到各產品域的需求支持策略滿足“3、6、1”，即30%的需求通過配置化支持，60%的需求通過擴展點開發支持，10%的需求才需要中台定制化開發。
基於“7+14”和“3、6、1”兩個目標，我們制定了“目標牽引、組織升級”的策略。首先，對組織架構進行升級。新組建了實施團隊和行業特種兵團隊。對於一些可以由套件直接支持的需求，由“實施團隊”進行快速實施落地；可以基於中台服務化能力擴展開發的，則由“行業特種兵”牽頭交付；而“中台團隊”則更專注於沉淀中台的服務化能力。
行業特種兵團隊的“7+14”最佳實踐
基於當前的現狀，提效目標設定的非常有挑戰。為了證明這個目標是可達成的，我們選擇在新組建的行業特種兵團隊，來打造一個最佳實踐。
在改進前，特種兵團隊的研發流程跟大家通常接觸到的比較類似，交付的周期也比較長。業務方提出需求，並在MRD通過審核之后（即業務價值得到認可），行業PD會將MRD進行全鏈路PRD（產品需求文檔）拆解，然后再進行技術方案評審、交互評審、測試評審等，最后拆解成開發任務。研發人員進行開發和自測，最后完成集成測試和UAT測試（用戶驗收測試），即可正常發布上線。那如何做到“7+14”呢？
首先，我們在特種兵團隊內部組建了全功能團隊。將行業PD、前后端開發、測試等職能拉通，這樣當需求從行業PD流轉到前后端開發，從開發流轉到測試，都不再需要再進行層次的“排期”等待了。
第二，引入“EDA+SBE”方法進行高效的需求分析。這兩個方法，是阿里雲研發團隊總結和沉淀的。EDA 是 “Event Driven Analysis”的縮寫，這里不展開講。通過這個方法，首先會組織業務需求的核心干系人（一般是業務方、PD、開發PM、測試PM、交互等關鍵角色）對業務需求的流程做一次徹底的分析，確保大家對業務需求流程理解是一致的。接下來再通過SBE這個方法對產品設計進行細化；SBE是“Specification By Example”的縮寫，聽過何勉老師分享的同學應該有所耳聞，這個方法其實就是實例化需求。通過這兩個方法完成了對業務流程的梳理以及產品功能的細化，接下來，大家只是對這個達成共識的需求產出設計文檔。顯然，后續的需求評審效率會大幅提升，返工的概率也會大幅降低；而且，經過在多個團隊的實踐，中小型業務需求是完全可以在7天內完成澄清和評審的。
第三，當業務需求完成評審后，需求會被拆解到不同產品域進入開發測試環節，各個域的研發人員需要對齊業務需求，確保需求可以快速上線。
第四，針對團隊里之前存在的測試數據准備困難、測試環境不穩定等問題，我們也進行了改進，這屬於工程領域的提效，這里不展開講了。
第五，建立倒逼中台服務能力提升的機制；快速響應業務依賴於中台的服務化能力，為了避免中台團隊閉門造車，倒逼機制也很重要。
在目標的牽引下，經過這五步，大部分中小型的業務需求在協作過程復雜的中台型團隊里也是可以在21天內完成交付的。
“數字化”促進規模化提效
落地了特種兵團隊的最佳實踐后，我們開始思考如何在這一千多人的團隊里進行規模化提效。通過“數字化”實現團隊協作過程的透明化是一條必經之路。
為此，我們為大型團隊設計了這張“數字化”全景圖。共分為三個層次：規划層、實施層和交付層。規划層，“數字化”的是目標或者方向明確的戰役。實施層，“數字化”的是基於目標的實施過程，這個過程通常是通過項目或者需求完成實施過程。交付層，“數字化”的是從一行行代碼到發布上線直至完成需求的過程。這個方案，實現了從目標、需求到代碼的全鏈路數字化；整個過程也都在Aone（雲效）落地了。
再來看一看具體的落地過程：目標在線，上下對齊。怎么確保目標在被合理的推進呢？可以在圖中看到，一條條的目標（部分文字做了模糊處理）已經在線了，所有的團隊成員都可以看到組織的關鍵目標是什么。其次，目標和事情之間也實現了“鏈接” 。哪個目標由哪些事情（項目或需求）在支撐，哪個需求在支持那個目標，一目了然；這就完成了第一層的對齊。
接下來，再看實施層的實踐：需求在線，順暢交付。
可以清晰的看到，梳理后的供應鏈中台團隊的整體交付流程。當業務方提出需求后，行業PD會對需求進行評估，被接受后，行業PD會指派給不同的團隊去負責，后續再不同團隊內對需求進行排期，以及完成全鏈路的PRD評審，此時，也就完成了需求澄清。
通常情況下，業務需求是比較復雜的，澄清后的需求，會拆解一個子需求（產品類需求）到不同產品域，需求的技術PM牽頭，協同參與方完成自己負責的部分，最后進行集成測試和發布，整個需求才算被交付完成。
如上圖中下部分所示，雲效（阿里巴巴集團內部叫Aone）可以對“需求”進行分層管理，左側是業務需求，右側是產品需求。通過這個分層，解耦了業務和產研團隊的關注點，業務方關注自己“業務需求”的交付進展，產品研發同學關注“產品需求”的交付；但是，過程中產研團隊要與業務需求進行“左右對齊”，在7+4目標的牽引下，這過程變的更加的主動；這樣，就實現了協作過程的通暢。
在團隊提效實踐的過程中，我們發現，要持續高效的交付，除了前面提到的，確保“協作通暢”，還要“高效的進行需求分析”以及有“更好的服務化能力”的保駕護航。在前面的最佳實踐部分有提及，這里則不再贅述。
“數據化”建立改進閉環
通過前面的介紹，我們知道，供應鏈中台團隊基本實現了“數字化”；這個是前提，在一個大型團隊里要規模化的提效，我們還要能發現問題，改進問題。這就是“數據化”要做的事情。通過數據化建立改進閉環，讓團隊可以看到過程中的效能問題，然后想辦法去改進。
“數據化”的關鍵是要定義合理的數據指標。數據並不是越多越好，有些數據甚至會起到反面效果。
關於指標的定義，應用了“黃金圈”法則來思考；先考慮“Why”：為什么要定義這個目標？一定是為達成業務結果，這就是“最終目標”。再考慮“How”：如何才能達成最終的目標？作為一個“產研”團隊，就是要去提升“研發效能”，這是“代理指標”。“研發效能”實際上是一個偏結果性的東西，一切效能的提升都是為了達成最終的業務結果。再來看“What”：具體需要做哪些事情才能提升效能指標呢？這些事情還應該是產研團隊能改變的，比如：協作行為、技術能力、工程能力？ 否則拿到一個無法改變的事情，也是無濟於事的。
基於以上邏輯，我們確定了“數據化”指標（如上圖所示）；最終目標是：加速業務發展，引領業務創新。作為產研團隊，提升研發效能（代理指標）方面定義了三個指標：中台團隊對業務需求的支持要符合“3、6、1”；開通新行業的時間為“2周+2周”；業務需求交付周期縮短50%。
有了這個“研發效能”指標后，再向前推導，看產研團隊內部哪些指標是可以控制的：協作上可以更順暢、技術上提升服務化水平、工程能力上縮短變更前置時間等。
ALPD+雲效 助力企業10倍效能提升
最后，我對數字供應鏈中台團隊研發效能提效的實踐做一個總結。
首先，從最終目標出發：引領業務創新，加速業務發展。其次，作為產研團隊確定研發效能提升的2大目標：提升中台服務化能力：中台化服務能力要符合“3、6、1”標准；對新行業開通周期滿足“2周+2周”的周期；快速響應業務：業務需求到為“7+14”天交付。
為了證明目標可達成，我們在“特種兵”團隊打造了“7+14”的最佳實踐。 為了實現規模化；進行了“數字化”和“數據化”的建設和落地，讓數字供應鏈這個千人的超大規模研發團隊實現規模化提效。
在此過程中，我們還沉淀了一套賦能方法。 技術方面：如何評價和提升中台的服務化能力；如何梳理領域的模型和邊界治理； 協作方面：需求的高效分析方法和分層的需求管理數字化； 工程方面：如何在14天交付的約束下提升行業測試效率等等。
這一整套方法，就是雲效的“ALPD”(Advanced Lean Product Development)，是業務牽引、數字化、數據化、方法賦能、工具落地等組成的下一代精益產品開發體系。
通過阿里巴巴數字供應鏈中台提效實踐，也進一步證明ALPD在超大規模、超復雜場景里提升研發效能的威力。當然，我們也在持續不斷的打磨和完善ALPD，未來，希望在更多行業實踐和落地。
作者：Yvonne
本文為阿里雲原創內容，未經允許不得轉載