在 KubeCon & CloudNativeCon 欧洲大会上，Eugenia Bergman 和 Hagen Tonnies 分享了他们如何在平台规模超出单个团队使用的范围后，从项目思维转向产品思维。他们认为，平台存在的局限性包括一次性交付、缺乏产品愿景以及反馈循环薄弱。如今，他们已经转向一种 API 驱动的自助式多租户基础设施。该架构拥有更清晰的责任归属和更完善的抽象层。
Bergman 提到，他们平台的开发周期是围绕年度项目规划来组织的。工作通常从前期范围界定、预算分配和明确交付里程碑开始。每个项目都被视为一个具有明确起止时间的独立项目，其成功与否取决于是否在范围、时间和里程碑方面都达到了预期目标：
当平台仅支持向提供游戏流媒体产品的组织提供单一服务时，这种模式运转良好。但随着时间的推移，我们的平台需要逐渐演变，从而支持多个具有不同需求的内部团队。这从根本上改变了系统的性质。
Bergman 提到了他们认为该平台存在的几个局限性：
- 每次改进都被视为一次性交付
- 这会导致积累的功能在优先级上与下一轮交付产生冲突
- 该平台没有明确的产品定义
Bergman 表示，虽然他们是持续交付，但并未能始终如一地改善整个平台的易用性或一致性。反馈循环主要在内部进行，围绕冲刺表现（速度、完成率、质量）展开，几乎没有来自平台实际用户的验证。系统优化针对的是任务完成率，而非长期价值。
Tonnies 解释说，在外部影响与内部反思的双重启发下，他们从项目导向转变为产品导向：
我们有些早期的同行就已经开始引入系统思维和产品思维，借鉴 Prometheus 和 Grafana 等开源生态系统的实践。而在内部，我们也开始研读《从项目到产品》和《凤凰计划》等著作，从中认清了我们自身面临的许多痛点。
Tonnies 表示，这促使架构师和高级工程师之间形成了一个小型实践社区，他们在其中就这些想法展开讨论，并探索当前模型的替代方案。
Tonnies 解释道，随着时间的推移，他们的开发平台发生了显著的演变。它从来都不是一个统一的平台，而是一套围绕 Kubernetes 和 GitOps 实践有机发展起来的能力集：
早期，该平台以基于 Helm 的部署、命名空间级资源管控、GitLab 驱动的工作流为核心，团队通过内部 IDP 模式加入，并主要在共享集群中运行。在标准化应用程序交付方面
，这种模式效果良好，但主要是针对单服务团队进行优化，未能完全满足更广泛的多租户需求或更复杂的基础设施需求。
随着其生态系统的扩展，尤其是随着 AWS 等公有云服务的推出，他们观察到，用户期望自然而然地发生了转变：团队逐渐习惯了自助式基础设施和更清晰的所有权模式。Tonnies 解释道，这凸显了他们改善内部平台体验的机遇，特别是在抽象化、文档编写以及实现平台与用户职责之间更明确的关注点分离方面：
我们一直在向更关注产品的平台模式演进。该模式具有更清晰的租户边界、更强大的自助服务能力，以及更明确的基础设施配置和管理接口。
Tonnies 总结道，如今，他们正在投资于更高层次的抽象概念，例如环境和项目构造，以及更贴合云服务提供商范式的 API 驱动型工作流。这是一个持续进行的过程，但方向很明确：朝着更具可扩展性、以用户为中心的松耦合平台迈进。该平台既能赋能团队，又能在整个组织内保持一致性和有效的治理。
InfoQ 就其平台向产品化模式转型一事，对 Eugenia Bergman 和 Hagen Tonnies 进行了专访。
InfoQ：是什么促使你们从项目导向转变为产品导向？
Eugenia Bergman：这一转变并非源于某一项单独的决策，而是由一系列我们无法再忽视的信号所驱动。我们观察到：
- 尽管采用了持续交付，待办事项却仍然在不断增加
- 其他团队会绕过平台开展工作，而非利用它
- 我们无法明确回答：我们构建的东西是否真的被使用了
- 我们并不总是能明确地回答：我们是否支持某些功能，甚至这些功能是否属于我们平台提供服务的范围
与此同时，我们意识到，自己不再仅仅是交付基础设施，而是向内部客户提供能力。这需要采取不同的方法：
- 从交付功能 → 到解决用户问题
- 从固定范围 → 到假设驱动的路线图
- 从输出指标 → 到采用率和可用性信号
从这个意义上说，转向产品化方法与其说是一次转型举措，不如说是对规模扩张的必要适应。
Hagen Tonnies：这种转变也源于长期以来对 Scrum 的怀疑态度。虽然我认可它的框架，但它往往无法真正地体现实际成果，也无法为团队营造合适的环境。产品思维似乎是一条能够更好地协调工程工作、用户价值和团队体验的途径。
InfoQ：你们的开发平台什么样？
Bergman：从宏观层面来看，我们的开发平台就像一个内部云服务提供商。
它提供了诸如 Kubernetes 集群、存储、网络以及支撑平台服务等基础设施能力。这些能力通过自助服务接口提供，主要采用 Kubernetes 原生模式，例如 API 和自定义资源。
从开发者的角度来看，目标是：
- 以代码形式配置基础设施
- 将平台能力直接集成到工作流中
- 避免手动协调或基于工单的流程
在内部，该平台的架构围绕服务层、控制层和管理层之间的关注点分离展开，采用可组合的构建模块来抽象底层基础设施，并通过契约来定义各层之间稳定的接口。
原文链接：https://www.infoq.com/news/2026/07/platform-projects-products/
