移動開發團隊協作優化一套共用程式碼提升產能

工程師自豪的擁有權和現實斷層裡的困局

從功能孤島到平台化。嗯，這標題看起來很像什麼產品發表會的主題，但其實是我們自己的碎念。唉，講白了，我們重組行動端工程，就是想讓速度、責任感還有擴展性這三個老大難問題，不要再互相扯後腿。本系列打算分成三篇，今天就是第一回，「為了更快前進：我們怎麼去改造 Zenjob 的行動端開發方式」。啊，好像標題又太正經？沒關係，繼續。

Zenjob 一直自詡工程文化很強調自主與那種「我就是負責」的精神。欸，可是話說回來，在2023年以前，那些美好理想離現實還真是有點距離耶。iOS 跟 Android 的應用，其實已經被搞得複雜到爆炸，一般工程師就算手癢也很難直接參一腳，所以各團隊都必須仰賴一對專門人員。說真的，有時候找人問個 bug 都像在傳紙條。

然後呢，那種知識孤島的情形愈來愈嚴重，加上對行動端專業的需求又忽高忽低——唉唷，要人沒人，要事情一堆，協作根本卡住。有時我甚至懷疑，到底為什麼非得要搞得這麼分散？啊拉回來啦。所以結果就是交付週期無限拉長，誰該負責也不明不白，有時候大家都躲起來裝死，也不是誰願意，只是真的不知道接下去怎辦才好吧。

需求忽高忽低，規劃一團亂，還要假期請假了誰補？

通往成功的路上，好像從來沒人說過會很簡單，對吧？我們其實試了好幾種方法想要應對那些讓人頭痛的挑戰——有時半夜還會突然想到一個點子，然後第二天又覺得，好像也不是那麼管用。最後，我們總算找到了一套比較合用的解法，大概可以這麼說。本篇文章就打算跟大家攤開來聊聊：我們到底都做過哪些嘗試？哪些方式有奇效？哪些則根本不如預期、甚至讓人懷疑人生。

先說第一招好了，就是找移動端工程師直接塞進產品團隊裡。不知道你有沒有聽過Zenjob？嗯，他們到2022年底之前，在行動端開發這塊，基本策略就是把iOS和Android工程師當專才丟進每個功能型小組。初看感覺挺合理的嘛，但現實總是不太配合劇本。

某些情境下，這樣分工確實有效，可是……久而久之，你會發現問題慢慢浮現出來。有時候明明以為溝通暢通無阻，但細節處卻卡關卡得要命。效率開始下滑、彼此間默契也漸漸稀薄。不曉得是不是只有我們這樣，但真的令人煩躁。

產能管理，也是一大難題。怎麼講呢？市場環境變化快到連茶都泡不完就換新方向。團隊優先事項三天兩頭改來改去，有時剛適應一個目標，下一秒又全部翻盤——唉，講真的，要保持敏捷反應已經夠累了，還得隨時拉緊神經，不然很容易被捲走。所以在維持彈性與高效間掙扎，其實天天都在上演。欸，有點離題了，拉回正軌——總之，「產能管理」真的是讓團隊焦慮指數飆升的重要因子之一啦。

Comparison Table:

結論	內容
集中管理行動端工程師的優勢	減少技術債務、提升平台穩定性，能更有效解決公司層面的複雜問題。
跨平台開發挑戰	行動端團隊需在Android和iOS上各自重複開發，增加時間成本與資源浪費。
轉型為平台型團隊的好處	賦能產品團隊參與行動端開發，減少瓶頸，提高整體流程效率。
教育與資源共享的重要性	提供學習資源及課程，以促進不同背景工程師的能力提升，建立「可信賴工程師」。
未來展望與改進方向	計畫將原生App改寫為共用程式碼底子，期望降低重複工作，提高整體開發效率。

知識藏在個人腦袋裡，專家不在什麼都卡住

唉，有時候想想，怎麼工作搞到這麼複雜。你看，現在行動裝置專家突然一下子超搶手，下一秒又好像被完全遺忘了一樣。有些團隊會莫名其妙冒出一大堆臨時的行動支援需求，但同一時間別的團隊卻連個影子都沒有。我有點納悶，到底大家到底有多依賴？欸，不過回來說正事啦，其實這全都跟 [bus factor] 偏低扯上關係，加上工程師經驗參差不齊，每次遇到假期、育嬰假或是有人突然要去緊急支援其他專案，那可用性真的變得亂七八糟。講白一點，專案規劃根本沒辦法預測，每一次跨專案協作不是卡住，就是整個時程失控，好像永遠在玩射飛鏢似的。

然後還有知識孤島這問題，真的是讓人頭痛啊。每個產品團隊基本都只能倚靠那幾位熟 iOS 跟 Android 的行動工程師，他們成了自家小圈子的寶貝，而其他人對行動開發嘛…坦白說，大部分只懂皮毛罷了。有時候我也會想，是不是該多學一點？但很快又忙著處理 bug 忘記了。不扯遠好了，就因為只有行動工程師真正明白那些系統裡面使用者介面的細節，所以全端負責變得越來越困難。合作起來也怪彆扭，只要碰到和行動有關的東西，就會自然而然地分出一道鴻溝，被歸類成「需要特殊技能」才能搞定的東西。所以喔，有些事情是真的蠻無奈的吧。

八年遺留技術債，複雜度與日俱增的惡性循環

行動端工程師在自己產品團隊裡，嗯，確實累積了很多背景知識啦，可是說真的，他們碰到系統其他部分的機會蠻少的，大多時候也就只是靠 pull request 審查去知道一點相關東西。這樣其實有點像隔著玻璃看世界？我常想，是不是大家也都這麼過活。

然後唉，複雜度這件事又來了。每次討論怎麼讓產品即時上線、趕著解決眼前需求，那些長遠技術優化…總會被擱在旁邊發霉。八年欸，我們各平台都已經連續開發超過八年，那種技術債務你說能不積下來嗎？反正它就是慢慢疊高。我想到前幾天還有人跟我抱怨，每次調整 APP 都覺得頭很痛。

而且越久越複雜，你根本只能賴行動端專家幫忙釐清和維護。有時想，要是沒有他們在，也許就沒人搞得懂那些繞口令一樣的模組。啊，突然想到昨天吃完飯差點忘記洗碗（好啦，拉回主題）。所以你看嘛，就是一個自我強化循環：愈難愈依賴專家、然後非專業的人更參與不了；再多一般人手進來，好像也插不上話。如果大家手頭本就忙，哪還有時間翻舊帳試圖處理深層問題？於是要掙脫這種困境——唔，大概只會越來越難吧。

把所有移動端聚成一隊，好像問題少了一點但新麻煩來了

講真的，每次遇到這些挑戰，心裡都忍不住嘆口氣——哎，怎麼還是大家各做各的？這種各自為政的行動裝置開發方式，說到底，是挺累人的。唉，有時候想，不知道大家是不是也有一樣的挫敗感？總之啦，現在看起來，好像有某些蛛絲馬跡告訴我們，是時候換個腦袋；要更協作、更整合才行。嗯，不只是那些所謂的行動裝置專家在那邊忙，也應該讓非行動裝置工程師能夠參一腳。其實講白了，就是希望每個人都能在自己擅長的事情上發揮吧。不過，欸，我剛剛好像差點忘記重點了——還是得拉回來說，這樣一來，那些專門搞行動裝置的人也許就可以去琢磨比較高層次的創新，而不是一直被日常瑣事拖住腳步。

然後啊，他們又想出了一種新的做法——把行動裝置團隊直接當成產品團隊來運作。有點繞口，可是真的這麼決定了。嗯……主要就是針對之前碰到的問題嘛，所以團隊最後下了一個蠻重要的決策：乾脆組建一支專責處理行動裝置的新隊伍。老實講，一開始我還懷疑這會不會只是改名而已，可是他們給自己定了兩個目標呢。一方面，要把所有跟行動裝置相關的東西集中起來管理；另一方面……噢，我話題又飄走了。但總之，他們想讓工作模式變主動，不再只是在那裡等著修補別人丟過來的小問題。嗯，大致如此吧——雖然說起來簡單，其實背後細節多得很難一次講清楚。

大家一起協作，產能上升了些，可是優先順序還是不太對

我們其實沒有把行動端工程師拆散丟進各產品團隊啦，反而弄了一個統一的隊伍，專門hold住全公司的行動端開發。唉，有時候我都覺得這樣會不會太集中了點？但初衷真的不只為了日常那堆雜事，也還有加強平台穩定性、技術債務減少（這詞聽起來就讓人頭痛），然後是推創新。不過……說到需求波動啊，其實集中管理還挺頂用的——欸，我剛才差點忘記我要講什麼，回來繼續。

當所有行動端工程師都聚在一塊兒，他們不必再因不同產品團隊的瘋狂節奏，被拉來扯去地搞得工時超負荷，又或者閒到發呆；現在比較多能量可以直接花在那些公司層面的大麻煩。嗯，話說回來，其實也沒那麼美好，有些人可能會想念原本自己領域的小圈圈，但整體看下來，他們確實能對公司全貌更熟悉，不像之前那樣井底之蛙，只看到自家的一隅。

而且喔，把人都拎出來組成專責部隊，好處也不是只有方便派任務而已——雖然bus factor（就是某個關鍵員工一請假大家就慘了）這風險變大是真的啦。可是，同時間要處理兩三件事，好像比以前單飛容易一點？突然想到昨天手機又當機，不知是不是技術債問題……咳，離題了，那個，集中式管理還有另一個妙處，就是很多bug和老舊問題容易浮上水面，因為大家步調一致，可以即時交換心得，相互協作，把那些重複出現的鳥事給一起解掉。

嘗試讓非移動工程師參戰，多平台基礎訓練開始出現

唉，有時候真的很煩——光是不同產品團隊之間要怎麼排優先順序這件事，就已經夠頭痛了。就算把行動端的工作統整到一起，嗯，流程是簡化沒錯，可是問題還是一大堆。因為行動端團隊得負責所有前端功能，結果呢？在一堆產品團隊之間拉扯來拉扯去，平衡需求什麼的根本就是場硬仗，而且領域歸屬感跟自主權也會互相踩線，搞得彼此有點小摩擦。唉，好像偏題了，但這情緒真的很難壓住，算了還是說回正事。

## 第三種方式：行動端作為平台型團隊

把行動端團隊聚在一起後，很快就發現單靠內部自己扛起全部任務，其實根本不太現實，也不可能一直撐下去。然後我們開始想，是不是該讓產品團隊的人也更主動地參與？說白話一點，就是少點瓶頸，多點賦能——所以方向轉成「平台型」團隊，反正就是盡量讓別人也能上手行動端開發啦。有一次我突然想到，不如讓 iOS 工程師去碰一下 Android 的基礎內容吧（雖然他們一開始滿臉問號），同樣道理，Android 工程師也是要摸一摸 iOS 的基本東西。這樣至少每個行動工程師都能處理兩個平台的入門級事情吧，不然遇到交接什麼的根本崩潰。

欸但說實話，要做到這個其實得花錢買教育課程啊，不然學習資源哪裡來？還有，每週還得抽時間出來專門學習，不安排真的會忘記初衷。另外，我們偶爾會辦些專案設定說明會、或者問答小聚，協助那些比較不熟悉行動開發領域的產品工程師慢慢建立信心。其實這過程也挺溫吞的，但看著大家願意參與，好像又覺得沒那麼無力了。

指南、Q&A、pair programming——人人都能碰手機，但要有人黏合才不會散掉

這些安排，唉，說穿了就是想讓大家不用每分每秒都巴著專業工程師不放嘛。某些原本和行動端八竿子打不著的團隊裡，有幾位工程師也慢慢地變成了那種「可信賴工程師」——講白一點，就是他們後來就像團隊裡 iOS 或 Android 相關疑難雜症的主責窗口。突然想到，其實我一直搞不懂「可信賴」到底怎麼定義啦，好吧，還是先回主題。

我們還丟出一份蠻明確的指引，專門在什麼時候一定得找行動端工程師插手、又有哪些狀況反倒鼓勵大家自己來。例如，如果只是要加個用戶追蹤事件，那就老老實實看文件好了——文件寫得其實算詳細，而且各式現成範例也不少，所以通常根本沒必要煩工程師本人直接處理。可是只要碰上超級複雜又需要很深技術底子的改動時，我們會建議：與其自己硬撐，不如乾脆採結對程式設計，邊做邊學比較快，也能順便互相交流一下腦筋。

話說回來，有沒有覺得外部請求有時真的像洪水猛獸？反正為了解決這問題，我們拉了一個叫 [glue] 的角色進來，就是有人專職去梳理支援需求、統整所有溝通管道，也方便大家集中注意力不要被外界一直干擾。最後，不免俗地我們還整理了一份學習資源清單，希望產品線上的工程師如果閒下來，可以隨手翻翻，加減提升一下自己在行動端方面的技巧啦。不然誰知道哪天就派上用場？

瓶頸消除了一半，每週釋出仍然感覺慢；兩套原生app寫到懷疑人生

轉向平台思維這事啊，其實我們就是想讓產品團隊能從頭到尾負責行動端開發，然後整個功能交付都自己來，這樣一來就可以省掉很多奇怪的交接流程，也希望前置時間能縮短。唉，有時候想到那些年常卡住的點……不說了，拉回來。如果瓶頸真的少一點、大家又能把完整開發過程掌握在手裡，新功能推得就會快多了，而且品質也比較一致，不容易出現那種「欸？怎麼又對不上」的窘境。

說起來，行動端團隊現在也終於不用每天埋頭苦幹各種繁瑣事務，可以更專注去處理技術債或是現代化架構這些比較關鍵、但老實講常被忽略的東西。有時候我還蠻羨慕那種只需要專心搞大方向、不用天天救火的日子。不小心岔題了，拉回正題。反正這波調整除了對行動平台短期內可擴展性有幫助之外，更重要的是釋放了一些團隊資源，所以大家終於可以把時間花在測試、自動部署、監控等自動化相關領域上——據說這些也是加速前置時間的一大法寶吧。

其實這套作法算是引爆了一連串更大層面的變革啦，影響感覺像悄悄蔓延開，在組織裡不斷浮現新狀況。欸，其實我們現在已經有一些行動工程師懂得跨平台操作，但現實很殘酷，每個平台該做的還是得分別弄一次。有時候明明只是要改個文案，就因為兩週一次版本發布和分階段推送機制，一拖可能四週才會讓Zenjobbers收到更新。嗯，就算真的狠下心把發布頻率壓成一週，也難保不會遇到兩套不同實作或多組人馬同時搶著找行動端支援想拼加速進度那種場面。所以嘛，事情總是不像預期那麼簡單，好吧。

終於決定，一套共用程式碼，從此想快就快，看誰還說不行

我們這次，嗯，算是第二回試這個方法吧。說真的，到目前為止雖然前進了一點，但「自主性」這回事還卡在一個很煩的點──所有東西都得重頭再做一次。你想像一下，無論團隊收到多少資源、支援什麼的，每當要給行動端上新功能，都繞不過必須在兩個平台各自寫一遍的事實。我有時候會想：「欸？怎麼又重複？」然後才意識到原來沒其他選項。

這樣下來，排程整個拖長，而且注意力也分散掉了，好累喔。有時候我甚至會在半夜亂想，如果可以不用一直複製貼上就好了。反正最後，我們就…算是下了一個比較激烈（其實也沒到很狂啦）的決定：直接把原本用 Kotlin 和 Swift 分別開發的那些原生 app，全數改寫成同一份、共用的程式碼底子。

唉，講起來簡單，其實心裡還是有點毛毛的。不過這樣子的話，產品團隊終於能用自己最順手、最喜歡那套技術堆疊，不管從頭到尾參與哪個階段，都比較自在。對了，我剛剛是不是又扯遠了？總之現在，有了這轉變後，全公司的人都能一起動手，把行動平台打磨得更完整、更強大。

下一篇嘛，大概會講我們怎麼挑方案和開始搬移工作流程吧……好像已經可以預見自己又會分神去查資料（苦笑）。