Scrum等敏捷開發(fā)框架，最初都是為5到9人的小團(tuán)隊(duì)設(shè)計(jì)的。通過保持專注和合理利用新技術(shù)，在相當(dāng)長的時間里小團(tuán)隊(duì)仍然可以支撐業(yè)務(wù)發(fā)展。

隨著業(yè)務(wù)成長，小團(tuán)隊(duì)的產(chǎn)出可能跟不上業(yè)務(wù)需要，團(tuán)隊(duì)就會面臨規(guī)模化的問題。從1個團(tuán)隊(duì)拓展到3個團(tuán)隊(duì)，仍然可以通過簡單的團(tuán)隊(duì)間溝通保持高效協(xié)作。當(dāng)產(chǎn)品復(fù)雜到需要5個以上團(tuán)隊(duì)同時開發(fā)時，我們需要一定的組織設(shè)計(jì)來保證團(tuán)隊(duì)間的順暢協(xié)作，使得多團(tuán)隊(duì)共同開發(fā)一個產(chǎn)品時仍能保持敏捷性。

保持小團(tuán)隊(duì)

在初創(chuàng)企業(yè)或產(chǎn)品剛起步時，團(tuán)隊(duì)通常都不大。隨著業(yè)務(wù)的發(fā)展，需求越來越多，產(chǎn)品越來越復(fù)雜，很多團(tuán)隊(duì)的第一反應(yīng)都是加人。事實(shí)上，加人并不是唯一選擇，也未必是最優(yōu)選擇。很多時候，小團(tuán)隊(duì)能交付驚人的業(yè)務(wù)成果。

一方面，通過保持專注：Do one thing and do it well，小團(tuán)隊(duì)可以聚焦于核心業(yè)務(wù)，摒除不必要的干擾。有一款微處理器ARM比英特爾先做出來，團(tuán)隊(duì)的一個leader說：“回過頭來看，當(dāng)時我們決定做一款微處理器的時候，我認(rèn)為我做了兩個重要的決定。我信任我的團(tuán)隊(duì)，并且給了團(tuán)隊(duì)兩件英特爾和摩托羅拉永遠(yuǎn)不會提供給他們員工的東西：第一是缺錢，第二是缺人。他們不得不保持簡單”。類似的，創(chuàng)辦于2009年的WhatsApp于2014年被Facebook收購時，公司只有55名員工，全球活躍用戶達(dá)到4.5億人，日發(fā)送短消息達(dá)160億條。

另一方面，隨著開源運(yùn)動、中臺技術(shù)和云化技術(shù)的發(fā)展，很多非核心業(yè)務(wù)邏輯可以借助外力快速搭建，在業(yè)務(wù)高速發(fā)展的同時，繼續(xù)保持一支精干的團(tuán)隊(duì)。例如，在阿里巴巴研發(fā)協(xié)同平臺“云效”上，二十分鐘就可以搭建一套Spring Boot web application的持續(xù)集成流水線，包含靜態(tài)代碼掃描、單元測試、編譯、打包、部署、接口測試。不僅操作方便快捷，還省去了采購機(jī)器、部署和管理 build farm的開銷。

業(yè)務(wù)單元特性團(tuán)隊(duì)

即便努力保持專注并用盡了技術(shù)紅利，有時業(yè)務(wù)的發(fā)展還是遠(yuǎn)遠(yuǎn)超出預(yù)期，此時組建多個團(tuán)隊(duì)勢在必行。

比較理想的選擇是按照業(yè)務(wù)單元來組建特性團(tuán)隊(duì)。一個業(yè)務(wù)單元類似于一家小型創(chuàng)業(yè)公司，有自己的長期使命和愿景，有相對清晰的業(yè)務(wù)邊界和盈利模式。人員方面，各業(yè)務(wù)單元有獨(dú)立的業(yè)務(wù)、產(chǎn)品和研發(fā)團(tuán)隊(duì)。技術(shù)方面，各業(yè)務(wù)單元可以獨(dú)立完成產(chǎn)品開發(fā)的全流程，包括業(yè)務(wù)決策、產(chǎn)品設(shè)計(jì)、開發(fā)、測試和發(fā)布，盡量避免業(yè)務(wù)單元之間的依賴。

作為一個超級app，手機(jī)淘寶分為幾條業(yè)務(wù)線，同一條業(yè)務(wù)線內(nèi)還分為幾個獨(dú)立業(yè)務(wù)。例如，微淘和淘寶直播都屬于內(nèi)容平臺業(yè)務(wù)線，二者的內(nèi)容生產(chǎn)、傳播渠道、受眾和盈利模式不同，因而是相對獨(dú)立的業(yè)務(wù)單元。二者有獨(dú)立的業(yè)務(wù)、產(chǎn)品和研發(fā)團(tuán)隊(duì)，業(yè)務(wù)目標(biāo)也分開設(shè)定和衡量。

技術(shù)上解耦是各業(yè)務(wù)單元能夠獨(dú)立發(fā)展的前提。為了解決團(tuán)隊(duì)間的依賴，手機(jī)淘寶對架構(gòu)做了容器化改造：一些必要的初始化操作放在common容器中，各業(yè)務(wù)在自己的bundle中。各業(yè)務(wù)bundle按需加載，只能依賴底層的common架構(gòu)，不能相互依賴。這樣各業(yè)務(wù)bundle可以并行開發(fā)，互不干擾。

按照獨(dú)立的業(yè)務(wù)邊界來組建特性團(tuán)隊(duì)，團(tuán)隊(duì)能獨(dú)立發(fā)布新功能，迅速獲得市場反饋，通過不斷試錯找到業(yè)務(wù)發(fā)展的方向。

全球第一大音樂平臺、音樂流媒體公司Spotify也按照業(yè)務(wù)單元組建團(tuán)隊(duì)。在" Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds "[1] ，敏捷教練Henrik Kniberg詳細(xì)介紹了Spotify模式。

Spotify的30多個“小分隊(duì)”（squad）分布在全球的三個城市，每個squad負(fù)責(zé)產(chǎn)品的特定方向（例如搜索或radio）。每個squad相當(dāng)于一個小創(chuàng)業(yè)公司，squad沒有特定的主管，只有一位產(chǎn)品負(fù)責(zé)人（Product Owner）。PO負(fù)責(zé)業(yè)務(wù)方向，squad成員組成跨職能團(tuán)隊(duì)交付業(yè)務(wù)結(jié)果。PO幫助squad制定目標(biāo)和管理優(yōu)先級，也會定期維護(hù)公司層面的產(chǎn)品路線圖并確保squad的目標(biāo)與公司戰(zhàn)略相匹配。squad被鼓勵應(yīng)用精益創(chuàng)業(yè)原則，例如先交付MVP（minimum viable product），并通過A/B測試來驗(yàn)證假設(shè)。此外，squad可以得到敏捷教練的幫助，敏捷教練引導(dǎo)squad持續(xù)改進(jìn)并幫助團(tuán)隊(duì)移除障礙。

在squad之上，spotify還有兩層組織架構(gòu)：具有相關(guān)專業(yè)知識的人橫向組成“分會”（chapter），工作在相似領(lǐng)域的squad組成“部落”（tribe）。此外，具有相同興趣的人組成“行會”（guild）。

這套架構(gòu)的主要目的，是促進(jìn)全公司范圍的信息和知識共享。員工向chapter lead匯報(bào)，在轉(zhuǎn)換squad時匯報(bào)線不變。盡管看上去像普通的矩陣式組織，這個矩陣是向產(chǎn)品交付傾斜的。同一個squad的成員坐在一起，組成高度自治的跨職能敏捷團(tuán)隊(duì)，共同決定產(chǎn)品目標(biāo)以及如何交付產(chǎn)品。橫向的chapter維度只是為了更方便地共享知識、工具和代碼。chapter lead的工作是引導(dǎo)和支持信息流動和知識共享，而不會像傳統(tǒng)職能經(jīng)理那樣負(fù)責(zé)分配工作。

與此類似，淘寶直播的業(yè)務(wù)、產(chǎn)品和研發(fā)團(tuán)隊(duì)也匯報(bào)給不同的職能經(jīng)理。高度統(tǒng)一的業(yè)務(wù)目標(biāo)把團(tuán)隊(duì)成員凝聚在一起，團(tuán)隊(duì)共同決定業(yè)務(wù)方向、業(yè)務(wù)目標(biāo)以及如何達(dá)成目標(biāo)。職能經(jīng)理為業(yè)務(wù)發(fā)展提供支持和幫助，并幫助團(tuán)隊(duì)成員在職業(yè)道路上成長，并不會把主要精力放在具體的產(chǎn)品交付上。淘寶直播敏捷實(shí)踐參見《阿里敏捷教練，全面解析淘寶直播敏捷實(shí)踐之路》。

無限制特性團(tuán)隊(duì)

有時團(tuán)隊(duì)在業(yè)務(wù)發(fā)展時壯大了，但是經(jīng)過了一段高速發(fā)展，原有的業(yè)務(wù)方向遇到了瓶頸，新的業(yè)務(wù)方向還在摸索中。此時，業(yè)務(wù)方向還不明朗，難以按照明確的業(yè)務(wù)單元組建團(tuán)隊(duì)，團(tuán)隊(duì)需要快速適應(yīng)業(yè)務(wù)方向的變化。此時，要鼓勵團(tuán)隊(duì)廣度學(xué)習(xí)，避免局部優(yōu)化。

不同于圍繞業(yè)務(wù)單元組建的特性團(tuán)隊(duì)，無限制特性團(tuán)隊(duì)沒有相對獨(dú)立的業(yè)務(wù)領(lǐng)域，多個特性團(tuán)隊(duì)共享一份產(chǎn)品代辦列表（Product Backlog），按照統(tǒng)一的優(yōu)先級交付產(chǎn)品功能。無限制特性團(tuán)隊(duì)，并非所有團(tuán)隊(duì)都相同的無差別特性團(tuán)隊(duì)，每個團(tuán)隊(duì)還是可以有自己的特色和專長，只要多個團(tuán)隊(duì)組合起來能夠按照Product Backlog的優(yōu)先級交付特性即可。

2018年3月，我支持阿里健康互聯(lián)網(wǎng)醫(yī)療業(yè)務(wù)線時，正遇到這樣的情況：互聯(lián)網(wǎng)醫(yī)療業(yè)務(wù)經(jīng)過兩年多的摸索，找到了一些可能的發(fā)展方向，但是還沒有找到非常明確的盈利模式，多個方向都需要進(jìn)一步嘗試。研發(fā)團(tuán)隊(duì)包括服務(wù)端開發(fā)、H5開發(fā)、Android開發(fā)、iOS開發(fā)、測試等30多位同學(xué)。

在原有的資源池模式下，每月職能經(jīng)理按照產(chǎn)品經(jīng)理的輸入，分配研發(fā)同學(xué)到各個項(xiàng)目中。由于業(yè)務(wù)的復(fù)雜性，產(chǎn)品涉及的核心應(yīng)用有15個以上，除了電商平臺的商品、庫存、營銷等基本功能，還包含互聯(lián)網(wǎng)醫(yī)療特有的問診、掛號等服務(wù)，并涉及到算法和AI。人員技能的瓶頸非常突出：部分核心應(yīng)用只有一位同學(xué)特別了解。

2018年4月至5月，商品模塊負(fù)責(zé)人和AI問診模塊負(fù)責(zé)人先后休假，相應(yīng)模塊的技術(shù)方案設(shè)計(jì)幾乎停滯，嚴(yán)重拖累進(jìn)度。為了平衡復(fù)雜的人員技能和項(xiàng)目需要，職能經(jīng)理經(jīng)常絞盡腦汁，仍然不免捉襟見肘，一線同學(xué)身兼多個項(xiàng)目非常普遍。多個項(xiàng)目都依賴同一位團(tuán)隊(duì)成員時，不得不串行等待。在多個項(xiàng)目間頻繁切換也增加了上下文切換成本。

為了解決人員技能瓶頸的痛點(diǎn)，同時考慮到互聯(lián)網(wǎng)醫(yī)療特定的業(yè)務(wù)發(fā)展階段，嘗試了無限制特性團(tuán)隊(duì)共同交付一個產(chǎn)品的協(xié)作模式：30人自由組合成兩支特性團(tuán)隊(duì)。組隊(duì)只需滿足約束條件：人數(shù)均衡，核心應(yīng)用在每個團(tuán)隊(duì)都有人了解，新老結(jié)合，男女搭配。組隊(duì)成功后，兩支團(tuán)隊(duì)從同一份Product Backlog里按照優(yōu)先級領(lǐng)需求。如果某個團(tuán)隊(duì)無法獨(dú)立完成當(dāng)前最高優(yōu)先級的需求，先由這個團(tuán)隊(duì)認(rèn)領(lǐng)，另一個團(tuán)隊(duì)派師傅指導(dǎo)。師傅主要是培養(yǎng)徒弟，具體工作由認(rèn)領(lǐng)團(tuán)隊(duì)的同學(xué)動手完成。

由于資源瓶頸的限制，2018年5月1日到6月14日需求交付的累計(jì)偏差（需求實(shí)際交付日期與計(jì)劃交付日期的偏差累加）達(dá)到了151天。經(jīng)過兩個月的努力，兩支特性團(tuán)隊(duì)都具備了完成各類需求的能力，團(tuán)隊(duì)可以完全按照Product Backlog的優(yōu)先級領(lǐng)需求，既不需要團(tuán)隊(duì)成員并發(fā)支持多個項(xiàng)目，也不需要等待資源瓶頸的釋放。6月15日到7月31日的累計(jì)交付偏差縮短到了3天。8月1日到8月31日繼續(xù)保持準(zhǔn)時交付，累計(jì)交付偏差為2天。團(tuán)隊(duì)成員的個人能力得到了充分鍛煉，主動拓展技能承擔(dān)重任的同學(xué)獲得了晉升，得到了認(rèn)可。團(tuán)隊(duì)的自組織能力也得到了發(fā)展，遇到問題和阻礙，團(tuán)隊(duì)成員會主動想辦法解決，不再事事依賴職能經(jīng)理。職能經(jīng)理的角色從派活變成了輔導(dǎo)和幫助團(tuán)隊(duì)，減少了救火時間，有更多時間考慮團(tuán)隊(duì)的長遠(yuǎn)發(fā)展。

綜上，無限制特性團(tuán)隊(duì)方案解決了業(yè)務(wù)需求等待資源瓶頸的痛點(diǎn)，不是讓業(yè)務(wù)發(fā)展來匹配人員的技能，而是人員拓展技能匹配業(yè)務(wù)發(fā)展的需要。與此同時，團(tuán)隊(duì)成員的個人能力得到了鍛煉，團(tuán)隊(duì)的自組織能力得到了發(fā)展，也解放了職能經(jīng)理。

無論是業(yè)務(wù)單元特性團(tuán)隊(duì)，還是無限制特性團(tuán)隊(duì)，每個團(tuán)隊(duì)都要具有獨(dú)立交付產(chǎn)品特性的能力。一個復(fù)雜的產(chǎn)品特性，通常都需要修改多個模塊才能實(shí)現(xiàn)。多個團(tuán)隊(duì)修改同一個模塊時，如何保證模塊設(shè)計(jì)的一致性，并及時清理代碼償還技術(shù)債？

引入模塊守護(hù)者通常是個有益的實(shí)踐：每個模塊最好有兩位模塊守護(hù)者互相backup，修改模塊代碼需要請模塊守護(hù)者做code review，一些復(fù)雜的修改最好預(yù)先進(jìn)行設(shè)計(jì)評審。模塊守護(hù)者可以是兼職的，只要保證每周抽出一定比例的時間維護(hù)模塊代碼即可。

隨著業(yè)務(wù)方向越來越清晰，業(yè)務(wù)模式逐漸穩(wěn)定，無限制特性團(tuán)隊(duì)會逐步找到相對固定的分工合作模式，每個特性團(tuán)隊(duì)會逐步找到自己最擅長和最感興趣的產(chǎn)品方向。明確的產(chǎn)品方向，為團(tuán)隊(duì)提供了長期深耕的條件，團(tuán)隊(duì)逐步成為某一領(lǐng)域的專家。此時，無限制特性團(tuán)隊(duì)就完成了向業(yè)務(wù)單元特性團(tuán)隊(duì)的過渡。

小結(jié)

通過手機(jī)淘寶、Spotify和阿里健康的案例，我相信多團(tuán)隊(duì)開發(fā)一個產(chǎn)品仍然可以保持敏捷。

在業(yè)務(wù)方向明確的情況下，按照業(yè)務(wù)單元組建特性團(tuán)隊(duì)是最理想的選擇。在業(yè)務(wù)方向不明朗的情況下，可以先組建無限制特性團(tuán)隊(duì)，再逐步過渡到業(yè)務(wù)單元特性團(tuán)隊(duì)。無論采用何種組織設(shè)計(jì)，目的都是快速跑通業(yè)務(wù)閉環(huán)：持續(xù)地交付業(yè)務(wù)價值，并在真正的市場環(huán)境中檢驗(yàn)假設(shè)，通過快速試錯找到在一定的利潤水平上為企業(yè)或終端用戶提供產(chǎn)品和服務(wù)的可行方法。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的阿里敏捷教练：多团队开发一个产品的组织设计和思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。