軟體專案會不會爆，常常在簽約那天就決定了。不是工程師不夠強，也不是預算抓得不夠多，而是雙方對「做完」的定義根本不一樣。等到驗收那天才發現落差，已經來不及。
多數業主在發案時，心裡想的是「我要一套能解決我痛點的系統」。但他把這句話丟給開發團隊時，往往只給了三件事：一份功能列表、一個預算上限、一個期望上線的時間。這三件事看起來很完整，實際上三個都是變數，而不是規格。
需求沒講清楚，比預算不夠更貴
「需求模糊」聽起來像是老生常談，但它造成的成本，比大多數業主想像的高。因為模糊不會在估價時爆發，而是在開發中後期才會冒出來。
舉個例子，假設一家傳產想做會員系統，合約上寫「支援會員註冊、登入、積分」。開發到一半，業主說：「積分要能跨門市共用，而且線下 POS 也要能查。」這句話在業主心裡是「本來就該這樣」，在開發團隊眼中卻是「這要重新設計資料流、要跟 POS 廠商對接 API、要處理同步衝突」。
這類變更的成本，不是加一個欄位這麼簡單。它會動到資料庫結構、動到權限模型、動到測試範圍。而且因為是中途變更，先前已經寫好的部分可能要回頭改。業主以為是加功能，實際上是重做。
我們在報價時通常會建議客戶：寧可花兩到三週把需求談深，也不要急著讓團隊「先動工再說」。把 use case 一條一條走過一遍，問自己「如果使用者這樣操作，系統該怎麼回應」，比列功能清單有用一百倍。
驗收標準要在開工前就寫出來
另一個常見的坑是驗收。很多合約的驗收條款寫得像作文：「系統需穩定運行」「操作需順暢」「符合業主需求」。這種條款的問題是，爭議發生時沒有任何依據。
可驗證的驗收標準長什麼樣？大致有幾個特徵：有明確的輸入與預期輸出、有可以點擊重現的操作步驟、有可以量測的條件（例如「同時 X 個使用者下單不會出錯」，而 X 是雙方談好的數字，不是開發團隊自己猜）。
這件事不是為了綁住開發方，而是保護雙方。開發團隊知道做到哪裡算完成，業主知道付尾款的依據是什麼。沒有這張清單，驗收就會變成情緒拉鋸。
還有一個業主端經常忽略的風險：關鍵人力抽離。這包含兩邊——開發團隊的核心工程師被調去救火，以及業主端最懂業務的那個窗口突然離職或被調職。前者業主沒辦法控制，但可以在合約裡要求「關鍵角色異動需事先通知」；後者則是業主自己的功課，窗口的知識要有文件、有備援，不能全在一個人腦袋裡。
我們的觀察
軟體專案的風險，九成在開工前就能看出來。合約談得越快、需求講得越含糊、驗收寫得越抽象，之後出事的機率就越高。發案前多花兩週談清楚，比上線後花兩個月補救便宜太多。預算抓多少是其次，先確認雙方對「做完」有沒有共識，才是真正省錢的做法。