需求變更怎麼處理?「順便加一下」的代價

「順便加一下」大概是專案裡最貴的四個字。它聽起來這麼小、這麼合理,拒絕的人顯得斤斤計較。但做這行久了就知道:毀掉專案的很少是大改,而是三十個「順便」的總和。這篇想把「加一下」背後的真實成本攤開,也講我們現在怎麼處理需求變更——一套讓雙方都不用受委屈的透明機制。

「小功能」的漣漪效應

業主看到的是水面上的那一角:多一個按鈕、多一個欄位。工程端看到的是整條漣漪:

• 資料要動:多一個欄位,意味著資料庫要改、舊資料要不要補、匯出報表要不要跟著改。
• 牽連要查:這個欄位有沒有別的功能在用?改了會不會弄壞已經驗收過的部分?查這件事本身就要時間。
• 介面要順:手機版放得下嗎?必填還是選填?填錯了怎麼提示?
• 測試要重跑:改動過的路徑,相關測試都要重新驗一輪——不重驗,就是拿已經做好的品質去賭。
• 文件要更新,時程要重排:而重排影響的不只這個功能,是排在它後面的所有事。

所以「加個欄位而已」的真實工時,常常是業主想像的三到五倍。這不是廠商在灌水,是冰山本來就長那樣。

更深的代價:免費的「順便」會毀掉合作

早年我們也當過爛好人,小改動就默默吸收。結果學到兩件事。第一,免費的東西沒有重量——不用付出成本的變更,對方不會認真想「真的需要嗎」,於是變更越來越多、越來越隨口。第二,吸收的成本不會消失,它會從別的地方漏出來:壓縮測試時間、犧牲程式品質、或是團隊加班到士氣崩盤。每一個免費的順便,都是從專案品質裡偷來的。最後傷到的還是同一個專案、同一個業主。

對「順便加一下」說好很容易,難的是誠實告訴對方:天下沒有免費的變更,只有還沒被看見的代價。

我們現在的變更流程

不是拒絕變更——需求本來就會變,看到半成品才想清楚是人性,我們在延期解剖報告裡也承認這是常態。重點是用流程接住它:

1. 寫下來。任何變更需求,口頭講完必須落成文字。寫的過程常常就會發現,需求根本還沒想清楚。
2. 評估、報價、報時程影響。每個變更我們回覆三件事:要多少錢、時程差多少、有沒有更省的替代做法。小到不用錢的,我們也會明講「這個免費,但吸收在下次交付裡」。
3. 讓業主自己排優先。最有效的一招:新需求進來,問「它跟原清單裡哪一項交換?還是加預算加時程?」當變更有了價格,業主自然會分辨哪些是真需要、哪些只是當下的靈感。
4. 白紙黑字確認,才動工。保護的是雙方——業主不會收到意外帳單,我們不會做白工。

透明的變更機制不是防小人的城牆,是讓好人不會不小心互相傷害的護欄。合約裡怎麼把這件事寫清楚,可以參考委託開發合約那篇——變更條款,永遠值得在簽約前多花十分鐘談。