我参加了于 10 月 22 至 23 日举办的 2025 企业工程峰会，并决定运用吉布斯反思循环来回顾这次经历。

描述

10 月底，我和几位同事参加了这场为期两天的会议，会议聚焦于大型企业中的平台工程实践。我们希望进一步了解其他组织如何落地平台工程，并收集有助于改进自身平台团队工作方式的见解。

本次大会由行业专家带来了多场演讲和圆桌讨论，分为三个议题方向：

• 平台工程
• 开发者体验
• 可观测性与 SRE

我主要参加了平台工程专场，听取了以下演讲：

感受

我带着好奇与期待走进峰会。虽然我们的平台团队已经构建了一些实用的共享解决方案，但我觉得在平台工程的组织与管理方式上，我们还有很多值得向其他组织学习的地方。

在聆听演讲的过程中，我的心情交织着认同感与挫败感。许多分享展示了他们成熟的平台团队——实践规范、工程资源充沛，还有专人以产品化的方式运营平台工程。看到我们面临的许多挑战在其他组织中同样存在，让人感到些许宽慰；但看到有些团队已经远远走在我们前面，又不免感到沮丧。不过，其他团队的解决方案也给了我启发，让我更有动力把这些想法带回团队。

离开时，我既感到谦逊，也对未来的道路充满期待，开始思考我们可以采取哪些务实的步骤来推动平台团队的演进。

评估

有些演讲与我们的实际情况关联不大，尤其是那些来自强监管行业或拥有雄厚资源的超大型企业的分享。

不过，了解各种不同的实践方式，并从中提炼出支撑成功平台团队的共性基础方法，仍然非常有意思，无论团队规模或所属行业如何。

特别有意思的是了解不同组织如何运用指标来衡量平台团队的成效，以及聆听那些资源有限却仍在有效管理遗留系统的企业故事。

分析

我在 2023 年写过一篇博客，谈及我们平台团队面临的一些挑战，回过头来看这些观点如何与本次峰会的主题相呼应，颇有意思。

优先级

我当时提到，我们在优先级排序上遇到挑战——需要在不同产品团队相互竞争的需求之间取得平衡，并确保平台工作与更广泛的业务目标保持一致。

在峰会上，多场演讲都强调了将平台视为产品的重要性，并设立专门角色来理解用户需求、据此确定工作优先级。例如，Bruno Suárez Laffargue 谈到了他在 Tesco 担任 Head of Product for Engineering Effectiveness 的角色，以及他们如何基于开发者反馈和业务影响来为平台举措排序。

在工程团队中培养 product mindset 是一个反复出现的主题，凸显了平台团队不能只关注功能搭建，而要聚焦于为用户创造价值。

虽然有些组织有资源设立专职的产品工程岗位，但在我们的现状下，或许需要探索如何在现有角色中融入这种思维方式。

通过问卷和指标收集开发者反馈、衡量平台举措的影响，也被强调为有效排序的关键实践。DX 是其中被频繁提及的工具，我们之前在 Mintel 也曾考虑引入，此外我们还曾自研工具来采集 DORA 指标和设计系统采用率指标。

排期与过早共享

我也曾谈到时机把握的挑战：在需求尚不明确时过早构建的风险，与等待过久、反而成为产品团队阻碍之间的两难。

多场演讲都强调了学会说“不”的重要性，认为这在平台生态中是一种健康的做法。平台团队需要避免成为瓶颈，有时就意味着要对那些与整体目标不一致或不适合纳入平台的需求予以回绝。

另一个常见的主题是鼓励团队自治，让产品团队在平台规范内自主决策、构建解决方案。这有助于减少对平台团队的依赖，加快开发速度。

一场精彩的圆桌讨论聚焦于自治与治理之间的平衡，来自 Saxo Bank、SOK 和 Cycloid 的嘉宾分享了他们在各自组织内如何把握这一平衡。其中一个观点是，试图面面俱到反而会让平台抽象比底层工具本身更复杂，违背了为开发者降低认知负担的初衷。

打造真正有人用的东西

我还提到过打造出无人问津的东西的风险——要么是因为未能满足用户需求，要么是因为团队更倾向于自建方案。

这与前文优先级部分提到的观点有所关联，此外关于采用曲线也有一些有意思的见解。多场演讲强调了共创的重要性，即让开发者参与到平台方案的设计与开发中，以确保真正贴合实际需求。

Ionut Craciunescu 分享了他们在 Utility Warehouse 切换至托管 Kafka 服务的过程中，如何在早期通过 RFC 征求反馈、凝聚开发者共识。这一做法有助于确保方案满足用户需求，并提升了采用率。

遗留系统

我提出的另一个观点是，相比改进和维护现有系统，另起炉灶用全新方案替换遗留系统的诱惑与风险。

有几场颇有启发的分享涉及这一话题。Donovan Thomson 谈到在 Utility Warehouse 引入 A/B 测试，以验证从纸质邮寄转向电子发票的影响，从而用可量化的收益来说服相关方。

来自 GroupOn 的 Nick Simmonds 分享了他们应对遗留系统的务实做法，聚焦于渐进式维护与成本削减。他提到可靠性是一个 economic decision，并提出了在遗留系统中识别 crumple zones 的理念——即那些即使出现故障也不会影响系统核心价值功能的区域。

沦为知识孤岛

最后，我还提出了平台团队沦为孤岛、与其它团队在日常使用平台时遇到的问题脱节的风险。

多场演讲都提到构建社区、促进跨团队协作的重要性，例如定期组织跨团队社群和交流会。一些组织还会举办内部开发者大会，让来自业务各方的工程师汇聚一堂，分享知识与最佳实践。

团队轮岗与工程师交流也被提及为增进平台团队与产品团队之间共情与理解的有效方式。Daniel Gittins 谈到在 Ford，他们每年举办一次活动，让开发者可以选择来年想加入的团队，从而体验业务的不同环节、建立跨团队联系。来自 DKB 的 Stephane Di Cesare 则分享了他们如何通过影子跟岗来发现和理解开发者的需求与痛点。

AI 与大语言模型

我在之前的文章中未曾涉及的一个话题，是 AI 与大语言模型对平台工程的影响，而这正是本次峰会上的热门议题。

思考我们的平台方案如何支持 AI 工具以提升开发者生产力很有意思。来自 SOK 的 Niko Kivelä 和 Jacob Lärfors 谈到，他们正计划自建内部开发者门户方案，以更好地集成 AI 编程工具，而非直接采用 Backstage 这类现成方案。

AI 编程工具常常宣称能大幅提升生产力，但如何衡量和验证这些说法呢？David Graça 分享了他们在 AXA 如何利用开发者生产力指标来评估 AI 工具的实际影响。

结论

聆听其他组织如何开展平台工程，对我而言是一次非常宝贵的经历。对我来说，主要收获有以下几点：

• 将平台作为产品来运营对于有效排序和为开发者创造价值至关重要。即使没有专职的产品工程岗位，我们也需要找到在现有角色中融入产品思维的方式。
• 收集开发者反馈并通过指标衡量平台影响至关重要。我们应当探索更有效的工具与流程，不仅用于平台本身的建设，也用于衡量在 AI 编程工具上投入的成效。

行动计划

我的下一步计划是：

• 与团队其他成员分享这些思考
• 重新审视我们目前收集开发者反馈、衡量平台影响的方式，并寻找将其更好地融入优先级决策流程的办法
• 寻找机会建立更多跨团队社群与协作