产品交付团队为公司的客户构建功能 - 他们正在构建的产品的最终用户就是公司的客户。我还看到这些类型的工程团队被称为“功能团队”、“产品团队”或“垂直团队”。在本文中，我将使用“产品团队”作为产品交付团队的简写。
相比之下，平台交付团队为公司内部的其他团队构建产品——平台团队产品的最终用户是公司内部的其他团队。我将使用“平台团队”作为“平台交付团队”的简写。
用团队拓扑的语言来说，产品交付团队通常被描述为流对齐团队。虽然团队拓扑作者最初定义了 平台团队作为一种独特的拓扑结构，他们随后将“平台”视为一个更广泛的概念，而不是一种独特的工作方式 。
当谈到团队拓扑术语时，一个好的平台往往会作为一个流对齐的团队（他们的平台是他们的价值流）或作为一个支持团队来运作，帮助其他团队通过他们的平台取得成功。
「平台」>内部开发者平台
目前围绕平台工程有很多讨论，主要集中在内部开发人员平台 (IDP)。我想澄清的是，这里对“平台”的讨论要广泛得多；它包含其他内部产品，例如数据平台、前端设计系统或实验平台。
事实上，虽然我们主要关注技术平台，但这里提出的许多想法也适用于提供共享业务功能的内部产品——金融科技公司的资金流动服务，或电子商务公司的产品目录服务。统一的特征是平台是组织内其他团队使用的内部产品。因此，平台团队正在构建其客户是公司内其他团队的产品。
平台采用的阶段
我们将研究需要平台团队和产品交付团队之间协作的三个场景：
- 平台迁移、
- 平台消费、
- 平台演进、
当我们审视这三个阶段时，重要的是要注意两个具体特征：哪个团队正在推动工作，以及哪个团队拥有工作将发生的代码库。这两个问题的答案极大地影响了每种场景中哪种协作模式有意义。
更详细点击标题。
总结
《团队拓扑》一书中指出，在两个团队之间设计良好边界的最佳方法是，最初以一种专注、协作性很强的模式一起工作。
这一时期可以用来探索系统之间和团队之间的最佳边界和界面（康威定律告诉我们，这两者密不可分）。
不过，《团队拓扑》的作者也警告说，重要的是不要在这种合作模式下停留太久。
平台团队应努力定义自己的接口，利用 "提交ticket "和 "内部开源 "等模式，快速转向 "即服务 "模式。
就平台团队而言，协作性更强的交互模式根本无法扩展。
此外，协作模式给消费团队带来了更大的认知负荷--转而采用更放手的交互方式，可以让产品交付团队将更多时间用于关注自身成果。
《团队拓扑》认为减少认知负荷是平台团队的定义目的