5 種讓外包專案失敗的『客戶端』行為（不是廠商的錯），以及怎麼自我檢查

一位老闆帶著一個「做壞掉」的專案來找我們：換了三家廠商、燒了 NT$180 萬、系統還是沒上線。他問的第一句是「是不是廠商都不專業？」但攤開三份合約與往來紀錄後，真正的共通點不在廠商，而在客戶端的五種行為。這篇不談廠商多爛——談的是外包專案失敗時，客戶自己那一半的責任，以及怎麼自我檢查。這是為了讓你的下一個專案不要成為第四次。

業界迷思打破

• 迷思一：「專案失敗一定是廠商技術不好。」真相：產業研究長年指出，多數專案失敗來自需求不清與範圍蔓延，而非純技術問題。
• 迷思二：「多找幾家比價就能避開地雷。」真相：一路比最低價，換來的是最不敢說實話的廠商。
• 迷思三：「需求邊做邊講就好。」真相：沒有書面範圍，每一次「順便加一下」都在拆掉時程與信任。
• 迷思四：「窗口越多越安全。」真相：五個人下五種指令，等於沒有決策者。

核心框架：專案失敗前兆自檢表

用「5C 失敗前兆」自檢，命中越多，翻車機率越高：

• Clarity（清晰）：有沒有一份雙方簽字的書面範圍？
• Contact（窗口）：是否只有一位能拍板的決策窗口？
• Change（變更）：需求變更是否走書面、有工時與費用估算？
• Cadence（節奏）：是否有固定的驗收節奏、而非上線前一次爆驗？
• Cash（金流）：付款是否綁在里程碑、而非「做完再說」？

三類情境對照

隱藏成本完整清單

• 換廠商的重工成本：新廠商接手看懂舊碼，約多花原開發 20–40% 工時
• 決策延遲成本：一個需求卡兩週，整條時程順延
• 範圍蔓延成本：每次「順便加」平均吃掉 3–8 小時未估工時
• 信任崩壞成本：一旦進入互相不信任，溝通成本翻倍
• 機會成本：系統晚三個月上線＝晚三個月產生效益

評估外包夥伴的 KPI 計分卡

• ☐ 是否主動要求書面需求範圍？
• ☐ 是否敢對你的需求說「這個不建議做」？
• ☐ 報價是否拆到功能與工時、而非一個總價？
• ☐ 是否有固定進度回報節奏？
• ☐ 變更是否有明確的估算與簽核流程？
• ☐ 是否交付原始碼與文件（IP 歸屬清楚）？
• ☐ 是否談上線後的維護與 SLA？
• ☐ 過往案例是否可驗證？

ScriptWalker 的對應方案 + 不適合的情境

我們的做法：專案啟動一定先做「一頁範圍書 + 單一窗口 + 里程碑付款」三件套，寧可花 3–5 天把需求談清楚，也不急著開工。合作模式對應：小專案走專案制、長期走月費 Retainer。誠實說，我們不適合這幾種客戶：

• 堅持不簽書面範圍、要「邊做邊喬」的
• 只以最低價為唯一標準的
• 無法指定單一決策窗口的
• 把驗收無限延後、又要求準時上線的

過渡期遊戲書（接手一個做壞的專案）

• 第 1 週：凍結新需求，盤點現況與可用資產，產出健檢報告。
• 第 2–4 週：定義「最小可上線範圍」，砍掉爭議功能，先讓核心跑起來。
• 第 5–8 週：核心上線、建立變更與驗收節奏。
• 第 90 天：回顧失敗根因，把流程固化成雙方都遵守的合作規則。

決策清單

• ☐ 我有沒有一份寫下來的需求範圍？
• ☐ 我方是否只有一位決策窗口？
• ☐ 我是否願意讓需求變更走書面流程？
• ☐ 我是否安排了固定驗收時間？
• ☐ 付款是否綁在里程碑？
• ☐ 我選廠商是不是只看價格？
• ☐ 我是否給了廠商說「不建議」的空間？
• ☐ 我是否預留了上線後維護預算？

常見問題 FAQ

專案失敗真的有一半是客戶的責任嗎？

把責任量化很難，但可驗證的是：需求不清與範圍蔓延是最常見的失敗根因，而這兩件事的源頭多在客戶端。承認這一半，不是自責，是你唯一能主動控制的部分——你換不了廠商的能力，但改得了自己的流程。

我不懂技術，怎麼判斷需求有沒有講清楚？

用一個測試：能不能用一頁 A4 寫出「這個系統上線後，誰、在什麼情況、點了什麼、會發生什麼」。寫得出來就夠清楚；寫不出來，代表還沒想清楚，此時開工必翻車。

已經做壞的專案，還救得回來嗎？

多數救得回，但要先凍結新需求、定義「最小可上線範圍」，先讓核心跑起來，再談其他。最貴的錯誤是一邊救火一邊加新功能。

怎麼避免又選到不對的廠商？

用上面的 KPI 計分卡。最關鍵的一題是「他敢不敢對你的需求說不」——只會說好的廠商，通常也不會在該擋的時候擋你。

行動呼籲

想在下一個專案開工前，先做一次免費的「5C 失敗前兆」自檢與需求盤點？我們用 30 分鐘幫你把風險攤開。聯絡我們：

• Email：[email protected]
• 電話：0916-224-047
• LINE：@ufv9089p