SE Radio 646: Matthew Skelton on Team Topologies
57:08 Share

Matthew Skelton joins host Giovanni Asproni to talk about team topologies—an approach to organizing teams for fast flow of value. The episode starts with a description of the underlying principles before exploring the approach in more detail. From there, they discuss when to consider implementing the approach; keys to a successful implementation; and some common mistakes to avoid. Brought to you by IEEE Computer Society and IEEE Software magazine.</context> <raw_text>0 这是软件工程广播，面向专业开发人员的播客，网址为se-radio.net。SE Radio由IEEE计算机协会和IEEE软件杂志提供支持。网址为computer.org/software。

欢迎收听软件工程广播。我是主持人Giovanni Asproni，今天我将与Matthew Skelton讨论团队拓扑结构。Matthew是现代组织动态方面的领导者，专注于快速流动，利用团队拓扑结构和共同适应来支持组织向可持续快速价值流的转型。他是《团队拓扑结构》一书的合著者，也是Confluence和Team Topologies的首席执行官。

Matthew，欢迎来到软件工程广播节目。您还有什么需要补充的吗？听起来不错。很高兴来到这里。感谢您的邀请。很高兴再次与您交谈。是的。感谢您来到这里。现在，让我们从团队拓扑结构开始。所以第一个问题显然是，什么是团队拓扑结构？

我认为，团队拓扑结构是组织快速价值流的领先方法。团队中的团队，组织是重点。它起源于IT领域，但实际上适用于所有知识工作。到目前为止，这是我们发现的。我们稍后可以对此进行一些探讨。

但是，由于我们在《团队拓扑结构》一书中并没有真正深入研究具体的技术，因此事实证明，这种方法实际上非常适合思考各种知识工作，而不仅仅是软件交付和IT，还包括其他方面。因此，您可以将团队拓扑结构视为一种知识工作方法，我们利用技术来增强我们作为人类的能力，以真正有效地大规模地进行知识工作。

好的。现在，我知道该模型基于四种团队类型和三种交互模式。您可以简要地向我们描述一下吗？

是的，但我认为这不是最好的起点。这就是我们在书中谈论它的方式。但实际上，如果你从团队类型和交互模式开始，就会存在一个危险，那就是人们对团队拓扑结构的理解非常肤浅。他们只是从结构的角度来看待它，从更名一些团队的角度来看待它。因此，实际上重要的是要退一步，看看团队拓扑结构背后的原则。这些原则实际上是，我们试图达到一个能够快速将价值传递给用户的状态。是的。

我们将拥有多个独立的价值流，因为我们试图快速前进。因此，我们故意将这些流程解耦。我们不会试图将它们全部整合在一起并进行协调。因此，一些大型软件交付敏捷框架试图协调所有内容，但我们故意进行去协调以获得快速流动。我们需要关注团队规模，因为我们希望拥有高度信任，以便能够快速前进。因此，参与其中的团队规模相当小。

顺便说一下，我们将团队视为最小的交付单元。当我们考虑角色和职责时，我们不会深入到个人层面。我们需要考虑该团队的认知负荷或心理负荷，因为他们将构建和运行

一项服务，一种对用户有用的价值流。他们将持续地构建和运行该事物。为了能够处理这类事物的所有不同方面，您需要考虑构建和运行事物的各个方面，我们必须注意我们给人们施加的认知负荷，否则他们将无法正确地支持它。我们必须考虑

真正适合流动的系统和组织架构。如果我们要拥有多个快速的价值流，那么实际上只有少量架构能够很好地工作。我们必须注意所谓的康威定律，即组织沟通路径与由此产生的架构之间存在镜像关系。这已经……

这是一种趋势。这是一种正在发挥作用的力量，如果你愿意的话。我们可以选择反对它，但是如果我们反对这种所谓的同态力，就会更加困难。因此，我们必须注意，我们组织沟通路径的形状可能会影响我们最终构建的系统类型。我们需要记住，我们现在引入的任何数字技术都可能在五年、三年或十八个月内过时。

因此，我们思考引入和使用技术的方式需要预期它会在很短的时间内消失，这与之前的几十年相比相当极端。因此，您实际上建议团队也为此做好规划，例如，规划技术将发生变化的事实。

我们必须这样做，因为这就是组织陷入困境的地方。他们期望他们会引入新技术，他们会从中获得十年的使用寿命。情况不再是这样了。我们可能会引入一项技术来给我们带来18个月的优势，然后在18个月之后，这项技术实际上可能会开始成为一种阻力。我们需要预期用我们刚刚从云提供商那里获得的东西来替换这项技术。

因此，团队支持提供了基本的思维方式和动态，使我们能够在技术快速变化的情况下实现真正的业务敏捷性和组织敏捷性。并且在我们拥有可以每天数百次交付软件更改的技术和实践的情况下。老实说，对于许多组织来说，能够做到这一点是基本要求，你知道，良好的版本控制，持续交付实践，敏捷实践，你

你知道，规模较小的团队等等。就像这些东西，正如你所知，已经被了解和实践了几十年，并非每个组织都是如此，但在许多组织中都是如此。如果我理解正确的话，这些原则和实践比团队有时关注的事情（例如团队类型和交互模式）更重要。我这样说对吗？

差不多，是的。我的意思是，就团队拓扑结构而言，我们稍后会深入探讨细节，但团队拓扑结构源于围绕大约2008年开始的DevOps运动的所有实践和认识，这实际上是由基础设施自动化、配置自动化和云的可用性引发的，这些大约在2006年、2007年和2008年出现，对吧？

因此，突然之间出现了新的实践。突然之间，IT基础设施不再是瓶颈。突然之间，我们有了持续交付等融合的实践，该书于2010年出版，新的工具使我们能够例如大规模地以相当高的保真度进行应用程序日志记录等等。在这个领域出现了一堆工具，这些工具突然为技术人员提供了更好的、更多样的快速选择。所以

因此，从某种意义上说，团队拓扑结构实际上是对核心DevOps原则的一种有见地的表达，而DevOps的真正含义是有效的开发和运营团队一起工作，而不仅仅是……

DevOps的缩小版本，有些人指的是，这仅仅是处理构建部署管道或处理Kubernetes基础设施等。这个版本是DevOps如今的样子。但十年前，它实际上意味着这种让IT交付真正有效运行的整体方法。

所以它源于所有这些东西。因此，团队支持在一个层面上实际上只是在实施一些约束后会得到的结果的自然表达。我们需要快速流动。我们需要考虑认知负荷。我们需要采用基于团队的方法。我们需要团队规模较小，以便我们能够高度信任并快速前进。我们需要考虑康威定律。我们需要一种语言来处理这些事情。我们需要确保……

我们定期检测组织中的改进机会，而不仅仅是拥有许多孤立的小团队等等。如果您采用所有这些约束并在现代软件和IT交付的背景下应用它们，您将获得类似于团队拓扑结构的结果。

就像它是一种自然现象，它并非凭空出现。它是实施这些操作约束的自然结果。因此，我们不仅仅是发明了很多东西。我们在团队技术中谈到的这些技术实际上已经被一些公司有效地使用了大约十年。但我们使用了特定的术语，我们对它进行了特定的诠释，如果你愿意的话，或者我们对……

基于子公司，更先进的公司（如Netflix和亚马逊AWS的一些团队）以及其他一些类似的地方已经发生的事情，我们提出了特定的观点。其中一些公司在书中有所提及。我们说，让我们尝试反向工程这里发生的事情。亚马逊为什么谈论两个披萨团队？发生了什么？听起来很有趣，对吧？两个披萨，哈哈，哈哈，哈哈，等等。披萨是什么尺寸？是意大利披萨还是美国披萨？所有这些东西，对吧？但是

显然，在下面有一些非常重要的东西。我们有效地反向工程的两个披萨团队下的东西是，你从一个相对较小的团队那里获得的信任。因此，您可以非常快速地进行操作，并且可以拥有自主权。将其与杰夫·贝佐斯在2001年或2002年左右提出的非常重要的设计原则相结合，他当时说，

每个接口都必须是可外部化的。换句话说，您构建的每种API或事物，都需要将其视为要公开到互联网，有效地公开给外部客户，

因为这为系统和组织本身提供了一种极其强大的扩展技术。因此，我们采用了这些东西，并尝试用一种独立于任何特定组织的语言来重新表达它，并将其转换成适合我们遇到的典型组织的形式。典型的银行、典型的零售商、典型的物流公司、典型的制药公司、典型的……

基本上任何类型的公司，制造商等等，典型的政府部门等等。我们试图找到一种易于理解、易于接受的语言。我们试图提出模式、术语和特别是图表样式。图表样式对我们来说非常重要，非常重要。我们试图以一种易于技术人员和非技术人员理解的方式将这些东西整合在一起。

在我的职业生涯中，我长期以来一直在做的一件事就是弥合差距。通常情况下，这是一种技术人员和非技术人员之间的鸿沟，解释这些东西是如何工作的以及为什么。这绝对是我们通过《团队拓扑结构》一书所看到的事情之一，非技术人员，他们可能是战略主管，可能是首席执行官，可能是首席运营官，他们可以阅读这本书并说，我明白了。它的解释方式并不屈尊俯就，不需要我过多地了解技术等等。

我现在可以问你一个问题吗？因为之前你说过，对于团队拓扑结构，你试图，你说，去同步主题。我使用的是正确的术语吗？我认为你说的是去同步而不是同步。现在我觉得这很有趣。就像，你这是什么意思？对于去同步，也许你可以给我们举一个你参与过的项目的真实例子？是的。所以……

有一种常识。我认为，人们和组织作为一个整体，都有自然倾向于想要尝试同步多个团队的工作。

出于某种原因。人们相信，为了在正确的时间获得正确的价值，需要同步这项工作等等。问题是同步无法扩展。你做的同步越多，问题就越严重。我们在大型组织中看到了这一点，他们有大型工作项目，并且有数百个团队都在……

进行某种工作。将所有这些工作同步在一起、整合在一起、进行规划并试图按时完成这项工作以供其他团队使用所付出的努力。然后那个团队在等待另一个团队，等等。如果你真的对这一点进行计算，组织仅仅因为团队互相等待而花费的资金每年都是数百万美元。这绝对是疯狂的。

然而，这是一种所谓的常识。实际上这并不是好主意。这只是存在的一种感觉，是一种被接受的智慧，如果你愿意的话。事实证明，还有另一种方法。

另一种方法是故意去同步。所以继续思考，例如限制同步单元中的团队数量或人员数量，并将其保持在极小的范围内。因此，您可能会将同步限制为两三个团队。就是这样。这就像，可能是八个人、十五个人或二十四个人，然后说，好吧，我们可以尝试在几个或三个团队之间进行同步，但是

但是比这大得多，让我们故意去同步它。让我们故意不去尝试将它整合在一起，并使用功能标志和其他一些现代技术，以便我们将某些东西交付到生产环境中

首先，然后在稍后的某个时间点，其他一些东西会进入生产环境。然后也许几周后，其他一些东西会到达生产环境。然后我们获得价值。但是通过故意去同步并使用这些技术，我们实际上会更快地获得价值，因为与我们尝试将所有内容同步在一起相比，该价值会在生产环境中更快地出现。你现在可以给我们举一个……

你参与过的特定系统或项目的真实例子，以便帮助我们的听众创建一些关于实际工作方式的心理模型。你知道，简短的，你不需要描述整个项目。

Netflix几十年来一直有效地这样运行。这就是整个亚马逊AWS的运行方式。在亚马逊AWS中，您实际上不允许坚持要求另一个团队在给定的时间范围内更改其API。这就是他们能够如此大规模扩展的方式。事实上，如果你看看亚马逊AWS的扩展方式

当他们增加一名员工时，他们实际上会从该新员工那里获得超过一名员工的价值，这取决于扩展方式。而大多数组织在增加一名新员工时，他们从该员工那里获得的员工价值大约为0.85或更低，因为大多数组织的运作方式与之不同。因此，最好的例子已经来自正在进行此类工作的组织。它们规模巨大。并且

它们正在交付大量的价值，但这对于那些不以这种方式工作的人来说似乎很神秘，因为这与直觉相悖。什么样的组织，你知道，这种团队拓扑结构方法适合，你知道，初创公司，小型项目，涉及多少团队的大型项目？你知道，有没有一个最佳点，以及在什么情况下你会推荐其他方法？

这是一个很好的问题。我认为最佳点实际上是一个相当大的点，如果你愿意的话，但这对于真正想要赋能员工、真正想要赋能团队、真正想要使组织成为一个更人性化和更有效的地方的组织至关重要。对于想要施加强烈控制、命令和控制工作方式的组织或领导者来说，它并不适合。

因此，如果您进行命令和控制，那么就进行命令和控制。告诉人们该做什么。接受您的组织将非常缓慢。接受它将非常烦人和痛苦，人们会想要离开，并接受该组织可能会在某个时候失败。如果这就是您想做的，那就去做吧。但是，如果您真的想要一个真正有效、人性化、灵活并且具有超高绩效的组织……

并且从员工那里获得的价值比竞争对手多得多，那么像团队拓扑结构这样的方法实际上非常适合。那么它是否也适用于小型初创公司，你知道，总共只有五到十人的初创公司，因为它们才刚刚起步？它是否也适用于这些非常……

小型项目？如果您只有非常少的人，那么您可能不会真正看到康威定律的影响以及您在较大的组织规模之外会获得的一些扩展效应。所以

如果您只有，比如说，十个人，那么您可能可以不用如此强烈地定义边界，因为您仍在探索您正在做什么以及市场适应性等等。但是当您走向，我不知道，也许是十五个人，

您可能需要开始考虑在哪里设置一些认知负荷的边界、流程的边界、扩展的边界等等。因为如果您不这样做，那么您就有可能使事情变得太大，然后它实际上就变得太难管理了。因此，我们在很久以前，我认为是在2015年做过一些工作。

与一家从事视频广告的初创公司合作。所以你可能不信，但当时，这是在英国。当时，对不起，不是视频广告。是电视广告，电视广告。所以是英国的全国广播。当时，广播电视的广告……

制作完成，录制完成，刻录到DVD上，然后放在快递员，摩托车快递员身上，从伦敦的一端移动到另一端。这是最快的交付方式。这就是这家初创公司试图解决并成功解决的问题。后来被我记不清了，风险投资公司或其他什么公司收购了。因此，他们所做的是通过亚马逊AWS在云中完成所有这些工作。当时，2015年左右，他们是第一个……

针对全球，我认为，至少对于英国市场而言，基于云的广告审查和批准解决方案。当他们大约有15个人时，我们正在帮助他们。我们看到一些早期问题开始出现，因为他们并没有真正考虑认知负荷。他们并没有真正考虑技能差异等等。或者我们帮助他们有效地考虑这个问题。我们帮助他们思考，好吧，你看，对于这群人来说，实际上要考虑的事情太多了

对于这一个群体来说，你需要稍微区分一下技能，也许开始考虑提供我们最终称之为平台的东西，也许开始考虑一些更复杂的东西。例如，将对该复杂事物的认知负荷转移给一小部分人，以便其他人可以专注于最终客户体验等等。因此，我们开始尽早测试一些团队拓扑结构的想法。

但是正如我所说，当初创公司大约有15到20个人时，我们开始看到这些问题出现。有没有一些团队实际上团队拓扑结构并不一定适用？你知道，我说的是，一个小型团队试图在一个领域中发现某些东西的情况，你知道，充实他们不太确定自己在做什么的信息。所以有很多实验、原型设计、发现等等。

或者也许在一些公司中，现在有很多数据，有一些数据分析团队并不一定是功能团队或流对齐团队或复杂的子系统团队。基本上，我的意思是，有没有一些类型的团队实际上有点超出了团队拓扑结构框架，但它们需要与该框架内的团队进行交互？好问题。所以我们认为

也许研发，研究与开发，是一个团队方法可能不起作用的领域。但有人告诉我们我们错了。一家大型全球制药公司研发部门的全球主管告诉我们我们错了。他说，不，不，不，这些绝对适用于研发。所以我们说，好吧，好的。我们会相信你的话。因此，如果您仔细考虑一下，如果我们正在进行探索性研究，

如果我们正在进行分析，如果我们正在使用软件或软件支持的产品或服务或用户旅程等方面工作，我们有一个核心任务，或者理想情况下我们有一个核心任务。我们了解我们向谁交付价值。我们有一个价值消费者，有效地，是我们正在做的工作的消费者。并且有一些东西……

阻碍了价值交付。因此，我们对价值流，价值流有一种感觉。有时更容易感觉它是一个价值流，但即使在研究和开发中，即使在探索和随意尝试和实验中，我们仍然有一种感觉，即我们有一个价值流，因为价值在于我们正在学习的经验教训。

我们将该价值传递给某种利益相关者，他们正在为这项工作的完成和这些发现的发生付费。总有一些东西会妨碍工作。有一些东西会有效地造成工作摩擦。我们总是会遇到一些与团队中根本没有的专业领域相关的障碍。

这就是团队拓扑结构方法能够有效地应用于所有知识工作的原因。这是我们发现的。我们不是这样设计的，但实际上，当我们在书中写作并使用这些模式进行思考时，我们最终所做的是提供一个框架或一种方法来进行知识工作，来处理知识工作，我应该说，是技术辅助的知识工作。因此，团队拓扑结构实际上是一种高效的知识

快速进行技术辅助的知识工作的方法。也许您可以详细介绍一下结构、团队结构以及它们之间的沟通。因此，团队拓扑结构是，老实说，我们从一个巨大的假设开始。我已经提到了。这个巨大的假设是，组织了解其价值流。事实证明，这基本上大多是不正确的。大多数组织需要大量帮助才能了解其价值流，这很好。我们

我们在这里提供帮助。我在过去几年里建立的团队非常出色，我们一直在与许多组织进行许多有趣的工作。因此，假设我们达到了开始了解一些价值流的程度，至少。也许我们正在做一个试点项目，并且有，我不知道，五个或六个团队参与其中。因此，我们从这个想法开始：这是一个价值流。我们希望在这个价值流中拥有最快的价值流。为了做到这一点，

我们不希望从一个团队转移到另一个团队。我们不可能让一个团队做一些工作，然后转移到另一个团队做更多工作，然后转移到另一个团队。因为如果您研究过关于排队论和类似内容以及过程控制的任何内容，那么转移绝对会扼杀流程。那么我们如何才能达到为价值流的特定部分获得端到端价值流的地步呢？我们需要有一个团队拥有端到端

事物。我们不能从一个团队转移到另一个团队。这是我们的起点。这就是我们所说的流对齐团队。它们与价值流对齐。我们故意在那里选择了一个不太有见地的词。它有点中性。这就是为什么它被称为流对齐团队。它只是与价值流对齐。它不是产品团队。它不是功能团队。它不是其他任何类似的东西，因为这些词在不同的地方意味着所有不同的东西。至关重要的是，流对齐团队与价值流对齐，这在各种知识工作中也很方便。

这是一个起点。在这种情况下，团队最多约有八个人。对于大多数组织来说，这非常小。该组中的人数非常少。有趣的是，我上周在汉堡的一个会议上与某人交谈，他说，马修，八九个人对我来说是一个巨大的团队。我可以应付三到四个人。但无论如何，他生活在一个他真正习惯于非常非常小的团队的世界里。但无论如何……

最多大约八个人是因为这个人数，我们仍然获得了非常高的信任度，但我们拥有相当广泛的技能。因此，在这样的团队内部，我们拥有各种不同的技能，有时被称为跨职能，有时被称为多功能，多技能。我们故意引入不同的视角，以便我们可以快速前进。有时在这样的团队内部，我们可能有一位专家或合规专家或

例如，如果我们需要非常非常快地进行操作并了解做出决策以及构建和运行这些服务的背景，那么团队内部可能会有律师。

因此，该团队拥有它需要独立交付价值所需的一切，90% 的时间都是如此。这是我们的起点。理想情况下，我们将拥有多个具有这些流对齐团队的独立价值流，多个流对齐团队。如果我们可以用组织中的100个流对齐团队来提供100个不同的价值流，那么我们将从这里开始。如果我们可以做到这一点，那就太好了。但在现实中……

现实情况要复杂得多。实际上，如果你拿其中一个或几个精简团队，如果它们完全独立，那么随着时间的推移，它们将处理越来越多的东西。它们处理数据。它们处理安全问题。它们处理生成式 AI。它们处理基础设施。它们处理报告、审计，以及一大堆类似的事情。随着时间的推移，这些额外的事情与它们的核心理念并没有真正的关系。

如果他们的核心任务是专注于申请信用卡。

或者订购比萨饼，或者进行某种特定类型的药物研发，或者其他什么。无论该团队的任务是什么，无论他们应该交付的价值是什么，所有这些额外的事情都会有效地减缓他们的速度。它们开始成为一种干扰。它们开始消耗集体团队的认知能力。因此，我们需要一些方法来帮助鼓励精简团队持续快速地流动价值。

我们该如何做到这一点呢？一种方法是处理安全、审计、合规等一些与核心任务无关的方面。我们该如何做到这一点呢？有多种不同的方法。在《团队拓扑》一书中，我们讨论了三种不同类型的团队来帮助解决这个问题。所以第二种团队类型被称为赋能团队。赋能团队是一个专家团队，可以帮助提升精简团队的能力。

因此，这些可能是法律合规、生物科学研究或信用卡数据分析方面的专家。

法规或其他什么。这个专家团队可以介入并帮助精简团队一小段时间，也许几天，几周，直到精简团队的能力得到提升，直到精简团队理解如何更好地处理这个方面。然后他们可以将其融入到他们的日常流程中。赋能团队帮助精简团队获得他们所不具备的技能。没错。这是他们所做的事情之一。没错。这是他们所做的事情之一。赋能团队也可能，因为赋能团队也可能发现

20 个团队中有 17 个团队都存在同样的问题。他们都发现这个特定的技术非常难以使用，或者这个特定的法规方面非常难以处理，因为他们在组织中跨越多个不同的精简团队工作。因此，赋能团队在组织设计术语中充当边界跨越者。他们正在检测这些东西。他们就像一个跨越组织的感知机制。然后他们可以这样说，哦，

如果 20 个团队中有 17 个团队都存在同样的问题，也许我们需要做些什么。然后他们可以说，我们已经发现了一个机会，可以增强整个组织的能力，而不仅仅是反复解决同样的问题。我们该怎么办呢？我们可以进行全组织培训。我们可以购买一个新工具。如果需要，我们可以聘请一些人并将他们安排到每个团队中。我们不必这样做，但是

这可能是一个选择。或者我们可以构建或增强使用该特定技术或该特定事物的体验。我们该如何构建它呢？这就是另外两种类型的团队发挥作用的地方，其中一种被称为复杂子系统团队，我们在这里处理精简团队内部非常复杂的一部分工作。

它可能像一个算法一样，比如一个视频处理算法。它可能是生成式 AI 的数据准备。它可能是一些精简团队的人们无法承担这种认知负担的事情。我们将它放到一个复杂的子系统团队中，但是

我们将它放到这个单独的团队中的原因是因为我们正在处理认知负荷，以使精简团队能够更快地运行。你怎么决定，你知道，创建这种复杂的子系统团队？那么，精简团队中有哪些信号表明他们需要这种帮助呢？

这是一个好问题。因此，信号是精简团队基本上只是在努力处理该特定技术方面、该特定库或组件或算法或概念或其他任何东西。

我们已经尝试使用赋能团队来提升他们的技能。但这并没有奏效。这就像赋能团队真的无法提供所需的提升一样。我们已经让他们参加了培训。然而，精简团队只是说，看，这太复杂了。你需要那些拥有博士学位或在物理学、天体物理学或核物理学等方面具有研究背景的人。你需要让这些了解复杂数学的人参与进来。

他们真的理解复杂的数学。然后我们可以说，“哦，好吧，这是其中一件事。让我们把它作为一个单独的部分分解出来。”你有没有一个你参与过的真实情况的例子，来做出这种决定？是的。所以那个视频处理，之前提到的电视广告创业公司，他们的系统有一个特定的部分是视频编码。

他们实际上并没有编写算法，但它是运行在特定类型的操作系统等等上的软件本身。它管理起来相当笨拙，而且超出了团队中大多数人使用它的经验。因此，实际上更有意义的是将它的细节隐藏在我们现在称为复杂子系统的内部，以使其他人能够更好地专注于用户体验。

通过这样做，它实际上获得了更好的流程。他们可以更好地关注广告审批流程的体验细节，而不必考虑配置、运行和操作这个实际上是视频编码和解码的复杂子系统的细节。

所以这一切似乎也围绕着认知负荷的概念，你知道，人们必须知道的事情，他们并不一定知道所有的事情。你已经几次提到认知负荷了。所以它是团队拓扑中的一个相当核心的概念。但是我们如何在相对准确的方式下定义它呢？它是什么？

当我们谈论时，因为直觉上它似乎是，你知道，很多东西，让我们感到疲惫的事情。我不知道，但我们如何定义它？这是一个很好的观点。所以在《团队拓扑》一书中，我们使用了澳大利亚心理学家约翰·斯韦勒在 1988 年给出的定义。我认为可以公平地说，关于约翰·斯韦勒观点的适用性和有效性存在一些争论。

对认知负荷的看法，以及解释它的不同方式。事实上，我们一直在与劳拉·韦斯博士合作，她拥有组织心理学博士学位，她一直在帮助我们提出一种更全面的方法

来处理认知负荷，它考虑了工作场所周围的一堆其他额外维度，以及人们在工作场所中遇到的额外干扰等等。这已经被编码到一个现在已经走出测试版的工具中。它实际上可以用于一般发布，称为 TeamPritchard，有点像温度计，但我们正在测量

团队的温度。所以 TeamPritchard，他们去 teampritchard.com，你会找到它。我们已经成功地与一家欧洲银行和一家欧洲电信提供商一起运行了这个工具。我相信他们已经运行了将近一年了。是我的同事曼努埃尔·佩斯负责这方面的事情。

但是我们一直在与他们密切合作，并且在寻找检测高认知负荷、检测认知负荷随时间的变化方面取得了一些非常有用的成果，因为它可能会根据一年中的时间而变化。如果你像零售商一样有黑色星期五的销售等等，那么，你知道，认知负荷可能会增加，因为有很多其他的事情需要考虑等等。所以我们目前正在探索这一点，并正在探索。

在第二本主要的《团队拓扑》书中，我们现在已经开始计划，我们将对第一本书中提出的认知负荷意图进行更新的表达或更新的观点。我认为我们的意图绝对是正确的，就像真正考虑人类的体验一样

作为知识工作者的人类是什么样的，我认为将这一点纳入并对此持现实态度非常重要。因为说实话，如果我们让人们超负荷工作，他们就不可能做好工作。他们不可能有效地照顾这些系统。这根本没有任何意义。所以让我们对此持现实态度。显然，我们可以使用技术来消除一些无关的认知负荷，一些不太有趣的认知负荷。

酷。让我们使用生成式 AI。让我们使用云。让我们使用任何可以帮助解决这个问题的技术。酷。但这仅仅意味着那些人类现在可以专注于更以使命为中心的事情，这很棒，这就是你想要达到的目标。这个循环一直在变化，因为技术一直在变化。但我们总是试图达到一种平衡认知负荷与快速流动、流动量的位置。

如果我们过度压缩认知负荷，如果我们只让人们做少量的事情，那么切片可能太薄了。我们可能没有获得足够的价值。如果我们扩展价值堆栈，或者说认知负荷的量太多，那么人们可能会放慢速度。因此，认知负荷和快速流动之间始终存在着持续的张力，这很好，因为它会变得有趣。如何在两者之间取得正确的平衡？你如何衡量认知负荷？

来决定正确的平衡是什么。你如何做到这一点呢？那么，TeamPitcher 工具是我们衡量认知负荷的方法。它基本上包含许多不同的变量。它需要有效地持续进行。我认为可能会出现，好吧，我们已经开始看到一些工具的出现，这些工具

通过查看 Slack 中的消息或聊天，例如，通过查看代码复杂性或其他代码复杂性度量等内容，并将其映射到团队，从而自动检测认知负荷的某些方面，而不是所有方面。所以有一些像 CodeScene 这样的工具参与其中，这太棒了。

以及其他此类工具，它们使用遥测和组织信号来为我们提供一些线索，了解认知负荷可能高于其他地方的位置。这只是帮助我们查明并开始调查。FRANCESC CAMPOY：好的，这很有趣。所以它是一种查看各个方面的方法，包括

代码库中的技术方面，形状和非技术方面，就人员互动而言，他们在消息中所说的内容，在 Slack 上所说的内容，以及他们谈论的内容以及他们可能正在努力解决的事情，并以某种方式提出一种衡量方法来决定这个团队实际上需要帮助。

有一些工具可以做到这一点。我们实际上正在与这个领域的一家有趣的初创公司合作，该公司正在使用生成式 AI 来大规模进行情感分析。我们正在与他们合作，看看如何将其纳入我们的咨询服务中。但这只是一个信号。工具是其中一个重要部分。

但我们还需要关注心理安全和组织文化，使人们能够大胆地说出来。因为如果人们害怕，任何工具都无法真正提供帮助。我们需要处于一种人们能够被赋权并感到足够安全以能够说出来的情况，看，

那件事简直是一场噩梦。我们根本无法处理它。我们需要就此进行一次对话。我们需要改进使用该事物的用户体验。他们需要知道，他们不会因为提出这个问题而被斥责。这就是我之前所说的，TeamPritchard 绝对适合那些真正想要赋能员工的组织，但不适合领导者或管理者、高管真正想要施加命令和控制的情况。绝对要说清楚。它需要……

这些关于运行组织的生成式方法需要从心理安全的基础开始，才能使人们能够有效地运作。我们可能应该提到书中第四种类型的团队。在书中，我们实际上称之为平台团队。这实际上是错误的。

这确实是书中唯一一个错误。你们会出版一本勘误表来更正吗？我们可能会这样做。我们可能会这样做。它应该真正地说平台分组，因为它不是一种单独的团队类型。啊，这很有趣。你能详细说明一下吗？你这是什么意思？在我们看来，一个团队最多由大约八个人组成。所以非常高的信任度和多种不同的技能等等。而团队

平台概念实际上更像是一个团队的组合。我们期望在一个平台内，在一个平台边界内看到多个不同类型的团队在一个大型组织中。我的意思是，如果是一个只有 15、20 个人的小型组织，那么你可能只有一个平台团队。但是一旦你超过，我不知道，30 个人，那么你将拥有多个在给定平台内运作的不同团队。

平台。让我看看我是否正确理解了这一点。所以这就像我们可以考虑一些团队，它们可能正在处理一些，我不知道，在一些 AWS 东西之上创建一些抽象，我不知道，以特定方式配置数据库。所以当团队需要它时，他们已经完成了所有事情。但是然后我们可以考虑，我不知道，一个安全团队，那些在安全方面是专家的人，做一些需要不同技能的事情，仍然是平台级别，但是一种不同的特殊技能。是的。

以及类似的事情，或者我错过了什么？是的，但说实话，很多组织谈论，很多 IT 部门和使用 Interpol 的部门谈论像云平台这样的东西，这很好。所以这是……

该组提供了围绕云使用的抽象和简化。通常，在大多数企业内部，你有多个不同的云提供商，只是技术提供商。因此，你需要某种简化和抽象。但在内部，你有多个不同的团队在处理不同的事情。价值流是什么？不同工作的价值消费者是谁？这不仅仅是关于技术的一团糟。如果你基本上需要查看该组提供的价值，

人们正在提供什么，以及我们向谁提供？我们将其提供给其他内部团队。好的，很好。我了解他们的需求。

用户体验或有时称为开发者体验是什么？路线图是什么？这一切如何协同工作？你将如何制定下一步计划？这只是产品管理。我不知道是否正确，但这听起来像，你知道，一直都是流对齐的团队。没错。因为那里有一种模式，平台分组实际上也是一些流对齐的团队，在这种情况下，需要交付价值的客户实际上是

提供价值给最终客户的精简团队。没错。没错。这就像著名的特里·普拉切特的名言，对吧？乌龟一直到最后。是的，这似乎与此类似。要么是精简团队一直到最后，要么你可以认为是平台或平台分组一直到最后，因为……

在这个内部平台分组之下，将会有一个平台，就像云提供商或其他某种类型的技术提供商。在里面也有同样的模式。显然，如果你放大 AWS、谷歌或微软，猜猜看？你会看到一些专注于特定价值流的团队，称它们为精简团队，他们也在忙着做一些事情。

它一直持续到操作系统。你有一些团队在处理 Red Hat Linux 或 Windows 或其他任何东西的不同方面，等等。一直到嵌入式软件。你有一些团队在里面处理不同的价值流。所以这是一种非常分形的、自相似的分形方法。你可以放大，缩小，这真的很好。

因为它非常适合 Wardley 映射，比如战略意识和核心域图表以及域驱动设计等方法，因为你从 DDD 中获得了良好的边界上下文。所以我们可以将边界上下文应用于平台分组内部，但我们并不总是想考虑所有这些上下文。所以我们可以缩小并只考虑位于该平台分组之外的上下文。因此，它确实有助于在整个组织中进行导航，因为我们可以有效地使用这些技术

我们可以将相同的技术应用于整个知识工作组织。我明白了。在我们开始讨论如何开始使用团队拓扑之前，还有一个问题，假设在一个组织中，人们想要实施它们，他们应该如何开始。但在那之前，现在有了团队拓扑，你今天也提到了这一点，它强调快速流动，我认为这在某种意义上看起来像生产力。但是

这如何影响系统的其他质量，代码的质量和性能，以及其他任何东西？我的意思是，这种快速流动是否会以牺牲其他系统质量为代价，或者可能不会？

让我讲一个故事。有可能将快速流动的事情推向极端，并过度关注，真正专注于小型团队或小型部门内部的个体快速价值流动，而没有协调这些事情，但是

但至关重要的是，它们之间没有关联。几年前，我们实际上与一个组织合作进行了一些工作，他们非常了解他们的价值流和客户是谁。他们已经到位了平台。他们已经到位了基于团队拓扑或受其影响的赋能团队。

但他们有一些奇怪的激励措施。这是关于，我不知道为什么这些东西会存在。但无论如何，你有一个开发经理对他们的团队说，不要与你旁边的其他团队的人交谈。不要与那边的团队的人交谈。你的时间是我的时间。它很宝贵。我希望你专注于这个产品。所以他们最终得到了，这太疯狂了。这完全是疯狂的。他们实际上有，无论是什么，70 个人。

团队，但他们完全独立。他们就像小型机构一样运作，就像组织内部的 80 个小型数字机构一样。但他们没有互相交流，他们没有分享任何东西，等等。这是一个例子，这种方法朝着我们没有预料到的方向发展，而且我们永远不会推荐。

实际上，这种方法反映在过去五年中我们看到的一些对团队拓扑的批评中。人们说这会导致价值碎片化等等。是的，当然，如果你将这一点推向极端，并且不考虑组织文化和学习方面以及这些事情，那么当然，你最终会得到一些看起来非常奇怪的东西。

好的，在讨论如何实施团队拓扑之前，我想看看我是否理解了一些东西。因为一开始，当我问到团队类型和沟通互动模式时，

你说，这不是一个好的起点，因为这似乎是每个人都关注的地方。然后你转向了原则。那么你现在所说的就是你不想从团队结构、互动模式的特定元素开始，而是强调原则的原因之一吗？这只是为了帮助人们避免过度关注机制，而没有真正理解根本原因。没错。

团队类型看起来很容易。我们将直接复制粘贴它们，而无需考虑这样做的原因。原因非常重要。就像我们为什么创建平台分组的原因，或者我们为什么创建复杂子系统团队的原因等等。所有这些都是由流动和认知负荷驱动的。它以非常具体的方式驱动。它不仅仅是，我们已经看到一些例子，人力资源部门或人员部门已经使用这些类型的团队设计了组织，而没有意识到认知负荷或流动或价值流的概念。那是，

你知道，充其量是错误的，最坏的情况实际上是对组织有害的，因为你的边界位置不对，好的，现在让我们谈谈，你知道如何开始，让我们假设我们有一个组织，他们想要，让我们说改进他们的团队结构以及他们交付价值的方式，他们正在研究团队拓扑，是的

他们应该如何开始？因为我在书中也看到，你指出，处于不同技术和文化成熟度阶段的组织会发现不同的团队结构是有效的。是的。那么组织应该如何开始呢？也许你也可以告诉我们他们如何找到他们在组织成熟度方面的立场。所以……

约翰·斯马特在《更快、更安全、更快乐》一书中使用了一个很好的短语。《更快、更安全、更快乐》这本书是在《团队拓扑》之后一年出版的。顺便说一下，由同一出版商 ITV Evolution 出版，这是一个令人惊叹的出版社，很高兴成为这个大家庭的一员。ITV Evolution 的几乎任何一本书都是我个人购买和阅读的书，而且我基本上也推荐其他人这样做。所以约翰·斯马特在《更快、更安全、更快乐》中谈到了大象薄片。那么你如何吃掉一头大象呢？你把它切成非常非常薄的片。是的。

所以你将如何在这些方法中开始，我们正在谈论端到端的价值交付。所以我们开始的地方是找到一个我们可以立即使用的端到端价值流。基本上，这就是我们的起点。所以它可能被称为试点项目。它可能被称为

希望不是项目这个词，而是试点。我们将用一个特定领域来试点这个项目。例如，我们目前正在一家欧洲银行做一些工作。这是一家较小的欧洲银行，这实际上非常方便，因为更容易完成事情。它们没有那么大。

并且假设有机会通过使其变得非常非常容易，不仅仅是容易，而且是申请贷款或申请抵押贷款等非常好的体验来区分该银行在市场上的产品。并且……

我们说，好吧，这实际上是一种非常有用的端到端价值流。在接下来的 18 个月或更长时间内，将会有持续的差异化，持续的工作来改善这种体验，对吧？所以实际上……

我们有一个明确的价值客户，那就是想要贷款的人。我们很好地理解他们的需求，或者我们可以做一些工作来了解他们的需求以及我们从他们那里需要什么。我们可以召集一个精简团队。假设是八个人可以处理这件事。无论如何，这就是我们将要开始的地方。也许最终是几个团队或三个团队或其他什么。但首先，让我们假设只有一个团队。只需要一个八人团队需要什么？我们将使用更容易使用的特定技术。

这样我们就可以将其保持在一个团队中。所以我们可能会使用低代码，或者我们可能会使用更适合真正专注于申请贷款用户体验方面的创新的特定语言。然后我们说，好的，

这很好。安全、云基础设施、数据以及其他许多事情呢？为了使精简团队能够完成其工作，我们需要哪些最低限度的条件？让我们把它计算出来。让我们从让该团队到位开始倒推。他们还需要什么？我们可以随着时间的推移来探索它。但是当他们在处理这些事情时，当他们建立了他们的部署管道时，当他们建立了他们的云基础设施时，我们正在寻找

是什么减缓了他们的速度？是什么让他们把时间从专注于申请贷款的端到端价值交付中转移开了？我们说，好的，看起来云基础设施的这个方面正在造成问题。这真的在减缓事情的进展。我们能否找到一个合理的边界，

并从我们在团队拓扑术语中将要称之为平台或平台分组的地方提供一些服务。我们只在这些其他结构中投入资源来支持价值的流动，从而减少认知负荷。我们使用该试点来探索我们正在使用的语言，来探索不同的团队类型，来探索当我们引入赋能团队时、当赋能团队脱离并前往其他地方时的不同动态。

探索我们如何谈论我们获得的价值，我们如何谈论以这种方式工作，我们如何进行展示，我们如何做一大堆其他事情。我们使用该试点来学习

我们将如何做到这一点，我们需要什么样的东西，以及什么样的，体验是什么等等。然后我们找到另一个机会来做这件事。也许这次不是申请贷款。也许这次是不同的东西。所以它真的是一次做一件事情，并以这种方式防御你的大象薄片。没错。所以随着时间的推移，基本上是薄片，边学边做，并故意在整个组织中分享这些学习成果，从而积累越来越多的薄片。随着时间的推移，

创造一些友好的 FOMO，友好的错失恐惧，基本上是参与。这不是关于恐惧，而是关于，哦，这看起来真的很酷。我想参与其中。需要什么？并随着时间的推移建立动力和兴奋，但至关重要的是要确保我们正在学习。一些公关来吸引其他人关注这种方法。

好奇心。是的，好奇心。对错过的东西感到好奇。那是什么？对……感到好奇。就是这样。我们希望人们对正在发生的事情感到好奇和兴趣，并尝试看到价值。但至关重要的是，从一开始就达到最终状态。几年前，我在英国政府做了一些工作，一些供应商在那里工作多年，但他们仍然没有将任何东西部署到生产环境中。

他们已经在那里工作了，我认为是三四年了。在那段时间里，没有一行代码被部署到生产环境中。这就是需要开始的地方。第一天，你构建你的部署管道。它进入生产环境。你部署一个文本文件，然后你说，好吧，让我们倒着来。让我们把审计跟踪放在适当的位置。让我们把日志记录放在适当的位置。让我们把批准门放在适当的位置，这样即使只是一个文本文件，也能让这些事情发生。因为一旦我们对我们将如何做到这一点有了所有的信任和认识，

那么我们可以非常非常快地进行。我可以想象你所在的团队工作了三四年没有部署任何东西的情况。然后你去那里部署一些东西，无论是什么。动力开始增强，因为，哦，最终，我们实际上正在取得一些成就。但我们尝试从第一天就开始这样做。就像绝对一样，就像我们做必要的事情一样。我的意思是，这部分是我的公司所做的工作。

我们与真实的人一起工作，引导人们完成它，直到我们能够在这里安装这个庞大的补丁，因为我们已经进行了先锋工作。我们已经解决了围绕技术、部署管道、批准门、授权、安全合规性等所有这些难题，以便我们能够从第一天开始就实现端到端的部署。然后随着时间的推移，我们将构建应用程序的功能。

是的，我们可能会故意有效地将应用程序隐藏在外部世界之外，但我们正在尽可能接近第一天，理想情况下从第一天开始进行完整的端到端部署。然后以这种方式工作就会让利益相关者大开眼界，因为他们可以说，哇，

这里的交付速度真是令人难以置信。我们已经设法把这个东西弄出来了，而且它是符合规定的，我们还有它的审计跟踪。审计员对此很满意。为什么我们不以这种方式处理所有事情呢？团队在实施团队拓扑方法时会遇到哪些常见的挑战或陷阱？你一次又一次看到的那些事情，你知道，常见的问题。

首先，如果你仔细想想，一个教师团体基本上是对行业现状的一种有见地的版本，是围绕DevOps、云和这些实践的集体智慧。它是原始敏捷软件交付的延伸。但显然，当最初的敏捷宣言被创建时，根本没有云计算这样的东西。你无法每天多次向全球受众交付。那根本不是一回事。最初的敏捷宣言完全围绕着桌面软件等等。

虽然敏捷实践是必不可少的，但如果你喜欢的话，它们不足以满足现代软件交付的需求。所以是的，所以从一个层面上来说，团队支持不一定是特殊的事情。它与

过去大约20年来行业周围的集体智慧并没有什么不同，它实际上是对它的一个有见地的版本，所以我的部分答案实际上是围绕着组织未能应用围绕软件工程的集体智慧的方式，所以这很常见，对任何地方都是一样的，对吧，他们组织不花时间去理解底层发生了什么，他们不明白到底是什么，即使你只是喜欢最初的敏捷实践，他们也不真正理解

在一些团队实践中真正发生了什么，在合奏编程中真正发生了什么，在回顾等方面真正发生了什么。其中一些事情只是变成了仪式，然后失去了它们所有的内在含义，因为组织没有花时间去融入对价值的真正认识。因此，它们最终变得毫无意义。这是我们在团队机构中看到的事情之一。我们已经看到组织……

对团队职责的理解非常肤浅。他们只关注四种团队类型和一些交互模式。他们并不真正理解交互模式。我们今天没有讨论过它们，但他们说，哦，我不太理解这些东西。这不是关于结构的。他们看到了14种类型，然后他们就说，好吧，就是这样。基本上，三个星期，我们就完成了。我们真的和北美的一家零售商一起参加了一个研讨会。首席执行官读过这本书。在研讨会的中间，我们看到，好吧，这听起来很棒。三个星期后我们就完成了。我们都笑了。

然后出现了一个非常尴尬的停顿，我们意识到他实际上是认真的，因为他真的认为这只是给一些团队改名，然后我们就完成了。他没有将它所暗示的巨大变化内化。这是典型的事情。我想改变一切，而实际上并没有改变任何实质性的东西。没有改变任何东西，正是如此。因为团队拓扑的含义，FastFlow的含义，我的意思是，最初敏捷的含义，但无论如何，是……

我们将所有东西重新定向到价值流方法，这包括架构、资金、流程，如果你在一个大型组织中工作，这还包括营销，

外部采购，当你从外部供应商采购软件时使用的采购边界需要与流程对齐。如果你不这样做，那么你就没有任何流程。所以，如果你想要一种基于流程的工作方式，这将非常有效且非常人性化，如果你到达那里，你必须改变很多东西。当然。

所以你必须改变很多东西，而不仅仅是团队的名字。很多团队的名字。我们应该加上一个健康警告。我们应该在团队制作的书上贴上警告，上面写着：警告，以这种方式工作的影响比你想象的要大得多。你有一个机会，因为你说你正在写下一本书，你应该这样做。也许在封面上。关于实施的最后一个问题。

所以，团队拓扑不应该是不变的。例如，组织会发展，需求会发展，也许，你知道，价值也会发展。可能会发生方向变化。那么，组织如何才能使团队与价值流和流程的变化保持一致呢？那么，组织如何才能做到这一点呢？

有一些非常好的技术。特别是，Heidi Helfand 的动态重组，它提供了重塑和改变团队构成的方式，使团队保持健康。

所以你不仅仅是从团队中抽出人然后把他们扔到另一个团队，或者在几周或几个月后就解散一个团队。有一种改变团队的方式，比大多数组织的实践要健康得多。这非常有用。我可以想象这些实践中有一个元素是某种

逐步地，也许是迭代地。你不会说，好吧，伙计们，从现在开始，这就是组织的新形状。就像，你知道，从一天到另一天突然改变一样。想象一下，这是你可以逐步完成的事情。没错。这正是团队交互模式存在的目的

定义的，例如协作、服务访问和促进。交互模式有效地设定了与另一个团队或另一组团队合作的感觉的期望。所以我们依靠组织中人们的情感方面来说，好吧，

设定这种期望，然后让人们能够检测到，说实话，感觉就像我们期望将这个东西作为服务从 API 中消费一样。但实际上，我们不得不一直通过电子邮件或消息与人们讨论这件事。感觉不太像服务。用它作为一个信号来说，好吧，服务边界曾经很好。

现在不行了。是的，我明白了。所以任何一种摩擦，对于某些人来说是不正常的，可能很难非常精确地定义它，但一些比它们应该更尴尬的事情是信号。它是一个让我们进行对话的信号。就像一个占位符一样。猜猜看？它就像一个对话的占位符，对吧？就是这样一种心态。我们正在寻找告诉我们让我们重新组合、重新思考这件事的事情。没有人责怪任何人。

18个月前我们制定的边界当时很好。技术已经发展了。领域已经发展了。法规已经发展了。我们需要改变责任所在的位置，以便我们有合理的认知负荷，并且有更好的流程。让我们来谈谈吧。好吧，让我们来谈谈吧。它摆脱了那种责备游戏、责备陷阱。是的，是的。好的，好的。

好的。非常感谢。我认为我们现在正在接近谈话的结尾。所以我想你帮助我们，你知道，实际上做得相当不错，我认为，介绍了团队拓扑。我认为我们的听众将会有一个，让我们说，一个更好的介绍，如果他们想使用这种方法，有很多事情需要考虑。还有什么你想要提到的吗？

所以只有几件事。我们有一个不断发展的全球团队拓扑合作伙伴计划，这在世界各地都被证明是越来越成功和有用的。如果你有兴趣加入，请告诉我们。对于组织和个人来说，都有机会成为团队拓扑倡导者。

如果你对之前提到的主动知识传播方面感兴趣，我们正在举办会议，吸引人们参与，并提高一致性，那么请联系我和我的公司 Confluence，我们也可以在这方面提供帮助。如果你想联系我，我的网址是 matthewskelton.com。这是找到我的最简单方法。我们会在本集的链接中添加一些信息。所以，谢谢你，马修，来参加节目。

这实际上是一种荣幸。我真的很享受这次谈话。这是 Giovanni Esproni 为软件工程广播。感谢收听。感谢收听 SE Radio，这是一个由 IEEE 软件杂志为您带来的教育节目。有关播客的更多信息，包括其他剧集，请访问我们的网站 se-radio.net。

要提供反馈，您可以在网站上对每集进行评论，或通过 LinkedIn、Facebook、Twitter 或我们的 Slack 频道 seradio.slack.com 联系我们。您也可以通过 [email protected] 向我们发送电子邮件。本剧集和所有其他 SE Radio 剧集均获得知识共享许可证 2.5 许可。感谢收听。