本文面向在产品导向型组织中应对产品交付复杂性的IT领导者、产品经理和工程总监。如果您正在推动创新、实施新的IT能力或增强跨团队协作，本文将提供有关挑战的见解，并探讨一些实现创新、敏捷性以及使IT举措与更广泛业务目标相一致的关键概念。

在我的经验中，虽然以产品为中心的方法有其优点，但许多组织在实施新的IT能力、新的架构和创新时会面临独特的挑战，原因如下：

• 孤岛式运营 : 团队倾向于专注于单一产品，导致跨部门协作的需求增加，这对于实施新的IT能力至关重要。产品团队需要工具和系统来创建新的功能，如基础设施、安全、测试、交付流水线和其他团队交付成果。虽然他们可以自行管理其中一些，但他们通常需要在其他方面获得帮助，因为他们的知识和资源有限。

• 所有权挑战 : 新的能力需要跨越多个产品团队的任务所有权，这会削弱产品或团队的边界，导致所有权的灰色地带。

• 复杂的协调 : 跨产品计划需要各个团队之间的对齐，使得协调变得困难，从而减缓了市场时间。

• 创新 : 专注于特定产品的渐进式改进可能会限制更广泛的、变革性的创新努力。

• 敏捷性降低 : 由于依赖共享团队，该模型的僵化会阻碍组织快速适应市场变化和客户反馈的能力，影响市场策略。敏捷框架完全不是解决方案！

• 扩展挑战 : 如果IT和业务领导不监督所有产品的愿景，它们的独立演化可能导致碎片化的系统，使得扩展和集成新技术变得更加困难。

• 与业务目标保持一致 : 产品团队可能优先考虑自己的目标，而不是更广泛的业务驱动因素，导致IT能力和组织目标之间的脱节。

那么，我们应该如何组织团队来解决这些不足之处呢？

Matthew Skelton 和 Manuel Pais 的书《Team Topologies》提供了一种组织现代软件系统团队的新方法。在这篇文章中，我将探讨书中的一些关键理念，分享我的看法，并提出如何通过关注价值来增强该框架的建议。如果你想了解更多详情，可以在这里查看该书 here。

作者指出，软件系统中的价值流动主要受到三个主要因素的影响：

• 系统的架构
• 过程（如敏捷和DevOps）
• 团队之间的交互方式

如果你只调整这些领域中的一个而不考虑其他领域，你可能会创建一个不如预期好用的系统——甚至更糟糕，一个完全崩溃的系统。系统的速度和效率只和其中最慢的部分一样好。

例如，僵化的架构或设计不佳的团队互动可能会造成瓶颈，导致延迟和依赖关系，从而减缓进度。这可能成为一个巨大的障碍，即使对于那些使用设计良好、解耦架构的高技能敏捷团队也是如此。

• 业务流程对齐团队 : 通常与业务领域或产品细分工作流程对齐。
• 赋能团队 : 赋能团队帮助业务流程对齐团队克服障碍并识别缺失的能力。我设想这个团队能够快速构建解决方案或原型的基本版本。
• 复杂子系统团队 : 当需要显著的技术专长并且从0到1构建某物时，这个团队是必不可少的。
• 平台团队 : 一个提供内部产品以加速业务流程对齐团队交付的团队。推动DevSecOps达到更高水平。

参考:https://github.com/TeamTopologies/Team-Shape-Templates/blob/main/resources/Recreated%20book%20shapes%20example.png

一个流对齐的团队专注于与特定业务领域或能力相关的持续工作，例如产品、服务或用户旅程。该团队有权快速独立地向客户交付价值，而无需将工作交接给其他团队。

在现代软件组织中，流对齐团队是主要的团队结构。其他类型的团队，如赋能团队或平台团队，存在是为了支持流对齐团队，帮助他们获取新技能或通过提供易于使用的服务来减轻他们的认知负担。

这些团队与客户紧密相连，使他们能够快速响应反馈和系统问题。不同的流，如客户或产品流，可以在一个组织中共存，每个流对齐团队的资金支持是为了长期的可持续性而不是临时项目。

这种方法与传统的任务分配方式不同，传统方式中一个大型项目涉及多个团队，每个团队有独立的任务列表，常常导致延迟和低效。Stream-aligned团队确保工作流程稳定且清晰，从而实现更敏捷和高效的开发。

一个负责整个产品交付流程的流式对齐团队（Stream-aligned team）常常因为需要快速交付而难以找到时间学习新技能。这时，赋能团队（Enabling team）就派上了用场。赋能团队由一些专家组成，他们通过研究、实验并推荐工具、实践和框架来支持流式对齐团队。他们帮助填补流式对齐团队的知识空白，而不增加他们的额外负担。

赋能团队可能专注于构建工程、持续交付或测试自动化等领域，建立初始框架或工具，供流式对齐团队使用。根据需求，赋能团队和流式对齐团队之间的合作可能是临时的或长期的，并且通常涉及直接合作，如配对，以有效传递知识。

一个高效的团队会在其他团队需要之前，掌握其专业领域内的新方法和工具。

一个复杂的子系统团队构建和维护需要专门知识的解决方案。团队成员在其领域是专家，他们的工作减少了流对齐团队否则需要管理的复杂性。这种方法避免了将专家嵌入到每个流对齐团队中，这将既低效又昂贵。

这些团队负责处理复杂的子系统，例如AI模型，其中专门的知识至关重要。与基于共享组件创建的传统组件团队不同，复杂的子系统团队仅在子系统需要大量专门知识时才会形成。因此，一个组织通常拥有的复杂子系统团队数量少于传统组件团队。

最后，让我们讨论平台工程，以了解平台团队的目标。我将更深入地探讨这一主题，因为它在软件工程中是一个较新的趋势。

任何优秀的工程团队都旨在通过提升开发者体验（DX）来加速客户价值的交付。本节将探讨平台工程，这是一种在2024年具有战略意义的技术趋势，同样承诺实现这一目标。让我们来探索这一概念，并看看平台工程如何帮助工程团队应对现代软件架构的复杂性并提供业务敏捷性。

现代解决方案是由众多服务组成的分布式系统，每个服务都是一个复杂的子系统，这并不是什么新鲜事。随着我们采用新技术、新架构以及第三方解决方案和服务（如云提供商），这种复杂性正在不断增加。开发者不可能成为他们工作所依赖的数百个服务的专家。试想一下，构建复杂 web 解决方案时使用了多少开源和云服务。

让我们来探讨一下平台工程这一领域，以及它是如何帮助处理认知负荷和复杂性的。

据Gartner称，平台工程是构建和运营自服务内部开发者平台的学科，用于软件开发和交付。每个平台是一个由专门的产品团队维护的层，与复杂的底层基础设施、工具和流程进行交互。到2026年，大型软件工程组织中将有80%建立内部平台工程团队，而这一比例在2022年为45%。

平台工程旨在通过开发内部开发者平台（IDPs），减少管理基础设施和工具的认知负荷，从而提高开发人员的效率和满意度。这些平台为入职、开发、测试和部署活动提供了一个集中的平台。

效益总结：

• 通过抽象基础设施和后端服务的复杂性，平台工程使应用团队能够更多地专注于应用开发，而较少关注后端环境的细节。
• 自动化部署环境的创建和管理简化了扩展操作。它使团队能够轻松地扩展或调整资源，而无需深入了解复杂的底层过程。这将使开发人员能够专注于价值创造，从而加快整个开发周期。
• 精简的工具和流程缩短了新团队成员变得高效所需的时间，从而增强了团队的整体敏捷性和响应能力。
• 平台工程为开发人员提供自助服务工具，在定义的参数内提供自主权，减少手动工作并鼓励团队内的创新。
• 自动化安全、隐私和合规性任务确保这些关键要求得到有效管理，而不会给开发人员增加额外负担，从而创建一个安全且合规的操作环境。

内部开发者平台（IDP） 就像一个集中的中心，包含了开发者高效构建和管理软件应用程序所需的所有工具。它将各种开发资源，如API、工具和服务整合到一个地方，简化了访问。这种设置帮助开发者避免单独使用多个第三方工具，减少了混乱并简化了流程。它们提供了一个更简单的界面，帮助开发者理解软件开发周期，访问必要的文档，并管理软件部署，而无需直接处理底层的复杂性。这种方法不仅帮助有经验的开发者更高效地工作，还帮助新开发者快速上手。

例如，一个开发人员需要部署一个新的应用。有了 IDP ，他们可以访问整个DevOps生态系统中的所有工具和资源——源代码仓库、CI/CD流水线、容器管理系统等。他们可以手动配置流水线、设置环境和管理部署，这需要对整个系统及其组件有很好的理解。

然而，如果这位开发者使用了内部开发者门户，他们将与一个更简单的界面进行交互，该界面会引导他们完成部署过程。例如，开发者不需要手动设置CI/CD管道，门户可能会提供一个预配置的模板或向导，以抽象掉复杂性。开发者选择模板并填写一些参数，门户会处理其余部分。

这种设置简化了各个任务，并确保所有开发人员遵循标准化流程，提高了效率并减少了错误。

IDP 的关键组件:

1. 服务和资源目录：这些目录提供了一个集中的仓库，开发人员可以在其中查找和访问项目所需的各类服务和资源。
2. 基准测试评分卡：这些工具用于衡量软件质量和安全性，帮助确保开发标准得到满足。
3. 脚手架模板：这些模板为开发人员提供了一个结构化的框架，使他们能够快速且一致地构建新组件。
4. 集成插件允许无缝集成到现有平台服务中，增强功能和互操作性。
5. 自助服务配置：IDPs使服务的配置变得简单，让开发人员能够自主启动和管理服务。
6. 自动化支持系统：这些系统提供性能指标和应用程序可用性的自动更新，减少了手动监督的需求。
7. 简化操作：通过管理底层基础设施，IDPs减轻了开发人员的操作负担，使他们能够专注于编码。
8. 快速部署能力：IDPs使开发人员能够快速部署应用程序，通常只需简单的步骤，如单击一个按钮。

在以产品为中心的组织中，产品工程团队为产品的最终用户构建解决方案和能力。

平台工程团队提供开发者门户，帮助产品团队减少完成有价值工作的摩擦，实现业务敏捷性。具有前瞻性的公司已经开始构建平台，这些平台在用户与其依赖的底层服务或平台之间进行交互。

平台工程（作者绘制的图表）

主动文化 vs 反应文化

平台工程团队的成功不仅仅取决于技术实力，还受到组织文化的重要影响。强大的、适应性强且积极主动的文化 对这些团队的发展至关重要。本文探讨了培养一种能够提升平台工程团队效率和创新能力的文化的关键方面。

产品思维

这个概念涉及以与管理市场上的产品相同的关注度和战略规划来管理和改进平台。主要思想是创建一个不仅功能强大而且吸引用户使用的平台。在平台工程中，采用产品思维模式将重点从仅仅提供技术解决方案转向确保这些解决方案能够提升用户体验（开发者体验）。这种方法确保平台根据用户反馈、业务需求和技术进步不断进化。

始终从一个 TVP（最简可行平台）开始。平台应该从小规模开始，并随着验证的有效性和使用量的增长而扩展。Microsoft 提供了一个很好的 JTBD（工作要完成）框架来指导平台的发展。

Ref: https://learn.microsoft.com/zh-cn/platform-engineering

https://learn.microsoft.com/en-us/platform-engineering/media/pe-steps.svg

团队拓扑为组织现代软件团队提供了一个良好的框架，使团队能够更加敏捷、响应迅速和高效。通过围绕流对齐、赋能、复杂子系统和平台团队等关键领域构建团队，组织可以减轻认知负担，提高自主性，并增强协作。

没有任何模型是100%完美的；实施这种模型会带来一些挑战，包括可能的协调问题、资源分配复杂性以及形成孤岛或过度专业化风险。在确定拓扑结构时，应考虑组织的战略目标和需求。

另一个重要的方面是，该模型更侧重于工作的流程。为了最大化这种拓扑结构的好处，必须用一个强大的价值框架来补充这种方法，该框架专注于为客户创造价值。组织可以通过将团队目标与客户成果对齐，并定期重新评估团队结构如何支持或阻碍这些目标，来确保他们的努力产生有意义的影响。

通过这种团队拓扑结构（Team Topologies）平衡技术与运营效率，并专注于客户价值，将使组织在竞争激烈的环境中蓬勃发展。这将确保每个团队的贡献都与提供卓越产品和服务的更广泛使命保持一致。