在 KubeCon & CloudNativeCon 欧洲大会上，Eugenia Bergman 和 Hagen Tonnies 分享了他们平台从支持单一团队扩张到服务多个内部团队后，如何逼着自己从项目思维转向产品思维。
在他们看来，旧模式的局限性很明显：每次改进都被当作一次性交付，功能堆砌导致优先级冲突，平台本身也从未有过清晰的产品定义。如今，他们已转向 API 驱动的自助式多租户基础设施，责任归属和抽象分层变得更加清晰。
Bergman 提到，早期平台的开发节奏完全围着年度项目规划转：需求先框定范围，再分配预算并标出里程碑，成功与否就看是否在范围、时间和里程碑上都达成了目标。
当平台只需要为一个提供游戏流媒体产品的组织提供服务时，这种模式运行得很好。但渐渐地，平台需要同时支持多个需求各异的内部团队，这从根本上改变了系统的性质。
Bergman 总结了当时认为的几个关键痛点：
- 每次改进都被视为一次性交付；
- 积压的功能在下一轮交付中常常互相“打架”；
- 平台缺乏清晰的产品定义。
虽然他们一直在做持续交付，但平台整体的易用性和一致性并没有得到持续改善。反馈循环主要只盯着团队内部的冲刺表现（速度、完成率、质量），几乎听不到平台真正用户的声音，系统优化也更偏向任务完成率，而非长期价值。
Tonnies 补充说，在外部影响和内部反思双重作用下，他们终于从项目导向切换到了产品导向：
一些早期的同行已经开始引入系统思维和产品思维，从 Prometheus、Grafana 这类开源生态中汲取实践经验。在内部，我们也开始研读《从项目到产品》和《凤凰计划》这类著作，慢慢认清了自己面临的许多痛点。
这就催生了一个由架构师和高级工程师组成的小型实践社区，他们在社群里反复讨论这些想法，并探索当前模式的替代方案。
Tonnies 解释道，随着时间的推移，开发平台发生了巨大演变。它从来就不是一个统一的大平台，而是一套围绕着 Kubernetes 和 GitOps 实践有机生长起来的能力集合：
早期，平台的核心是基于 Helm 的部署、命名空间层的资源管控、GitLab 驱动的工作流，团队通过内部 IDP 模式加入，多数时候跑在共享集群里。这种方式在标准化应用交付上效果不错，但主要是为单服务团队优化，没办法很好地满足更广泛的多租户需求或更复杂的基础设施场景。
随着生态不断扩展，尤其是 AWS 等公有云服务的引入，用户的期望悄然改变：大家越来越习惯于自助式基础设施和更清晰的资源所有权模式。Tonnies 指出，这正好凸显了他们改善内部平台体验的机会，尤其是在抽象化、文档建设以及让平台职责和用户职责分得更清等方面：
我们一直在朝着更产品化的平台模式演进——租户边界更清晰，自助服务能力更强，基础设施的配置和管理接口也更明确。
Tonnies 最后总结说，目前他们正大力投入于更高层级的抽象（比如环境和项目构造），以及更贴合云服务商范式的 API 驱动型工作流。这虽然是一个持续推进的过程，但方向已经非常明确：迈向一个更可扩展、以用户为中心的松耦合平台——既能真正赋能团队，又能在整个组织内保持一致性、做好治理。
InfoQ 专访实录
InfoQ：是什么促使你们从项目导向转向产品导向？
Eugenia Bergman： 这个转变并不是某一项单独决策推动的，而是一连串再也无法忽视的信号在逼着我们往前走。我们观察到：
- 尽管在持续交付，待办列表却一直在膨胀；
- 其他团队宁可绕过平台去干活，也不使用平台；
- 我们回答不了“我们构建的东西到底有没有被用过”；
- 我们也不总能够说清楚：我们到底支不支持某个功能，甚至这个功能到底在不在平台的职责范围里。
与此同时，我们意识到，自己不再只是交付基础设施，而是在向内部客户提供各种平台能力。这就需要一套完全不同的打法：
- 从“交付功能”转向“解决用户的问题”；
- 从“固定范围”转向“假设驱动的路线图”；
- 从“盯产出指标”转向“关注采纳率和可用性信号”。
从这个角度看，转向产品化并不是一次所谓的转型工程，而更像是在规模压力下一种顺理成章的进化。
Hagen Tonnies： 这种转变也来自我长期以来对 Scrum 的某种“不信任感”。虽然我认可这个框架，但它经常没有办法真正体现出实际成果，也没能为团队创造一个好的工作环境。产品思维看起来是一条能更好协调工程实践、用户价值和团队体验的路。
InfoQ：你们现在的开发平台是什么模样？
Bergman： 从宏观看，我们的开发平台就像一个内部云服务商。
它提供基础设施能力，如 Kubernetes 集群、存储、网络和一些支撑性的平台服务。这些能力都通过自助服务接口暴漏出来，采用的主要是 Kubernetes 原生模式，比如 API 和自定义资源。
站在开发者角度看，目标是明确的：
- 基础设施即代码，以代码形式完成配置；
- 将平台能力直接嵌入自己的工作流中；
- 彻底避开手动对接和以工单驱动的流程。
在内部，平台的架构围绕服务层、控制层和管理层实现关注点分离，用可组合的构建块来抽象底层基础设施，并通过定义好的契约来确保各层之间的接口稳定。
原文链接：
https://www.infoq.com/news/2026/07/platform-projects-products/
在云栈社区，我们同样持续关注平台工程与云原生领域的实践与演进，欢迎一起交流探讨。
发表于 1 小时前
|
查看: 4|
回复: 0
