從孤島到平台：企業數位轉型的組織整合策略與實踐要點

嗯...今天要來聊聊一個有點頭痛，但又蠻重要的事。就是關於團隊怎麼合作，特別是手機 App 開發這塊。

我自己是覺得，很多公司都喜歡喊「自主」、「敏捷」、「Ownership」這些口號，但真的去看手機 App 開發團隊，常常是另一回事。我們公司之前就是這樣，整個卡住了。

問題大概就是，iOS 和 Android 這兩個 App，搞了快八年，變得超複雜。複雜到只有那幾個「專家」才敢碰。結果就是，每個產品團隊都得嚴重依賴這幾個人，變成一個個知識孤島。然後需求又不穩定，有時候這個團隊忙到炸，另一個團隊的手機工程師又閒得發慌。真的，整個流程變得很慢，而且沒人能對一個功能從頭負責到尾。

重點一句話

說穿了，就是把手機開發團隊從一個「救火隊」，慢慢變成一個打造工具、讓所有工程師都能開發手機 App 的「平台團隊」。

第一次嘗試：把手機專家塞進各個團隊

一開始最直覺的想法嘛，就是把 iOS 和 Android 的工程師，像貼標籤一樣，分派到各個產品開發團隊裡面。想說這樣溝通應該最直接。

但...事情沒這麼簡單。很快就冒出幾個很頭痛的結構性問題。

首先是資源調度。你知道的，市場變化很快，團隊的優先級也跟著一直換。這就導致對手機專家的需求超級不穩定。有時候 A 隊突然需要大量手機開發支援，B 隊那邊卻完全沒事。然後這些專家人又不多，那個所謂的 [bus factor] 超低... মানে，就是負責的人只要一請假、去開會，甚至只是去忙別的緊急狀況，整個專案規劃就亂七八糟。時程根本沒辦法管。

再來就是，知識孤島的問題不但沒解決，還更嚴重了。每個團隊都把手機開發當成「專家」的事，其他人根本不碰也不想懂。結果就是，只有那幾個手機工程師知道 App 是怎麼跑的。他們雖然對自己團隊的業務很熟，但對整個 App 的其他部分就越來越陌生，頂多就是 review 一下別人的 PR。這讓整個團隊沒辦法做到真正的「全端負責」。

嗯...然後就是複雜度。為了趕產品上線，很多技術上的改善都被犧牲了。積了八年多的技術債，讓整個系統越來越複雜，然後大家就更依賴專家...這變成一個惡性循環，想跳出來都難。

第二次嘗試：好吧，那組一個「手機中央廚房」

既然分散開來有問題，那...不然全部抓回來？我們後來決定，成立一個專門的手機團隊。

目標很簡單：把所有手機開發的工作集中起來，從被動救火，變成主動規劃。這個團隊不只做日常開發，還要負責提升 App 的穩定性、還技術債、做一些創新。

這樣做，確實解決了資源一下過勞、一下沒事做的問題。我們可以更穩定地處理整個公司的優先事項。而且，手機工程師們終於可以跳出自己原本的小圈圈，看到整個產品的全貌。知識也開始流通了。

不過呢，新的問題又來了。這個「中央廚房」要怎麼決定先炒誰的菜？每個產品團隊都覺得自己的功能最緊急。這個手機團隊負責了所有的前端功能，結果變成一個巨大的瓶頸。到底誰該擁有某個功能的決定權？團隊之間的摩擦也變多了。

最後的解法：不當專家，當「平台」

集中管理之後，我們很快就意識到，靠一個團隊處理所有手機的任務，根本不可能規模化。想要賦予產品團隊真正的能力、減少瓶頸，唯一的路，就是從「專家團隊」轉變成「賦能平台」。

我們的角色，不再是「唯一會做手機 App 的人」，而是「幫助大家都能做手機 App 的人」。

具體做了幾件事：

• 技能打通：我們開始讓 iOS 工程師去學 Android 的基礎，反之亦然。至少讓大家都能處理兩個平台的基本維護。公司也給了額外的教育預算，還有固定的學習時間。
• 建立信心：我們辦了很多工作坊，帶著其他後端或網頁工程師一步步設定手機開發環境，回答他們的各種笨問題。慢慢地，有些團隊裡就出現了他們自己的「手機達人」，可以處理大部分的需求。
• 畫清界線：我們發布了明確的指南。哪些事情，比如加個使用者追蹤事件，你們可以照著文件自己做，範例也很多。哪些事情，因為改動太複雜，才需要我們（平台團隊）介入。而且只要需要我們，就盡量用 pair programming 的方式，帶著他們一起做，順便教學。
• 設立窗口：為了減少干擾，我們弄了一個 [glue] role（黏膠角色？）。這個人專門負責處理各種臨時的支援請求、集中溝通，好讓團隊其他人可以專心在長期目標上。

我自己是覺得，這個轉變最關鍵。我們不再是那個天天被追著跑的執行者，而是可以靜下來，專心處理更核心的戰略問題，像是處理技術債、現代化我們的架構、改善測試和部署的自動化流程。

這也讓產品團隊終於能「端到端」地負責自己的功能，從後端一路做到前端 App，交接變少，速度自然就快了。

三種模式走下來，感覺差在哪？

老實說，每個階段都有它的理由跟好壞。我把它們整理一下，可能比較清楚。

但...我們還是漏了一件最重要的事

走到平台這一步，感覺好很多了。真的。團隊能自己跑，速度也上來了。但，總覺得哪裡怪怪的。

那個最根本的問題一直都在：所有東西，我們還是得做兩次。

一次給 iOS (用 Swift)，一次給 Android (用 Kotlin)。

就算我們把發版週期縮短到一週，一個簡單到不行的文案修改，從開發到真正送到所有使用者手上，可能還是要花掉將近一個月。這還沒算兩個平台因為實作方式不同，跑出不同 bug 的鳥事。

就算我們把其他工程師都教會了，他們還是要花雙倍力氣去做同一件事。這...這根本稱不上真正的自主和效率。

所以，我們最後下了個更大、更狠的決心。

就是...砍掉重練。把兩個原生 App，整個重寫成一個單一、共用的 codebase。這聽起來超瘋狂，但我們想了很久，這是唯一能讓產品團隊擁有真正端到端所有權的方法，讓他們用自己熟悉跟喜愛的技術（對，就是 Web 技術）來做貢獻。

這個決定，才算是真正開始打造一個「行動平台」。一個整個公司都能貢獻的平台。這背後的故事...嗯，我們怎麼評估、怎麼開始遷移的，那又是另一個很長的故事了。

這條路真的走得很崎嶇。從頭痛醫頭、腳痛醫腳，到最後才發現是整個體質的問題。重寫聽起來很可怕，但說真的，有時候...這反而是最快的一條路。