我在 10 月 22、23 日參加了 2025 企業工程高峰會，並決定運用 Gibbs 反思循環來回顧這次經驗。

描述

十月底，我和幾位同事參加了這場為期兩天的研討會，主題聚焦於大型企業中的平台工程實務。我們希望更了解其他組織如何導入平台工程，並收集能幫助我們改善自身平台團隊實務的洞見。

活動由業界專家帶來多場演講與座談，分為三大主題軌道：

• 平台工程
• 開發者體驗
• 可觀測性與 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 則談到他們如何運用 shadowing 作為發掘開發者需求與痛點的一種探索手法。

AI 與大型語言模型

我在先前的文章中沒有涵蓋的一個主題，是 AI 與大型語言模型對平台工程的影響，而這在本次高峰會的演講中是常見的話題。

思考我們的平台解決方案如何支援 AI 工具以提升開發者生產力，是很有意思的課題。來自 SOK 的 Niko Kivelä 與 Jacob Lärfors 分享了他們計畫自行打造內部開發者入口網站解決方案，以更好地整合 AI 程式碼工具，而非直接採用像 Backstage 這類現成解決方案。

AI 程式碼工具往往宣稱能大幅提升生產力，但該如何衡量與驗證這些說法呢？David Graça 分享了他們在 AXA 如何運用開發者生產力指標來衡量 AI 工具的實際影響。

結論

聆聽其他組織如何實踐平台工程，對我而言是十分寶貴的經驗。對我來說，最重要的收穫有：

• 將平台視為產品，對於有效排定優先順序、為開發者創造價值至關重要。即使沒有專職的產品工程角色，我們也需要找到在現有角色中內化產品思維的方法。
• 收集開發者回饋並運用指標來衡量平台影響力至關重要。我們應該探索能更有效做到這一點的工具與流程，不僅用於平台開發，也能用來衡量投資 AI 程式碼工具的成效。

行動計畫

接下來我的下一步是：

• 與團隊其他成員分享這些想法
• 重新檢視我們目前收集開發者回饋與衡量平台影響力的方式，並找出更融入優先順序流程的方法
• 尋找機會建立更多跨團隊社群與協作