从项目到产品：平台团队必须打破的2个思维定式

仅仅拥有一个平台还不够；真正的挑战在于确保用户能够理解和使用它，并且真正采用它。Eugenia Bergman 和 Hagen Tonnies 在 KubeCon & CloudNativeCon Europe 大会上介绍了他们如何让自己的平台从项目思维转向产品思维。

Bergman 提到，他们引入了生产者—消费者模型，以简化团队理解交互关系的方式。在该模型中，提供某项能力的团队是生产者，使用该能力的团队则是消费者。

这有助于明确依赖关系：

• 生产者定义清晰的接口和预期
• 消费者通过这些接口进行交互，而不是采取临时协调的方式

Bergman 表示，其中一项关键转变，是从通过会议和中间人进行协调，转向通过接口和契约进行协调。他们发现，一条实用的经验法则是：

如果两个团队需要定期开会来协调工作，那么它们之间的接口很可能没有得到明确定义。

通过采用更接近 API 的方式处理团队交互，并设定清晰的边界和预期，他们减少了协调开销，使更多决策可以在局部完成。

Bergman 提到，最初对我们来说，“完成”意味着项目或功能按照范围和时间表交付。当他们意识到这一定义并不适用于平台时，便转向一种更以产品为导向的定义：当一项能力能够被其他人可靠地使用时，它才算完成：

一项能力只有在集成到平台生态系统中、拥有文档且易于理解、获得支持且可以运维，并且真正被目标消费者使用时，才算完成。

为了评估进展，他们会问自己：“它有人使用吗？”以及“它是否减少了用户的阻力？”Bergman 表示，这有助于让开发工作与实际用户价值保持一致，而不只是关注交付。

Tonnies 表示，领导层的支持至关重要，但这种支持不是自上而下的命令，而是一股促成力量，为转型创造共识、信任和演进空间。最重要的是愿意支持实验、接受迭代，并认识到从项目转向产品，会从根本上改变团队规划、确定优先级和衡量成功的方式。

Tonnies 解释说，从架构角度来看，这也意味着需要拥有“组织层面的错误预算”——能够探索新方法、从失误中学习并改进方向，而不必立即承受满足僵化预期的压力：

这种安全感让我们能够将转型视为一个学习系统，在这个系统中，进展来自理解预期与结果之间的差距，并根据这一信号持续改进。

Tonnies 总结道，从项目向产品的转变并非完全由高层推动；它源于团队和用户观察到的真实阻力，而领导层让我们能够根据这些信号采取行动。拥有信任和受保护的实验空间，使我们可以与高级利益相关者展开有意义的沟通，在创新与责任之间取得平衡，并逐步建立一种更加以产品为导向的平台模式。

演讲结束后，InfoQ 采访了 Eugenia Bergman 和 Hagen Tonnies。

InfoQ：作为平台的生产者和消费者，各团队如何开展协作？

Hagen Tonnies：我们的团队作为生产者和消费者时所采用的协作模式仍在演进，但它正日益围绕明确的所有权和经过精心设计的交互点进行组织。在开展新的协作工作时，我们从 Team Topologies 中汲取灵感，学习了这些概念。通常，每个产品领域都由一名产品负责人和一名首席工程师代表，他们共同与其他团队中相对应的人员沟通，并就共享能力达成一致。这些互动通过定期沟通进行，通常融入冲刺节奏之中，团队会在此期间讨论并完善所提供内容与预期回报之间的契约。其中一项重点是明确这些关系——理解作为生产者的 API 或能力作出了哪些承诺，以及消费方需要承担哪些义务，并确保双方都以真实用例为基础。

主要挑战之一，是围绕这种生产者—消费者动态建立共同的思维模式，尤其是从隐式协调转向显式的契约驱动型协作。我们强调关注常见用例，即“80% 路径”，以确保持续交付价值，同时避免针对边缘场景进行过度设计。为此，我们引入了 Scrum Master 和产品运营经理等角色，帮助推动这些对话并改善团队之间的协调。与此同时，我们也在投资于指导和赋能，帮助产品负责人和工程师培养必要的技能，从而在以产品为导向、由 API 驱动的生态系统中有效开展工作。

InfoQ：你们如何追踪平台是否真正得到使用？

Eugenia Bergman：使用情况是我们有意识地衡量的指标，而不是想当然地作出假设。我们结合运维信号和以产品为导向的信号来追踪采用情况，包括 API 请求量、活跃消费者数量、配置活动，以及特定能力随时间推移的使用情况。

时间周期因能力而异。存储配置或配额管理等服务在发布后几乎会立即产生采用信号。网络或基础设施拓扑能力等其他服务的使用频率自然较低，团队可能需要数周时间或数个规划周期，才会将其集成到自己的工作流中。

最重要的是，我们能够观察一项能力是否有人使用，以及它是否正在创造价值。我们在这段历程中得到的一项重要经验是，交付功能并不等同于交付价值。只有在目标用户采用并依赖一项能力之后，它才算真正“完成”。