回顾 Enterprise Engineering Summit 2025
我于 10 月 22 日和 23 日参加了 Enterprise Engineering Summit 2025，并决定使用 Gibbs' Reflective Cycle（吉布斯反思循环）来回顾这次经历。
描述
10 月底，我和几位同事参加了一场为期两天的会议，主题是大型企业中的 platform engineering（平台工程）实践。我们希望了解 platform engineering 如何在其他组织中落地，并收集一些能够帮助我们改进自身平台团队实践的见解。
活动安排了由行业专家主持的多场演讲和圆桌讨论，分为以下三个主题：
我主要参加了 Platform Engineering 主题的活动，听取了以下演讲：
| 日期 | 演讲 | 演讲者 | 组织 |
|---|---|---|---|
| 周三 | 在整个企业范围内将平台视为产品 | Bruno Suarez Laffargue（布鲁诺·苏亚雷斯·拉法格） | Tesco |
| 周三 | 利用 AI 加速产品开发生命周期 | Noud Donders（诺德·东德斯） | Ex-Maersk |
| 周三 | 圆桌讨论：在平台生态系统中平衡自治与治理 | Simon Rohrer（西蒙·罗勒）、Jacob Lärfors（雅各布·拉尔福斯）、Benjamin Brial（本杰明·布里亚尔） | Saxo Bank、SOK、Cycloid |
| 周三 | 从遗留平台中淘出金子 | Donovan Thomson（多诺万·汤姆森） | Utility Warehouse |
| 周三 | 在保持可靠性的同时扩展平台工程 | Italo Vietro（伊塔洛·维耶特罗） | Parloa |
| 周三 | AI 驱动的开发者效率：工具、权衡与切实影响 | David Graca（大卫·格拉萨） | AXA |
| 周三 | Capital One 的转型之路：重新思考云端敏捷 | Tom Morton（汤姆·莫顿） | Capital One |
| 周三 | Platform as a Product——在 DKB 为开发者交付真正的价值 | Stephane Di Cesare（斯特凡·迪·切萨雷） | DKB |
| 周三 | 通过社区学习与协作打造卓越工程 | Daniel Gittins（丹尼尔·吉廷斯） | Ford |
| 周四 | 大规模提升开发者技能——复杂工程组织中真正有效的方法 | Alistair Watkins（阿利斯泰尔·沃特金斯） | Lloyds Banking |
| 周四 | 如何将战略融入开发者生产力 | Niko Kivela（尼科·基韦拉）、Jacob Lärfors（雅各布·拉尔福斯） | SOK |
| 周四 | 圆桌讨论：应对全球团队与远程文化：分布式企业中的开发者体验 | Pablo Fernandez（巴勃罗·费尔南德斯）、John Knowles（约翰·诺尔斯）、Fatima Mookhtiar（法蒂玛·穆赫蒂亚尔） | Pexels at Canva、Capital One、Maersk |
| 周四 | 以清晰为准则：追踪从推送到生产环境的代码 | Dima Prekrasnyi（迪马·普列克拉斯尼） | Westwing |
| 周四 | 缩减规模并清理整顿：在 GroupOn 管理遗留系统 | Nick Simmonds（尼克·西蒙兹） | GroupOn |
| 周四 | The Gym Group 如何通过全方位 observability（可观测性）打造富有韧性的 SRE 文化 | Colm Campbell（科姆·坎贝尔） | The Gym Group |
| 周四 | 铺设路径与平台转型——通过战略赋能推动 DevEx 演进 | Ionut Craciunescu（约努特·克拉奇乌内斯库） | Utility Warehouse |
| 周四 | 证明平台的价值：将成本中心转变为战略价值引擎 | Lobo Olsson（洛博·奥尔松） | HelloFresh |
感受
我怀着好奇和希望参加了峰会。虽然我们已经和平台团队一起构建了一些有用的共享解决方案，但我觉得，我们还有很多东西可以从其他组织构建和管理其平台工程工作的方式中学习。
听取演讲时，我的感受既有验证，也有挫败。许多演讲介绍了成熟的平台团队：他们拥有明确的实践、更充足的工程资源，以及专门负责将平台工程作为产品进行管理的岗位。看到我们面临的许多挑战在各个组织中都很普遍，这让我觉得自己的判断得到了验证；但看到有些团队已经远远领先于我们当前所处的阶段，也让我感到挫败。不过，其他团队已经实施的解决方案也让我受到启发，并促使我想把其中一些想法带回我们自己的团队。
离开时，我对未来的道路既感到谦逊，也感到兴奋，同时思考着我们可以采取哪些务实步骤来推动平台团队发展。
评价
有些演讲与我们的情况关联较小，尤其是来自高度监管行业以及资源非常充足的大型企业的分享。
不过，了解各组织正在采用的各种方法，并找出支撑成功平台团队的共同基本做法，而不论其规模或所属行业如何，仍然非常有意思。
特别有意思的是，了解不同组织如何使用指标衡量平台团队是否成功，以及听取一些资源有限的公司管理遗留系统的案例。
分析
我在 2023 年写过一篇博客文章，概述了我们平台团队面临的一些挑战。现在回头看这些问题，并观察它们如何与峰会上的主题相呼应，很有意思。
优先级排序
我曾写到，我们在优先级排序方面面临挑战：需要平衡不同产品团队相互竞争的需求，并确保平台工作与更广泛的业务目标保持一致。
峰会上的几场演讲强调了将平台视为产品的重要性，并指出应设置专门的岗位来了解用户需求，进而据此确定工作优先级。例如，Bruno Suárez Laffargue（布鲁诺·苏亚雷斯·拉法格）介绍了自己在 Tesco 担任 Head of Product for Engineering Effectiveness 的工作，以及他们如何根据开发者反馈和业务影响确定平台计划的优先级。
在工程团队中培养 product mindset（产品思维）是反复出现的主题，强调平台团队不能只考虑构建功能，还应关注为用户交付价值。
有些组织有资源设置专门的产品工程岗位，而在我们的情况下，可能需要探索如何将这种思维融入现有岗位。
峰会还强调，使用调查和指标收集开发者反馈并衡量平台计划的影响，是有效进行优先级排序的关键实践。这里经常使用 DX，我们之前也曾考虑在 Mintel 采用这一工具，同时还开发过自己的工具来收集 DORA metrics 和 design system adoption metrics。
安排时间与过早共享
我还写过关于时机方面的挑战：在明确需求出现之前过早构建东西，与等待太久、最终成为产品团队的阻碍之间存在风险。
几场演讲强调了说“不”的重要性，并指出这在平台生态系统中是一种健康的做法。平台团队需要避免成为瓶颈，而这有时意味着要拒绝那些与更广泛的目标不一致，或不适合纳入平台的请求。
演讲中还普遍提到，应鼓励团队自治，赋予产品团队在平台规范范围内做出决策和构建解决方案的权力。这样可以减少对平台团队的依赖，并加快开发速度。
一场有趣的圆桌讨论重点探讨了自治与治理之间的平衡。来自 Saxo Bank、SOK 和 Cycloid 的嘉宾讨论了他们如何在组织内部管理这种平衡。其中一个观点是，试图支持所有事情，可能会让平台抽象层变得比底层工具更加复杂，从而违背降低开发者认知负担的初衷。
构建真正有人使用的东西
我还写过构建最终无人使用的东西所带来的风险：这些东西可能无法满足用户需求，也可能是因为团队更愿意构建自己的解决方案。
这与前面在优先级排序部分讨论的内容有关，但采用曲线也带来了一些有意思的观点。几场演讲强调了共同创建的重要性，即让开发者参与平台解决方案的设计和开发，确保解决方案满足真实需求。
Ionut Craciunescu（约努特·克拉奇乌内斯库）介绍了他们在 Utility Warehouse 切换到托管 Kafka 服务时，如何在早期使用 RFCs 收集反馈，并在开发者之间建立共识。这种方法帮助他们确保解决方案满足用户需求，并提高了采用率。
遗留系统
我还提出了一个问题：人们往往倾向于构建新解决方案来替代遗留系统，而不是改进和维护现有系统，这其中存在诱惑，也存在风险。
有几场有趣的演讲涉及这一主题。Donovan Thomson（多诺万·汤姆森）介绍了 Utility Warehouse 如何引入 A/B 测试，以验证从纸质邮件账单切换到数字账单所带来的影响，从而量化收益并说服利益相关者。
GroupOn 的 Nick Simmonds（尼克·西蒙兹）介绍了他们在 GroupOn 处理遗留系统时采取的务实方法，重点是渐进式维护和降低成本。他谈到，可靠性是一项 economic decision（经济决策），并提出了在遗留系统中识别 crumple zones（缓冲区）的想法：这些区域发生故障时可以被容忍，而不会影响系统中最有价值的功能。
成为知识孤岛
最后，我还提出了平台团队成为孤岛、与其他团队使用平台时每天遇到的问题脱节的风险。
几场演讲提到了建立社区和促进跨团队协作的重要性，包括定期开展跨团队社区活动和聚会。一些组织还会举办自己的内部开发者大会，将来自企业各处的工程师聚集起来，分享知识和最佳实践。
团队调动和工程师交流也被认为是增进平台团队与产品团队之间同理心和理解的有效方式。Daniel Gittins（丹尼尔·吉廷斯）介绍了 Ford 如何每年举办一项活动，让开发者选择下一年希望加入的团队，从而体验业务的不同部分并建立跨团队关系。DKB 的 Stephane Di Cesare（斯特凡·迪·切萨雷）介绍了他们如何使用 shadowing（跟岗观察）来了解开发者的需求和痛点。
AI & LLMs
我上一篇文章没有涉及的一个方面，是 AI 和大语言模型对平台工程的影响；这是演讲中经常出现的主题。
考虑我们的平台解决方案如何支持 AI 工具的使用，从而提高开发者生产力，这很有意思。SOK 的 Niko Kivelä（尼科·基韦拉）和 Jacob Lärfors（雅各布·拉尔福斯）介绍了他们计划构建自己的 Internal Developer Portal（内部开发者门户）解决方案，以更好地支持与 AI 编码工具的集成，而不是使用 Backstage 这样的现成解决方案。
AI 编码工具也常常宣称能够大幅提高生产力，但这些说法应如何衡量和验证？David Graça（大卫·格拉萨）介绍了他们如何在 AXA 使用开发者生产力指标来衡量 AI 工具的影响。
结论
对我来说，了解其他组织如何开展平台工程是一次非常有价值的经历。对我而言，主要收获如下：
- 将平台视为产品，对于有效进行优先级排序并为开发者交付价值至关重要。即使没有专门的产品工程岗位，我们也需要找到一种方法，将产品思维融入现有岗位。
- 收集开发者反馈并使用指标衡量平台影响至关重要。我们应探索工具和流程，帮助我们更有效地完成这项工作，不仅要衡量平台开发的影响，也要衡量对 AI 编码工具的投资所产生的影响。
行动计划
我接下来的计划是：
- 与团队其他成员分享这些想法
- 重新审视我们收集开发者反馈和衡量平台影响的方式，并寻找将这些内容更充分地纳入优先级排序流程的方法
- 寻找机会建立更多跨团队社区并开展协作