行動應用程式開發停滯怎麼辦？創業者重啟專案的5個關鍵決策

你的 App 專案是不是也卡住了？

今天要來聊一個，嗯，一個很多人都遇過但超不想承認的痛點。就是你的 App 專案，做到一半，然後…就沒然後了。開發者回訊息越來越慢，進度報告永遠是「在處理了」，但你好幾週都沒看到任何能動的東西。錢燒了，時間花了，結果手上只有一堆跑不動的程式碼跟一肚子火。

我自己是覺得，這種鳥事真的太常見了。你可能覺得是自己倒楣，或是被開發者騙了。老實說，有時候是，但更多時候，問題比你想像的還要複雜，但也…也更有機會解決。

重點一句話

App 專案會停擺，十次有九次都不是技術真的搞不定，而是「人」跟「流程」出了問題，只是它剛好長得像技術問題而已。

為什麼 App 會做到一半動彈不得？

在想怎麼救之前，得先搞懂它是怎麼「死」的。我看過太多案子，原因差不多都是這幾種，真的，萬變不離其宗。

開發者人間蒸發（或變得像龜速一樣慢）

這超經典的。一開始熱情滿滿、秒回訊息的開發者，突然變成已讀不回。進度更新從「我今天完成了登入頁面跟 API 串接」變成「還在弄」。

你知道嗎，很多時候這不是他故意擺爛。我後來發現，有些獨立開發者或小團隊，他們會同時接好幾個案子。當壓力一來，他會下意識地先去處理那個時薪最高、或是最緊急的案子。如果你的專案是固定預算的，那…嗯，很抱歉，你的優先級可能就被默默排到後面去了。

錢快燒完了，但沒人敢說

這是另一個超級常見，但大家都假裝沒看見的大象。開發者最討厭開口講兩件事：一個是「這個我不會做」，另一個就是「老闆，要加錢了」。

所以他們會幹嘛？他們會選擇「慢慢做」。把剩下那一點點預算，用龜速前進的方式，盡量延長專案的壽命。他們希望拖到你自己發現不對勁，而不是由他來開第一槍。結果就是雙方都在猜忌，時間就這樣浪費掉了。

「只是加個小功能」的溫水煮青蛙

我也常在會議上看到這種情況。原本只是 15 分鐘的進度同步，結果開了兩小時，變成功能許願大會。「欸，我們能不能順便加個分享到 IG 的功能？很簡單吧？」「喔對了，使用者應該也能自己換頭像吧？」

每一個要求聽起來都很小，但六個「小要求」加起來，就足以讓你原本三個月的開發時程，直接延長到半年。這就是所謂的「功能蠕變」[Feature Creep]，專案殺手排行榜前三名。

真的踢到鐵板了

當然，有時候也確實是技術問題。比如，業主想要一個「簡單的」圖像辨識功能，結果發現這背後需要機器學習的專業，但原本的開發者根本沒碰過。或是要做一個超複雜的即時支付系統，牽扯到金流、資安，結果發現比想像中難一百倍。

這種時候，專案就會卡住，因為開發者不知道下一步該怎麼辦，他又不敢直接承認自己能力不足。然後，就沒有然後了。

怎麼做：你的專案急救SOP

好，問題我們知道了。如果你現在就身陷泥沼，下面這幾步是我通常在介入一個「待救援專案」時，頭 48 小時會做的事。你可以照著做，至少先止血。

第一步、也是最重要的一步：拿回你的程式碼

這不是不信任，這是商業。你付了錢的東西，就該在你手上。立刻、馬上，跟你的開發者約個時間，目標只有一個：完整的專案交接。

你得把話講清楚，你要的東西包括：

完整的程式碼庫存取權（GitHub, GitLab, Bitbucket...不管他們用什麼，你都要 Admin 權限）。
所有相關服務的帳號密碼、API 金鑰。
一份文件，或是一段螢幕錄影，教你怎麼在電腦上把這個專案跑起來。
目前已知的所有 Bug 清單。

很多人會覺得「這樣做是不是太撕破臉了？」。但換個角度想，如果對方合作得很順利，那代表他做事很專業。如果對方推三阻四，一下說「程式碼還很亂不能給」，一下說「我電腦壞了」，那這本身就是一個超大的警訊。這代表事情可能比你想的還嚴重。

第二步、就算氣到爆炸，也要專業地結束合作

我知道你可能很氣，但相信我，燒掉溝通的橋樑對你一點好處都沒有。我真的看過有老闆把離職的開發者罵得狗血淋頭，結果兩週後，新團隊有個環境設定問題卡關，全世界只有那個前開發者知道答案。你猜他會不會回信？

比較好的做法是，用一個很專業的口吻請他做交接。像是：「非常感謝你這段時間的付出。為了讓後續的交接更順利，能不能請你幫忙整理一下目前專案的狀況？」這樣通常能拿到最有價值的資訊。

第三步、檢查有沒有「版本控制」

這點可能比較技術，但超級重要。你得問清楚：「我們的程式碼有沒有用 Git 在管理？」如果答案是沒有，或是程式碼只存在工程師自己的筆電裡…天啊，那真的是災難。

版本控制（Version Control）像是你專案的時光機。有它在，新的開發者才能安全地修改程式碼，改壞了還能一鍵回到上個版本。如果沒有，請立刻建立一個，把現有的程式碼放上去。這件事沒得商量。

（對了順便分享，Git 不只是備份，它最重要的精神是紀錄了「誰、在什麼時候、為了什麼、改了哪段程式碼」。這對後續追蹤問題超有幫助。）

讓專案重回正軌的策略

止血之後，我們才能開始治療。下面這幾件事，是讓專案死灰復燃的關鍵。

找個第三方來「健康檢查」，聽實話

在找下一個開發團隊之前，先花點小錢，找一個完全無關的、有經驗的技術顧問或工程師，幫你做「程式碼審查」[Code Review]。

為什麼？因為你原來的開發者，或急著想接案子的新團隊，他們說的話都可能有偏見。我遇過一個創辦人，他之前的開發者跟他說「完成 90% 了啦！」，結果他沒做查證就直接找了新的人來收尾。新團隊接手後才發現，那個「90%」是灌水的，核心架構一團亂，實際完成度可能連 40% 都不到。這超痛苦的，但早點知道，總比晚知道好。

一個好的審查報告會告訴你：

現有的程式碼品質如何？是千瘡百孔還是還能救？
到底有哪些功能是真的「做完了」？
有沒有什麼隱藏的技術債或架構大坑？
一個比較實際的、完成剩餘工作的時間估算。

砍功能，要像個外科醫生一樣狠

這是創辦人最痛苦，但也最有效的一步。你已經投了這麼多錢，要再砍掉原本規劃好的功能，感覺像割肉一樣。但這能救你的命。

問自己三個很誠實的問題：

沒有哪個功能，我的 App 就完全沒有價值？（這個一定要留）
哪個功能跟我的賺錢模式直接相關？（這個也要留）
哪些功能很酷，但可以等 App 上線後，當作 2.0 版再來做？（這些先砍）

我從來沒看過任何一個創辦人後悔「用比較少、但做得好的功能先上線」。但我看過太多人因為堅持「完美的功能組合」而把公司拖垮。

第二次，怎麼找對人？

找新的開發者或團隊時，你的標準要不一樣了。你現在不是從零開始，而是在收拾爛攤子。這需要不同的技能。

你可以直接問他們：「聊聊你上一個『接手別人』的案子是什麼狀況？」「你通常怎麼去理解不是你寫的程式碼？」「你的判斷標準是什麼，決定哪些東西要重寫，哪些可以留著改？」

有「救援經驗」的開發者，價值連城。他們更務實，也更懂得如何評估風險。

再來，關於專案管理，我發現很多台灣的案主可能習慣了比較「隨性」的溝通，但國外像 Atlassian (Jira 的母公司) 他們發布的最佳實踐指南裡，會一直強調「Definition of Done」(完成的定義) 的重要性。這點在救援專案裡尤其關鍵。你必須跟新團隊在一開始就定義好，到底怎樣才算「一個功能做完了」？是程式寫完就好，還是要通過測試、沒有明顯 Bug 才算？先把這個講清楚，可以避免後面無窮無盡的爭吵。

「專案卡死」時，兩種完全不同的處理方式
處理項目	踩雷的做法（然後就沒有然後了）	比較聰明的做法（起死回生）
溝通方式	訊息石沉大海，只好一直催，搞得雙方壓力都很大。	直接約個時間，設定好議程，把問題一次攤開來講清楚。
程式碼處理	相信開發者說的「快好了」，不敢要程式碼，怕對方不開心。	把拿回程式碼的完整所有權當作第一優先，這是你的資產！
新功能要求	會議上想到什麼就加什麼，覺得「只是個小修改」。	建立一個變更紀錄，任何新想法都寫下來，評估對時程的影響，再決定做不做。
找下一個人	急著找下一個能「馬上開始」的人，不管他有沒有相關經驗。	先做獨立的程式碼審查，再找有「救援經驗」的開發者。