從專案思維轉向產品思維：如何打造真正被使用的平台
對於許多企業內部的平台工程（Platform Engineering）團隊來說，最常見的挫折莫過於：我們花了好幾個月開發了一個功能強大的內部平台，但最後發現其他開發團隊根本不用，或者使用過程極其痛苦。
這正是 Eugenia Bergman 與 Hagen Tonnies 在 KubeCon & CloudNativeCon Europe 分享的核心問題。他們指出，許多平台團隊陷入了「專案思維」（Project Thinking）的陷阱，而要讓平台真正成功，必須將其轉型為「產品思維」（Product Thinking）。
對於 Junior 工程師來說，這聽起來像是管理術語，但實際上這涉及到了溝通成本、介面定義以及對「價值」的衡量方式。
核心問題：專案思維 vs. 產品思維
在傳統的專案思維中，開發團隊的目標通常是「交付」。 定義： 只要功能按照需求文件（Scope）在預定的時間線（Timeline）內上線，就定義為「完成」（Done）。 後果： 團隊關注的是「把東西做出來」，而不是「別人怎麼用」。這導致平台雖然功能完整，但缺乏易用性、文件糟糕，甚至不符合使用者的真實痛點。
而產品思維則將平台視為一個對內銷售的產品。 定義： 功能上線僅僅是開始。只有當該能力被其他團隊可靠地使用、整合進生態系且能降低使用者的摩擦時，才定義為「完成」。 核心指標： 不再是「是否準時交付」，而是「是否有人在使用？」以及「是否真的減少了使用者的開發阻力？」。
技術實作：引入「生產者-消費者模型」
為了將產品思維落實到日常開發中，Bergman 引入了生產者-消費者模型（Producer-Consumer Model）。這將團隊之間的互動從「人對人」的協調，轉化為「介面對介面」的契約。
角色定義 生產者（Producer）： 提供特定能力（Capability）的團隊（即平台團隊）。他們負責定義清晰的介面（Interface）與預期行為。 消費者（Consumer）： 使用該能力的團隊（即應用開發團隊）。他們透過定義好的介面與平台互動，而非透過臨時的溝通。
從「會議協調」轉向「契約驅動」 在專案思維中，如果兩個團隊需要合作，通常會開很多會來對接。但 Bergman 提出了一個非常實用的經驗法則（Heuristic）：
> 「如果兩個團隊需要定期開會才能協調工作，那麼他們之間的介面（Interface）很可能定義得不夠清楚。」
當互動變成像 API 一樣具有明確邊界與預期時，協調成本（Coordination Overhead）會大幅降低，各團隊能進行更局部化的決策，而不需要每次都等待同步會議。
組織實踐與協作機制
將平台視為產品，不僅是技術問題，更是組織結構問題。Tonnies 提到他們參考了 Team Topologies 的概念來優化協作。
協作結構 每個產品領域由一名 產品負責人（Product Owner） 和一名 首席工程師（Lead Engineer） 代表。他們與其他團隊的對應角色對接，在 Sprint 週期內討論並精煉「契約（Contracts）」： 承諾（Promises）： 生產者提供的 API 或能力保證能做到什麼。 義務（Obligations）： 消費者在使用該能力時需要遵守的規範。
聚焦 80% 路徑 為了避免過度工程化（Over-engineering），他們採取聚焦於「共同使用案例（Common Use Cases）」的策略，即優先滿足 80% 的標準路徑，而非為了少數邊緣案例（Edge Scenarios）而增加系統複雜度。
如何衡量平台的成功？
如果不再用「交付日期」來衡量，平台團隊該如何證明自己的價值？Bergman 建議追蹤實際的採納信號（Adoption Signals）：
量化指標： API 請求量、活躍消費者數量、資源配置（Provisioning）活動、特定能力的調用頻率。 時間維度： 不同的能力有不同的採納週期。 * *快速信號：* 儲存配置（Storage Provisioning）或配額管理（Quota Management）通常在發布後立即產生數據。 * *慢速信號：* 網路架構或基礎設施拓撲能力，可能需要數週甚至數個規劃週期才會被整合進工作流。
關鍵的成功因素：組織容錯預算
轉型最困難的部分在於領導層的認同。Tonnies 提出了一個非常有意思的概念：組織容錯預算（Organizational Error Budget）。
就像 SRE（Site Reliability Engineering）會為系統設定錯誤預算一樣，組織在轉型過程中也需要空間去： 嘗試新方法。 從錯誤中學習。 在沒有立即面對僵化績效壓力（Rigid Expectations）的情況下調整方向。
這種安全感讓團隊能將轉型視為一個「學習系統」，透過觀察「預期」與「結果」之間的差距來持續迭代。
總結與工程判斷
對於工程師而言，這次轉型的核心啟示在於：技術能力的交付 $\neq$ 價值的交付。
適用情境 當你的內部平台雖然功能強大，但開發者抱怨難用或不願意遷移時。 當平台團隊與應用團隊之間充滿了無盡的同步會議，導致開發進度緩慢時。
限制與風險 心態轉變困難： 從「我做完了」轉向「別人用了」需要強大的文化推動力。 初期成本增加： 定義明確的契約與介面在初期比「隨便開會對接」更耗時，但長期能降低協調成本。
實務建議 如果你想在自己的團隊中實踐，可以嘗試從以下三點開始： 重新定義 Done： 將「功能上線」改為「功能被文件化 $\rightarrow$ 被可操作 $\rightarrow$ 被實際採納」。 審視會議： 檢查是否有重複發生的協調會議，並思考如何將其轉化為明確的介面定義。 追蹤數據： 不要假設使用者在用你的功能，建立基本的 API 監控來量化採納率。