回顧 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 |
| 週三 | 在維持可靠性的同時擴展 Platform Engineering | Italo Vietro（伊塔洛·維埃特羅） | Parloa |
| 週三 | AI 驅動的開發者效率：工具、取捨與具體影響 | David Graca（大衛·格拉薩） | AXA |
| 週三 | Capital One 的轉型之旅：在雲端重新思考敏捷 | Tom Morton（湯姆·莫頓） | Capital One |
| 週三 | 平台即產品——在 DKB 為開發者創造真實價值 | Stephane Di Cesare（史蒂芬·迪·切薩雷） | DKB |
| 週三 | 透過社群學習與協作打造卓越工程 | Daniel Gittins（丹尼爾·吉廷斯） | Ford |
| 週四 | 大規模開發者技能提升——在複雜工程組織中真正有效的做法 | Alistair Watkins（阿利斯泰爾·沃特金斯） | Lloyds Banking |
| 週四 | 如何將策略融入開發者生產力 | Niko Kivela（尼科·基維拉）, 雅各布·拉爾福什 | SOK |
| 週四 | 座談：駕馭全球團隊與遠距文化：分散式企業中的 Developer Experience | 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 |
感受
我帶著好奇與期待的心情進入高峰會。雖然我們的平台團隊已打造出一些實用的共享解決方案，但我覺得在平台工程的組織與管理上，還有很多值得向其他組織學習的地方。
聆聽演講時，我的心情交織著獲得肯定與些許挫折。許多演講介紹了成熟的平台團隊，其作法明確、工程資源充沛，並設有專職角色將 platform engineering 以產品的方式來經營。看到我們面臨的許多挑戰在各組織間相當普遍，令人感到被肯定，但同時也因看到有些團隊的進展遠遠領先我們現階段的狀態而感到挫折。不過，其他團隊所實施的解決方案也讓我深受啟發，並激起我將其中一些想法帶回團隊的動力。
離開時，我帶著謙卑與對未來道路的興奮，思考著我們可以採取哪些務實的步驟來演進平台團隊。
評估
有些演講感覺與我們的情境關聯性較低，特別是來自高度監管產業與資源極其豐富的大型企業的分享。
然而，能聽到各種不同作法的嘗試非常有趣，也能從中辨識出無論規模或產業為何，成功平台團隊背後共通的基礎作法。
特別有趣的是了解不同組織如何運用指標來衡量平台團隊的成效，以及聽到一些企業在資源有限的情況下如何管理既有系統的故事。
分析
我在2023 年曾寫過一篇部落格文章，點出我們平台團隊面臨的一些挑戰，回頭檢視這些要點，與本次高峰會的主題相當吻合，十分有趣。
優先順序
我曾談到我們在優先順序上遇到的挑戰，如何在不同產品團隊相互競爭的需求之間取得平衡，並確保平台工作與更宏觀的商業目標保持一致。
在高峰會上，數場演講強調將平台視為產品的重要性，並設有專職角色專注於理解使用者需求並據此排定工作優先順序。例如，布魯諾·蘇亞雷斯·拉法格談到他身為 Tesco 的 Head of Product for Engineering Effectiveness，如何依據開發者回饋與商業影響來排定平台倡議的優先順序。
在工程團隊中鼓勵 product mindset 是反覆出現的主題，突顯平台團隊需要超越僅僅建構功能，專注於為使用者創造價值。
雖然有些組織有資源設立專職的產品工程角色，但在我們的情境中，或許需要探索如何在現有角色中內化這種思維。
透過問卷與指標來收集開發者回饋並衡量平台倡議的影響，也被強調為有效排定優先順序的關鍵作法。DX 是此處常用的工具，也是我們在 Mintel 過去曾考慮導入的工具之一，此外我們也曾自行打造工具來收集DORA metrics與設計系統採用指標。
時程安排與過早分享
我也曾寫到時機掌握的挑戰。在需求尚未明確前就過早打造，與等待過久而成為產品團隊阻礙之間的風險。
數場演講強調學會說不的重要性，並指出這在平台生態系中是一種健康的做法。平台團隊需要避免成為瓶頸，有時意味著要回絕那些與整體目標不一致或不適合納入平台的請求。
另一個常見的主題是鼓勵團隊自主，賦能產品團隊在平台規範內自行決策與建構解決方案。這有助於降低對平台團隊的依賴並加快開發速度。
一場精彩的座談聚焦於自主性與治理之間的平衡，由來自Saxo Bank的西蒙·羅勒、來自SOK的雅各布·拉爾福什，以及來自Cycloid的班傑明·布里亞爾共同討論他們在各自組織中如何管理這種平衡。其中一個觀點是，試圖支援所有需求可能導致平台抽象層比底層工具本身更複雜，反而違背了降低開發者認知負荷的初衷。
打造真正會被使用的東西
我也曾談及打造出最終無人使用的東西的風險，原因可能是未能符合使用者需求，或是團隊偏好自行打造解決方案。
這與我在優先順序一段中提到的要點相關，此外關於採用曲線的討論也很有趣。數場演講強調共創的重要性，讓開發者參與平台解決方案的設計與開發，以確保符合真實需求。
約努茨·克勒丘內斯庫分享他們在 Utility Warehouse 轉向託管式 Kafka 服務的早期如何運用RFCs，透過 RFCs 收集回饋並建立開發者共識。這種做法有助於確保解決方案符合使用者需求並提高採用率。
既有系統
另一個我曾提到的要點是，為了取代既有系統而打造全新解決方案的誘惑與危險，而非改善與維護現有系統。
有幾場關於此主題的演講相當精彩。多諾萬·湯姆森分享在 Utility Warehouse 如何導入 A/B 測試來驗證從實體郵寄轉向數位發票的影響，藉此量化效益以說服利害關係人。
尼克·西蒙茲談到他們在 GroupOn 務實處理既有系統的做法，專注於漸進式維護與成本降低。他提到可靠性是一種 economic decision，並提出在既有系統中辨識 crumple zones 的概念，也就是在不影響最有價值系統功能的前提下可容忍失敗的緩衝區。
淪為知識孤島
最後，我也曾提出平台團隊淪為孤島、與其他團隊日常使用平台時遇到的問題脫節的風險。
數場演講提到建立社群與促進跨團隊協作的重要性，透過定期的跨團隊社群與聚會。有些組織會舉辦自己的內部開發者大會，讓來自企業各處的工程師齊聚分享知識與最佳實務。
團隊輪調與工程師交流也被提及為在平台與產品團隊之間建立同理心與理解的有效方式。丹尼爾·吉廷斯分享，他們在 Ford 每年舉辦一場活動，讓開發者選擇來年想加入的團隊，藉此體驗企業不同面向並建立跨團隊關係。史蒂芬·迪·切薩雷則分享他們如何運用影子跟隨作為發掘開發者需求與痛點的探索技巧。
AI 與大型語言模型
有一點是我先前文章未涵蓋的，即 AI 與大型語言模型對 platform engineering 的影響，這也是演講中常見的主題。
思考我們的平台解決方案如何支援運用 AI 工具來提升開發者生產力十分有趣。來自 SOK 的尼科·基維拉與雅各布·拉爾福什談到他們計畫自行打造 Internal Developer Portal(內部開發者入口網站)解決方案，以更好地支援與 AI 程式碼撰寫工具的整合，而非使用像Backstage這類現成解決方案。
AI 程式碼撰寫工具也伴隨著大幅提升生產力的宣稱，但該如何衡量與驗證這些宣稱呢？大衛·格拉薩分享他們在 AXA 如何運用開發者生產力指標來衡量 AI 工具的影響。
結論
對我而言，能夠聽到其他組織如何實踐 platform engineering 是非常寶貴的經驗。對我來說，關鍵收穫有：
- 將平台視為產品對於有效排定優先順序並為開發者創造價值至關重要。即使沒有專職的產品工程角色，我們也需要找到在現有角色中內化產品思維的方法。
- 收集開發者回饋並運用指標衡量平台影響至關重要。我們應探索能更有效協助我們做到這一點的工具與流程，不僅用於平台開發，也用於衡量投資於 AI 程式碼撰寫工具的影響。
行動計畫
我接下來的步驟：
- 與團隊其他成員分享這些想法
- 重新檢視我們收集開發者回饋與衡量平台影響的方式，並找出更有效地將其納入優先順序流程的方法
- 尋找建立更多跨團隊社群與協作的機會