越来越多的金融组织在推进规模化敏捷时，会开始采用虚拟部落小队架构，来对齐业务、加强科技团队价值交付能力。但作为科技敏捷的第一步，很多组织在划分部落小队时，仍会遇到各种各样的问题和困惑。本文就聚焦在小队这一独立价值交付和效能分析单元，来与大家分享，小队是什么、在划分小队时的常见问题分析、组建小队的基本步骤，并给出了一个小队划分的成功案例，供读者参考。

划分小队前，对组织现有状况进行摸底是一个非常重要的步骤。我们为大家准备了一份Agilean咨询团队使用的部落小队划分摸底信息模板，关注本公众号，回复“小队摸底”即可获取。

1

小队到底是啥

金融组织通常会有某某部门、某某科室以及某某项目组的划分方式，而在Adapt框架的组织结构中，我们更注重的，是从交付层面关注的、以业务领域为切分原则的部落或者小队，它们都面向价值交付，以价值交付和业绩提升为目标和方向。

图 / Adapt框架中的部落小队架构

部落是对齐或拉通相关业务与产品条线的最小管理单位，人数大概在50~100人；而小队是业务端到端交付的最小管理单位，包含所需业务、产品、开发、测试人员等，人数一般约12人左右。小队一般有两种类型，业务小队和系统小队。

图 / 两种不同类型的小队

业务小队（或称业务流团队），指的是一个可以一起协作独立交付一个或多个业务的跨职能团队。

业务小队是一类典型流动式团队

在《Team Topologies》一书中，流动式团队对应一条单一有价值的工作，也许是一个产品、一项服务、一组功能特性、一个故事或者一组用户画像。而业务小队就是一类典型的流动式团队，这种团队模式的目的是能让大家更关注于需要交付的功能特性，可以减少因为交接而引起的浪费，能确保总是让合适的人去讨论问题，同时更好地评估设计决策影响。之前业界中也常用特性团队(Feature Team)来定义这类团队，它是从业务架构出发而切分出来的领域。

从软件行业发展的趋势来看，在以前的系统建设中，因为初期的业务场景相对单一，通常是单体系统对应单一的业务，而随着业务复杂性的增加以及系统架构设计中微服务、中台等技术的应用，目前很多组织里面出现业务领域和系统多对多的对应关系，摸底组织现状时，就会看到很多团队不是以业务小队的形式存在。

系统小队（或称组件小队），指的是专为研发一个或几个组件而在一起协作的团队。

系统小队的优劣分析

系统小队的优势，在于完成同一系统的人在一个团队内，团队的代码所有权清晰；不足之处在于如果系统的设计与特性交付不完全匹配的情况下，多个系统小队的存在不利于产品交付，做出的系统与其他系统集成时往往容易出现问题，形成交付流畅性的阻碍。系统的概念在组织中往往也有其它的名称，比如应用，模块，子系统等，总之它是从系统架构出发而切分出来的领域。

业务小队无疑是更理想的，但在推行虚拟部落小队初期，系统小队也可以接受。确保在建立一个60分的基础方案后，先动起来，并以此作为不断演进的基础。当然，如果条件允许，应该优先组建业务小队。

业务和系统其实都是抽象概念，它们的界限并不明确。一个人规划出业务领域的也可能是另一人的系统，随着近年微服务、DDD、企业架构设计的兴起，单一业务最好能被实现为独立的、面向服务的系统，也就有利于逆康威定律的应用。

2

小队价值何在

VUCA时代，我们观察到大多数组织目前都面临着三大难题：管理难度高、重构任务重、市场竞争大。

业务需求多而杂乱，IT部门要快速交付业务需求的同时，还要不停解决之前欠下的技术债，加上IT部门中还存在一定比例的外包人员，如果还是以之前项目制的方式来进行资源的分配，项目的进度、质量及项目的最终交付上都面临着极大的压力。

看起来资源池似乎是解决了组织中人员忙闲不均的问题，让每个人都有事可做。但实际是需要更多的基层管理资源，去追踪每个人的任务完成情况，才能更好的实现任务分配，并且如果频繁的进行团队中人员的调配，团队中的信任感也会降低。

部落小队 VS 资源池

行为心理学表明，合适的组织规模和明确的目标可以激发员工的责任感。在这一过程中，科技研发领导必须发现心中的调配感。

之前我们发现不少科技领导，很喜欢资源池模式，感觉哪里有火就可以派许多人去救火。结果火越救越多，但是，科技领导乐此不疲，因为，感觉自己在不断调配资源，升级打怪。部落小队恰恰要求科级领导放下自我，向下授权，构建部落生态却解决研发交付问题。

要应对日益复杂的世界，任何组织和团队都需要提升自己的应变能力。认识到这一点并不难 ，难点在于如何打造一个组织的应变能力，使其最终成为敏捷组织。

《赋能》中，作者斯坦利•麦克里斯特尔就提到一个关于如何打造敏捷组织的方法论：

团队和组织需要拥有共同使命，建立信任，团队成员需要拥有共享意识，这种共享意识必将提升人与人之间的相互依赖，同时也使得被授权被赋能的执行力变得容易，这种被赋能的执行力最终会推动速度。

帕特里克•兰西奥尼所著的《团队协作的五大障碍》中也提到缺乏信任、无视结果将会是团队协作的巨大障碍。

小队的组建不仅是为了将人员管理细化以后工作效率的提升，更多是明确团队的使命感，增强团队中的信任感，可以在更短的时间内看到更有价值的团队产出。

如果我们已经明确了需要划分小队，那应该具体如何开始？

3

组建小队的基本步骤

1. 收集团队所服务的细分业务领域、对应业务部门或科室，梳理相应的团队所服务的业务架构。

2. 收集团队负责的系统清单，有时需要调阅团队的代码，梳理团队的系统架构

3. 确定组建小队的策略，优先遵循业务架构来划分小队，若部落所服务的业务多数属于中后台业务，也可遵循系统架构来划分小队

4. 盘点团队各个职能角色的人员，以及其任务在各个业务领域的占比

5. 依据初步划分后的小队来观测小队人数，若人数过多，则需要适当拆分

6. 组建小队时，同时也需考虑小队长的人选

按照这样的基本步骤，团队有可能可以被拆分出一个相对合理的小队，在实际操作中其实还是会有很多的问题涌现，下面为大家分享一些我们遇到过的组建小队时的难点以及我们的解决思路。

4

组建小队的常见问题

若按照细分业务领域或一个产品线来拆，人数就是过多

小队是面向业务交付的最小管理单位，当一个小队能单独的完成一个或几个业务领域的交付时，由于系统设计耦合度等各方面的影响，有可能小队人数会达到2-30人左右，此时可考虑在小队中细分小组的方式，原则上还是需要让一个相对独立团队中的人数满足两个披萨的原则。

两个披萨原则是由亚马逊CEO贝索斯提出的，他认为如果两个披萨不足以喂饱一个团队，那么这个团队可能就显得太大了。

因为人数过多的项目会议将不利于决策的形成，而让一个小团队在一起做项目、开会讨论，则更有利于达成共识，并能够有效促进企业内部的创新。并且依据组织行为学及管理学的研究来说，基层管理者的管理能力是有限的，这被称为“管理宽度”。一般来说，基层管理者有效管理的下属上限是15至20人。建议小队人数在12人以下，有利于之后的小队长管理。

拆分了小队，某一段时间内，小队A很忙，小队B很闲

许多组织中很多已习惯用资源池的方式对人员进行管理，在划分时，管理者会有疑虑说，人员若归属于一个业务子领域，会引起工作忙闲不均的现象。此时我们应有意识的引导管理者更多去遵循“事流向人”的原则。

若一个小队的工作量不饱和时，小队可以承接其它小队的工作，让小队人员尽量稳定，是为了打造团队中的沟通顺畅度。建议正常情况下，所有的研发人员都不跨小队，特殊时，建议开发人员不跨小队；85%以上的测试人员专职在部落内，兼职的测试人员有85%的测试任务优先服务部落。

测试人员通常是在做端到端的测试，无法划分进小队

在我们提倡质量内建、测试左移的时候，测试人员未来的确是会更多的去负责端到端的测试，以及非功能性测试（比如性能测试、安全测试等）。

但是在目前大多数组织，特别是金融领域涉及到专业金融领域知识时，有的团队还是会有固定的测试人员对应的进行测试，因此小队的人员组成还是会有测试人员，有时候也会出现几个小队对应一个测试资源池的情况。

建议依据测试人员平时的测试负责领域对应到小队，也就是测试专职进入小队。若实在无法划入时，每个小队应有固定的测试接口人，部落中也有一个测试负责人做部落测试资源的整体管理。

内部人员较少，划分小队后没有足够的人员做小队长

小队长负责组织小队交付需求，并管理小队的研发容量、进度以及研发质量，通常会建议内部人员来担任此角色，但是有些组织中的符合资格的内部人员较少，无法选出合适的小队长。

建议是前期可以增设小队长B角，逐步培养出合格的小队长。从管理层面来说，小队的划分也是为了培养出更多的面向交付的基层管理者或负责人。

组建小队后，对小队如何进行考核

小队目标是部落目标的细化分解，从小队层级的效能层面来看，建议可以从多快好赞四个维度来衡量。

小队层级的效能度量指标是为了给小队的自我提升改进指明方向，完全不同业务或系统形态的小队无可比性，不能搞一刀切，因此部落内的小队也要试情况来看是否适合进行小队间的横向比较。

图 / Adapt框架中的部落小队效能度量

与小队间的关联也遵从高内聚，低耦合性的原则，至少保证85%的业务需求都在小队内可以进行交付，若有小队频繁的发生关联，则需要考虑小队划分的合理性，同时也观测现阶段的业务需求是否已经和之前组建小队时的业务需求方向有所变化。

业务需求横向来看，前中后台，会横跨了好几个小队，小队之间的速度不一样时 ，如何平衡？

小队的迭代周期不一定完全一致，通常来看渠道侧的小队会是2周1个迭代，核心侧的小队是4周一个迭代。建议若有需求同时需要渠道和核心小队参与时，可以用找公倍数时间的方式来同频小队间的交互。

比如渠道侧还是2周一个迭代，但是第2个迭代中会安排和核心侧的联调以及上线。另外一种情况是，如果两个小队交互耦合太频繁了，需要考虑初期小队划分是否合理，有无重新划分小队的必要。

进行小队划分后，各小队自行管理，纵向来看，会有重复造轮子的风险

多个小队上面有部落这一层的管理，而部落中有架构师的角色，去把控重复造轮子的情况。小队间若有资源需要调配时，也有部落长来做统一的调度。

小队组建以后是不是就一直存在，不会变化

由于某一些小队可能是因为依据业务领域进行划分的，而在一段时间以后，此业务领域的需求有可能消减到非常低的程度，此类小队可以考虑在恰当的时候与其它的小队进行合并。

因此，部落中的小队也是会进行动态的调整，并不是完全不变，同样符合Bruce Tuckman的团队发展阶段模型，小队也会有组建期、激荡期、规范期、执行期和休整期。

5

长沙银行小队划分案例

初始：小队独立完成需求交付，产研测专职划入

在2019年推行规模化敏捷之初，长沙银行在科技侧推行面向业务的虚拟研发部落制架构，将千名科技人员划入了六大部落，并设立部落长，小队长对需求交付端到端负责。

图 / 转型初期长沙银行部落小队

这一过程中，长沙银行的要求是任何人只允许对应一个小队，一个部落，不允许跨部落，跨小队。

在当时，长沙银行每个小队约 10 人，产品、开发、测试均专职进入小队，保证小队成员具备各样的能力，能完成独立的需求交付。

与部落相比，小队可能负责一块更小的业务，如信用卡部落中设「卡产品小队」，即上文我们提到的业务小队；也可能负责几个系统，如分成前端小队或后端小队。即系统小队。

长沙银行部落小队的建立打下了研发组织精细化管理的骨架，需求任务分解体系、敏捷活动、研发度量体系等，均得以依托科学划分的部落小队得以顺利落地。

例如，长沙银行的三层需求任务分解体系，系统功能拆到 10 人天以内（单系统、可反馈），且明确主办部落和主办小队，个人任务拆到 1-3 人天左右。在小队站会同步时，小队长根据成员报出的风险与进度，反推到需求都有明确的跟进处理事项与优先级。

小队既是独立的价值交付团队，也是效能分析单元。对于上文提到的小队考核问题，长沙银行依托Adapt框架多快好赞度量体系，在长沙银行部落级、小队级建立起了研发效能度量体系。

演进：按新策略升级小队划分

初始的部落小队划分，是针对转型初期问题进行的设计。在长沙银行数字化转型进入规模推广阶段后，情况已大为不同。

因此，长沙银行基于平台业务分离、系统归属调整、小队内嵌、跨部落需求协作四项策略，重新优化部落小队结构，将多个研发团队分拆，减少跨部落耦合，缩减小队人数规模，进一步精细化管理 。

图 / 长沙银行优化调整后的部落小队结构

例如，长沙银行根据在上一阶段统计的系统工时反推系统人数，通过各系统在一定周期内的工时以及周期内的工作时间，计算出所需资源与岗位，进行各小队的资源划分调整。

我们曾撰文全面复盘过长沙银行3年的研发数字化转型历程，感兴趣的读者，可从文末延伸阅读部分，查看详细复盘。

福利时间

在划分小队前，对组织现有状况进行摸底是一个非常重要的步骤。摸底应从哪些维度进行？对哪些人进行访谈？收集哪些数据？

我们为大家准备了一份Agilean咨询团队使用的部落小队划分摸底信息模板，关注本公众号，回复“小队摸底”即可获取。

本文作者：

程萃(江湖绰号：CC)，Agilean资深顾问，精益敏捷转型专家。四川大学软件工程硕士，16余年软件和咨询行业经验，银行、软件开发企业、教育等行业从事过咨询和培训服务，曾深度服务于平安银行，建信金科等大型金融组织，帮助组织进行组织级的流程改进，部门级的技术、业务、组织协同的敏捷转型。

延伸阅读

01

长沙银行3年数字化研发管理转型复盘

02

宁波银行规模化敏捷试点案例

03

金融组织规模化敏捷速赢：部落制

04

Adapt规模化敏捷框架