軟體專案超支的原因，九成不在寫程式那一段。真正吃掉預算的，是發案前沒講清楚的需求、開工後不斷改的方向、驗收時才發現彼此想的不一樣，以及專案跑到一半關鍵人力被抽走。這四件事，業主端其實比開發商更能控制。
四個讓預算失控的真實原因
需求沒講清楚。很多業主帶著「我要一個像蝦皮那樣的系統」來詢價。開發商為了報價，只能猜。猜對了萬事太平，猜錯了就是後面每一次改動的火種。這不是誰的錯，是雙方一開始就沒有把「這個系統要解決什麼商業問題」講到同一個顆粒度。舉個例子，假設你要做一個會員系統，「會員可以登入」和「會員登入後要根據等級看到不同價格、而且要跟現有 ERP 對得起來」，兩者的工作量可能差十倍以上。
中途變更沒管控。開工後兩個月，業務部門說「順便加個折扣券吧」、行銷說「首頁想改一下版」、老闆看到競品說「他們有這個我們也要」。單獨看每一個變更都不大，但累積起來就是工期爆炸。問題不是不能改，而是每次改都沒有重新評估對時程、預算、其他功能的影響。開發商為了不得罪客戶，常常吞下去，最後結果就是延宕。
驗收標準模糊。「這個功能做好了嗎？」如果雙方對「做好」的定義不一樣，驗收會拖非常久。常見的爭議像是：效能算不算？異常情境要不要處理？瀏覽器相容到哪一版？手機開起來版型跑掉算 bug 還是新需求？這些如果沒有在合約或需求文件裡寫清楚，最後就是靠感覺吵。
關鍵人力抽離。這一條業主最容易忽略。你以為專案只跟開發商有關，但事實上業主端的窗口、負責決策的主管、提供資料的 IT，任何一個角色臨時被抽去做別的事，專案就會停擺。開發商可以繼續寫程式，但寫出來沒人確認、沒人回答問題、沒人給測試資料，程式就只能躺在那裡。
業主端可以做什麼
發案前，先把商業目標寫成一頁。不是規格書，是「這個系統上線後，我希望公司哪個指標改變」。這一頁會變成後面所有取捨的依據。當有人吵著要加功能時，回頭問「這對那一頁上的目標有幫助嗎？」，很多爭議會自動消失。
在合約裡定義變更流程，不是禁止變更。變更一定會發生，重點是每次變更都要有一個小小的儀式：寫下來、評估影響、重新確認時程與費用、雙方簽字。這個儀式不是官僚，而是讓雙方都不會事後翻臉。我們在報價時通常會建議客戶把「變更管理」明確寫進合約，而不是模糊地說「小改動免費」。
驗收標準要在開工前談，不是完工後才談。至少要包含：功能清單、效能底線、支援的裝置與瀏覽器、異常情境怎麼處理、上線後的保固範圍。談這些會很痛，因為你會發現自己其實沒想清楚。但這個痛，開工前談要比上線後談便宜非常多。
指派一個真正有決策權的窗口。不是傳話的助理，是可以當場說「這個我們要」或「這個我們不要」的人。而且要保護這個人的時間，不要讓他被日常業務淹沒。專案期間，這個窗口的時間比開發商的時間更貴。
我們的觀察
技術風險其實是四種風險裡最好處理的一種，因為它有明確的解法。真正難的是需求、決策、溝通這些「軟」的部分，而這些恰恰是業主端最有影響力的地方。發案不是把問題丟給開發商就結束，而是雙方一起把模糊的商業需求，逐步收斂成可以交付的東西。願意在開工前多花時間把這些談清楚的業主，最後的總成本通常比較低，即使表面上看起來一開始跑得比較慢。