越來越多的金融組織在推進規?；艚輹r，會開始采用虛擬部落小隊架構，來對齊業務、加強科技團隊價值交付能力。但作為科技敏捷的第一步，很多組織在劃分部落小隊時，仍會遇到各種各樣的問題和困惑。本文就聚焦在小隊這一獨立價值交付和效能分析單元，來與大家分享，小隊是什么、在劃分小隊時的常見問題分析、組建小隊的基本步驟，并給出了一個小隊劃分的成功案例，供讀者參考。

劃分小隊前，對組織現有狀況進行摸底是一個非常重要的步驟。我們為大家準備了一份Agilean咨詢團隊使用的部落小隊劃分摸底信息模板，關注本公眾號，回復“小隊摸底”即可獲取。

1

小隊到底是啥

金融組織通常會有某某部門、某某科室以及某某項目組的劃分方式，而在Adapt框架的組織結構中，我們更注重的，是從交付層面關注的、以業務領域為切分原則的部落或者小隊，它們都面向價值交付，以價值交付和業績提升為目標和方向。

圖 / Adapt框架中的部落小隊架構

部落是對齊或拉通相關業務與產品條線的最小管理單位，人數大概在50~100人；而小隊是業務端到端交付的最小管理單位，包含所需業務、產品、開發、測試人員等，人數一般約12人左右。小隊一般有兩種類型，業務小隊和系統小隊。

圖 / 兩種不同類型的小隊

業務小隊（或稱業務流團隊），指的是一個可以一起協作獨立交付一個或多個業務的跨職能團隊。

業務小隊是一類典型流動式團隊

在《Team Topologies》一書中，流動式團隊對應一條單一有價值的工作，也許是一個產品、一項服務、一組功能特性、一個故事或者一組用戶畫像。而業務小隊就是一類典型的流動式團隊，這種團隊模式的目的是能讓大家更關注于需要交付的功能特性，可以減少因為交接而引起的浪費，能確保總是讓合適的人去討論問題，同時更好地評估設計決策影響。之前業界中也常用特性團隊(Feature Team)來定義這類團隊，它是從業務架構出發而切分出來的領域。

從軟件行業發展的趨勢來看，在以前的系統建設中，因為初期的業務場景相對單一，通常是單體系統對應單一的業務，而隨著業務復雜性的增加以及系統架構設計中微服務、中臺等技術的應用，目前很多組織里面出現業務領域和系統多對多的對應關系，摸底組織現狀時，就會看到很多團隊不是以業務小隊的形式存在。

系統小隊（或稱組件小隊），指的是專為研發一個或幾個組件而在一起協作的團隊。

系統小隊的優劣分析

系統小隊的優勢，在于完成同一系統的人在一個團隊內，團隊的代碼所有權清晰；不足之處在于如果系統的設計與特性交付不完全匹配的情況下，多個系統小隊的存在不利于產品交付，做出的系統與其他系統集成時往往容易出現問題，形成交付流暢性的阻礙。系統的概念在組織中往往也有其它的名稱，比如應用，模塊，子系統等，總之它是從系統架構出發而切分出來的領域。

業務小隊無疑是更理想的，但在推行虛擬部落小隊初期，系統小隊也可以接受。確保在建立一個60分的基礎方案后，先動起來，并以此作為不斷演進的基礎。當然，如果條件允許，應該優先組建業務小隊。

業務和系統其實都是抽象概念，它們的界限并不明確。一個人規劃出業務領域的也可能是另一人的系統，隨著近年微服務、DDD、企業架構設計的興起，單一業務最好能被實現為獨立的、面向服務的系統，也就有利于逆康威定律的應用。

2

小隊價值何在

VUCA時代，我們觀察到大多數組織目前都面臨著三大難題：管理難度高、重構任務重、市場競爭大。

業務需求多而雜亂，IT部門要快速交付業務需求的同時，還要不停解決之前欠下的技術債，加上IT部門中還存在一定比例的外包人員，如果還是以之前項目制的方式來進行資源的分配，項目的進度、質量及項目的最終交付上都面臨著極大的壓力。

看起來資源池似乎是解決了組織中人員忙閑不均的問題，讓每個人都有事可做。但實際是需要更多的基層管理資源，去追蹤每個人的任務完成情況，才能更好的實現任務分配，并且如果頻繁的進行團隊中人員的調配，團隊中的信任感也會降低。

部落小隊 VS 資源池

行為心理學表明，合適的組織規模和明確的目標可以激發員工的責任感。在這一過程中，科技研發領導必須發現心中的調配感。

之前我們發現不少科技領導，很喜歡資源池模式，感覺哪里有火就可以派許多人去救火。結果火越救越多，但是，科技領導樂此不疲，因為，感覺自己在不斷調配資源，升級打怪。部落小隊恰恰要求科級領導放下自我，向下授權，構建部落生態卻解決研發交付問題。

要應對日益復雜的世界，任何組織和團隊都需要提升自己的應變能力。認識到這一點并不難 ，難點在于如何打造一個組織的應變能力，使其最終成為敏捷組織。

《賦能》中，作者斯坦利?麥克里斯特爾就提到一個關于如何打造敏捷組織的方法論：

團隊和組織需要擁有共同使命，建立信任，團隊成員需要擁有共享意識，這種共享意識必將提升人與人之間的相互依賴，同時也使得被授權被賦能的執行力變得容易，這種被賦能的執行力最終會推動速度。

帕特里克?蘭西奧尼所著的《團隊協作的五大障礙》中也提到缺乏信任、無視結果將會是團隊協作的巨大障礙。

小隊的組建不僅是為了將人員管理細化以后工作效率的提升，更多是明確團隊的使命感，增強團隊中的信任感，可以在更短的時間內看到更有價值的團隊產出。

如果我們已經明確了需要劃分小隊，那應該具體如何開始？

3

組建小隊的基本步驟

收集團隊所服務的細分業務領域、對應業務部門或科室，梳理相應的團隊所服務的業務架構。

收集團隊負責的系統清單，有時需要調閱團隊的代碼，梳理團隊的系統架構

確定組建小隊的策略，優先遵循業務架構來劃分小隊，若部落所服務的業務多數屬于中后臺業務，也可遵循系統架構來劃分小隊

盤點團隊各個職能角色的人員，以及其任務在各個業務領域的占比

依據初步劃分后的小隊來觀測小隊人數，若人數過多，則需要適當拆分

組建小隊時，同時也需考慮小隊長的人選

按照這樣的基本步驟，團隊有可能可以被拆分出一個相對合理的小隊，在實際操作中其實還是會有很多的問題涌現，下面為大家分享一些我們遇到過的組建小隊時的難點以及我們的解決思路。

4

組建小隊的常見問題

若按照細分業務領域或一個產品線來拆，人數就是過多

小隊是面向業務交付的最小管理單位，當一個小隊能單獨的完成一個或幾個業務領域的交付時，由于系統設計耦合度等各方面的影響，有可能小隊人數會達到2-30人左右，此時可考慮在小隊中細分小組的方式，原則上還是需要讓一個相對獨立團隊中的人數滿足兩個披薩的原則。

兩個披薩原則是由亞馬遜CEO貝索斯提出的，他認為如果兩個披薩不足以喂飽一個團隊，那么這個團隊可能就顯得太大了。

因為人數過多的項目會議將不利于決策的形成，而讓一個小團隊在一起做項目、開會討論，則更有利于達成共識，并能夠有效促進企業內部的創新。并且依據組織行為學及管理學的研究來說，基層管理者的管理能力是有限的，這被稱為“管理寬度”。一般來說，基層管理者有效管理的下屬上限是15至20人。建議小隊人數在12人以下，有利于之后的小隊長管理。

拆分了小隊，某一段時間內，小隊A很忙，小隊B很閑

許多組織中很多已習慣用資源池的方式對人員進行管理，在劃分時，管理者會有疑慮說，人員若歸屬于一個業務子領域，會引起工作忙閑不均的現象。此時我們應有意識的引導管理者更多去遵循“事流向人”的原則。

若一個小隊的工作量不飽和時，小隊可以承接其它小隊的工作，讓小隊人員盡量穩定，是為了打造團隊中的溝通順暢度。建議正常情況下，所有的研發人員都不跨小隊，特殊時，建議開發人員不跨小隊；85%以上的測試人員專職在部落內，兼職的測試人員有85%的測試任務優先服務部落。

測試人員通常是在做端到端的測試，無法劃分進小隊

在我們提倡質量內建、測試左移的時候，測試人員未來的確是會更多的去負責端到端的測試，以及非功能性測試（比如性能測試、安全測試等）。

但是在目前大多數組織，特別是金融領域涉及到專業金融領域知識時，有的團隊還是會有固定的測試人員對應的進行測試，因此小隊的人員組成還是會有測試人員，有時候也會出現幾個小隊對應一個測試資源池的情況。

建議依據測試人員平時的測試負責領域對應到小隊，也就是測試專職進入小隊。若實在無法劃入時，每個小隊應有固定的測試接口人，部落中也有一個測試負責人做部落測試資源的整體管理。

內部人員較少，劃分小隊后沒有足夠的人員做小隊長

小隊長負責組織小隊交付需求，并管理小隊的研發容量、進度以及研發質量，通常會建議內部人員來擔任此角色，但是有些組織中的符合資格的內部人員較少，無法選出合適的小隊長。

建議是前期可以增設小隊長B角，逐步培養出合格的小隊長。從管理層面來說，小隊的劃分也是為了培養出更多的面向交付的基層管理者或負責人。

組建小隊后，對小隊如何進行考核

小隊目標是部落目標的細化分解，從小隊層級的效能層面來看，建議可以從多快好贊四個維度來衡量。

小隊層級的效能度量指標是為了給小隊的自我提升改進指明方向，完全不同業務或系統形態的小隊無可比性，不能搞一刀切，因此部落內的小隊也要試情況來看是否適合進行小隊間的橫向比較。

圖 / Adapt框架中的部落小隊效能度量

與小隊間的關聯也遵從高內聚，低耦合性的原則，至少保證85%的業務需求都在小隊內可以進行交付，若有小隊頻繁的發生關聯，則需要考慮小隊劃分的合理性，同時也觀測現階段的業務需求是否已經和之前組建小隊時的業務需求方向有所變化。

業務需求橫向來看，前中后臺，會橫跨了好幾個小隊，小隊之間的速度不一樣時 ，如何平衡？

小隊的迭代周期不一定完全一致，通常來看渠道側的小隊會是2周1個迭代，核心側的小隊是4周一個迭代。建議若有需求同時需要渠道和核心小隊參與時，可以用找公倍數時間的方式來同頻小隊間的交互。

比如渠道側還是2周一個迭代，但是第2個迭代中會安排和核心側的聯調以及上線。另外一種情況是，如果兩個小隊交互耦合太頻繁了，需要考慮初期小隊劃分是否合理，有無重新劃分小隊的必要。

進行小隊劃分后，各小隊自行管理，縱向來看，會有重復造輪子的風險

多個小隊上面有部落這一層的管理，而部落中有架構師的角色，去把控重復造輪子的情況。小隊間若有資源需要調配時，也有部落長來做統一的調度。

小隊組建以后是不是就一直存在，不會變化

由于某一些小隊可能是因為依據業務領域進行劃分的，而在一段時間以后，此業務領域的需求有可能消減到非常低的程度，此類小隊可以考慮在恰當的時候與其它的小隊進行合并。

因此，部落中的小隊也是會進行動態的調整，并不是完全不變，同樣符合Bruce Tuckman的團隊發展階段模型，小隊也會有組建期、激蕩期、規范期、執行期和休整期。

5

長沙銀行小隊劃分案例

初始：小隊獨立完成需求交付，產研測專職劃入

在2019年推行規?；艚葜?#xff0c;長沙銀行在科技側推行面向業務的虛擬研發部落制架構，將千名科技人員劃入了六大部落，并設立部落長，小隊長對需求交付端到端負責。

圖 / 轉型初期長沙銀行部落小隊

這一過程中，長沙銀行的要求是任何人只允許對應一個小隊，一個部落，不允許跨部落，跨小隊。

在當時，長沙銀行每個小隊約 10 人，產品、開發、測試均專職進入小隊，保證小隊成員具備各樣的能力，能完成獨立的需求交付。

與部落相比，小隊可能負責一塊更小的業務，如信用卡部落中設「卡產品小隊」，即上文我們提到的業務小隊；也可能負責幾個系統，如分成前端小隊或后端小隊。即系統小隊。

長沙銀行部落小隊的建立打下了研發組織精細化管理的骨架，需求任務分解體系、敏捷活動、研發度量體系等，均得以依托科學劃分的部落小隊得以順利落地。

例如，長沙銀行的三層需求任務分解體系，系統功能拆到 10 人天以內（單系統、可反饋），且明確主辦部落和主辦小隊，個人任務拆到 1-3 人天左右。在小隊站會同步時，小隊長根據成員報出的風險與進度，反推到需求都有明確的跟進處理事項與優先級。

小隊既是獨立的價值交付團隊，也是效能分析單元。對于上文提到的小隊考核問題，長沙銀行依托Adapt框架多快好贊度量體系，在長沙銀行部落級、小隊級建立起了研發效能度量體系。

演進：按新策略升級小隊劃分

初始的部落小隊劃分，是針對轉型初期問題進行的設計。在長沙銀行數字化轉型進入規模推廣階段后，情況已大為不同。

因此，長沙銀行基于平臺業務分離、系統歸屬調整、小隊內嵌、跨部落需求協作四項策略，重新優化部落小隊結構，將多個研發團隊分拆，減少跨部落耦合，縮減小隊人數規模，進一步精細化管理 。

圖 / 長沙銀行優化調整后的部落小隊結構

例如，長沙銀行根據在上一階段統計的系統工時反推系統人數，通過各系統在一定周期內的工時以及周期內的工作時間，計算出所需資源與崗位，進行各小隊的資源劃分調整。

我們曾撰文全面復盤過長沙銀行3年的研發數字化轉型歷程，感興趣的讀者，可從文末延伸閱讀部分，查看詳細復盤。

福利時間

在劃分小隊前，對組織現有狀況進行摸底是一個非常重要的步驟。摸底應從哪些維度進行？對哪些人進行訪談？收集哪些數據？

我們為大家準備了一份Agilean咨詢團隊使用的部落小隊劃分摸底信息模板，關注本公眾號，回復“小隊摸底”即可獲取。

本文作者：

程萃(江湖綽號：CC)，Agilean資深顧問，精益敏捷轉型專家。四川大學軟件工程碩士，16余年軟件和咨詢行業經驗，銀行、軟件開發企業、教育等行業從事過咨詢和培訓服務，曾深度服務于平安銀行，建信金科等大型金融組織，幫助組織進行組織級的流程改進，部門級的技術、業務、組織協同的敏捷轉型。

延伸閱讀

01

長沙銀行3年數字化研發管理轉型復盤

02

寧波銀行規?；艚菰圏c案例

03

金融組織規模化敏捷速贏：部落制

04

Adapt規模化敏捷框架

總結

以上是生活随笔為你收集整理的金融组织做规模化敏捷怎么划小队，一文讲清的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。