团队拓扑和有效的软件交付

播客成绩单

Ashok Subramanian：

你好每一个人。欢迎收听Thoughtworks科技播客。188bet宝金博app下载我是阿肖克，你们的常客之一今天和我一起主持节目的是埃文。

Evan Bottcher:

嗨，我是来自澳大利亚墨尔本的埃文·博彻。我是澳大利亚Thoughtworks的工程主管。为了提供一点背景知识，几年前我写了一篇关于平台团队的文章，其中包含了平台团队的概念。我做了188bet宝金博app下载很多关于工程组织设计和如何撼动团队的咨询。这就是我今天的谈话内容。

Ashok Subramanian：

太棒了，对于我们今天讨论团队拓扑的两位嘉宾来说，这似乎是相当相关和切题的，而且谁比自己写书的人更适合做这件事。马特和曼纽尔，请向我们的客人介绍一下自己?对于我们的听众，对不起。

马修斯凯尔顿：

当然，嗨，马修·斯凯尔顿是《团队拓扑》一书的合著者。我和我的合著者也在这里。

曼努埃尔·派斯:

嗨,我是曼努埃尔。我就像Matthew说的，另一个合著者，我做的工作和Evan提到的相似，帮助组织理解他们的团队结构以及如何实现更快的流动。

Ashok Subramanian：

所以，也许我们从一些东西开始，给我们的听众，那些可能听说过团队拓扑学甚至可能略读过它的人，一个关于这本书的简要概述，以及最初是什么促成了它。

马修斯凯尔顿：

这是个好问题。那天我意识到，我们的书是…你可以把它看作是一篇长达215页的咆哮，反对现代世界中软件工程的大量错误。因为这源于我们与组织合作的经验看到了组织内部的挫折无论是在工程层面，经理层面，还是业务层面，都不是很好。我们自己也曾经历过很多痛苦我们在书中试图解决这些痛苦。这就是为什么这本书最终非常实用，很有主见，很有指导性，告诉我们应该如何安排事情，以便在当前环境下更有效地构建和运行软件系统。这就是我们写这本书的目的，我们认为，这类模式应该帮助组织在软件交付方面变得更有效。

曼努埃尔·派斯:

是的，这也是基于我们的经验。书中有不同的输入。主要是我们有经验的咨询，看到了不同组织在尝试采用DevOps、持续交付方面遇到的问题，但他们没有看到结果。再深入一点，你会发现他们经常有团队间的误解，缺乏沟通，这类人的问题我们知道是很难解决的。这不仅仅是，有了一个新的工具集，带来了一些好处。但是在一天结束的时候，如果团队不沟通或者过度沟通，这类问题就会出现。所以这本书帮助我们了解了一些我们认为有效的模式和不太有效的模式。幸运的是，很多组织已经把这看作是一种新的词汇，用来谈论团队，目的，以及如何发展他们之间的交互。

马修斯凯尔顿：

现在，有趣的是，曼努埃尔和我都有很多工作的经验，现在称为CI / CD。所以......这种软件交付世界的中心，这是文凭管道，显然是由JEZ谦逊和戴夫法利的伟大书籍所推广的，回到2010年。我们都做了很多工作围绕持续交付和思考组织如何设置。实际上，我的意思是，连续交付，概念绝对基础甚至很好，因为这本书最近发表了更多，我已经意识到了如何让这些概念嵌入那些概念。那种......使用部署管道在组织中实现最终价值流动的思想是......没有那个，那么我们不能有快速的流量变化。

团队拓扑中的很多东西，都不会发生因为我们需要扎实的工程实践。所以我们在这方面的经验。如果您喜欢组织的核心，部署管道级别，我认为它极大地影响了我们对组织的思考，使我们能够在软件领域快速地进行变更。

其他一些事情，一些对这本书的影响，我在2013年写过一篇博客文章，研究不同类型的组织，不同的团队责任界限。那时我们叫它DevOps。我的意思是，DevOps现在的意思有所不同，但在那时，DevOps是关于思考开发团队和运营团队之间的关系。

那个博客文章有很多牵引力，在图表中有很多兴趣。他们就像具有不同颜色的Venn图表，代表不同种类的团队。所以曼努埃尔和我那种转变为一个名为Devops Topologies的网站，它仍然存在全部和开源，创造性的共享。这甚至得到了进一步的牵引力，并帮助组织，包括Netflix和Conde Nast International，思考不同团队和边界之间的关系以及不同的动态基本上，不同的责任界限的不同权衡。这导致了我们更多的谈话，最终我们决定超越这个原始的Venn图，世界的静态视图，并包含许多其他维度，这实际上是康威的法律等重要的东西。因此，组织中的通信路径和可能的软件架构之间的社会技术镜像，通常是结果或系统架构，结果，以及团队认知负荷等事情，这是我们有效地种类或塑造的术语书。在团队级别应用内容负载是一个非常新的概念。

然后，确保这些组织是通过对团队类型的限制和团队之间的互动类型的限制来实现，这些约束最终是我们在复杂的自适应系统中启用约束。我们正在减少这个组织可以精确使用的自由度，以便我们有更好的能力倾听组织内发生的信号。所以，这就是我们最终结束的地方。这是一个可能的旅程，嗯，至少是想法，我猜，当然来自......受到连续送货书和一堆其他事情的启发

Evan Bottcher：

我不得不说，在Thoughtworks，在我们的188bet宝金博app下载咨询工作中，它实际上是非常有影响力的。关于有限数量的模式和语言模式的创造性限制非常非常强大。我们所做的工作,我知道我所做的,我们很多人的时候,我们拿起这本书已经说过,你有三个一半完成了幻灯片,我们与客户所做的描述这些模式在组织紧急处理。但你基本上是在做这项工作，以一种清晰的方式发表和解释这些，这非常非常有帮助。

其中一些与过去几年的趋势背道而驰长寿命的产品导向的团队，你的流导向的团队，引入了一些替代模式这些模式都是很好的开场白，实际上，它打破了人们的一些默认和一些功能障碍。我想知道有多少……当你把材料放在一起的时候，有多少是通过观察团队中现有的模式，又有多少是你认为这是一个推荐的前进方式的想法?

马修斯凯尔顿：

这是观察的结合，什么是有效的。一点创意。但也从一些原则开始，从三个基本原则开始。如果你想总结团队拓扑，它是为快速流程、快速反馈和团队认知负荷的限制而优化的。如果你从这三个原则开始，我的意思是，康威定律的东西是有用的，但在某些方面并不是它的核心。如果你寻找组织设计优化的快速流动变化的实时系统,快速反馈的实时系统,这样团队才能正确的认知负荷和限制的团队,那么你最终会与设计,与一组原则和实践,看起来像团队拓扑。这就是你会得到的结果。

你可能会有一些细微的不同。你可能有5种不同类型的团队，或者你可能有4种不同的互动模式，很好，但如果你从这些原则开始，那么我将很难看到你如何得到不同的东西。因为你想要避免快速流程的移交，你不想有很多等待人们去做不同的事情。你想要一个端到端的责任，这样你就能非常接近客户，不管客户是谁，但是你不能期望团队只承担越来越多的东西。所以你需要限制认知负荷。因此，你需要一个平台之类的东西。你可以用不同的说法来称呼它，但你必须从团队中拿走一些，以帮助他们专注于更相关的东西。实际上，我们从这些原则开始，然后观察不同的组织在做什么。

实际上，回顾一下我们最终所做的是一些组织正在做的逆向工程。所以亚马逊，AWS是一个经典的例子，不管它是不是真的，杰夫·贝佐斯在2002年的备忘录中说，每个团队都将通过清晰的API与其他团队沟通，并将其他团队视为外部团队。所有服务都将是可外部化的。就像两个披萨一样。很多人都忽略了两个披萨队的意义，这不是关于食物或其他什么。这是一种高度的信任，因此对变化有高度的环境意识，能够迅速做出改变，并使其走向正确。最重要的是，我们限制了团队的认知负荷。我们无法承受系统中越来越多的东西。因此，我们将不得不将我们的整个解决方案组合成更少的离散的，很好地解耦的离散服务，这是一种很好的软件工程实践。对吧? Good engineering practice in general.

所以我们有效地对已经存在的东西做了一些逆向工程。事实上，亚马逊正在发生什么。是的。两个披萨团队听起来都很可爱，但在它们的背后是构建可伸缩软件系统的基础——真正关键的原则。所以我们也试着从其他地方把它们拆出来，比如，看看Spotify在做什么，以及人们开始称之为Spotify模式背后的意图是什么。除了球队的名字和角色之类的东西，到底发生了什么?这就是我们试图捕捉在团队拓扑这种逆向工程的模式,似乎工作得很好,或似乎有一些值在一个特定的时间点,在某些情况下,试着找出他们试图解决什么问题或者他们试图解决什么,那些背后的原则,外部模式和逆向工程，然后用一种前瞻性的方式来描述。

曼努埃尔·派斯:

归根结底，正如Matthew前面提到的，团队拓扑真正关注的是，您是否希望您的组织能够更快地响应、更快地交付，以及拥有健康的、长期存在的、可持续的团队。所以有时人们问我们如果一个组织没有这些要求怎么办?这没关系，也许团队拓扑对他们来说不是理想的方法。我们只是看到，现在没有多少组织能够承受得起不走得太快，适应变化如此之快的情况。

但即使是团队拓扑学在最后也是一种权衡如果你想引入团队拓扑学的概念，约束条件，骑兵，以及理解为什么这些约束条件是有用的，这是你必须投入的一点努力，这样你就可以实现快速流程，特别是流对齐的团队。是的，这种长期存在的跨职能、负责端到端的团队是很难实现的，他们需要随着时间的推移而成长。我们又不是要…今天和明天创建一个新的模型，我们有高效率的团队。

事情不是这样的。你需要对这些团队进行投资。你需要考虑他们需要什么样的支持在平台支持团队方面，在工程实践方面以及资金实践方面，等等，这有点超出了团队拓扑的范围。但这必须是一项投资，才能与马修所说的理念和原则相一致。如果你想实现更快的心流，就必须能够快速适应并拥有健康的团队。这可能不是每个组织都想做的权衡，但我们并不是说团队拓扑的一切都很容易采用，并使事情变得更好，这是一个谬论，而不是因为谁写了Spotify的文章或类似的东西。他们只是在解释这种方式当时是如何帮助Spotify的。但当人副本,并试图复制的组织没有理解我们为什么要这样做,有什么不同和我们如何适应我们的需求,那么它会成为一个问题经常有很多货物崇拜和弹出和人们想要的关键字没有好处。

马修斯凯尔顿：

这就是我们想要避免这些特定角色的原因之一，有点像，我不知道，从scrum中，你得到了scrum master之类的角色。你可能有这些特殊的个体角色。我们在团队拓扑中避免了这一点，因为我们真的想避免另一种，我不知道，行业认证驱动，让人们跳上这个潮流，并说，“好吧，我已经通过了这个认证，因此，我们现在正式成为敏捷版本7了，”或者其他什么。所以我们非常小心地试图避免这种反模式，并试图强调组织需要内化原则，快速流程，快速反馈，限制团队的认知负荷。

一些其他原则包括高度信任,观察组的大小在组织和试图最大化的信任,因为如果我们有高度信任,我们可以更快的流动变化,因为我们至少没有不信任的人停止的事情或想批准或检查的事情。但回到关键的原则,我们希望有更多的机会,组织可以不断调整和发展而不是自锁上如果你有一个好的固定组像这样的团队,然后将解决你所有的问题。不管怎样，这就是我们要做的。

Evan Bottcher:

我认为这种转变，曼努埃尔，你在和那些试图采取一种方法的组织对话。我曾参与过一些组织，他们试图向产品对齐的、长寿的团队结构发展，但底层架构并不匹配。所以我想，当他们说，“不，但我们想要有独立自主的团队，有能力对客户的需求做出反应”时，他们会遇到认知上的不协调，但实际上，他们不需要对系统进行改变。我们几年前在科技雷达中创造了这个词，逆康威机动。对于许多组织来说，这是一个非常痛苦的过程，因为他们重新组合到一个新的结构中，为了创建新的结构，底层的架构不得不自我分裂。这需要时间，会带来很多痛苦，对一些组织来说风险很大。

不过的一件事情吸引我在团队拓扑模式是这一概念的复杂的子系统,这确实给了我们一种语言来描述的系统还没有安全采取改变或作为一个自助服务方式被放置成流线型的控制团队。所以他们可能需要一些不同的治疗。一个问题出现了，我想我最近看到了你的一个网络研讨会，谈到这个，马修，这个复杂的子系统团队，它和一个平台的区别或者它们之间是否随着时间的推移有一个演变。它们是否自然而然地属于一些更自助的平台?这很有趣。

马修斯凯尔顿：

所以这里的部分挑战是，我们正在看到基于现代软件的组织能力的根本转变，尤其是云软件，但我们可以说，受云启发的软件，像代码一样的基础设施，诸如此类。回顾20年前，改变你的业务运营方式或提供的服务类型需要一些时间。现在，特别是如果你提供的东西有在线数字元素的话，可能所有的东西都是…让我们说一下20年前的保险，有人可能会访问一个网站，但可能只是打电话或发邮件之类的。现在都是通过客户销售自助服务。他们可以登录。他们可以更改保险细节。他们可以要求新的报价。很多新的保险费的计算是自动或半自动完成的。这是数字启用。

我们并不是说每个组织都是软件公司。我认为这是误导。但是现在每个想要保持竞争力或差异化的组织都可以使用软件来做到这一点。所以我们能够更快地做出改变。这表明很多组织甚至不清楚他们的目的是什么。像团队拓扑这样的方法，像领域驱动设计这样的方法，像数据网格这样的方法，这些方法强调了许多组织在他们实际做什么和他们的目的是什么方面非常缺乏清晰的认识。所以很难与商业目的相一致也就不足为奇了因为根本就没有商业目的或者说商业目的很模糊，定义很不明确。

在过去，这并不少了一个问题，因为事情如此慢地移动。你有这些系统，我不知道，以某种方式拥有或管理，这需要大的变化，一个接一个地发生一个，然后多个不同的人协调变化，以便得到大门。现在，部分原因是技术，但部分原因是其他技术，我们能够更快地进行更改。因此，成功的组织是那些将其技术架构与业务变革流或所需的组织变革流对齐的组织。是的，团队拓扑等方法基本上在过去的组织商业实践和新技术的组织商业实践之间突出显示了这种不匹配。

曼努埃尔·派斯:

是的。而且你提到了逆康威机动或反向康威机动，即我认为，在很大程度上被詹姆斯刘易斯从思想家宣传的人们晋升。188bet宝金博app下载为了实际执行权，我认为有很多方面需要考虑。一个是我认为如果你不明白你的实际业务流是什么，那么马太福音才能才能达到什么，那么你也不会与那些价值流匹配，因为它是要成为的东西耦合，如果您想要解耦，您就没有很好地了解建筑服务是什么。然后还有其他层，即使是耦合，您甚至可以使用架构，甚至可以越来越多地解耦，但随后团队仍然依赖于彼此，因为它们共享基础架构或者它们共享工具，或者它们与组织中的某些过程互锁。因此，我们仍然没有获得自治和更多的独立团队，因为它。所以有几个层，但显然，与马修说的话，如果你没有关于你的业务流的清晰度，你甚至如何将系统架构或团队对齐这些流？

并回到您关于复杂子系统和平台的问题，因此我们实际上我们称之为复杂的子系统，因为我们希望避免复杂的术语，因为[听不清00:23:39]以及通常在您基本上紧急事物的情况下的事实和你无法真正控制的属性。但是，无论如何，对于一个复杂的子系统团队，起点是它是太多的认知负荷，它是一个简化的团队对系统的复杂部分负责。因此，这是一个起点，这意味着您可能只有一个复杂的子系统，该子系统只能被一个简化的团队使用，并且由于简化团队的认知负荷减少了仍然是有意义的。我们在演化方面看到的是复杂的子系统，它可能处于恒定的变化通量，但这些系统在某些时候，变化的节奏开始减速。随着技术的发展，在许多情况下，您可以看到更好的解决方案，更多的第三方解决方案。

例如，我们可以谈论我的系统使用面部识别子系统，这实际上是复杂的。你需要一个博士学位来研究它，但现在你有很好的解决方案。所以在某些时候，你可以期望将复杂的系统通过一些改变转变为一个平台服务，在那里你可能更多地依赖于第三方，或者它只是有一个非常缓慢的变化节奏。这并不能证明有一个团队围绕着它。如果我们有正确的文档支持，那么它就可以成为平台的一部分。事实上，我们希望一个复杂的子系统团队在向其他团队提供服务或子系统的方式上采取与平台团队非常相似的行为。

马修斯凯尔顿：

是的，我们没有把它放在书中，但我们已经实现了一个复杂的子系统就像一个迷你平台。很多行为都非常相似。我们不使用那种术语，但有效地表明你应该如何看待它。

曼努埃尔·派斯:

这是我们现在看到的挑战之一，Team topology已经发布了大约一年半，并且更多的组织正在采用它。我们看到一些组织认为他们需要比实际更复杂的子系统团队。我认为，这与这样一个事实有关，即这似乎更类似于传统的组件团队，当你着眼于快速流动时，通常会出现一些问题，当你有许多团队依赖于同一个组件团队时，会造成瓶颈。所以这是一个挑战，理解我们应该限制尽可能多的复杂子系统的数量，并试图在可能的时候将它们移到平台上。

Evan Bottcher:

是的，人们没有真正的限制，他们可以阅读一些见解，然后将自己的世界观应用到其中，然后说，“好的，是的，我们有1700个复杂的子系统，它们实际上只是组件团队，每个团队在整个组织的发布序列中工作。”

曼努埃尔·派斯:

是的。这又回到了我们之前讨论的内容，尝试着复制/粘贴这些模型，却没有真正了解基本原则和想法，以及我们为什么要采用这个模型。

Ashok Subramanian：

我认为作为复杂子系统的后续，我认为我们经常看到的一个挑战是…也许这也反映了马修和曼纽尔关于一个组织的目的的观点。很多时间,我想我们看到当你去试着找出“业务”业务显然在双引号,试图或实现你有时得到指向你需要去问团队管理系统X等等。

事实上，它几乎具有技术驱动或定义需要做什么的翻转。在这种情况下，系统往往变得相当大，或者它们几乎像是它们倾向于定义和控制组织内发生的事情。这些复杂的子系统的过渡，特别是在过渡到最终可能成为多个流线型团队的过渡中，你会建议人们考虑或注意什么？或者这种转变可能是什么样的？

马修斯凯尔顿：

这是个好问题。在我们写这本书之前，我们确实为一个组织做过一些工作，一个全球性的组织，但这个组织的总部在英国。曼努埃尔和我一直在努力让物资持续到位，比如梅子管道之类的东西。但是已经有了一个巨大的单片系统，并且当时有一些非常有趣的讨论需要关注，观察组织中不同团队围绕这项技术有效定位的动态。

曼努埃尔·派斯:

在文化上也是如此。

马修斯凯尔顿：

哦,是的。文化,肯定的。

曼努埃尔·派斯:

在不同的国家，你需要注意不同的问题。甚至民族文化也是不同的。我认为这也对该组织产生了影响。

马修斯凯尔顿：

你必须小心你可能做出的一些假设。所以在这个特殊的例子中，我们实际上开始假设我们实际上能够得到这个单片系统的某些方面，这些方面看起来有点像通过一些自动化测试的连续交付。事实证明，这个特殊的系统，这个系统本身已经从一个跨国技术供应商卖给了另一个大约四五次，这可能表明它在总体上是合适的。但无论如何，事实证明它没有一个合适的方法来测试它，所有的逻辑都存在于数据库表中，这使得测试和梳理变得非常困难。因此，实际上有一个很好的迹象表明，有时候你需要对技术有一个适当的低层次的理解，以便能够计算出这个问题的规模和大小。实际上，你不能马上假设你可以应用一些模式。

这是一个很好的例子，说明了技术在推动我们所需要的团队，正是因为你。启动一个系统的开发人员环境需要40分钟，在一个虚拟机上，在云中的一个大型虚拟机上，需要40分钟。我认为他们设法将系统的建造时间从48小时缩短到21小时。他们认为为这个系统构建一个新版本的软件就很棒了。当时，那里的人都说，“哦，哇，这太神奇了。我们已经把……是啊，但那也太长了。我想他们最终把时间缩短到四个小时左右。但是，这仍然是意料之中的。

曼努埃尔·派斯:

我认为要有一个适当的生活环境，能够扩大规模并满足需求，仅仅建立基础设施就花了两周时间。

马修斯凯尔顿：

是的。也许这些是边缘案例，也许不是。但绝对有一些情况，你当然不想过度承诺你可以实现的目标。也许有些情况下一些情况，正确的事情是隐藏一些界面背后的一些尴尬，让您在边缘或顶部进行创新，然后专注于您提供的一些东西API进入这个较旧的，更困难的系统。这是所有标准的东西，主机和类似的东西。但肯定地，花时间做正确的技术深度潜水到你正在使用的系统的潜在限制。

事实上，这个系统比大型机更有限，因为至少在大型机上，您可以进行虚拟化和一些现代测试工具。这件事真是一团糟。

所以，不要过度承诺。别指望你能一下子就把书的封面上的两个字改过来，快速流动。这就是它的设计初衷。我们不应该期望能够将其改造到一个为其他目的而设计的系统上，例如，为即时一致性而设计。这是一个关系数据库或逻辑关系数据库。如果他们已经为立即的一致性进行了优化，那很好。这与我们所追求的最终一致性和独立的内容流有很大的不同。

曼努埃尔·派斯:

所以说到精简团队的转变，你会觉得，就像我们之前说的，第一步是开始理解这些流程到底是什么。这也是一种进化。在这个例子中，马修给我们的组织不是停止一切然后说"好吧。我们需要的是，“比如说，”采用DevOps，因为它将解决所有这些问题。现在我们要改变我们将采用部落或我们要采取任何最近的趋势,“和期望来解决我们的问题,事实上,我们需要先看是什么流和从你在哪里开始进化朝着一个更好的地方或更适合快流。

但这不是一场革命。这不是一个大的reorg，通常是要实现这一点。有时，这将是一个痛苦的过程，我们开始发现，就像在这个例子中，有一些技术问题阻碍我们实现更快的流量。还有团队组织问题。在那个例子中，有些人习惯于以某种方式工作，并不认为自己与内部或外部客户有联系，他们存在一些行为问题。所以他们只想做他们一直知道的工作。所以无论如何，有很多因素，行为的，技术的和组织的，这意味着这将是一个通往更好地方的旅程。因此，当我们帮助客户及其团队时，我们所要做的不是创建一个新模型，其中只包含流线型团队，或者主要是流线型团队和平台，等等。我们要做的是了解你现在在哪里，你有哪些团队，然后开始帮助那些团队找出答案，我们是不是更精简的团队？如果是的话，我们还缺少什么，或者我们还缺少什么，以便更符合精简团队的理念，如果这就是我们想要的？

然后我们经常谈到团队的职责和能力，比如约翰·卡特勒，他做了很多很棒的工作，在产品开发和团队动态方面发表了很多文章。所以他有一些非常好的东西围绕着简化团队的责任领域，在那里你可能有团队基本上只做构建和测试。然后你就有了能够在生产中支持自己服务的团队。但是你仍然有很多团队在实际的产品开发或服务开发中投入很少，他们了解客户，客户需要什么，然后能够进行试验。您开始看到您期望从一个真正自治的流线团队或自给自足的流线团队中获得的职责范围。所以这不是一步就能改变的。但是我们今天可以看看团队，有了这种模式和这种类型，我们可以开始寻找什么是缺失的，并采取步骤。

Evan Bottcher:

我注意到在过去的几年里，有一个很大的重点，我知道我自己，这是我咨询的一个很大的部分，一直围绕着那些想要，引入一些内部平台，以便能够更快，减轻负担的组织。书中关于认知负荷的美丽描述是一种描述你试图减少什么以使团队更快行动的方式。我想知道我们是否可以探讨一下这一点，尤其是在构建平台时，围绕产品思维的重要性这一概念。

马修斯凯尔顿：

对我们来说，当我们开始思考认知负荷的概念如何适用于整个团队时，这是一个真正的灵光一闪的时刻。这让我产生了共鸣，那些我们多年来一直在努力播种的东西。但在团队层面，它突然变得更有意义了。我们在书中谈到了团队认知负荷的概念因为最终我们希望团队关注的是对组织来说很重要的事情。如果你是一家从事银行业务的机构，那么很多团队都会专注于银行业务，因为这是一个区别所在。你的团队主要专注于工作的差异化方面因为特别是现在技术变化的速度，有太多的东西来自外部供应商，云供应商，不管什么，如果我们在做的东西没有差异化，我们很有可能会被甩在后面。

所以我们有一个很强烈的想法那就是我们需要关注在这一点上对组织来说是有区别的事情并且尽量减少对团队来说是无关的事情的认知负荷。精简团队中最小化额外的团队认知负荷的想法是其他三种团队类型的驱动力。为什么我们有其他三种团队类型，使能团队，复杂子系统团队和平台团队，主要是为了减少精简团队的认知负荷。就是这样。在过去，内部平台可能用于共享硬件或共享许可成本或类似的事情。这是一个合理的设计决策，在那个硬件极其昂贵和稀缺的年代，当你想要关系数据库等，你只有一个供应商可以选择的时候。所以并不是说这些东西本身就是不好的。只是商业格局的动态发生了变化。就像我们之前说的，我们试图优化一个快速的流动变化。

如果你有一个精简的团队，希望在某个特定领域非常、非常迅速地开展工作，那么他们可以选择从事与业务领域相关的工作。比如说，这是金融交易。如果他们想快速发展，那么您可以允许他们构建自己的基础设施。如果您想让他们非常、非常、非常、非常快地运行，可能他们需要创建自己的特殊数据库。也许目前市场上没有适合他们的东西。此时，正确的做法是创建自己的数据库。好的如果这有助于他快速、安全地实现客户价值，那么，如果有商业案例，如果组织愿意为此付费，就让他们这样做。如果这给了他们自主权、速度和安全性，那么如果公司有钱，你为什么不这么做呢？

在某个时候，该团队将为消费者处理金融交易，构建大量基础设施并维护该自定义数据库。在某种程度上，这种认知负荷会阻碍，传递的方式。所以在这一点上，你有一个选择。你是做什么的？你会改变技能组合吗？你们派人去培训吗？您是否切换技术以使其更简单，如果您愿意，向上移动到更简单的语言或其他什么？或者你会做一些类似的事情，比如把这些东西移到平台上？但所有围绕平台的思考都应该由这种快速流动、快速反馈和限制认知负荷的组合驱动。在我们看来，这应该是驱动力。这应该告诉你什么是正确的边界，或者告诉你那些正确的边界应该是什么，而不仅仅是，哦，我们确实需要一个平台，因为这些东西是基础设施。我认为那不是真的。对于一个专注于提供比萨饼或其他东西的流线型团队来说，管理自己的基础设施是完全合理的，如果这样做对速度和安全来说是正确的。

但你必须平衡这种认知负荷，或基于他们是否有足够的时间考虑主要业务领域的可用内容容量?如果管理这些基础设施意味着他们没有足够的时间专注于销售披萨，那么你就有问题了，你想要承担一些责任。这就是权衡，对吧?所以，这是一种工程权衡，从我们的角度来看，这才是真正应该推动思考的东西，尤其是围绕平台。

相反地，平台的起点不应该是，无论平台做什么，无论它怎么做，它都不应该增加使用它的团队的内容负载。这对我们来说是一个非常重要的起点。这应该是平台的北极星;我们是否增加了使用我们平台的团队的认知负荷?如果是，那就是我们做错了。然后我们可以开始考虑应用产品管理技术和自助服务，以及所有其他的东西，这是非常重要的，但如果我们应用所有这些伟大的技术，我们增加了使用平台的团队的认知负荷，我们做错了。

曼努埃尔·派斯:

是的。非常简单，我想，许多侦听者的直接示例将与之相关。但是，如果您的平台的想法例如，我们正在向我们的内部团队提供协调员，我们所做的是创建一些群集，然后告诉团队使用它们并部署他们的服务，然后这是一个很可能正在增加，可能很多，因为现在你要求开发团队或简化的团队，如果你愿意，只需要学习有关这个新平台的新信息的整个负载。并且，是的，有很大的Kubernetes文档，但如果你要求团队读到这一点，能够在一个完全新的平台上做他们在做的事情，这是一种巨大的认知负荷增加。

所以我认为平台团队应该差不多,我说这个培训平台的工程,我们做的是,几乎有一种创业的心态,是的,首先,你提供一些技术和一些做事情的新方法,或者更好的方法,这是起点,但我们如何让它更容易消费，更容易理解，以及我们如何通过了解内部团队的具体需求，为他们提供更大的价值?我们如何，不仅提供技术访问，而且实际上提供良好的抽象层，以及Matthew所说的，作为产品的平台的区别?

埃文，在你的定义中，我们一直在引用“现代数字平台是由什么构成的?”你说过，它应该是一个引人注目的内部产品，对吧?所以我认为这个定义是,真的很好,因为引人注目的意思,好吧,我们看到平台的客户看到他们看到,“好了,这使我的生活更容易,因为现在我不需要了解所有这些细节Kubernetes部署或你,你提供了我一个更好的抽象,一个更高层次的障碍，这样我就可以专注于我需要为我的产品或我的业务流做的事情，专注于它。我知道，通过一个简单的配置文件或其他东西，我可以将服务带到实际环境中。”

显然，这适用于您可能拥有的所有其他类型的平台服务。因此，想想这样的事情，平台及其不同服务的价值主张是什么，我们在内部提供的实际价值是什么？这与直接使用第三方外部选项的开发团队有什么区别？所以我们有团队需要的内部环境，或者至少我们可以直接与他们交谈并了解他们需要什么，这应该会给我们带来非常强大的竞争优势，对吗？与外部组织相比。但我们并不总能看到这一点得到充分利用。许多平台团队认为，“我们只是让技术在内部可用。”这并不是真正的贬值，也不一定减少认知负荷。

最后，如果你有创业的方法或者产品驱动的方法，那么你应该非常清楚采用周期，对吧?所以产品的采用周期也应该适用于平台服务内部，在那里你有早期采用者;团队中更有参与感的人更愿意接受，服务最初版本的粗糙部分，他们愿意提供反馈，你会有早期多数和晚期多数。因此，你还必须了解，或者至少对我们的服务在内部的应用生命周期中的位置有一个想法，这样我们可能需要做不同的事情。如果我们现在的目标是晚期的大多数人，那么我们需要理解为什么他们不采用这些调查?他们可能会有什么样的摩擦，或者我们是否错过了某些工作流程，这些工作流程对某些不受服务支持的团队来说很重要，等等?所以我认为将平台视为产品是很重要的。

马修斯凯尔顿：

在这本书出版后，我们想到了一个短语，遗憾的是，我们现在回想起来，如果这本书里有这个短语就好了，这个平台是工程师的一次精心策划的体验。这就是起点。起点不是技术，起点是，人们使用它的体验是什么?这会增加他们的认知负荷吗?这会让他们的生活更轻松吗?这能帮助他们专注于自己的主要领域吗?策划体验，然后开始让我们思考产品，设计思考，用户体验，以及所有这些领域，在2021年，当我记录这个的时候，已经被相对理解了。这些是很容易理解的，特别是在消费类软件服务方面。所以我们把这种丰富的意识和实践应用到内部平台上。

所以，这不是一个简单的翻译，但关键的是，在这个行业中有很多人已经掌握了这些技能。我们所做的是将其应用于内部客户;精简团队，软件开发团队，工程师，测试人员，等等，并应用于这种内部平台产品。所以我们不需要发明一大堆新的技术和东西，我们可以重复使用和适应现有的团队，已经被证明的技术。我的意思是，在规模上，云计算公司已经被证明价值数十亿美元，他们已经使用这些技术，并证明他们至少在更广泛的市场是成功的。所以，从这种感觉开始，需要为我们的客户和内部团队策划一种体验，我认为这真的是一种北极星，一种很好的方式来指导我们做出关于现代平台的决定。

曼努埃尔·派斯:

我们仍然看到许多客户有时甚至没有产品管理思维，甚至没有平台团队中的角色。因此，有些客户不仅建议开始在平台中担任产品管理角色，而且实际上，您最有经验的产品经理应该在这些团队中，因为这是最没有意识的地方。所以，也许你是在你的开发团队或流线型团队中，他们更常见的是，他们更关注产品开发和用户体验，等等。但实际上，在这个平台上，你可能需要最有经验的人来帮助这些团队获得不同的工作方式，并看看谁是这个平台的客户。

Evan Bottcher:

我相信我们可以探索一下。这里有一整本书和一堆额外的材料，还有可供学习的课程。我想我们应该开始结束讨论了。你建议听众接下来去哪里了解更多?显然是这本书，但你可能还在整理其他材料?

曼努埃尔·派斯:

是的。所以在我们的网站上，Teamtopologies.com，这是我们新的行业的例子。我们最近发表了一些非常受欢迎的信息图表，就可以在团队拓扑上开始的那种，以及坚果壳的团队拓扑，这帮助人们至少开始谈论这个组织，了解团队拓扑的原因。我们也推出了一个团队拓扑学院，这是我们为想要的人的团队拓扑书的第一个蒸馏版，他们可以开始获得词汇，以及基本上了解团队拓扑中的原则和模式。当组织希望采用这些想法时，这非常有用，他们希望在所有员工中都有一种共同的理解。所以是的，所有这些资源，我们还有许多关于GitHub的存储库。所以github.com/teamtopologies，或者你可以去teamtopologies.com/tools，基本上是一组模板，以及我们在我们帮助他们那种理解的时候与客户一起使用客户的评估和有用的技术发展朝着更快的流动。

Ashok Subramanian：

太好了。我看了一下这个网站，肯定有很多很棒的资源，包括你提到的模板，曼纽尔，我们用过。我自己也用过一些。所以你绝对值得一看。我知道,我们可以继续,我相信一个小时有点很容易的问题,但我想说,对我来说,我认为一些主要外卖,如果从这是,当你发现的模式,我认为我发现更有趣的或照明的是其背后的原则。你提到的三件事是关于确保人们所做的任何事情都专注于快速流动，快速反馈和限制认知负荷，对吧?我认为对于我们的听众来说这些都是很重要的，如果你想从中学到什么，确保你关注的是团队结构的发展等等。

非常感谢Evan, Manuel和Matt，我认为这是一次有趣的讨论，希望我们的听众喜欢听这期Thoughtworks技术播客。188bet宝金博app下载