前言

[现代]组织设计……是基于用户的协作设计。

——Naomi Stanford，摘自Guide to Organization Design

团队总有忙不完的事情，但如果将团队和业务关联，那么它就成了持续不断交付价值的最佳选择。理想情况下，团队应该长期存在、自我管理并拥有充满热情的成员。但实际上，团队并非孤立存在的，团队需要明白什么时候、如何跟其他人产生交互。而这些交互方式也会随着时间不断演进，从而支持产品和技术在整个生命周期不同阶段的探索和运转。简而言之，组织不仅要努力做到团队自治，还要不断地思考和与时俱进，以便快速地向客户交付价值。

本书提供了一种实用的、分步的、适应性的组织设计模型，我们在不同成熟度的公司业务中都曾实践和观察过这种模型，团队拓扑由此而来。

然而，团队拓扑并非成功构建和运行软件系统的通用模式。即便有些团队的动态组织形式和本书描述和推荐的差异巨大，也并不妨碍他们取得巨大的成功（特别是在那些拥有优秀文化和最佳实践的组织中）。

团队拓扑希望提供一种清晰明了的模式，以满足不同团队和组织的参考和解释的需要，而不是指导大家应该如何操作。我们愿意将团队拓扑看作管弦乐队或大型乐团中的一系列音乐篇章，而不是一个顶级爵士乐小号手的旋律。印刷出来的乐谱有助于大型乐团获得成功，但却无法覆盖一场成功表演的方方面面。大量的细节仍然有待于乐团根据不同的场合、地点，甚至不同的演奏者来即兴发挥。同样地，为了实现完美的软件交付，统一团队语言和共同协作方式所带来的价值是巨大的。

团队拓扑方法希望能够帮助那些纠结于寻找一种合适的方法来优化团队结构的组织，或者那些还没有意识到团队设计可以带给业务产出和实际软件系统良好影响的组织，从而帮助他们获得更加快速和持续的成功。

本书适用于那些关注软件系统开发和运维过程效率的公司领导层（包括CTO、CIO、CEO、CFO等）、经理、部门主管、软件和系统架构师，以及所有参与构建和运行软件系统的人，他们都想要让系统的交付和运行变得更加高效。

我们为什么要写这本书

2013年，为一家英国企业引入DevOps和持续交付的时候，Matthew在博文What Team Structure Is Right for DevOps to Flourish？中最早提出了DevOps拓扑模式。那个时候，他提供咨询服务的公司正在努力采用现代软件交付方法，而他创造的拓扑模式为该公司提供了一种与众不同的探索选项。

2015年，Manuel在伦敦举办的QCon软件开发大会上采访了Matthew，当时Matthew作为分享嘉宾介绍了康威定律和早期的DevOps拓扑模式。根据这次分享的内容，后来InfoQ平台发表了文章How Different Team Topologies In昀uence DevOps Culture？，并且该文章被翻译成多种语言。在此之后，Manuel进一步拓展了DevOps拓扑模式，并融合了来源于社区的贡献。

从此之后，DevOps拓扑模式开始广为流传，在演讲、文章和分享中不断地被引用。它们帮助了世界范围内不同规模和不同领域的组织，思考团队和团队交互如何影响组织文化和软件架构的关系。

随着时间的推移，我们意识到最初的DevOps拓扑提供了团队相互关系的静态视图，尽管这对于初期讨论有所帮助，但却难以扩展。通过我们和来自世界各地的培训和咨询机构合作发现，有些团队更适合独立和自治的形式，而另一些团队则通过紧密协作获得了更好的工作效果。于是，我们问自己这是为什么，并通过客户的反馈不断改进我们的想法。

最终，这些想法通过《高效能团队模式》一书呈现在你的面前，这是一种动态的、不断发展的组织设计方法，基于不同地域和行业的真实场景总结而来的。

如何使用这本书

《高效能团队模式》是一本工具书，我们的初心是提供交互性的内容，并在有限的篇幅中传递尽可能多的真知灼见。为了达到这个目标，我们进行了精心的设计来帮助你更好地浏览这本书。

首先，本书分为三个部分。

第Ⅰ部分探索了康威定律，阐述了组织交互方式是如何限制我们的系统设计的，以及应该如何顺势而为并将其转变成我们的优势。接下来，我们定义了什么是团队，并研究了那些影响团队协作效率的现实约束。

第Ⅱ部分研究了一组已经在业界被证明了的静态团队模式，以及如何结合康威定律和组织的实际情况来选择其中一种模式。这部分内容可以帮助你思考适合所在组织的团队拓扑，并且提供了如何将团队映射到系统中的指导原则，进一步思考了康威定律和基础团队拓扑。

最后，第Ⅲ部分研究了组织设计的进化方法，提供了强大的创新能力和快速交付能力来应对快速变化的外部环境。这部分内容解释了如何使用团队拓扑方法来建立一个对市场和用户需求具有敏感度的组织，并提供了相关的人员招聘和技能方面的指导。

每个部分在最开始汇总了所属章节的核心观点。图示和编号贯穿章节始终，这些是你需要了解和掌握的关键信息。我们还提供了一些简单易懂的场景、案例学习和针对不同场景的建议。

最后，在本书的配图中，你可以发现各种形状、颜色和模式，它们在本书中拥有一致的含义，说明如图0.1所示。

为了全面了解这些团队类型和交互模式，你应该通读本书，因为本书的主题是随章节层层递进的。不过，我们在编写内容的时候也尽量保证了每一章节的独立性。

为了实现这个目标，针对典型场景，我们提供了一些推荐的阅读方法。

· 若希望了解不同的团队类型，以及哪种类型最高效，请查看第1章（概览）、第4章（静态拓扑）和第5章（基本拓扑）。

· 若希望解耦一个巨大的单体软件系统，请查看第6章（边界）和第3章（团队）。

· 若希望改进软件系统架构，请查看第2章（康威定律）、第4章（静态拓扑）和第6章（边界）。

· 若希望提升软件开发团队的效率，请查看第3章（团队）、第6章（边界）和第5章（基本拓扑）。

· 若希望提升团队的士气和效率，请查看第3章（团队）和第5章（基本拓扑）。

· 若希望了解在哪些方面投入可以实现预期的增长，请查看第1章（概览）和第5章（基本拓扑）。

· 若希望了解如何持续改进团队拓扑以适应业务变化的需求，请查看

第7章（动态方面）和第8章（拓扑改进和组织意识）。

影响本书的关键因素

除我们自身的经验外，本书还受到了以下几个相关方法和思维方式的强烈影响。首先，我们假设一个组织是一个社会技术系统或一个生态系统，这个系统由个体和团队之间的交互塑造而成。也就是说，一个组织应该是人和技术共同作用的结果。在这方面，本书和以下领域不谋而合：控制论[特别是将组织视为一个“感知系统”，这个理论最早可以追溯到1948年Norbert Wiener首次出版的《控制论：或关于在动物和机器中控制和通信的科学》（Cybernetics：Or Control and Communication in the Animal and the Machine）一书]、系统思考（尤其是戴明博士的杰出工作）、Cynefin框架等用于访问复杂系统的方法论（Dave Snowden和Mary Boone在2007年Harvard Business Review上发表了论文A Leader's Framework for Decision Making）和适应性结构理论（Gerardine DeSanctis和MarshallScott Poole在Organization Science上发表了文章Capturing the Complexity in Advanced Technology Use：Adaptive Structuration Theory。他们在其中强调了技术影响力并不是恒定的，而是取决于团队和组织如何看待这项技术）。

其次，我们假设“团队”会根据个体的集合和团队在发展运行中得到的培养和支持程度的不同而不同。在这个方面，我的想法来源于Bruce Tuckman（他在1965年发表的论文Developmental Sequence in Small Groups中提出了四个阶段：建模-构造、震荡、规范和表现），Russ Forrester和Allan Drexler（他们在1999年发表的论文A Model for Team-Based Organization Performance中提出了基于团队的组织绩效），Pamela Knight（她在2007年发表的论文Acquisition Community Team Dynamics：The Tuckman Model vs.the DAU Model中发现的证据表明，stroming贯穿于团队生命周期始终），Patrick Lencioni（在他那影响深远的书The Five Dysfunctions of a Team：A Leadership Fable中，他发现了常见的交互问题），以及类似的以团队为核心的理论和研究。

再次，我们假设康威定律（或是与它类似的定律）是软件产品形态的强大动力，组织能够正视这些定律并从中获益。在这个部分，我们借鉴了梅尔·康威、软件架构咨询师和团队组织设计奖得主Ruth Malan、ThoughtWorks技术总监和“逆康威定律”的支持者之一James Lewis，以及其他作者和实践者的作品和思想。

最后，我们借鉴了源自大规模开发和运行软件系统的成功实践，包括Adidas、Auto Trader、Ericsson、Netflix、Spotify、TransUnion等公司的实践。这些组织的规模和交付速度使他们有可能从组织结构和团队交互的变化中看到真正的收益，这个过程往往需要持续数月到数年之久。

当你浏览本书时，我们希望你可以获得一些启发，这本书可以改变你对团队、团队结构及团队功能方面的认知。