如果我们将团队类型的数量缩减为四类基本团队拓扑，这个问题就迎刃而解了。
· 流动式团队
· 赋能团队
· 复杂子系统团队
· 平台团队
只要使用得当，这四类团队拓扑能够满足构建和运行现代软件系统的需要。结合
有效的软件边界（第6章）和团队交互模式（第7章），这四类团队类型可以成为高效
组织设计的利器
1）流动式团队
流动式团队对应一条单一、有价值的工作流，这也许是一个产品、一项服务、一
组功能特性、一个用户故事或者一组用户画像。更进一步地，团队有能力做到快速、
安全和独立地构建和交付用户价值，而不需要移交给其他团队来完成部分工作
2） 赋能团队
赋能团队应该尽可能地不让自己变成知识的“象牙塔”，干涉其他团队的技术选
择，而是要帮助团队理解并遵循组织级的技术约束。这也被称为“服务式领导力”，但
其适用于团队交互而不是个人交互。赋能团队的使命是通过提升流动式团队的能力来
提高其自主性，所以需要聚焦于解决流动式团队遇到的问题，而非推广自己手中的解
决方案。如果赋能团队做得不错，那么他们帮助的团队应该能在几周或者几个月内独
立运转，而非永远依赖于自己。
一个高效能的赋能团队应该有哪些行为和产出呢？
· 赋能团队要主动了解流动式团队的需求，在深入协作时建立定期检查点和联合沟
通机制。
· 赋能团队要在他们的专业领域保持浪潮之巅，在流动式团队提出实际需求之前，
持续跟进新方法、工具和实践。在过去，这常常被视为架构师或者创新团队的使命，
但如果能通过赋能其他团队来达成这个目标就更好了。
· 赋能团队既要传播好消息（比如，“这里有一个新的UI自动化测试框架，可以将
我们的测试脚本代码减少50%”），也不能遮掩坏消息（比如，“当前我们广泛使用的
JavaScript框架已经不再被维护了”）。这样才能在合适的时候引入特定技术，并在合
适的时候舍弃它们。
· 有些时候，当流动式团队难以直接使用某些服务时，赋能团队应该充当内外部的
服务代理。
· 赋能团队不仅要促进自身团队内的学习，也要在流动式团队之间扮演组织内促进
共享必要知识的角色（这也是Tom DeMarco和Tim Lister提到的“关键学习能力”）。
3） 复杂子系统团队
复杂子系统团队负责构建和维护系统中严重依赖专业领域知识的子系统。相应
地，大多数团队成员都必须是这个领域的专家，这样才能理解和变更子系统。
设立该团队的目标是降低包含或使用复杂子系统的系统中各个流动式团队的认知
负荷。处理复杂和专业的工作需要具备特定能力的专家，他们通常很难培养或者寻
找。我们没法在每个使用复杂子系统的流动式团队中都配备相应的专家，这很难实
现，因为成本太高，并且与流动式团队的目标也不匹配。
下面是一些复杂子系统的例子：视频编码和解码、某种数学模型、实时交易冲突
解决算法、财务服务的业务报告系统、人脸识别引擎等。
一个高效能的复杂子系统团队应该有哪些行为和产出呢？
· 复杂子系统团队根据子系统当前的开发阶段来安排相应的工作：在早期的设计和
开发阶段，与流动式团队密切协作；在子系统趋于稳定的后期阶段，减少交互并重点
关注子系统接口、特性的演化和使用。
· 有复杂子系统团队协助时，该子系统的交付速度和质量都要明显高于仅由流动式
团队负责时的情况（在决定拆分前）。
· 复杂子系统团队需要根据使用这些复杂子系统的流动式团队的需求来合理地安排
优先级并完成交付。
4） 平台团队
正如我们看到的，平台团队的使命是为流动式团队提供底层内部服务，方便流动
式团队交付高级服务或功能，从而降低流动式团队的认知负荷。
一个高效能的平台团队应该有哪些行为和产出呢？
· 平台团队与流动式团队密切协作，理解流动式团队的需求。
· 平台团队依赖于快速原型技术，尽早引入流动式团队成员以获得快速反馈，哪些
有效而哪些无效。
· 平台团队需要重点关注服务的可用性和可靠性，并将平台视为一种产品，需要定
期回访用户以确认服务的可用性，以及服务是否依然满足用户需求。
· 平台团队自己也应该是他们所提供服务的用户（如果适用的话），同流动式团队
和赋能团队并肩战斗，可能的话，也应该依托于其他平台团队负责的下层平台。
· 平台团队应明白其提供的新的内部服务（如新技术）将像创新曲线那样被各个流
动式团队逐步引入，而不是一蹴而就的。
