不懂技術的老闆怎麼管外包開發專案？里程碑與止損指南｜恆遠

不懂技術的老闆與外包開發團隊在會議室討論專案進度

「我每週都問進度，他每週都回『差不多 80% 了』，連續回了三個月。」這是一位做傳統製造業的老闆，在系統做到第五個月、準備上線前一週跟我們說的原話。他不懂程式，看不到後台，只能靠對方一句話判斷整個專案值不值得繼續付錢。後來那套系統沒能準時上線，已經付出去的兩期款也拿不回來。

如果你也是不會寫程式、卻得花幾十萬甚至上百萬發包一套系統的老闆，這篇就是寫給你的。你不需要看懂任何一行程式碼，但你需要一套「即使聽不懂技術，也能判斷專案有沒有走偏」的管理方法。

這件事的難度有數據可以佐證。Standish Group 長年追蹤 IT 專案結果，CHAOS 報告的統計 顯示只有大約 31% 的軟體專案算「完全成功」（準時、沒超預算、功能完整），50% 屬於「打折交付」，19% 直接失敗。換句話說，你發包出去的這套系統，照機率走有將近七成會出狀況——而且狀況的核心通常是管理問題，技術反而不是主因。

ℹ️這篇文章適合誰看

你是中小企業老闆或負責發包的主管，自己不寫程式，正要或正在外包一套客製化系統（POS、CRM、ERP、報價、會員、後台等），預算落在 30 萬到 300 萬之間，最怕的是「錢付出去、東西做不出來、或做出來不能用」。如果你已經有內部技術主管能幫你把關，這篇對你來說太基礎，可以直接看怎麼選客製化 AI 系統開發公司？7 個評估標準與合約必看條款。

不懂技術的老闆，到底卡在哪三件事

先把問題講清楚。不懂技術的老闆管理外包專案，真正卡住的從來不是「看不懂程式碼」這件事本身——畢竟你也看不懂律師的法條、看不懂會計師的分錄，照樣管得動律師和會計師。真正的差別在於，軟體專案有三個結構性的盲區，讓你比管其他外包更容易被矇。

盲區一：進度無法用肉眼驗證

蓋房子你看得到牆砌到哪、磁磚貼了沒；做網站系統，後台一片漆黑，你只能聽對方說「資料庫架構做好了」「金流串接中」。這些字你聽得懂，但你無法確認那是真的做完、還是只是 PowerPoint 上的一個方塊。資訊不對稱在這裡被放到最大。

盲區二：80% 陷阱——最後 20% 吃掉 80% 時間

軟體開發有個惡名昭彰的現象叫「90% 完成綜合症」：專案永遠卡在「快好了」。為什麼？因為前面 80% 是把功能堆出來，看起來很快；最後 20% 是把各種邊界情況、整合、測試、修 bug 補完，這部分最耗時也最不可見。老闆聽到「80% 了」會以為快結束，實際上可能才走到一半的工。

盲區三：你不知道自己漏講了什麼

你以為需求講清楚了，但你不是工程師，講的是「我要一個會員系統」，沒講「會員可以同時登入幾台裝置」「退費怎麼處理」「資料要不要匯出」。這些缺口在開發到一半才被發現，每補一個就是一次追加報價、一次延期。這就是業界講的 scope creep（需求蔓延）。多份 2026 外包統計 指出，需求蔓延影響超過半數專案，平均替預算增加 10% 到 20%，而高達七成的專案會因此延期。

這三個盲區疊在一起，就是那句「差不多 80% 了」能連騙你三個月的根本原因。好消息是，這三件事都有對應的管理手段可以拆解——而且全都不需要你會寫程式。

老闆參與 Sprint Demo 看可運行的功能展示

溝通成本才是隱形殺手：開工前先把節奏談好

很多老闆把專案失敗歸咎於「找錯廠商」，但攤開數據會發現，溝通問題的殺傷力遠比技術能力大。AlterSquare 整理的外包專案數據顯示，62% 的外包 IT 專案會超出預算，而溝通不良是造成失敗的 56% 主因；溝通崩潰甚至會讓時程拉長七成。技術差頂多做得慢，溝通差會讓你付了錢卻收到一個「對方理解的系統」，而不是「你要的系統」。

開工前，你要跟廠商把三件「節奏」談定，白紙黑字寫進合約或會議紀錄：

要談定的節奏	具體約定	為什麼重要
回報頻率	每週固定一次進度會議（30 分鐘內），有書面紀錄	把「差不多 80%」逼成「這週做完了 A、B 功能，下週做 C」
展示節奏	每 2-4 週一次可操作的 demo，由你親手點點看	讓進度從『口頭』變成『你能驗證的東西』
決策窗口	你方誰能拍板需求變更、多久內回覆	避免廠商以『等你回覆』當作延期藉口

這裡的關鍵字是「可操作的 demo」。Atlassian 對 sprint demo 的說明講得很直接：demo 要圍繞「使用者故事」和「業務成果」展開，而不是技術細節——因為利害關係人在意的是問題有沒有被解決，不是程式怎麼寫的。對你這個不懂技術的老闆來說，這正是你的施力點：你不用懂程式，但你絕對知道「這個功能符不符合我公司的實際流程」。

⚠️最危險的兩種廠商回報方式

第一種：只給你看『進度百分比』或『甘特圖顏色』，從不給你實際能點的東西——百分比可以隨便填，能操作的功能騙不了人。第二種：每次 demo 都用『假資料、理想路徑』跑一遍，從不讓你用自己公司的真實資料測。要求廠商用你的真實情境 demo，一測就知道是真做完還是表面功夫。

把整個專案切成五個你看得懂的里程碑

管理外包最有效的工具，是把一個你看不懂的「開發黑箱」，切成五個你能驗證、能對應付款的里程碑。每個里程碑都有一個「外行也能檢查」的交付物，做不到就不放下一期款。這套節奏跟 MVP 不是把功能砍少：找外包做 MVP 的 4 階段付款與驗收節點完整指南 講的分階段付款邏輯一脈相承，只是這裡聚焦在「你怎麼當場驗收」。

里程碑	廠商該交什麼	你（外行）怎麼驗收	建議付款比例
1. 需求確認	需求規格書 / 原型畫面（wireframe）	照著畫面講一次你的業務流程，看有沒有漏	簽約 20%
2. 介面設計	可點擊的 UI 設計稿（看得到長相）	找你的第一線員工試點，問順不順手	10%
3. 核心功能	最重要的 1-2 個功能可實際操作	用真實資料跑一次最常用的流程	30%
4. 完整功能 + 測試	全功能可用 + 你方人員 UAT 測試	列你最怕出錯的 10 個情境逐一測	30%
5. 上線穩定	正式上線並穩定運行一段時間	看實際使用一個月有沒有重大 bug	10%（壓在最後）

這張表有兩個設計重點。第一，每個里程碑的「驗收方式」都是外行能做的——你不需要看程式碼，只需要「照流程點一次、用真資料測一次」。第二，最後 10% 一定要壓在「上線後穩定運行」才付，因為這筆尾款是廠商願意認真修 bug 的唯一動力。把錢全付完，bug 就變成「下次再說」。

需求規格書怎麼確認、UAT 怎麼測，這兩件事細到可以各自寫一篇。如果你想要現成的範本，可以參考 軟體 RFP 怎麼寫？老闆版需求書範本與 30 條必備欄位 checklist 和 軟體驗收 SOP 與 UAT 測試清單：給找外包老闆的 30 點 checklist，把里程碑 1 和里程碑 4 的檢查做紮實。

七個不用懂技術也能察覺的危險訊號

專案走偏通常是一連串小訊號累積出來的，幾乎沒有一夕崩塌這回事。下面這七個訊號，你完全不需要技術背景就能察覺。出現一兩個還能補救，同時出現三個以上，就該認真評估止損。

回報越來越模糊：早期講「做完登入功能」，後期變成「整體進度推進中」「在優化架構」——具體變抽象，通常是進度卡住了。
demo 一直延期：說好兩週給你看一次，結果一拖再拖、或每次都「下次給你看完整版」——能跑的東西不怕展示，怕展示的多半是還沒做出來。
只給你看簡報、不給你操作：報告很漂亮、圖很多，但你從沒親手點過任何一個功能。
每次溝通都在追加報價：你提的需求對方都說「這個原本沒包含」——可能是當初需求沒寫清楚，也可能是廠商在用變更單補利潤。
聯絡的人一直換：原本對接的工程師離職、PM 換人，交接過程你的需求被遺漏。
回訊息越來越慢：從半天回變成兩三天回，通常代表這個案子在他們內部的優先級掉了。
拒絕把原始碼放進你能存取的地方：堅持不交付程式碼、不給你版控（如 GitHub）的存取權，等於把你綁死，換廠商時什麼都帶不走。

第七點特別要強調。Standish 的大型專案統計顯示，預算超過一定規模的 IT 專案有 45% 會超出預算、交付的價值比預期少 56%——而當你想中途換廠商時，「程式碼在不在你手上」直接決定了你是能止損、還是只能整套重做。合約裡一定要寫明：所有原始碼的著作權於付款後完全移轉，且開發過程程式碼存放在你能存取的版控倉庫。

專案進度儀表板與里程碑追蹤畫面

專案出狀況時，先別急著翻臉——用這張決策樹判斷

發現訊號不對，老闆的本能反應是「找對方理論」或「乾脆不付錢」。但翻臉之前，先冷靜跑一次下面這張決策樹，判斷現在是該溝通、該換人、還是該認賠。

圖表載入中…

這張樹的核心邏輯是：所有判斷都回到兩個事實——「有沒有能操作的東西」和「程式碼在不在你手上」。這兩件事都不需要你懂技術就能確認，卻決定了你的所有選項。把這兩件事顧好，就算最壞要換廠商，你也是「帶著半成品換人」，而不是「從零開始又賠一次」。換廠商與後續維運的決策細節，軟體外包驗收後的維運合約怎麼簽？3 種模式對比、12 條必看條款與換廠商決策樹 這篇有更完整的拆解。

ℹ️我們做過這件事

順帶說一下，恆遠自己做客製化系統開發時，就是用「每 2-4 週給客戶一個能親手操作的版本」這個節奏在跑——這篇講的管理方法，是我們實際在專案裡用、確認真的能降低誤會之後才寫出來的。例如我們做過的補習班補課系統、恆遠會員中樞系統，都是讓不熟技術的承辦人從原型階段就一路參與、每個里程碑親手驗收。看到這裡，如果你也在想『這套節奏放在我的專案會是什麼樣子』——我們很樂意聽你聊聊現在的實際情況，一起看看怎麼開始最不容易踩雷。

為什麼同一套需求報價差三倍：你該怎麼讀懂

管理專案的前一步，是把廠商選對。不懂技術的老闆在比價時最常見的崩潰是：同一份需求，A 廠報 40 萬、B 廠報 120 萬，到底誰在亂報？答案通常是——兩家報的根本不是同一件事。

便宜的報價往往省略了你沒注意、但事後一定會出事的部分：測試、文件、上線後保固、教育訓練、資料移轉。這些「看不見的工」佔一個專案的成本可能高達三到四成。讀報價單時，與其比總價，不如比「同樣的工項有沒有都列到」。

報價單常見落差項	便宜廠商常見做法	你該確認的問題
測試	報價不含測試，上線才修	有沒有列『測試與除錯』獨立工項？
教育訓練 / 文件	完全不提	上線後員工怎麼學會用？有沒有操作手冊？
資料移轉	假設你資料很乾淨	舊系統的資料誰負責搬？要不要清洗？
保固期	驗收後不負責 bug	上線後幾個月內的 bug 免費修？
需求變更	低報後靠變更單加錢	變更單的計價方式有沒有先講好？

如果你想更系統化地拆解一份報價單、看懂哪些是隱藏成本，系統開發費用完整拆解：從報價單看懂隱藏成本，不再被當冤大頭 把每個工項的合理區間都列出來了。另外，如果你還在「到底要客製化還是買現成 SaaS」這個更前面的問題上猶豫，可以先看 SaaS vs 客製化系統：中小企業到底該選哪一個？完整比較與決策框架，先把要不要客製化想清楚，再回來談管理。

土法盯專案的天花板，與更省力的那條路

前面這套方法——週會、demo、五里程碑、警訊清單、決策樹——你完全可以自己土法執行，而且應該執行，這是你身為出錢方最基本的把關。但土法盯專案有個天花板：你能管「節奏」和「訊號」，但你管不了「品質」。

舉個具體的：你能要求廠商每兩週給你 demo，但你沒辦法判斷他寫的程式碼是「乾淨、好維護、未來能擴充」，還是「能跑就好、半年後沒人敢動的義大利麵」。Standish CHAOS 的長期數據一再顯示，小型專案的成功率可以接近九成，但大型、複雜的專案成功率掉到一成以下——差別往往就在「有沒有人在技術層面替出錢方把關」。

這就是天花板所在：當專案規模到一定程度、或這套系統是你公司的核心命脈時，光靠老闆土法管理已經不夠，你需要一個「站在你這邊、聽得懂技術、又願意講白話給你聽」的角色。這個角色可以是你內部找一個懂技術的顧問，也可以是直接找一家「開發跟把關同一隊」的廠商——讓做事的人從第一天就用你能驗收的節奏交付，而不是等你事後抓問題。

這正是恆遠在做 客製化系統開發 時的基本工作方式：我們是真的會寫程式的工程師團隊，會把每個里程碑做成你能親手點的版本、用你的真實資料 demo、把原始碼放進你能存取的版控，並用白話跟你解釋每個決策背後的取捨。如果你的需求帶 AI（例如智慧客服、文件自動分析），可以一併了解 AI 系統開發，我們做過的 AI 智慧客服系統 與 生產力管理系統 都是這樣一路陪客戶從原型走到上線。

有沒有用這套方法管專案，差在哪

講了這麼多方法，最後用一張「有管 vs 沒管」的對比表收尾，讓你直接看到差別在哪。這不是理論——每一列都對應前面提過的某個盲區或手段。

情境	沒有方法地盯（土法問進度）	用本文方法管理
進度	靠對方一句『80% 了』判斷	每 2-4 週親手操作 demo，眼見為憑
需求	做到一半才發現漏講，瘋狂追加	里程碑 1 用流程驗收，缺口提早補
付款風險	前期付太多，後期沒籌碼	尾款壓在上線穩定，廠商有動力修 bug
出狀況	翻臉、不付錢、整套重做	用決策樹判斷，帶著半成品止損
最壞結果	錢付了、系統沒了、程式碼拿不回	程式碼在手，換人接手損失可控

這套方法不保證你的專案百分百成功——沒有任何方法能做到，畢竟連業界平均也只有三成完全成功率。但它能做到一件很實際的事：讓你在「錢還沒全部付出去、程式碼還在你手上」的時候，就察覺問題、做出選擇。對一個不懂技術的老闆來說，這就是把賭局變回一場你看得懂的生意。

常見問題

Q我完全不懂程式，真的有辦法管好外包專案嗎？

可以，而且你管的本來就不該是程式本身。你要管的是『節奏、驗收、付款、訊號』這四件事——全部都是外行能做的。週會逼出具體進度、每 2-4 週親手操作 demo、付款綁里程碑、出現危險訊號就啟動決策樹。你看不懂程式碼沒關係，但你絕對看得懂『這個功能符不符合我公司的流程』，這才是你最該把關的事。

Q廠商說『程式碼是商業機密不能給』，合理嗎？

不合理。你出錢開發的客製化系統，原始碼著作權在付款完成後本來就應該完全移轉給你，這要寫進合約。廠商可以保留他們的『通用框架方法論』，但專屬於你這套系統的程式碼一定要交付，而且開發過程就該放在你能存取的版控倉庫（如 GitHub）。拒絕交付程式碼是最強烈的紅旗訊號，等於把你綁死、換廠商時什麼都帶不走。

Q專案已經延期兩個月了，我該繼續還是換廠商？

先確認兩個事實：第一，核心功能現在『能不能實際操作』；第二，程式碼『在不在你手上』。如果核心功能能跑、只是慢，且對方願意給書面的明確時程，可以綁緊里程碑繼續。如果連能操作的東西都看不到，先發書面催告要求兩週內 demo，沒有就啟動換廠商評估。關鍵是無論哪種結果，先確保程式碼能拿回來，才有止損空間。

Q每週開會、每兩週要 demo，廠商會不會嫌我管太多？

正規、有信心的廠商不會排斥定期展示能操作的版本——能跑的東西不怕給你看。會嫌你管太多、抗拒 demo 的，通常正是進度有問題的那種。把回報與展示節奏在開工前、合約裡就談定，這是專業的專案治理，談不上『管太多』。對方一開始就拒絕，這個訊號本身就值得你重新考慮要不要簽。

Q尾款壓在上線後才付，廠商會不會不願意接？

把全部尾款壓到最後確實太極端，合理的做法是『分階段、尾款保留一小部分』。例如最後 10% 壓在上線並穩定運行 30 天後再付。這對雙方都公平：廠商拿到九成款項，你保留一成當作 bug 修復的保障。真正專業的廠商理解這個邏輯，因為這也保護他們不被『無止盡的免費修改要求』纏住——驗收標準與保固期講清楚，雙方都安心。

Q我預算不到 50 萬，這套管理方法還用得上嗎？

用得上，而且更該用。預算越小，犯錯的容錯空間越小，更不能讓錢白白付出去。小預算專案反而適合把里程碑切得更細、付款比例分得更碎，每完成一塊驗收一塊。小型專案的成功率本來就比大型專案高很多，只要你把節奏和驗收顧好，30-50 萬的客製化專案是完全可以管得動的。

外包專案管理 checklist 下載

我們把這篇的『五里程碑驗收節點 + 七個危險訊號 + 報價單必查工項』整理成一份可列印的對照清單，發包前印一份貼在辦公室，每個里程碑逐項打勾。可以先把你現在的專案情況丟過來，我們也很樂意陪你看一下，從哪一塊開始把關最能降低風險。

把專案變回一場你看得懂的生意

看到這裡，你手上已經有一整套不需要懂技術就能用的工具：開工前談定節奏、把專案切成五個能驗收的里程碑、用七個訊號提早察覺問題、用決策樹判斷止損、用報價落差表選對廠商。這些東西就算不找我們，你也帶得走、用得上。

如果你正準備發包、或手上的專案已經開始讓你不安，可以把現在的情況直接丟過來。先聊聊看你卡在哪——這套系統值不值得做、大概怎麼做、現在該繼續還是該換人，我們會用做過 補習班補課系統、病歷分析管理系統 + CT 解決方案 這些案子的實戰經驗，直接告訴你判斷。這個階段我們陪你想，後面真的要動手再談範圍跟費用。歡迎了解 恆遠的客製化系統開發服務，或直接 把你的情況告訴我們。