阿里敏捷教練：多團隊開發一個產品的組織設計和思考
Scrum等敏捷開發框架，最初都是為5到9人的小團隊設計的。通過保持專注和合理利用新技術，在相當長的時間裡小團隊仍然可以支撐業務發展。
隨著業務成長，小團隊的產出可能跟不上業務需要，團隊就會面臨規模化的問題。從1個團隊拓展到3個團隊，仍然可以通過簡單的團隊間溝通保持高效協作。當產品複雜到需要5個以上團隊同時開發時，我們需要一定的組織設計來保證團隊間的順暢協作，使得多團隊共同開發一個產品時仍能保持敏捷性。
保持小團隊
在初創企業或產品剛起步時，團隊通常都不大。隨著業務的發展，需求越來越多，產品越來越複雜，很多團隊的第一反應都是加人。事實上，加人並不是唯一選擇，也未必是最優選擇。很多時候，小團隊能交付驚人的業務成果。
一方面，通過保持專注：Do one thing and do it well，小團隊可以聚焦於核心業務，摒除不必要的干擾。有一款微處理器ARM比英特爾先做出來，團隊的一個leader說：“回過頭來看，當時我們決定做一款微處理器的時候，我認為我做了兩個重要的決定。我信任我的團隊，並且給了團隊兩件英特爾和摩托羅拉永遠不會提供給他們員工的東西：第一是缺錢，第二是缺人。他們不得不保持簡單”。類似的，創辦於2009年的WhatsApp於2014年被Facebook收購時，公司只有55名員工，全球活躍使用者達到4.5億人，日傳送短訊息達160億條。
另一方面，隨著開源運動、中臺技術和雲化技術的發展，很多非核心業務邏輯可以藉助外力快速搭建，在業務高速發展的同時，繼續保持一支精幹的團隊。例如，在阿里巴巴研發協同平臺“雲效”上，二十分鐘就可以搭建一套Spring Boot web application的持續整合流水線，包含靜態程式碼掃描、單元測試、編譯、打包、部署、介面測試。不僅操作方便快捷，還省去了採購機器、部署和管理 build farm的開銷。
業務單元特性團隊
即便努力保持專注並用盡了技術紅利，有時業務的發展還是遠遠超出預期，此時組建多個團隊勢在必行。
比較理想的選擇是按照業務單元來組建特性團隊。一個業務單元類似於一家小型創業公司，有自己的長期使命和願景，有相對清晰的業務邊界和盈利模式。人員方面，各業務單元有獨立的業務、產品和研發團隊。技術方面，各業務單元可以獨立完成產品開發的全流程，包括業務決策、產品設計、開發、測試和釋出，儘量避免業務單元之間的依賴。
作為一個超級app，手機淘寶分為幾條業務線，同一條業務線內還分為幾個獨立業務。例如，微淘和淘寶直播都屬於內容平臺業務線，二者的內容生產、傳播渠道、受眾和盈利模式不同，因而是相對獨立的業務單元。二者有獨立的業務、產品和研發團隊，業務目標也分開設定和衡量。
技術上解耦是各業務單元能夠獨立發展的前提。為了解決團隊間的依賴，手機淘寶對架構做了容器化改造：一些必要的初始化操作放在common容器中，各業務在自己的bundle中。各業務bundle按需載入，只能依賴底層的common架構，不能相互依賴。這樣各業務bundle可以並行開發，互不干擾。
按照獨立的業務邊界來組建特性團隊，團隊能獨立釋出新功能，迅速獲得市場反饋，通過不斷試錯找到業務發展的方向。
全球第一大音樂平臺、音樂流媒體公司Spotify也按照業務單元組建團隊。在" Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds "[1] ，敏捷教練Henrik Kniberg詳細介紹了Spotify模式。
Spotify的30多個“小分隊”（squad）分佈在全球的三個城市，每個squad負責產品的特定方向（例如搜尋或radio）。每個squad相當於一個小創業公司，squad沒有特定的主管，只有一位產品負責人（Product Owner）。PO負責業務方向，squad成員組成跨職能團隊交付業務結果。PO幫助squad制定目標和管理優先順序，也會定期維護公司層面的產品路線圖並確保squad的目標與公司戰略相匹配。squad被鼓勵應用精益創業原則，例如先交付MVP（minimum viable product），並通過A/B測試來驗證假設。此外，squad可以得到敏捷教練的幫助，敏捷教練引導squad持續改進並幫助團隊移除障礙。
在squad之上，spotify還有兩層組織架構：具有相關專業知識的人橫向組成“分會”（chapter），工作在相似領域的squad組成“部落”（tribe）。此外，具有相同興趣的人組成“行會”（guild）。
這套架構的主要目的，是促進全公司範圍的資訊和知識共享。員工向chapter lead彙報，在轉換squad時彙報線不變。儘管看上去像普通的矩陣式組織，這個矩陣是向產品交付傾斜的。同一個squad的成員坐在一起，組成高度自治的跨職能敏捷團隊，共同決定產品目標以及如何交付產品。橫向的chapter維度只是為了更方便地共享知識、工具和程式碼。chapter lead的工作是引導和支援資訊流動和知識共享，而不會像傳統職能經理那樣負責分配工作。
注：圖片來自於
https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
與此類似，淘寶直播的業務、產品和研發團隊也彙報給不同的職能經理。高度統一的業務目標把團隊成員凝聚在一起，團隊共同決定業務方向、業務目標以及如何達成目標。職能經理為業務發展提供支援和幫助，並幫助團隊成員在職業道路上成長，並不會把主要精力放在具體的產品交付上。淘寶直播敏捷實踐參見《阿里敏捷教練，全面解析淘寶直播敏捷實踐之路》。
無限制特性團隊
有時團隊在業務發展時壯大了，但是經過了一段高速發展，原有的業務方向遇到了瓶頸，新的業務方向還在摸索中。此時，業務方向還不明朗，難以按照明確的業務單元組建團隊，團隊需要快速適應業務方向的變化。此時，要鼓勵團隊廣度學習，避免區域性優化。
不同於圍繞業務單元組建的特性團隊，無限制特性團隊沒有相對獨立的業務領域，多個特性團隊共享一份產品代辦列表（Product Backlog），按照統一的優先順序交付產品功能。無限制特性團隊，並非所有團隊都相同的無差別特性團隊，每個團隊還是可以有自己的特色和專長，只要多個團隊組合起來能夠按照Product Backlog的優先順序交付特性即可。
2018年3月，我支援阿里健康網際網路醫療業務線時，正遇到這樣的情況：網際網路醫療業務經過兩年多的摸索，找到了一些可能的發展方向，但是還沒有找到非常明確的盈利模式，多個方向都需要進一步嘗試。研發團隊包括服務端開發、H5開發、Android開發、iOS開發、測試等30多位同學。
在原有的資源池模式下，每月職能經理按照產品經理的輸入，分配研發同學到各個專案中。由於業務的複雜性，產品涉及的核心應用有15個以上，除了電商平臺的商品、庫存、營銷等基本功能，還包含網際網路醫療特有的問診、掛號等服務，並涉及到演算法和AI。人員技能的瓶頸非常突出：部分核心應用只有一位同學特別瞭解。
2018年4月至5月，商品模組負責人和AI問診模組負責人先後休假，相應模組的技術方案設計幾乎停滯，嚴重拖累進度。為了平衡複雜的人員技能和專案需要，職能經理經常絞盡腦汁，仍然不免捉襟見肘，一線同學身兼多個專案非常普遍。多個專案都依賴同一位團隊成員時，不得不序列等待。在多個專案間頻繁切換也增加了上下文切換成本。
為了解決人員技能瓶頸的痛點，同時考慮到網際網路醫療特定的業務發展階段，嘗試了無限制特性團隊共同交付一個產品的協作模式：30人自由組合成兩支特性團隊。組隊只需滿足約束條件：人數均衡，核心應用在每個團隊都有人瞭解，新老結合，男女搭配。組隊成功後，兩支團隊從同一份Product Backlog裡按照優先順序領需求。如果某個團隊無法獨立完成當前最高優先順序的需求，先由這個團隊認領，另一個團隊派師傅指導。師傅主要是培養徒弟，具體工作由認領團隊的同學動手完成。
由於資源瓶頸的限制，2018年5月1日到6月14日需求交付的累計偏差（需求實際交付日期與計劃交付日期的偏差累加）達到了151天。經過兩個月的努力，兩支特性團隊都具備了完成各類需求的能力，團隊可以完全按照Product Backlog的優先順序領需求，既不需要團隊成員併發支援多個專案，也不需要等待資源瓶頸的釋放。6月15日到7月31日的累計交付偏差縮短到了3天。8月1日到8月31日繼續保持準時交付，累計交付偏差為2天。團隊成員的個人能力得到了充分鍛鍊，主動拓展技能承擔重任的同學獲得了晉升，得到了認可。團隊的自組織能力也得到了發展，遇到問題和阻礙，團隊成員會主動想辦法解決，不再事事依賴職能經理。職能經理的角色從派活變成了輔導和幫助團隊，減少了救火時間，有更多時間考慮團隊的長遠發展。
綜上，無限制特性團隊方案解決了業務需求等待資源瓶頸的痛點，不是讓業務發展來匹配人員的技能，而是人員拓展技能匹配業務發展的需要。與此同時，團隊成員的個人能力得到了鍛鍊，團隊的自組織能力得到了發展，也解放了職能經理。
無論是業務單元特性團隊，還是無限制特性團隊，每個團隊都要具有獨立交付產品特性的能力。一個複雜的產品特性，通常都需要修改多個模組才能實現。多個團隊修改同一個模組時，如何保證模組設計的一致性，並及時清理程式碼償還技術債？
引入模組守護者通常是個有益的實踐：每個模組最好有兩位模組守護者互相backup，修改模組程式碼需要請模組守護者做code review，一些複雜的修改最好預先進行設計評審。模組守護者可以是兼職的，只要保證每週抽出一定比例的時間維護模組程式碼即可。
隨著業務方向越來越清晰，業務模式逐漸穩定，無限制特性團隊會逐步找到相對固定的分工合作模式，每個特性團隊會逐步找到自己最擅長和最感興趣的產品方向。明確的產品方向，為團隊提供了長期深耕的條件，團隊逐步成為某一領域的專家。此時，無限制特性團隊就完成了向業務單元特性團隊的過渡。
小結
通過手機淘寶、Spotify和阿里健康的案例，我相信多團隊開發一個產品仍然可以保持敏捷。
在業務方向明確的情況下，按照業務單元組建特性團隊是最理想的選擇。在業務方向不明朗的情況下，可以先組建無限制特性團隊，再逐步過渡到業務單元特性團隊。無論採用何種組織設計，目的都是快速跑通業務閉環：持續地交付業務價值，並在真正的市場環境中檢驗假設，通過快速試錯找到在一定的利潤水平上為企業或終端使用者提供產品和服務的可行方法。
參考文獻：
[1] https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
作者：雲效鼓勵師
本文為雲棲社群原創內容，未經