系統做到一半想改需求，怎麼辦？

你第一次決定找人做系統，花了好幾週和廠商來回確認需求、畫面、流程，終於簽約動工了。結果做到一半，你發現有個環節沒想到、某個畫面操作起來跟你想的不一樣、或是同事實際試用後說「這樣不行」。

你心裡開始慌——這才做到一半就想改，會不會被加錢？會不會被覺得很難搞？要不要先忍一下，上線再說？

這是幾乎每個第一次做系統的老闆都會遇到的事，而你的擔心完全合理。

改需求是正常的，不是你善變

先講一個事實：幾乎所有專案都會在過程中改需求。這不是因為業主沒想清楚，而是因為很多事情在紙上看不出來。

你在會議室裡討論的流程，跟現場實際操作的流程，經常是兩回事。審批要不要多一關、欄位要不要多填一個、某個例外狀況系統該怎麼處理——這些東西往往要等到東西做出來、人開始用了，才會浮現。

所以改需求不是問題。問題是，你的合作方式有沒有為「改」留空間。

為什麼改需求會變成災難

大部分的系統專案是這樣開始的：先花幾週確認需求、寫規格書，然後根據規格報一個價格、定一個時程，雙方簽約，開工。

這個流程的隱含假設是——需求不會變。

但需求一定會變。於是問題就來了：

• 你覺得「這只是小調整」，對方覺得「這是新需求」
• 你想改一個畫面的流程，對方說要重新評估影響範圍
• 每次修改都要走一次變更流程、重新報價、重新排期
• 到後來你不敢改了，因為改的成本太高

最後的結果是：你花了幾十萬做出一個「符合規格」但不符合現實的系統。規格書上的每一條都做到了，但用起來就是不對。

這不是哪一方的錯。是合作模式本身製造了這個衝突——當合約假設需求是固定的，任何改變都會變成一場拉鋸戰。

有些改動不但不該怕，還該鼓勵

做到一半發現「這個功能其實沒人會用」——砍掉它，是替你省錢。

做到一半發現「缺了這個步驟流程跑不通」——加上去，是讓系統真正能用。

做到一半老闆看了說「我想要的其實是這樣」——調方向，總比做完才打掉重來好。

怕改才是最大的浪費。硬著頭皮把一個方向錯誤的東西做完，然後上線沒人用，那才是真正的災難。好的專案不是「從頭到尾都沒改過」，是「每次改都改對了」。

怎麼讓「改」不會失控

當然，也不是什麼都能改、什麼時候都能改。無限制的修改同樣會讓專案走不完。關鍵是有方法：

• 小步快跑——不要一次規劃三個月的功能，每兩到四週交付一次，做完確認再往下走。這樣每次修正的幅度都很小，不會傷筋動骨。
• 改的代價透明——不是不能改，但每次改之前先搞清楚：改了會影響什麼、要多花多少時間、值不值得現在改。透明就不會有爭議。
• 區分「方向調整」和「追加功能」——把 A 畫面的流程換成 B 流程，是方向調整，應該被允許。在原本沒有的地方多長出一整個模組，那是追加，該另外討論。

重點不是「不能改」，是「有節奏地改」。

找人之前，先問這個問題

如果你正準備找人做系統，在談規格和報價之前，先問對方一個問題：

「做到一半我想改需求，你們怎麼處理？」

對方的回答會告訴你很多事。

如果他說「規格確認後就不能改」——那你要確定你的需求真的不會變。

如果他說「可以改但要走變更單」——那你要有心理準備，每次改都有額外成本。

如果他說「我們的流程本來就預期會改，來聊聊怎麼一起調整」——那至少方向是對的。

合作模式決定了合作心態。找到一個「改了不會翻臉」的合作方式，比找到一個「一次就做對」的規格書，實際得多。