工程師說「太舊建議重寫」，你該改版還是系統重新開發？先自己打完這四格再決定

你接手家裡工廠不到一年，手上這套進銷存的管理系統是十年前外包做的，當年負責的那家人早就聯絡不上了。最近你想在裡面加一個小功能——出貨單自動帶進對帳表，不要每個月再手key一次。你找了工程師來看，對方點開程式翻了十分鐘，講了一句：「這程式太舊了，建議重寫。」

你卡在這裡。重寫聽起來就是一大筆錢，而你要的只是一個小功能；但對方是懂的人，你又不確定他是真的改不動，還是想接一個大案子。該花小錢繼續修補，還是咬牙做一次系統重新開發，你手上沒有可以判斷的東西。這篇不幫你決定，是幫你把「該不該信那句話」這件事，變成你自己也評得出來的四個變數。

「太舊、建議重寫」是結論，不是診斷

先把那句話拆開。「建議重寫」是一個結論，而你需要的是結論前面那段診斷——他是看到了什麼，才走到這個建議。問題在於，大多數人聽到「太舊」就直接跳到「那就重做吧」或「他是不是想坑我」，中間那段判斷被整個跳過了。

要不要做系統重新開發，真正的變數不是「這套系統有多舊」。舊，是年份，年份本身不決定什麼——有的系統跑了十二年還好好接新功能，有的三年就動不了。決定答案的是四件你其實比工程師更清楚、或至少問得出來的事：想加功能時卡在哪一層、你接下來要的功能跟原本的架構差多遠、程式碼還有沒有人接得住、以及換一組人從頭熟悉這套系統要付多少看不見的錢。把這四格一格一格打完，改版還是重做，答案多半自己就浮出來了。

舉一個會遇到的樣子。一家做金屬加工的工廠，二代想在舊的管理系統裡加一個「依交期自動排生產順序」的功能，工程師看完也說「太舊、建議重寫」，報了一個六位數。他沒有馬上答應，而是請對方把「為什麼非重寫不可」寫下來三點。對方寫完，他才發現其中兩點是「我不熟這套、接手要花很多時間」，只有一點是程式本身真的改不動。那一刻他要判斷的，就從「信不信這個人」變成「這三點裡，哪幾點是系統的問題，哪幾點是換人的問題」。

第一格：想加功能時，到底卡在哪一層

第一件要盤的，是你每次想動這套系統時，實際卡在哪裡。這就是一般講的技術債——不是系統壞了，是當年為了快點上線留下的東西，讓現在每次要改都比應該的更費力。

技術債要分兩種看。一種是「改得動，但很貴」：功能加得上去，只是每次都要動到一大片、測很久，報價一次比一次高。另一種是「幾乎改不動」：程式糾在一起，動一個地方會扯出三個地方壞掉，連原本能跑的功能都保不住。前一種，舊系統改版還有空間；後一種，才真的往系統重新開發靠。

分辨的方法不難，你問工程師一句就好：「我這個功能，是要在原本的地方加，還是要先把旁邊一大塊也一起動？」如果答案是前者，技術債還在可控範圍；如果連加一個小功能都要先「整理」半天，這一格就要往重做那邊記。

舉個例子。一家做食品批發的公司，想在管理系統開發的舊版裡加一個「客戶分級報價」的功能。找來看的人說，這套系統當年把價格寫死在好幾個地方，改一處、別處的價格就會對不上，得先全部拉出來重整。這不是功能難，是底下的帳本來就記得亂——這一格，他就該記成一個清楚的扣分。

第二格：你接下來要的功能，跟原本的架構差多遠

第二件，是把眼光放到這一個功能之後。你現在只想加一個對帳表，但你接手這家工廠，接下來三年還想做什麼？要不要接電商訂單、要不要讓外面的物流資料自動進來、要不要手機上也能看庫存？

這一格決定改版的天花板在哪。如果你未來要的，都還在原本這套系統設想過的範圍裡——它本來就是為了管進銷存做的，你加的也還是進銷存的事——那改版通常接得住。但如果你要的方向，是這套十年前的系統當年根本沒想過的事，那就算這次硬改上去，下次、下下次還是會一再撞牆。一直在一個裝不下的架構上加東西，加到後來的總花費，常常比一次做對還高。

舉一個設想的情況。一家連鎖手搖飲的二代，舊系統當年只為單店櫃台設計，他接手後想做的卻是十家店的總倉調撥、各店即時庫存、總部一張報表看完。這些需求跟原本「一家店結帳」的架構差太遠——這種時候，與其在舊的上面一塊一塊補，不如把系統重新開發放上桌面認真算，因為他要的已經是另一種系統，不是同一種系統的新版本。

第三格：換一組人從頭熟悉這套系統，要付多少看不見的錢

第三件，是最常被漏掉的一筆：換人的成本。原本做這套系統的人聯絡不上了，不管你選修補、改版還是重做，接手的都是一組對這套系統完全陌生的人。他要先讀懂十年前別人寫的東西，才動得了手——這段「熟悉的時間」，你多半是要付錢的，只是它不會單獨列在報價單上。

這一格的重點是：這筆銜接成本，修補、改版、重做各自差多少。如果是小修補，接手的人只要看懂要動的那一小塊；如果是系統重新開發，他反而不必去讀舊程式，直接照你現在的流程重做一套——有時候，正是因為舊系統老舊無法維護、沒人願意花時間去讀它，重做的總成本反而比硬改更實在。這不是說重做一定划算，是說你比價的時候，要把「讀懂舊系統要花的時間」也算進改版那一邊，兩邊才公平。

舉個會遇到的樣子。一家做五金零件的貿易商，原廠商失聯，找了新的系統開發公司來接。對方報了兩個數字：照舊系統改版是十四萬，但要先花三週讀懂舊程式；全部重做是二十二萬，不必讀舊的。老闆本來只看總價，覺得改版便宜八萬；把那三週的來回與風險算進去之後，他才看懂這兩個數字其實沒差那麼多。隱形的成本一攤開，選擇就不是「貴的和便宜的」，是「哪一種的錢花得明白」。

四格打完，答案自己會浮出來

把這四格擺在一起看，答案不會全指向同一邊——多半是兩格偏修、兩格偏重做，而你會從「哪幾格對你最要緊」裡，看出這次該往哪走。

四格都還好，那就是小修補；卡的是技術債、但未來需求還在原本範圍裡，那是舊系統改版；如果未來需求和架構差太遠、程式又幾乎沒人動得了，那才是真的該做系統重新開發的時候。重點是，這張表是你自己填的，不是工程師一句「太舊」替你填的——你再回頭跟對方談，問的就不會是「要不要重寫」，而是「我這四格是這樣，你的報價是對著哪幾格來的」。

想把這四格問清楚、或是正在改版與系統重新開發之間拿不定主意，意思創意的 App 與系統開發服務頁有完整的拆解可以參考。