在擁有多個團隊的工程部門中，為了維持一致性並提升開發速度，勢必得針對常見問題建立標準化的解決方案。引進「平台團隊」來負責這些共用解決方案的做法，固然有助於解決專案維護與發展方向的問題，但同時也會帶來新的挑戰。

為何要成立平台團隊？

從基礎架構到應用程式開發，各個開發團隊都會面臨各式各樣的共通挑戰。為了提升生產力並確保一致性，針對這些問題建立標準化解決方案至關重要。這種做法能加快開發速度、降低維護成本、促進人員在團隊間的流動，並支援如 UI 品牌規範與 GDPR 合規等業務導向需求。

起初，這些解決方案往往是以臨時、隨興的方式共享——無論是複製程式碼、引入共用函式庫，或是串接其他團隊的 API。但若任由這些系統自然野蠻生長，缺乏整體方向、沒有人為長期維護負責、知識傳承也不明確，很快就會變得難以使用，甚至根本無法使用。成立一個負責這些解決方案的團隊，也就是常說的 「平台團隊」，或許能解決這些問題——但同時也會帶來另一組全新的挑戰。

優先順序

新成立的平台團隊最早會遇到的問題之一，就是優先順序。由於有眾多工程團隊都依賴平台，團隊很容易被拉往不同的方向。關鍵問題在於：該如何決定先處理什麼？

對於工程團隊而言，擁有一位 產品負責人 至關重要，尤其是採用 Scrum 的團隊。然而，要為平台團隊找到適合擔任此角色的人選並不容易。這個人必須對工程師提出的需求有足夠的技術理解，同時也要了解業務上的優先順序，才能在各項業務計畫之間做出有效的排序。實際上，往往很難找到既能勝任這個角色、又有足夠時間投入的人。

一種做法是成立一個委員會來做高層次的優先順序決策。成員可能包括資深工程師、架構師、產品經理與高階主管。不過，這個小組無法頻繁開會，因此仍需要有一位被授權的人來負責日常的優先順序與工作範疇決策，無論是與團隊緊密合作的資深工程師或主管皆可。

時程安排

即使已經訂好優先順序，平台團隊仍可能成為專案交付的單點故障與阻礙。不斷聽到專案因為平台團隊而卡關，既令人沮喪，也會造成實質傷害。平台的主要目標本是提升交付速度，但若跨團隊的依賴關係管理不當，反而會導致整體變慢。

一個實用的做法是採用「固定時程的專案」，就像 Basecamp 的 Shape Up 那樣。投入時程固定、範疇有限的專案，能比短週期的 sprint 更清楚地讓人知道團隊在較長時間內會交付什麼、不會交付什麼。「Betting Table」 的概念也很適合搭配前述的優先順序委員會模式。

如果你的平台團隊總是被多個專案同時淹沒，就是該重新思考的時候了。好的平台應該是讓工程師更快，而不是用各種阻礙讓他們慢下來。彈性是關鍵！透過清楚的文件，讓常見需求能夠自助式完成。平台團隊可以扮演像「顧問」一樣的角色，透過協助系統設計與程式碼審查來支援其他團隊，而不是把所有事都攬在自己身上。

別讓自己一直處於被動回應新功能需求的狀態。應該專注於讓其他工程團隊能輕鬆地自行做出變更。讓他們運用你提供的工具與框架去解決難題。如此一來，平台團隊的大部分工作自然就會集中在那些重大的新增功能或變革上。

打造大家真的會用的東西

身為平台團隊，你的首要任務應該是協助其他團隊解決問題。然而，一旦成立一個獨立的團隊，就很容易與其他工程團隊實際遭遇的困境脫節。

有一位產品負責人可以帶來很大的差別。要避免一頭熱地用某些解決方案去解決問題，結果卻是支援的團隊根本不想用——無論是因為不符合他們的使用情境，或是那個問題對他們來說根本不是優先事項。

別忘了，平台本身就是一項產品，而其他工程團隊就是你的客戶。目標應該是讓他們 想要 且 主動選擇 使用平台，而不是被迫使用。想辦法保持以客戶為中心，如果採用率偏低，先重新檢視你的解決方案，再去考慮如何「強制推行標準」。

太早共享

有了平台團隊之後，各式各樣的人都會想把自己認為很棒的點子推進來，當成「通用解決方案」，而平台團隊就成了這些點子的歸宿。要抗拒太早共享的衝動！

想僅憑一個具體的使用案例，就為共用系統抓到恰到好處的抽象層次，是不可能的事。太早投入共用實作，往往會導致 API 變得混亂，隨著新需求出現而不斷硬加上各種選項。在有多個使用方的情況下，要做出破壞性變更的代價非常高。

及早意識到某個功能未來有可能成為平台的一部分是好事，但還是要讓工程團隊保有自主解決問題的空間，即使之後有可能發展成平台層級的解決方案也一樣。

我發現 三法則 是決定是否將某個解決方案納入平台時，一個很實用的判斷準則：「一個可重用的元件，應該要在三個不同的應用程式中試驗過，才算夠通用、可以收進重用函式庫」。

• 第一次有人提出需求：就自己解決
• 第二次有人提出需求：一起檢視現有解法、協作進行系統設計，但還是各自實作
• 第三次有人提出需求：再來實作一個能同時支援三種使用情境的平台層級解決方案

汰換舊系統

如果你已經成立了平台團隊，很可能是因為已有一些自然演變而成的共用解決方案，而且很可能因為缺乏明確的所有權、系統設計與維護而陷入困境。這些系統或許難用到讓人頭痛、文件匱乏，甚至還跑在已經終止支援的軟體版本上。這時想要全部打掉重練的呼聲會非常誘人……但也充滿風險！

很有可能，全面重寫並不一定會更好，尤其是從使用者的角度來看。那些在線上久經考驗的解決方案，儘管雜亂，卻往往承載著長期累積下來的複雜業務需求。

更糟的是，它很可能永遠無法完全取代舊系統，特別是當舊系統已經被多處使用時。遷移到新系統會為其他團隊帶來額外的工作與風險。如果最後只有部分遷移，你等於把維護工作量加倍——同時要支援兩套系統，還要處理兩者之間功能分歧的問題。

當然，還是要找出理想的解決方案，但重點應放在對現有系統進行漸進式改良。當有人提議重寫專案時，就該提高警覺。更深入地理解現有系統、完整地記錄文件，並建立自動化測試，來提升團隊進行變更時的信心。

當然，有時大規模的汰換是無可避免且有其道理的，但在界定工作範疇時務必謹慎。要把實作階段以外的所有事情都納入考量——支援遷移、完善的驗證、文件撰寫，以及說服其他團隊優先處理轉換。別在沒有完整計畫的情況下就匆忙投入重寫。漸進式改良或許就能讓你省去日後許多不必要的麻煩！

淪為知識孤島

平台團隊也很容易淪為孤島，與其他團隊日常使用平台時遇到的問題脫節。成立一個團隊固然能讓一群人聚焦於共同目標，但同時也會劃出一條「我們」與「他們」之間的界線，進而引發衝突。

持續與人交流、主動去了解他們遇到的問題非常重要。工程師都不想被卡住，如果彼此之間沒有建立好關係，他們往往會選擇繞過你提供的解決方案中的問題，而不是主動來找你討論。

建立連結至關重要。要鼓勵開放的溝通，並讓別人容易找到你、願意與你交流。一個有效的做法是透過工程師輪調來分享平台知識。當團隊成員輪動時，他們會帶來新的視角與來自過往經驗的寶貴洞見。

歡迎來自部門各處的程式碼貢獻，以培養協作文化。你的使用者能提供獨特的觀點與寶貴的改進建議。別忘了，平台團隊雖然要為解決方案負責，但整個組織中的工程師都有能力為平台的成長做出貢獻。

歸根究柢，協作與開放的對話將造就更強大、更有效率的平台團隊。擁抱共享知識與多元觀點的力量，才能持續進步。

結論

引進平台團隊是為共用解決方案建立明確所有權的好方法，但它也帶來了一系列獨特的挑戰。

要取得成功，關鍵在於將平台視為一項內部產品。找到合適的人選來擔任產品負責人的角色，對於順暢運作至關重要。與其他團隊協作，打造一個讓工程師真心想用的平台。

別忘了，文件的重要性不亞於、甚至更勝於實作本身。優先把 API 設計做好，快速實作出來，然後將重心轉向撰寫詳盡、完整的文件。