開發中一直改需求怎麼辦？變更管理與追加報價的規則

「這不是很簡單嗎？就加一個欄位而已。」

系統開發做到一半，這句話幾乎一定會出現。老闆在測試畫面上看了一下，覺得少了一個「客戶統編」，或者報價單上想多一欄「備註給倉庫看」。對他來說，這是一分鐘就講完的事。對開發的人來說，這可能牽動畫面、資料表、權限、報表、匯出格式，還有已經存進去的資料要怎麼補。

我是熊董，台灣川輝科技創辦人。我帶團隊做系統導入七年，經手超過 34 個案子、橫跨 14 個以上產業，現在一個人加 AI，一年交付 2,000 萬以上的客製系統。我站在廠商這一邊，也自己當過老闆、被廠商報過價，兩邊的委屈我都懂。我的結論是：開發中需求變更一定會發生，變更本身不是問題，沒有規則的變更才是。規則只要三條：第一，所有變更都寫成一張變更單，口頭講的、LINE 上提的都不算數；第二，每張變更單先分類——做出來跟書面規格不符是「修正」，由廠商負責；規格寫得模糊的是「澄清」，雙方協商；規格裡沒有的新功能是「新增」，推翻已確認的東西是「改方向」，這兩種都要追加報價和時程；第三，每張變更單都要寫清楚三件事——多少錢、延多久、已經做好的哪些要作廢，雙方確認了才動工。再加上一個「階段凍結」的習慣：正在開發的這一段不插隊，新需求排進下一段。

先承認：開發中想改需求，本來就很正常

我先講一句可能不像廠商會講的話：你在開發中想改需求，大部分時候是對的。

原因很簡單。寫規格的時候，你是在想像一套還不存在的系統。等畫面真的做出來、你用自己的資料點了幾次，才會發現「原來這裡少一步」「這個欄位現場根本不會填」「這張報表會計要的格式不是這樣」。這些發現很有價值，代表系統正在變得更貼近你們實際怎麼工作。如果一套系統從規格到上線一個字都沒改，我反而會擔心大家根本沒認真用過測試版。

所以問題從來不是「能不能改」，而是改的時候有沒有一套雙方都認的規則。沒有規則，就會出現兩種壞結局：廠商什麼都吞下來，最後時程爆掉、品質下降，甚至做到一半就撐不下去；或者廠商每一個小改動都開價，老闆覺得被敲竹槓，關係變成互相提防。兩種都不是你要的。

為什麼「只是加一個欄位」常常不只是一個欄位？

這是老闆和工程師之間最常見的認知落差，值得花一段講清楚。

在畫面上加一個欄位，看起來只是多一個格子。但這個格子背後通常還牽涉到：資料表要多一個位置存它；新增、編輯、查詢三個畫面都要處理；誰可以看、誰可以改要設權限；如果它要出現在報表或列印的單據上，版面要重排；如果有匯入匯出功能，格式要跟著改；如果系統已經有舊資料，那些舊資料這一欄要填什麼。

每一項都不難，但加起來就不是一分鐘的事。而且越晚提，牽動的東西越多。在規格階段加一個欄位，只是改一行字；在開發中加，要改程式；在測試完才加，要改程式再重測；在上線後才加，還要處理已經存在的真實資料。同一個需求，提出的時間點不同，成本可以差好幾倍。

這也是為什麼我會建議老闆：越早用真實資料看到畫面越好。早看到，早發現，改的成本就低。

需求變更分四種，誰承擔不一樣

要讓變更不吵架，最重要的是一開始就用同一套標準分類。我在現場用的是下面這張表：

類型	怎麼判斷	常見例子	由誰承擔
修正	做出來的東西跟書面規格寫的不一樣	規格寫要能依日期篩選，做出來不能	廠商，不另收費
澄清	規格有提到，但寫得模糊，雙方理解不同	規格寫「可匯出報表」，沒寫格式	雙方協商，看報價時是否合理應想到
新增	規格書裡完全沒有的功能、報表、串接	原本沒談的 LINE 通知、新的一張報表	業主，追加報價與時程
改方向	推翻已經確認、甚至已經做完的設計	已確認的簽核流程改成另一種邏輯	業主，追加報價，並計入已完成部分的作廢成本

這張表的前提是：你有一份書面規格。沒有書面規格，所有變更都會落進「澄清」這一格，雙方各說各話。這是為什麼我一直強調，客製開發要依書面規格報價——不是為了綁住業主，是為了在發生爭議時，有一個雙方都能指著看的東西。規格怎麼寫才夠用，可以參考ERP 需求規格怎麼寫。

「澄清」這一格最容易吵，我的判斷原則是問一句：一個有經驗的廠商，在報價當時是否應該合理想到這件事？例如規格寫「可匯出報表」，那匯出成一般試算表格式是合理範圍，廠商該吸收；但如果業主要的是對方會計軟體指定的特殊匯入格式，那就超出合理範圍，應該算新增。

分類談不攏的時候怎麼辦？

實務上最常見的爭議是：廠商說這是「新增」，業主說這是「澄清」。兩邊都覺得自己有道理，因為規格書上那一句話本來就可以有兩種讀法。

我的建議是先不要爭分類，先回頭看三樣東西：規格書的原文、報價時雙方往來的紀錄、以及當初需求訪談的筆記。如果三樣東西裡有任何一處提過這件事，就偏向澄清；三樣都沒提過，就偏向新增。真的還是各說各話，可以各退一步，例如這一次由廠商吸收，但雙方同意把這一條寫進規格書的補充說明，下一次同類的需求就有明確依據。

這種爭議的根源，通常是規格書寫「要什麼」，但沒寫「做到什麼程度」。例如「要有報表」，沒寫哪些欄位、什麼格式、誰要看。下一次寫規格時把程度寫出來，同樣的爭議就會少很多。

一張變更單要寫哪些東西？

變更單不用很正式，一頁就夠，但下面這幾欄缺一不可：

• 變更內容：用一兩句話寫清楚要改什麼，最好附上畫面截圖或手繪示意。
• 提出人與原因：誰提的、為什麼要改。原因很重要，有時候追問原因會發現有更簡單的解法。
• 分類：修正、澄清、新增、改方向，雙方都要同意這個分類。
• 影響範圍：會動到哪些畫面、報表、權限、既有資料。
• 費用：修正與澄清寫「不另收費」，新增與改方向寫追加金額與計算方式。
• 時程影響：上線日會不會延、延多久、哪一段要往後排。
• 作廢內容：已經做好的哪些部分會因此不用了。這一欄最常被忽略，但它是「改方向」成本的主要來源。
• 雙方確認：業主與廠商各一人確認，確認後才開始做。

變更單最大的價值不是收錢，是留下紀錄。專案結束時把所有變更單攤開，你就看得出時程延誤是誰造成的、預算多出來的每一塊錢花在哪裡。很多專案到最後吵架，吵的其實是「當初到底有沒有講過」，而變更單就是在回答這個問題。

階段凍結：讓新需求有地方去，而不是一直插隊

除了變更單，另一個很有效的做法叫階段凍結。

客製開發通常會分段交付、分段收款，每一段有明確的交付內容。川輝的做法是每段交付完、驗收完，該段的應收就結清為 0，不會累積到最後一次算總帳。在這個結構下，階段凍結的意思是：正在開發的這一段，需求鎖住不動；開發中冒出來的新想法，先寫成變更單放進「待排清單」，等這一段交付驗收完，再一起評估要不要排進下一段。

這個做法對雙方都好。對廠商來說，開發中不會一直被打斷，品質比較穩；對老闆來說，新需求不會被吞掉或忘記，而且等到一段結束再看，很多當下覺得急的需求，冷靜下來會發現其實不需要。很多當下覺得非做不可的需求，排進待排清單之後，到下一段開始前回頭看，業主自己就會判斷可以先不做。

唯一的例外是「修正」。做出來跟規格不符的地方，不用等下一段，該當場修。

追加報價怎麼算，才不會變成吵架？

追加報價要不吵架，關鍵在於「計算方式」要在簽約時就講好，而不是等到變更發生了才談。

常見的做法是在合約裡寫明：規格外的新增與改方向，依評估的工作量計價，並寫清楚單位價格怎麼算。這樣每一張變更單的金額都是用同一把尺量出來的，業主可以質疑「這件事需要這麼多工作量嗎」，但不會質疑「你們是不是看心情開價」。合約裡還有哪些該寫的條款，可以對照簽 ERP 合約前一定要問的 12 個問題。

舉一個假設的例子：假設合約約定追加工作依人天計價，一張變更單評估要兩個人天，那金額就是兩個人天乘上約定的單價，時程延後兩個工作天。如果這張變更單同時讓已經做好的一個畫面作廢，作廢那個畫面當初花的工作量，也要在變更單上寫出來，讓業主知道「改方向」的真實代價。

還有一個實務上的建議：小變更不要一張一張談。可以約定每一段累積的小型澄清與調整，在一定範圍內由廠商吸收，超過才開變更單。這樣雙方都不用為了一個按鈕顏色開會。

老闆自己能做的：減少變更的三個習慣

變更管理不只是廠商的事，業主這邊有三個習慣，能讓變更少一半。

第一，規格寫給現場的人看過再定稿。 很多變更來自「老闆以為現場這樣做，現場其實不是」。規格定稿前，讓每天用這套流程的人看一遍，他們會指出你沒想到的例外。

第二，指定單一窗口。 業主這邊如果業務提一個、會計提一個、老闆又提一個，需求會互相打架，廠商也不知道該聽誰的。所有需求先匯到一個人，由他決定要不要提、怎麼提。

第三，早點用真實資料測試。 不要等全部做完才看。每一段交付時就用你們真實的訂單、真實的客戶資料跑一次，問題越早發現，改起來越便宜。這也是驗收條件要寫清楚的原因，可以參考ERP 驗收條款怎麼寫才保護得了自己。

整個客製開發從規格、收款到驗收的全貌，我在客製化系統開發要注意什麼裡有完整拆過，這篇講的變更管理是其中最容易出事的一段。

常見問題

系統開發中改需求，廠商可以拒絕嗎？

可以，但好的廠商通常不會直接拒絕，而是告訴你這個變更要多少錢、延多久、影響哪些已完成的部分，讓你決定。如果一個變更會嚴重影響系統架構或整體時程，廠商建議排到上線後的下一階段，也是合理的做法。

追加報價很高，可以不做嗎？

可以。變更單本來就是讓你在知道代價之後做決定。很多時候看到追加金額，業主會回頭想有沒有更簡單的做法，例如改流程而不改系統，或先用現成工具撐一段時間。不做也是一種很好的決定。

上線之後才發現要改，算變更還是維護？

看性質。系統照原本的規格繼續運作、修正錯誤、處理小調整，屬於維護；新的功能、新的流程、新的串接，屬於新的開發或導入，要另外評估。合約裡最好把這條界線寫清楚，上線後才不會為了「這算不算維護範圍」爭執。

規格書寫得很細，就不會有需求變更了嗎？

不會。規格寫得細可以減少「澄清」類的爭議，讓分類更清楚，但看到真實畫面之後產生的新想法，本來就無法事先完全預料。規格的目的不是消滅變更，是讓每一個變更都有判斷的依據。

結語：需求可以改，規則不能沒有

需求變更這件事，一句話就能講完：改不是問題，沒講好怎麼改才是問題。四種分類、一張變更單、加上階段凍結，就足以讓大部分專案不會在後半段翻臉。

如果你正在規劃一套客製系統或 ERP，想先把規格、分段和變更規則一次想清楚，可以先看看 ERP 導入怎麼做，從頭把整個流程走一遍。