本文翻译自 Q&A: How Team Topologies Supports Platform Engineering。
Team Topologies 的联合创始人 Manuel Pais 讲述了如何以团队至上的心态将平台构建为产品。
今年以关于平台工程的大量对话拉开了序幕。在我接受的关于这个社会技术学科的每一次采访中，都提到了团队拓扑。
这种优化流程的软件开发和业务方法是由 Matthew Skelton 和 Manuel Pais 创建的。首先，他们合著了一本书，于 2019 年出版；然后他们将其扩展为一个组织，该组织经营一所学院来教授这种实践。
我们与 Pais 讨论了如何利用团队拓扑以及它如何与平台工程交互。因为篇幅和清晰度，对这次采访进行了编辑。
The New Stack：您能介绍一下自己并告诉我们团队拓扑是如何产生的吗？
Manuel Pais：我有 20 年的不同角色经验，从开发、测试、团队领导到咨询，尤其是围绕 DevOps 和持续交付。我在 2014 年遇到了 Matthew [Skelton]，我们开始与世界各地的客户一起开展这些咨询业务，主要是从“我们想要采用 DevOps”或“我们想要持续交付之类的东西”开始。 ”
通常我们会发现问题在于团队互动或不互动的方式，团队的目的不明确，团队超负荷。尤其是我们现在所说的“平台团队”，它们通常有太多的利益相关者，因此他们分布很薄，无法为客户提供实际价值。
当我们与客户合作时，我们发现了不同的模式，有些很好，有些不太好。我们意识到这比 DevOps 更广泛。这就是“团队拓扑”出现的地方。
因此，这本书将工程原理应用于我们组织和建立团队的方式，我们建立了互动。
什么是“团队拓扑”？
“拓扑”是指系统的不同部分连接或排列的方式。因此，当我们谈论团队拓扑时，没有单一的正确拓扑或组织的理想操作模型。
但事实是，如果我们拥有工具，如果我们拥有构建模块来理解如何将它们组合在一起，我们如何以适合我们的组织、适合我们的目标和挑战的方式安排它们，那么我们可能比仅仅采用某种框架要好得多，因为这是我们被告知或认为的正确组织方式。
重要的是从我们今天所处的位置开始，找出其中的差距。我们是否需要在组织中建立一些新的能力？我们是否需要让团队更加拥有其产品，以便他们可以更快地前进、进行实验，并比今天更快地为客户改进产品？如果我们需要这些东西，我们应该建立哪些类型的团队和相互作用关系？
这可能会导致：我们需要做出一些改变。也许我们需要创建一些新的团队，比如赋能团队或平台团队，或者我们只需要改变职责或将其他人带入现有团队。
“我看到很多次：‘让我们重组为这种新的运营模式。’它基于这样的假设，即一切都会变得更好。很多时候情况并没有好转——或者没有我们预期的那么好。我们需要的是在连续的基础上采取更小的步骤。”
—Manuel Pais，团队拓扑
对我来说，团队拓扑学不是一个框架，也不是一个模型。对我来说，它只是一组关于组织思考方式的方法。然后是一些有用的团队类型和交互模式的模式，以及我们如何演进，如何以比过去更加连续的方式感知我们何时需要改变组织。
人们如何开始？它是作为一项自上而下的活动开始的，还是可以在逐个团队的基础上完成？
平台团队并不是新事物。我认为团队拓扑的不同之处在于我们不是孤立地谈论平台。这是一个团队网络，我们需要为组织和客户完成工作。
是的，通常情况下你需要某种形式的平台。它可能非常小，非常薄弱。在一个小公司中，你可能只有几个人来定义这个平台，以及如何更有效地完成某些事情。在较大的组织中，这可能是多个团队，甚至是多个平台来提供帮助。
为什么我们需要它们？它们为什么存在？在团队拓扑中，平台的首要目标应该是减少开发面向客户的服务或产品的流对齐团队的认知负荷。
我认为这就是为什么你在平台工程的背景下听到这么多关于团队拓扑的原因。我们将平台称为产品，因为它需要帮助他们的平台客户（即其他团队）更有效地开展工作，减少他们的认知负担，以及做某些事情需要付出的努力。
而在过去，我们只是孤立地谈论平台。我们会更多地考虑技术方面：我们应该建造什么？其他组织正在发生什么？那么我们需要构建相同的东西或者我们需要使用相同的新技术。是的，我们需要利用技术，但这不应该是起点。
您将软件组织称为“有机体”之类的团队网络。那是因为团队拓扑结构在不断变化吗？一个组织应该多久检查一次它的团队拓扑结构？
仍然很常见的是进行大规模的重组，有些公司每两三年就会进行一次重组，他们会调整人员并改变他们的角色。然后他们会惊讶地发现人们为什么没有参与感或疲劳不堪。这不是一种有效的方式。
相反，我们应该思考：在组织层面上，我可以做出最小的改变来获取反馈，并了解这个改变是否真正有帮助？我经常看到这种情况：“让我们对这个新的运营模式进行重组。”它基于这样的假设：这一切都会变得更好。但是很多时候它并没有变得更好——或者没有我们预期的那么好。
我们需要在持续的基础上采取更小的步骤。例如，我们需要在数据科学方面得到帮助，或者我们需要拥有更多的数据洞察力的团队。也许我们只有一个集中式的数据科学家团队，而他们已经超负荷了。这太慢了，他们成为了瓶颈。我们该怎么办呢？
也许我们可以从让这些数据科学家做一些使能工作开始。帮助其他团队学习基础知识，这样他们就可以自己做一些事情了。他们不会一天变成专家，但也许他们可以做一些基本的事情，不再依赖那个集中式的团队。这是一个非常小的变化。
理想情况下，你希望有一种文化，团队本身作为“传感器”来行动，“我们需要改变一些东西；这不起作用。也许我们有太多的依赖关系阻止了我们，或者我们没有我们需要的技能。”
我们需要看看康威定律和邓巴数来建立信任团队。管理层需要更好地理解存在的约束条件，塑造团队合作的方式，为团队提供文化和自主权，让他们决定需要进行的小改变。归根结底，要真正成功，需要顶层和底层方法的结合。
根据团队拓扑，告诉我们一些不同类型的团队。
流对齐团队是许多人称之为跨职能产品团队的团队。但是今天，对于我看到的大多数产品，你不能只有一个团队。这不够。因此，我们需要在多个层面识别价值流。
最近我与一家大型制药公司交流。在最高层面上，他们真正拥有两到四个主要的价值流 — 药物开发、诊断和其他 — 然后有成千上万的人在这三个价值流下工作。因此，我们需要将其细分：在这个大的价值流下，我们有哪些较小的流可能与不同类型的客户、不同的市场、不同的地区对齐？
然后你向下再走一层。在这些不同的价值流中，我们正在构建哪些产品？在产品中，有哪些不同的流程可能是不同的客户旅程或在产品中相对独立的不同功能集？
因此，组织内的这种分层价值流非常有用。每个流对齐的团队都对工作流拥有端到端的所有权，这可能是作为产品一部分的一项服务，也可能是作为产品一部分的一组功能。但是您希望该团队拥有该所有权。
关于 DevOps，这些团队拥有构建和运行的所有权。他们也有创意所有权。理想情况下，他们进行实验，从用户那里获取数据，并且了解我们下一步需要做什么。
然后我们讨论赋能团队，通常是围绕某个领域的专家组成的小团队——比如数据科学、安全或用户研究。
无论哪个领域需要专家知识，我们如何才能以有效的方式将这些知识带给流对齐的团队，从根本上减少学习曲线，让团队加快他们需要做的事情，使我们的应用程序或服务更安全的？我们如何获得我们需要的数据以及我们如何分析数据以获得我们需要的关于我们服务的见解？
因此，赋能团队将通过教学、指导、帮助他们快速学习来与流对齐团队一起做到这一点。
然后我们谈论平台团队。这是一个别名，对吧？从某种意义上说，平台团队最终成为一个流对齐的团队，拥有端到端的所有权，只是他们提供的服务是内部的，供组织中的其他团队使用，供内部客户使用。
最终在大中型组织中发生的事情是，该平台团队是一组团队，您可能在平台团队内部拥有多个流对齐的团队，与不同的服务对齐。也许一个团队正在从事监控服务，而其他团队正在从事某种[站点可靠性工程]相关服务等。
“这是我经常看到的反模式，平台变成了所有东西的桶，变得一团糟，缺乏所有权，缺乏重点和大量浪费，团队超负荷工作并致力于很多并不是真正的优先事项。”
—Manuel Pais，团队拓扑
在平台内部，您可能还拥有赋能团队。在初创公司或扩大规模时，该平台可能只是某种 Wiki 页面，一些人在那里收集了一些关于如何创建一些数据库的指导，如何以有效的方式做一些事情以供其他团队入门更快——减少认知负担的东西。
[随着规模的扩大]，您希望每个平台，A，具有某种内部凝聚力，[和]B，提供一致的界面和供客户内部使用的方式。
例如，基础设施平台不同于数据服务平台，数据服务可能使用基础设施平台，并为组织中的其他团队提供数据服务。
您需要找到不同平台之间的界限，以便每个平台在内部具有凝聚力，共同研究如何以一致的方式为客户提供服务，而不会让他们感到困惑。但你也需要解耦平台，这实际上是两个不同的东西，它们应该是分开的，这样它们才能更独立地发展。
这也是我经常看到的一种反模式，平台变成了所有东西的桶，变得一团糟，缺乏所有权，缺乏重点和大量浪费，团队超负荷工作并致力于很多并不是真正的优先事项。
科技行业正处于技术裁员和招聘冻结的时期。您所描述的很多内容都暗示了招聘和培训的预算。您将如何调整团队拓扑以适应这些更贫乏的过渡和倦怠时期？
缺少的是团队至上的方法——将团队视为向客户交付价值的最小单位。意思是，我们不太关注个人，而是关注团队：什么可以帮助团队做出更好的决策，在工作中更加自主，并更快地为客户提供价值？
这通常与组织其他部分的工作方式不一致，例如培训预算。我们有这个在线学院，提供基于视频的培训。我们有一位工程总监，他们每个人每季度都有这样的培训预算——可能每季度 100 欧元。这位工程总监无法购买我们的课程，因为他们在本季度没有足够的预算。
我认为这是不该做什么的一个很好的例子。它非常关注个人，不支持团队应该决定的想法。从培训的角度来看，在这种情况下，您不需要增加培训预算，而是可以有一个桶，如果我们的团队中有 10 个人，那么我们就有 1,000 欧元，这是我们可以在每个季度使用的东西基础。
这就是为什么我们称之为团队优先方法。这也是关于团队中的个人将团队放在首位，然后思考 [关于] 什么对团队和组织有帮助。
将团队作为一个整体来考虑，然后裁员问题也很有趣，因为，是的，不幸的是，我们可能会有更小的团队，因为我们的人更少。但球队作为一个整体仍然存在，球队更有能力吸收裁员的影响。
但是你不需要拆散团队。你将团队作为一个整体，即使能力有所下降。团队拓扑结构在裁员期或经济低迷时期仍然有效。
你不想做的事情——我听过很多公司的例子——就是解雇拥有更多专业知识的人，可能是因为成本更高。当您在组织中拥有这些人时，他们非常有价值。
我们在团队拓扑中所说的是，您不希望它们成为瓶颈。您不想依赖专家来完成工作。您希望专家帮助他人。因此，让专家帮助其他团队学习我们在组织中存在差距的任何地方都会产生网络效应。不要放过专家，如果他们接受这种教导和帮助他人的想法，他们就会变得强大。
该平台是组织倾向于开始削减预算甚至裁员的另一个领域，因为他们认为，“哦，这是可以消耗的，因为它是内部产品的内部工作。”
但是你需要看整个局面：如果平台按照这种“平台即产品”的方法正确实现，那么潜在的收益可能比削减一些平台服务和团队所得到的收益要高得多，因为这些团队正在开发面向客户的产品。
团队拓扑如何定义团队？
我们将“团队”定义为通常由 5 到 9 个人组成的团队，他们一起工作 [一段时间] 并确定了他们喜欢的工作方式。他们相互理解，有一个与客户和组织目标一致的共同使命。
这是一个长寿或持久的团队。这是我们保持在一起的一个单位。这并不意味着它是静态的——当然，人们会离开，一些新人会加入——但团队作为一个整体保持稳定。
工作可能会发生变化，我们可能需要停止投资某些产品或某些工作流程，而我们正在投资其他一些工作流程。但我们将团队作为一个整体，因为这是很有价值的地方。该团队经历了一些人所说的 Tuchman 团队发展模型，团队需要时间真正了解彼此，相互信任，然后才能达到更高的绩效水平。
“您可以通过不同的方式将创新和新知识带入团队。这不仅仅是引进新人。你可以确保人们有时间、可用性和预算来学习新技能、进行培训或得到其他团队的帮助。”
—Manuel Pais，团队拓扑
这与组织创建团队来交付某些项目或变更，然后解散团队的情况不同。在这种情况下，您不拥有您构建的服务或能力的所有权，因为您只是移动人员。因此，这不是非常有效的，因为我们知道成功软件的大部分成本不在开发中，而是在维护和支持方面。
如果您有一个拥有该服务的团队，那可以确保它顺利运行，您可以整合新方法。你要确保你知道它一直在为客户提供价值。
这会阻碍创新吗？微软可访问性总监大卫·戴姆 (David Dame) 表示，一个在一起工作 18 个月或更长时间的团队已经形成了一种共同的思维方式，这会减少多样性和创新。
团队需要大约六个月到一年的时间才能真正凝聚起来，达到我们可以称他们为一个正在改进和执行的团队的程度。所以在 18 个月之后，这还很早，你绝对不想解散团队。
我很喜欢 Heidi Helfand 的著作《Dynamic Reteaming》，她谈到了一些这方面的模式和如何随着时间改变团队。团队的改变是不可避免的。但是如果你分散团队，那么你会失去团队拥有的所有知识。我们可以依靠团队所做的决策的文档，但是没有什么可以取代团队内部的那种讲故事的方式。
您可以通过不同的方式将创新和新知识带入团队。这不仅仅是引进新人。您可以确保人们有时间、可用性和预算来学习新技能、进行培训或获得其他团队的帮助。
这就是我们在团队拓扑中谈论的很多内容：我们如何以有效的方式将新功能构建到团队中？我们并不是说您可以在业余时间自学。我们应该在组织内部建立共享知识的机制。这就是您拥有支持团队和平台团队的地方。
关于“团队至上”的思想和价值交付的最小单位是团队的思想，这是否意味着在 DevOps 意义上，它们是完全自主的？这如何适应平台工程，他们应该能够自己构建和运行它？
平台的目标是帮助这些流程对齐的团队更有效地完成他们的工作。有些人谈到创建这些流程对齐的团队的“黄金路径”，意味着他们拥有自己的服务或产品，并负责监视、部署等。
“传统上，人们总是关注个人，围绕这位 10 倍工程师的一些被高估的想法。我们确实需要有专业知识的人，我们确实希望人们变得更好。但我认为这是对某种英雄文化和/或喧嚣文化的过度依赖。”
—Manuel Pais，团队拓扑
但是我们如何帮助他们减少做这些事情的认知负担呢？我们可以做到这一点的方法通常是使用平台，该平台提供非常好的监控服务、良好的可观测性服务、部署服务、持续集成和持续交付 pipelines ——所有这些类型的东西都可以作为基础设施平台的一部分提供，例如。
我们需要非常专注于作为平台团队或一组团队的目标，这是否能帮助流程对齐的团队更好更快地完成工作？因为平台提供服务的方式存在着一些真正的危险，比如这些服务不易于使用，或者不够可靠，或者令人困惑，或者不支持流程对齐的团队需要的用例。
如果这样，你并没有帮助他们，反而增加了他们的认知负荷。因为现在我们不得不使用那些不适合我们所需的服务，所以它实际上减缓了我们的速度，而不是帮助我们更快地前进。
将平台视为一种产品，了解您的用户 [并] 与他们交谈。对您在平台中提供的内容进行快速迭代，尽快从用户那里获得反馈。
我们需要优先考虑什么？什么更有价值？因为当你在一个平台上工作时，你可能会收到成千上万的请求，因为每个人都有自己的需求。所以你需要有我们要去哪里的产品愿景。对组织更广泛的价值是什么？我们不要构建只对一两个团队有帮助的东西。
所有这些都是产品思维。进行一些用户研究，与客户交流，了解他们如何使用您的服务。提供适当的文档作为自助服务，这样人们就可以使用平台而不依赖您作为平台团队来回答他们的请求。
为什么您认为培养团队至上的心态会有阻力？如果阻力来自团队之外会怎样？
传统上，一直关注个人，围绕这位 10 倍工程师的一些被高估的想法。我们确实需要有专业知识的人，我们确实希望人们变得更好。但我认为这是对某种英雄文化和/或喧嚣文化的过度依赖。
所有这些都导致组织大多数情况下都关注个人表现。从人力资源角度来看，他们关注的是个人，而从预算角度来看，它仍然非常基于项目或交付，并非基于团队，也不允许团队提供价值。
问题的一个重要部分是试图为我们认为客户需要的能力、产品或交付物进行预算。但是，由于我们周围的事物变化如此之快，三个月后，你会意识到它完全是错误的，但你已经为整整一年甚至多年进行了资金投入。