軟體需求變更 SOP：3 種計費模式、6 條合約條款，外包專案不被無限加價

原本 80 萬的案子，怎麼變成 180 萬

「我們一開始說好 80 萬就能做完，現在做到一半，工程師說每改一個地方都要再加錢，總價已經報到 180 萬了。請問這合理嗎？」

這是上個月一位科技業老闆寫給我的訊息，字裡行間都是火氣。他原本以為自己做足功課——比了三家報價、簽了正式合約、付了 30% 訂金，怎麼項目進行到第三個月，數字已經膨脹到原預算的兩倍多。

故事的細節後面會講，先講結論：這個案子失控的真正原因是雙方都沒有「需求變更管理」的概念，工程師報價沒問題、老闆也做了該做的功課，整套合作關係缺的就是一個機制。專案經理（PMI）的調查長期顯示，超過半數 IT 專案會超出原預算 27% 以上，主因就是兩個英文字——scope creep（範圍蔓延）。

這篇文章就是要把「中途要改需求」這件事拆成一個可以執行的 SOP。完整內容涵蓋：3 種變更計費模式怎麼選、合約必備的 6 條 Change Order 條款、4 個判斷該不該改的決策時機、無限加價的 3 種包商手法與防備。讀完這篇，你下次再聽到「這個要加錢喔」的時候，至少能心裡有底。

如果你想先看更上游的需求文件怎麼寫，可以先翻 軟體 RFP 範本指南；想知道整個外包流程怎麼走，中小企業網站系統外包流程 也整理過完整地圖。本篇專攻「合約簽下去之後，中途要改怎麼辦」這一段。

先附一個讓你心裡有數的數字。Project Management Institute（PMI） 在年度 Pulse of the Profession 報告中指出，全球有大約 52% 的軟體專案經歷過範圍蔓延，平均超支幅度在 27% 到 45% 之間；KPMG 全球專案管理調查 的數據更直白——只有 31% 的 IT 專案能準時、準預算交付。換句話說，「會超支」是常態，「不超支」反而才是例外，重點是用什麼制度把超支幅度壓到可控範圍。

什麼是 Change Order？為什麼這個英文詞值得記住

Change Order（變更指令書）這個詞最早來自營建業。蓋一棟大樓，過程中業主突然要把客廳隔間打掉、要把窗戶從鋁窗換成木窗，這些「合約簽完之後才提出的更動」，每一筆都要走一張正式的 Change Order——白紙黑字寫清楚改什麼、加多少錢、工期延幾天、雙方簽名。

軟體業把這套機制借過來，意思幾乎一樣。Change Order 是合約簽訂後、原始 SOW（Statement of Work，工作說明書）之外的任何需求變更，所衍生的正式書面文件。它的核心精神只有一句話：「想改可以，但要走流程」。

為什麼台灣中小企業老闆要記住這個英文詞？因為國內合約用語通常只寫「客變」「需求調整」「追加項目」，這些詞太模糊，包商可以解讀成「口頭講一下就好」，老闆可以解讀成「不就改個顏色」。一旦用 Change Order 這個明確的名詞，雙方就知道——這是一份要走正式程序的東西，不是吃飯時順口提的請求。

中途改需求的 5 個真實場景，哪些合理、哪些是危險訊號

不是每一次「想改」都是 scope creep。實務上，有些變更是健康的、合理的、甚至是必要的；另一些則是包商或內部混亂留下的破口。先學會分辨類型，才知道下一步該談價還是該喊停。

場景一：使用者試用後發現流程不順（合理）

UAT 階段使用者實際操作，發現原本設計的「報銷流程要走 5 個步驟」太繁瑣，要求合併成 3 步。這種變更來自真實使用回饋，屬於提升專案價值的健康變更，該做、要做，只是要透過 Change Order 走流程。

場景二：法規或外部 API 改版（合理但要算誰賠）

做到一半，財政部開放了新的電子發票格式，或 LINE Pay API 改版，原本寫好的程式要跟著改。這類變更通常雙方都沒錯，重點是合約裡有沒有寫「外部不可抗力誰負責」。沒寫，就是談判桌上拚誰理直氣壯。

場景三：老闆突然想多加一個模組（危險）

「欸對了，我們順便也做一個會員點數系統好不好？」這種需求 90% 來自老闆讀完一篇文章、看完一場展，或聽競爭對手在做。這是最典型的 scope creep，問題不在「該不該做」，而在「該不該現在做」——大多數答案是：放到 phase 2 再說。

場景四：包商主動建議升級技術棧（高度危險）

「我們建議從 Vue 2 升到 Vue 3，這樣以後更好維護」「不如直接上 microservices 架構」。聽起來很專業，但實際上可能是包商為了多賺工時、或工程師想練習新技術。老闆要問的是：升級對「業務目標」有什麼直接幫助？答不出來就是 nice to have，先不要。

場景五：原本講好的功能變得不一樣（紅燈）

最危險的一種——包商說「你當初講的那個功能，我們理解的不是這樣，要改成你要的版本要加錢」。這 100% 是當初需求文件沒寫清楚的後果，責任在誰看雙方合約。沒有清楚規格書的案子，這種爭議會層出不窮。

3 種變更計費模式對比：固定價、T&M、Cap Plus 怎麼選

變更發生後，第一個爭議永遠是錢——這個改要算多少？台灣業界常見有三種計費邏輯，各有適用情境，選錯模式比改價碼還危險。

模式 A：固定價（Fixed Price Change Order）

每一筆變更，包商開出一個固定金額、一個固定工期，雙方同意才做。優點是預算可控，缺點是包商會把「風險」灌進去，報價通常比實作成本高 30% 以上，而且小變更談一次合約就花掉半天時間。

模式 B：T&M（Time and Materials，按時計費）

包商提供「每小時工程師單價」，變更做幾小時就算幾小時。優點是小變更跑得快、不用每次寫合約；缺點是沒有上限機制就是無底洞，老闆完全沒辦法控制總額。台灣中小企業用這模式翻車的案子最多。

模式 C：Cap Plus T&M（封頂時數制）

這是我最推薦的模式：採用 T&M 計費，但每月或每季設定一個「總時數上限」，超過要再簽 Change Order 才能繼續。例如「每月 40 小時的變更額度，每小時 2,500 元」，超過 40 小時自動暫停，要老闆書面同意才解鎖。

合約必備 6 條 Change Order 條款，缺一條都會被吃豆腐

光講「我們會走變更流程」沒用，要把規則寫進合約。以下這 6 條是恆遠看過上百份外包合約後整理出來的最低必要條款，少一條都會留下被攻擊的縫隙。

條款 1：變更觸發點定義

白紙黑字寫清楚「什麼算 Change Order」「什麼不算」。例如：「原 SOW 第 X.X 節未列之新功能模組、跨模組流程調整、UI 大幅改版（影響超過 3 個畫面），需走 Change Order；單純文字校正、CSS 微調、bug 修正不屬之。」

條款 2：書面同意原則

「所有 Change Order 必須以書面（含電子郵件、PDF 簽署文件）確認，口頭或即時通訊（LINE / Slack 等）之指示不具效力。」這條超重要——台灣老闆很愛用 LINE 講需求，結果出事時對方截圖一句「你當時也說 OK」，整個防線就垮了。

條款 3：總額上限機制

「所有 Change Order 累計金額不得超過原合約總價之 30%；超過部分需另立補充協議。」這條是防止無限加價的最後一道防線，30% 是業界常見天花板，超過就要重新討論專案可行性。

條款 4：暫停權與退場條款

「業主有權在任一 Change Order 報價提出後 7 個工作天內決定接受、拒絕、暫停。拒絕後乙方仍需依原 SOW 完成交付。」沒有這條，包商可以用「不加錢就罷工」威脅你。

條款 5：知識保留條款（最容易被忽略）

「所有 Change Order 衍生之程式碼、文件、設計檔，均歸業主所有，乙方需於每次變更交付時同步更新 Git repository 與技術文件。」沒有這條，變更越多文件越亂，最後只有原包商看得懂，你被綁死。可以一起參考 找外包 9 個雷區實戰檢查表 中關於程式碼歸屬的章節。

條款 6：驗收複測機制

「Change Order 完成後，業主有 5 個工作天進行 UAT 驗收，發現之缺陷需於 3 個工作天內修正，不另計工時。」這條把「改完才發現改壞了」的風險推回給包商。UAT 怎麼跑可以看 軟體驗收 UAT 完整檢查表。

4 個決策時機：什麼時候該改、什麼時候該推到下一階段

變更要不要做，不只是錢的問題，還跟「現在做」對整個專案進度的衝擊有關。以下 4 個時機點，是恆遠輔導客戶判斷 Change Order 該不該按下去的關鍵節點。

時機 1：架構設計階段——大膽改

此時還沒寫程式，改設計只是改 Figma 跟資料表規劃。此階段提出的變更，加價幅度應該在原項目報價的 1-1.2 倍以內，因為實作成本還沒發生。如果包商此時就獅子大開口，是警訊。

時機 2：開發中期——慎改

已經寫了 30-60% 程式碼。此時變更要評估「會不會打掉重練」。能用前端調整解決的優先做，需要動到資料表或 API 結構的，除非業務真的卡住，否則一律 push 到下個 phase。

時機 3：UAT 階段——只接受流程性變更

已經到驗收階段，此時應該只接受「使用者實測發現的流程不順」變更，例如按鈕位置、欄位順序、文字提示。任何新增功能模組的需求，一律列入 phase 2 backlog，否則延遲上線會吃掉你的市場 timing。

時機 4：上線後維運期——分批排程

系統已經上線運作。變更需求應該月度排程化——每月底盤點所有需求，排序、估時、決策。緊急 bug 修正走獨立 SLA 流程，新功能進入維運合約的月度釋出。如果你還沒有正式維運合約，可以參考 軟體維運合約模式與條款指南。

老闆視角的內部 Change Order 審核流程：誰簽、看什麼、Veto 權給誰

外部合約寫得再嚴，內部如果隨便一個 PM 都可以對外簽 Change Order，制度等於零。中小企業的常見錯誤是「對外有 SOP、對內沒人在管」，結果包商每次找對你最 nice 的窗口拿同意，老闆永遠最後才知道。

分級審核制度：依金額分三層

1. 新台幣 5 萬以下：PM 可單獨核可，但需 24 小時內 email 副本給老闆。
2. 新台幣 5-20 萬：PM 與技術主管雙簽，老闆收書面摘要。
3. 新台幣 20 萬以上：必須老闆親自書面簽署，並有 7 天冷靜期可撤回。

審核時必看的 4 個資訊

• 變更原因：這個需求是誰提的、為什麼現在提、不做會怎樣
• 替代方案：有沒有比這個方案更便宜或更快的選項，包商評估了哪些
• 對原進度的衝擊：做了會延幾天、會不會拖累其他模組
• 累計變更金額占比：加上這筆，總變更金額占原合約幾 %（接近 30% 紅線就要喊停）

Veto 權給誰：永遠是出錢的人

我看過很多中小企業老闆把專案決策「全權」交給 PM，這在原合約 SOW 階段沒問題，但 Change Order 階段必須回到老闆桌上。出錢的人才有資格決定「為了這個功能值不值得多花 50 萬」，PM 沒有這個 context，給他們也不公平。

無限加價的 3 種包商手法與防備

不是所有包商都壞，但壞包商或經驗不足的包商會用以下 3 種手法把專案做成「金額無上限的開放式工程」。先學會辨認，下次遇到就能立刻拉警報。

手法 1：低價中標 + 高頻變更

一開始用明顯低於市場行情的價格搶單（例如別家報 120 萬、他報 70 萬），合約簽完之後幾乎每週都會跳出「這個原本沒包進去」的 Change Order，最後總價往往比原本的市場行情還高。

防備：收到報價低於市場行情 30% 以上的包商，要特別追問「你們的 70 萬包含哪些工作項目？」並把回答寫進合約 SOW 的 exclusion 清單。報價低不一定是惡意，但要查清楚是壓低利潤還是漏算項目。

手法 2：模糊規格利用解釋權

合約裡寫「會員系統」三個字就交差，等開始做才說「啊我們理解的會員系統不含會員等級、不含點數、不含優惠券，這些要另外做」。規格寫越模糊，包商解釋空間越大。

防備：SOW 不能只列模組名稱，要列「使用者可以完成的具體動作清單」。例如「會員系統」要拆成「使用者可註冊」「可登入」「可修改個資」「可查看訂單記錄」「可累積點數」「可兌換優惠券」等 20-30 個 user story。軟體 RFP 範本指南 那篇有 RFP 範本，可以對照著用。

手法 3：捆綁式 Change Order

把 5 個變更綁在一張 Change Order 裡，總價 80 萬，但其中只有 1 個是你真的要的、其他 4 個是包商主動建議或順便加進來的。一旦你說「我只要第 3 項」，對方就說「無法拆，這 5 個技術上綁在一起」。

防備：合約寫明「每張 Change Order 必須單一變更項目；如有多項，需分別估時、分別簽署、業主有權單獨選擇接受項目」。技術上 99% 的變更都可以拆，說不能拆通常是話術。

真實案例對比：好的 Change Order 流程 vs 災難

用兩個恆遠近兩年看到的真實案子（已隱去公司名稱與細節）對照，讓你看到「有制度」跟「沒制度」的金額落差到底有多誇張。

案例 A（災難）：B2B 報價系統，原 80 萬最終 180 萬

這就是文章開頭那位老闆的案子。原始 SOW 寫了「報價單管理、客戶管理、產品目錄」三個模組，總價 80 萬，工期 4 個月。實際發生過程：

1. 第 3 週老闆 LINE 跟 PM 說「順便也加個庫存連動吧」，PM 口頭答應、未簽 Change Order，後來追加 22 萬。
2. 第 6 週包商主動建議「升級到 microservices 架構比較好維護」，老闆沒問細節同意，追加 35 萬。
3. 第 10 週 UAT 發現原本的「報價單列印」功能規格沒寫清楚，包商說要另外做，追加 18 萬。
4. 第 14 週老闆想多加「業績儀表板」，包商說「現在加最方便」，追加 25 萬。

最終總額 180 萬，比原預算多 100 萬（125% 超支）。更糟的是上線延遲 3 個月，錯過業績旺季。事後檢討，這 4 筆加錢沒有任何一筆有書面 Change Order，全部是 LINE 對話 + 口頭同意，老闆連想跟對方爭都拿不出證據。

案例 B（健康）：電商物流系統，原 150 萬最終 175 萬

另一家中型電商，原始 SOW 寫了完整的物流串接與訂單管理，總價 150 萬，採用 Cap Plus T&M 變更計費（每月 40 小時上限）。實際發生過程：

1. 第 4 週 UAT 試用發現出貨單格式不符合物流公司要求，走 Change Order #1，估 18 小時，金額 4.5 萬。
2. 第 7 週業務部要新增「批次匯入訂單」功能，PM 評估後 push 到 phase 2，不影響上線。
3. 第 9 週財政部更新電子發票 API，走 Change Order #2，包商評估屬於外部 API 變動，依合約條款雙方各承擔 50%，金額 8 萬。
4. 上線後第 1 個月維運期，老闆提出 3 個小調整，併入維運合約月度時數，無額外費用。
5. 第 4 個月新增報表模組，走 Change Order #3，估 50 小時，金額 12.5 萬。

最終總額 175 萬（含 3 張正式 Change Order），超支 17%（業界平均水準內），準時上線。整個過程沒有任何爭議，因為每一筆變更都有書面紀錄、估時邏輯透明、業主有否決權。

Change Order 常見問題 FAQ

結語：把「會改」當成常態，把「亂改」當成例外

沒有任何客製化系統能在簽約那天把所有需求想清楚，變更必然發生，問題只在於有沒有制度承接。本篇從 Change Order 的定義、3 種計費模式、6 條合約條款、4 個決策時機、3 種包商手法到 2 個真實案例，把整個 SOP 拆得很細。實際執行起來，老闆只要記住三件事：

1. 白紙黑字：任何變更必須走書面，LINE 不算數
2. 總額上限：原合約 30% 是天花板，超過就要重新評估
3. 出錢的人簽：20 萬以上的變更，必須老闆親自決策

如果你正在找客製化系統開發、或想為現有專案重新檢視變更管理機制，可以直接看恆遠的 客製化系統開發服務，我們的標準合約已經把這 6 條 Change Order 條款內建在內，並提供 Cap Plus T&M 計費選項；如果你需要的是專案治理諮詢——例如找第三方審核包商提的 Change Order 是否合理——也可以參考 AI 與系統顧問服務。早點把變更管理制度搭起來，比事後省律師費划算太多。

延伸閱讀：完整的外包流程地圖看 中小企業網站系統外包流程指南、需求文件怎麼寫看 軟體 RFP 範本、上線前驗收怎麼跑看 UAT 檢查表、上線後維運合約怎麼簽看 維運合約模式指南，五篇連起來看就是一條完整外包路線圖。