平台团队如何开展工作：平台迁移、平台使用与平台演进中的跨团队协作

平台团队高度依赖与其他团队的协作，才能确保内部平台顺利推广。尤其是，将代码变更整合到其他团队的代码库中，往往是平台成功的关键。跨团队协作有多种模式，选择哪一种，取决于平台推广所处的阶段，也取决于相关团队和代码库对外部参与的接受程度。

对于平台工程而言，内部平台的成功，很大程度上取决于有多少团队真正采用它。这也意味着，平台团队的成败取决于他们与其他团队协作的能力，尤其是推动必要变更落地到其他团队代码库中的能力。

本文将探讨平台团队在与其他团队协作时通常会经历的几个阶段，并分析团队应如何在每个阶段取得成功。具体而言，我们将重点关注平台协作的三个阶段：平台迁移、平台使用和平台演进。我会说明每个阶段的特点，讨论平台团队和产品交付团队——也就是平台的客户——在每个阶段可以采用的运作模式，并分析哪些跨团队协作模式最为有效。

在思考软件团队如何协作时，我最常参考的一本书是《团队拓扑》。在第七章中，作者定义了三种团队交互模式：协作、X 即服务和促进。不出所料，本文介绍的模型与这三种团队拓扑模式存在一些重叠之处，我会在文中指出这些联系。此外，在本文结尾，我还会回顾《团队拓扑》中的一些重要观点。对于思考平台团队、产品团队以及软件组织如何协作而言，这本书确实是一本极具价值的参考资料。

平台交付团队与产品交付团队

在深入讨论平台团队如何开展工作之前，我们先明确平台团队与其他工程团队之间的区别。接下来，我会频繁提到两个概念：产品交付团队和平台交付团队。

产品交付团队负责为公司的客户构建产品功能，他们所构建产品的最终用户是公司的外部客户。我也见过这类工程团队被称为“功能团队”“产品团队”或“垂直团队”。在本文中，我将使用“产品团队”作为“产品交付团队”的简称。

与之相对，平台交付团队负责为公司内部的其他团队构建产品。平台团队所构建产品的最终用户，是公司内部的其他团队。本文中，我将使用“平台团队”作为“平台交付团队”的简称。

用《团队拓扑》的术语来说，产品交付团队通常会被描述为“流对齐团队”。虽然《团队拓扑》的作者最初将“平台团队”定义为一种独立的团队拓扑，但他们后来逐渐将“平台”视为一个更宽泛的概念，而不是一种独特的工作方式——我非常赞同这一点。根据我的经验，一个优秀的平台团队，在《团队拓扑》的语境下，通常要么以流对齐团队的方式运作——其平台本身就是它的价值流；要么以赋能团队的方式运作——帮助其他团队更好地使用平台。事实上，在本文将要讨论的许多跨团队协作模式中，平台团队都扮演着赋能团队的角色。

“平台”不只是内部开发者平台

当前，平台工程是一个非常热门的领域，而讨论焦点往往集中在内部开发者平台上。这里需要澄清的是，本文所说的“平台”范围要广泛得多。它也包括其他内部产品，例如数据平台、前端设计系统或实验平台。

事实上，虽然本文主要关注技术平台，但其中许多理念也适用于提供共享业务能力的内部产品，例如金融科技企业的资金转移服务，或电商企业的商品目录服务。它们的共同点在于：平台是组织内部其他团队使用的内部产品。因此，平台团队构建的产品，其客户是公司内部的其他团队。

平台采用的三个阶段

接下来，我们回到不同类型的跨团队协作。本文将讨论平台团队与产品交付团队之间需要协作的三种场景：平台迁移、平台使用和平台演进。

在分析这三个阶段时，需要特别关注两个关键问题：哪个团队负责推动工作？哪个团队拥有需要修改的代码库？这两个问题的答案，将极大影响每种场景下适合采用的协作模式。

平台迁移：推动内部平台落地的第一步

我们先来看平台迁移。所谓迁移，是指为了切换到新的平台能力，而对产品团队的代码库进行修改。

在这类场景中，推动变更的是平台团队，但需要修改的代码库却归另一个团队——也就是产品团队——所有。因此，跨团队协作就变得尤为重要。

平台迁移工作的示例

我们这里指的是哪些类型的变更？

一种相对简单的迁移，是版本升级。例如，升级共享组件库，或者升级服务所使用的底层语言运行时。

更常见的大规模迁移，是将产品团队对第三方系统的直接集成，替换为某种内部封装。例如，将日志、分析或可观测性工具的使用方式，迁移到平台团队维护的共享内部库；或者将产品团队与支付处理服务的直接集成，替换为通过某个内部网关服务进行集成。

另一类迁移，是将对已废弃内部服务的既有集成，替换为对新服务的集成。例如，从旧的用户服务迁移到新的账户资料服务；或者将原本分散在多个信用数据相关服务中的能力，迁移到一个新的统一信用数据网关服务。

最后一个例子，是基础设施层面的平台重构。例如，将产品团队拥有的服务容器化，引入服务网格，或者将某个服务的数据库从一种关系型数据库切换到另一种关系型数据库。

需要注意的是，在平台迁移过程中，产品团队通常并没有特别强烈的内在动机去完成这些变更。有时，如果新平台提供了令人期待的新功能，他们可能会积极响应；但更多时候，他们只是被要求配合一项更大的架构计划完成迁移，而他们自身未必能从中获得多少直接价值。

平台迁移中的协作模式

接下来，我们看看哪些跨团队协作模式适用于平台迁移工作。

将工作交给产品团队

平台团队可以在产品团队的待办列表中提交工单，要求他们自行完成必要变更。

这种方法有一些优势。首先，它具备可扩展性：实现工作可以分配给所有维护相关代码库的产品团队。其次，它也易于跟踪和管理：通常情况下，提交和跟进工单可以由项目经理或其他项目管理人员完成。在涉及多个产品团队、多个代码库和多个迁移阶段时，平台团队也可以借助 PingCode 这类智能化研发管理工具，将目标、需求、排期、开发、测试、发布和知识沉淀串联起来，让迁移进度、风险和协作数据更清晰地流转起来。

但这种方式也存在明显缺点。首先，它通常非常慢。有些产品团队可能要过很久才会开始处理这项工作。其次，它会引发团队之间的优先级拉扯。被要求执行迁移的团队往往无法从中获得直接收益，因此他们很自然会降低这项工作的优先级，转而处理那些更紧急或业务影响更明显的任务。

由平台团队完成工作

平台团队也可以选择自行修改产品团队的代码库。常见方式有三种：短期驻场、可信外部贡献者和内部开源。

在“短期驻场”模式下，平台团队的一名工程师会临时嵌入产品团队，在该团队中开展相关工作。

在“可信外部贡献者”和“内部开源”模式下，产品团队允许平台团队工程师向其代码库提交 Pull Request。

后两种模式的区别在于：是所有工程师都可以为产品团队的代码库做贡献，还是只有少数被信任的外部贡献者可以参与。产品交付团队很少会投入足够资源来支持完全意义上的内部开源，但允许少数值得信任的平台工程师提交贡献，却并不少见。

和提交工单一样，让平台团队自行完成迁移工作也有优缺点。

积极的一面是，这种方式通常可以缩短变更交付周期。因为最想完成这项工作的团队——平台团队——同时也是实际执行工作的团队。激励机制保持一致，意味着平台团队往往会比拥有代码库的产品团队更愿意优先处理这项迁移。

不利的一面是，这种方式只有在产品团队能够提供足够支持时才行得通。他们要么需要愿意接纳一位平台工程师暂时加入团队；要么需要已经与平台工程师建立了足够的合作基础，并信任他们可以独立修改代码库；要么需要投入大量资源来支持内部开源模式。

另一个缺点是，这种“平台团队亲自下场”的策略并不具备良好的可扩展性。平台团队的工程能力始终有限，而且通常少于所有产品交付团队的总工程能力。如果不把一部分工程工作分配给产品团队，就会浪费整个组织中已有的实施能力。

现实情况通常更加复杂

在实际工作中，这些方法通常会被组合使用。

例如，一个负责迁移的平台团队，可能会由项目经理向 15 个产品交付团队提交迁移请求，然后花一段时间跟进和推动各团队完成工作。过了一阵子，一些团队会自行完成迁移，但总会有一些团队因为忙于其他事务，或者根本不愿承担迁移工作而迟迟没有进展。此时，平台团队就会撸起袖子，采用一些扩展性较差但更直接的方式，亲自完成剩余迁移工作。

平台使用：让产品团队真正用起来

现在，我们来看平台采用过程中的另一个阶段：平台使用阶段。这是平台集成进入“稳定状态”后的阶段。此时，产品交付团队已经将平台能力融入日常功能开发工作中。

平台使用的一个例子是，产品团队使用由基础设施平台团队维护的服务框架来启动一项新服务。又比如，产品团队开始使用内部客户分析平台，或者开始使用专门的敏感数据存储服务来保存个人身份信息。从软件栈的另一端来看，产品团队开始使用共享 UI 组件库中的组件，也属于平台使用的一种形式。

平台使用工作与平台迁移工作的主要区别在于：在平台使用场景中，产品团队既是工作的推动者，也是需要修改代码库的所有者。产品团队有自己的业务目标，并通过使用平台能力来实现这些目标。这与平台迁移截然不同。在平台迁移中，是平台团队试图将变更引入其他团队的代码库。

由于在平台使用场景中，产品团队既是驱动方又是代码所有方，你可能会认为此时并不需要跨团队协作。然而，正如我们接下来会看到的，产品团队仍然可能需要平台团队提供支持。

平台使用中的协作模式

对于许多平台团队来说，一个理想目标是构建一个完全自助式的平台：它像海外某些成熟商业化平台那样，文档完善、体验顺畅，产品工程师无需任何直接支持，也不需要与平台团队协作，就能够独立使用平台。

但在现实中，大多数内部平台还没有成熟到这种程度，尤其是在早期阶段。产品工程师刚开始使用内部平台时，常常会遇到文档不完善、错误信息晦涩难懂，以及各种令人困惑的缺陷。这些产品团队可能很快陷入困境，转而寻求平台团队帮助，以便顺利使用平台能力。

当平台用户向平台所有者寻求实际支持时，我们又回到了跨团队协作的场景。此时，不同协作模式会再次发挥作用。

专业服务模式

有时，产品团队可能会要求平台团队代为编写使用平台所需的代码。这可能是因为产品团队难以理解如何使用平台，也可能是因为这种方式能减少产品团队自身的工作量。有时，这仅仅源于一种误解：产品团队以为自己不应该承担这项工作。例如，在向 DevOps 模式转型时，产品团队需要开始自行维护基础设施，这种情况就很容易发生。

在这种情况下，平台团队就变成了工程组织内部的一个小型专业服务团队，代表客户将平台产品集成到客户自己的系统中。

这种专业服务模式结合了多种协作方式。首先，产品团队通常会提交工单，请求平台团队提供服务。这与前面讨论的平台迁移模式类似，只是方向相反：在这里，是产品团队向平台团队提交工单，寻求帮助。随后，平台团队可以通过“可信外部贡献者”或“内部开源”模式来实际完成工作。

这种协作模式的一个常见例子，是产品团队需要进行一些基础设施变更时。他们可能想要启动一项新服务，向 API 网关注册一个新的外部端点，或者更新一些配置值，于是向平台团队提交工单，请求平台团队代为完成相应变更。

这种模式在基础设施领域尤其常见，因为它延续了一种既有习惯：在自助式基础设施出现之前，提交工单是产品团队申请基础设施变更的标准机制。

白手套式入门支持

对于一个仍处于早期阶段、文档尚不完善的平台，平台团队可能会选择采用“白手套式”服务模式来引导新的产品团队。他们会与这些早期用户并肩工作，帮助他们快速上手。这既能减轻首批产品团队的负担，加速新平台推广，也能让平台团队获得宝贵洞察，了解早期用户实际如何使用平台能力。

这种白手套式支持通常通过短期驻场协作模式实现：一个或多个平台工程师会花一段时间融入使用团队，在该团队内部完成所需的平台集成工作。

实践社群

随着平台日趋成熟、使用体验不断改善，平台团队可以逐渐停止直接承担集成工作，转而扮演更偏咨询和引导的角色。

这种咨询模式可能包括举办“办公时间”，让使用团队可以来提问；也可能包括安排平台团队代表参与使用团队的规划和设计会议，提供有针对性的建议和指导。用《团队拓扑》的术语来说，这相当于平台团队以“促进”模式与其他团队互动。

对于规模庞大、功能丰富的平台而言，最终可能会转向一种同伴互助模式。平台团队会投入时间，为平台用户建立实践社群。这可能包括建立社区即时通讯频道或邮件列表，定期举行实践社群会议以寻求帮助、分享创新想法，甚至可能包括举办年度从业者非正式会议。为了让这些跨团队协作不只停留在线下沟通中，团队也可以使用 Worktile 这类通用项目协作系统，将任务、项目、文档、日历、甘特图、审批等协作信息集中管理，降低平台团队与产品团队之间的信息同步成本。

亲自下场无法规模化

可以看到，平台团队需要向使用者提供多少实际支持，很大程度上取决于平台开发者体验的成熟度：文档是否完善，集成是否容易，操作是否顺畅。

在平台发展的早期阶段，平台团队投入大量精力满足用户需求是合理的。此时，开发者体验可能还不成熟，平台能力可能仍在不断扩展，而用户团队也未必愿意投入时间来充当“小白鼠”。此外，与产品团队并肩工作，也是平台团队了解客户及其需求的绝佳方式。

然而，亲自提供实施支持并不能规模化。如果目标是让平台被广泛采用，平台团队就必须持续投资于平台的开发者体验，避免自己被具体实施工作淹没。

同时，平台团队也必须清晰地向平台用户传达他们可以期待怎样的支持模式。如果产品团队在平台早期获得了周到细致的支持，那么除非平台团队明确说明变化，否则他们未来很可能会继续期待同样的体验。

平台演进：让内部平台持续适应团队需求

接下来，我们来看平台协作的最后一个阶段：平台演进。在这一阶段，使用平台的团队需要对平台本身进行修改，以弥补平台能力上的不足。

例如，使用 UI 组件库的团队可能需要新增一种按钮组件类型，或者为现有按钮组件增加额外的配置选项。又或者，使用服务框架的团队可能希望该框架能够提供更详细的可观测性信息，或者支持新的序列化格式。

可以看到，在平台演进阶段，团队之间的角色与平台迁移阶段正好相反：现在是产品团队在推动工作，但变更需要发生在平台团队拥有的代码库中。

那么，在这种背景下，哪些跨团队协作模式是合理的？

平台演进中的协作模式

提交工单

产品团队可以向平台团队提交工单，请求他们对平台进行必要修改。但这种做法往往会令人沮丧。产品团队通常只有在真正需要某个功能时，才会意识到平台缺少这项能力。而平台团队可能需要很长时间才能对该需求进行优先级排序并完成开发——毕竟，平台团队通常已经不堪重负，手头堆满了各种请求。结果就是，平台团队成为瓶颈，阻碍了产品交付团队的进度。

临时调配工程师

如果提前做好充分规划，团队可以通过临时调配工程师的方式，来补足平台能力上的缺口，从而完成所需的平台增强工作。产品工程师可以到平台团队短期轮岗，或者平台工程师也可以暂时加入产品团队，担任嵌入式专家。

工程师在不同团队之间调动，必然会对短期生产力造成影响。但从长期来看，安排一名驻场工程师可能会提高效率，因为这能减少产品团队与平台团队之间所需的跨团队沟通。驻场工程师可以充当沟通大使，理顺沟通渠道，减少信息传递过程中的“传话”损耗。

这种模式背后存在一个权衡：一次性的前期成本，换取后续持续收益。因此，重新调配工程师最好用于较大的平台改进。如果只是为了一个很小的变更，就将一名工程师调到另一个团队几周，往往弊大于利。

这类临时派遣也需要相对成熟的管理机制，以避免嵌入式工程师感到孤立。此外，如果将平台工程师作为嵌入式专家调入产品团队，他们也可能逐渐沦为普通“帮手”，只负责平台使用方面的工作，而没有真正参与产品团队所需要的平台改进。

远程操作平台代码库

如果平台团队采用了内部开源模式，那么产品团队可以选择直接自行实现所需的平台变更。平台团队的角色主要是提供咨询支持，包括设计建议以及审核产品团队提交的 Pull Request。经过几次 PR 审核后，产品工程师甚至可能赢得平台团队足够的信任，获得提交权限，成为“可信外部贡献者”。

许多平台团队都渴望达到这种状态：如果客户能够自主改进平台，从而减少平台团队的工作量，那该多好！然而，内部开源的现实与普通开源类似：支持外部贡献需要大量投入，而且绝大多数用户并不会成为真正有意义的贡献者。

因此，在开放代码库供外部团队贡献之前，平台团队应该谨慎行事，并做好充分准备来支持这些贡献。如果一个平台团队在全体会议上自豪地宣布他们的代码库是共享资源，但随后却发现自己不得不反复拒绝其他团队贡献者提交的变更，那么各方都会感到非常沮丧。

结论：平台团队协作模式需要随阶段变化

通过考察平台迁移、平台使用和平台演进这三个阶段，我们可以清楚地看到，团队围绕平台展开协作的方式多种多样。

显然，并不存在一种放之四海而皆准的协作方式。最佳协作模式不仅取决于团队采用平台所处的阶段，也取决于团队之间以及系统之间接口的成熟度。期望一个新的内部平台能够像成熟的外部服务一样，以完全无需人工介入的“即服务”模式被集成，往往是不现实的。同样，期望轻松修改一个从未接受过外部贡献的产品交付团队代码库，也是不切实际的。

要协作，但只是暂时协作

在《团队拓扑》中，作者指出，为两个团队设计良好边界的最佳方式，通常是先让它们以专注且高度协作的模式共同工作，例如采用“嵌入式专家”或“短期轮岗”模式。这段时间可以用来探索：在系统之间以及团队之间，最佳边界和接口应该设在哪里。康威定律告诉我们，这两者密不可分。

然而，《团队拓扑》的作者也提醒我们，不要在这种协作模式下停留太久。平台团队应该努力定义自己的接口，并尽快转向“即服务”模式，例如使用“提交工单”或“内部开源”等机制。正如我们在“平台使用”部分讨论的那样，对于平台团队而言，协作式交互模式无法真正规模化。此外，协作模式也会增加使用团队的认知负担。转向更放手的交互方式，可以让产品交付团队把更多时间集中在自己的业务成果上。事实上，《团队拓扑》将降低认知负荷视为平台团队的决定性目标——我非常认同这一点。

在我看来，对于一个年轻的平台团队来说，如何从高度协作模式转向服务模式，是他们面临的最大挑战之一。客户已经习惯了高度个性化的体验；而编写优秀文档很难，拒绝客户请求也很难。

以协作模式运作的平台团队，应当密切关注自身面临的扩展性挑战。随着转向更可扩展、更易管理模式的需求日益明显，平台团队应该开始向客户预告这种变化。尽早说明交互模式将如何变化以及为什么变化，可以让产品团队有机会做好准备，并开始转变他们对平台的认知，使其更加自主、高效地使用平台。

这一转型过程可能会很痛苦，但犹豫不决只会让情况更糟。产品交付团队会非常感谢平台提供方明确说明支持方式的规则。此外，摆脱对人工协作的依赖，也会强烈激励平台团队改进自助服务界面、文档和其他开发者体验。康威定律在这里同样适用：重新定义团队之间的集成方式，也会影响团队所构建系统之间的集成方式。

总的来说，平台团队的成功离不开与其他团队的协作，而这种协作可以采取多种形式。选择合适的协作模式，需要考虑其他团队正在开展的是哪一类平台相关工作，也需要务实评估双方团队及其系统的现状。正确选择协作方式，有助于平台团队提升内部平台采用率。但随着采用率不断增长，团队也必须有意识地转向更易运作、更具扩展性，并能最大限度降低平台用户认知负荷的协作模式。

如果用一句话总结：平台团队不能只关注平台能力本身，还要关注平台迁移、平台使用和平台演进过程中与产品团队的协作方式。只有协作模式与平台成熟度相匹配，内部平台才能真正被采用，并持续创造组织级价值。