「就改一個小地方，怎麼又要加錢？」這大概是軟體外包中最常見的摩擦。委託方覺得只是動一下，廠商卻說要重估報價、延後工期。其實雙方都沒錯——問題出在需求變更從一開始就沒有講好怎麼處理。本文說清楚：為什麼改需求常常牽一髮動全身、什麼情況該加錢什麼不用、以及如何用一套變更管理流程，讓改需求不再變成糾紛的導火線。
為什麼改「一點點」往往不便宜
軟體不像改文件改一行就好。一個功能背後可能連著資料庫結構、其他功能的邏輯、已經做好的畫面與測試。看似微小的改動，常常需要回頭追溯：
- 會不會影響到既有資料的儲存方式？
- 會不會牽動其他已完成功能的邏輯？
- 已經做好、甚至驗收過的部分要不要重做？
所以廠商面對變更時要求「重新評估」，多半不是刁難，而是避免改了一處卻悄悄弄壞另一處。理解這點，是雙方好好溝通變更的起點。需求談得越完整、開工前規格越清楚，後續變更就越少——這和報價為什麼差很多背後是同一個道理：規格的完整度決定了一切的精確度。
💡 觀念校正：變更的成本不只是「寫那段程式的時間」，還包含影響分析、回歸測試、文件更新。這也是為什麼「改一個欄位」有時要花的不只是想像中的十分鐘。
哪些變更該加錢，哪些不用？
不是所有變更都要追加費用。關鍵在於變更是否超出原合約約定的範圍。下表是常見的判斷原則：
| 變更類型 | 範例 | 通常如何計費 |
|---|---|---|
| 修正瑕疵 | 已約定功能沒做對、有 bug | 不另計（屬廠商履約/保固責任） |
| 等價替換 | 拿掉 A 功能換成工作量相當的 B | 多半不另計，雙方協調 |
| 新增 / 擴大範圍 | 多加一個模組、多支援一個平台 | 追加費用，重估工時 |
| 推翻已完成設計 | 已驗收的流程要整個重做 | 追加費用（含重做成本） |
釐清「修瑕疵 vs 改需求」的界線，很大程度仰賴一開始的驗收標準寫得夠不夠清楚——這正是驗收標準怎麼訂之所以重要的原因：標準明確，才分得出哪些是廠商該免費補的、哪些是新需求。
用「變更管理流程」把爭議擋在前面
成熟的外包合作不是「不准改」，而是「改有流程」。一套輕量的變更管理流程通常包含四步：
- 提出：委託方以書面（變更單、email、訊息皆可）描述想改什麼、為什麼。
- 評估：廠商評估影響範圍、增加的工時與對工期的影響。
- 報價與確認：提出追加費用與新工期，雙方書面同意後才動工。
- 納入紀錄：更新需求文件與驗收標準，避免下次驗收又對不上。
這套流程最大的價值，是把「口頭說好」變成「白紙黑字」。日後若雙方記憶不一致，紀錄就是依據。把變更條款寫進合約，也是外包合約必看條款的一環。
⚠️ 最該避免的事：口頭答應的修改。「上次群組裡你不是說 OK？」這種爭執幾乎都源於沒有書面。再小的變更，留一句文字確認，都比事後各執一詞好。
給委託方的 4 個務實建議
- 開工前多花時間談需求：前期把需求與畫面想清楚，是減少變更最有效的方法。不確定的部分，先做 MVP 驗證再迭代，比邊做邊大改省錢。
- 預留變更彈性預算：實務上很難一次想到位，預留一筆變更預算（例如總額的一定比例），心理與財務都不會被追加費用打亂。
- 區分「想要」與「需要」：每個變更先問「不改會怎樣」。把真正必要的先做，錦上添花的留待之後。
- 所有變更走書面：養成「再小也留紀錄」的習慣，是保護雙方關係最簡單的投資。
結語：改需求不可怕，沒流程才可怕
需求會變是軟體開發的常態，不是誰的錯。真正造成糾紛的，是沒有事先約定變更怎麼評估、怎麼計價、怎麼留紀錄。把變更流程談在前面，改需求就只是流程裡的一個步驟，而不是信任崩壞的開始。
如果你正在規劃一個需求還會持續調整的專案，歡迎聯絡宇若免費諮詢。我們會在開工前協助你把需求與變更規則談清楚，也歡迎參考我們的過往作品了解合作流程。