軟體維護費用怎麼算？影響成本的5大因素與預算規劃重點

軟體維護費用？這題超多人問，但答案比你想的更複雜

OK，直接切入重點。每次有人問「軟體維護費用怎麼算？」，大家最常聽到的答案就是「抓開發成本的 15-20%」。 講真的，這個數字...有點用，但也很誤導。把它當成一個超粗略的起點可以，但千萬別當聖經。

實際上，維護費用可能低到 10%，也可能飆到快 40%。 為什麼差這麼多？因為「維護」這兩個字，裡面包山包海。就像你養一台車，只有換機油是保養，引擎大修也是保養，加裝渦輪改性能...也算廣義的保養。軟體也一樣。

所以，問題不該只是「多少錢」，而是「我的錢花到哪裡去了？」這才是關鍵。接下來，我會把我邊聽邊想的筆記整理一下，拆解這筆錢到底怎麼花的，又該怎麼規劃。

先說結論：錢都花在這四種「看不見」的工作上

軟體上線只是開始，後面的事才是大宗。研究說維護成本可能佔整個軟體生命週期總成本 (TCO) 的 50% 到 80% 甚至 90%。 這些錢，主要花在四種不同的維護類型上。比例會變，但基本上跑不掉這幾項：

• 修正性維護 (Corrective)： 這最好懂，就是抓蟲 (Bug)。 App 閃退、按鈕沒反應、算錯錢...都是。這部分大概佔了 20% 左右的維護心力。
• 適應性維護 (Adaptive)： 這部分是為了讓軟體適應新環境。 比如作業系統從 Windows 10 升到 11，或是串接的 Facebook API 改版了，你的軟體也得跟著改，不然就跑不動。法規變更也算，像是新的個資法要求，你就得去改資料處理邏輯。這塊佔比不小，有時甚至到 50%。
• 完善性維護 (Perfective)： 這塊其實是最多錢的，大概 25-30%，甚至更高。 簡單說，就是「讓軟體更好用」。 可能是優化使用者介面 (UI)、增加一個小功能、提升系統效能等等。O'Reilly 有個 60/60 法則，說 60% 的維護費用其實都花在這種功能增強上。
• 預防性維護 (Preventive)： 這最容易被忽略，但也最重要。就是重構程式碼、優化資料庫結構、更新老舊的套件。 目的是為了讓軟體在未來更容易維護、更穩定，避免以後出大問題。雖然只佔 10-15%，但做得好可以省下大錢。

到底什麼在影響我的維護成本？五大核心因素

好，既然知道錢花在哪幾種工作上，那到底是什麼決定了這些工作的「工作量」？這就是估價的核心了。我快速記下幾個最重要的點：

1. 軟體本身的複雜度
這超直觀。一個只有五個頁面的形象網站，跟一個串了金流、物流、會員系統的電商平台，維護成本絕對是天壤之別。要看的指標有：程式碼行數 (Lines of Code)、有多少功能模組、跟多少外部系統整合 (例如：ERP、CRM、第三方 API)。 架構越複雜，牽一髮動全身的可能性就越高，修個小東西都可能要花很多時間做迴歸測試。

2. 技術債 (Technical Debt)
這個超、級、重、要！「技術債」簡單說，就是當初為了快，寫了「能動就好」但「不夠好」的程式碼。 可能是架構沒想清楚、用了過時的技術、或是根本沒寫註解和文件。 這些「債」未來都要還，而且是加倍奉還。你現在閃退、改不動、效能差，很多時候都是在還以前欠的技術債。 技術債越高，修正性跟預防性維護的成本就越高，因為工程師要花大把時間去理解那些天書一樣的 code。

3. 團隊的技術能力與穩定性
一個經驗豐富的團隊，跟一個都由新手組成的團隊，處理問題的效率肯定不同。 如果團隊人員流動率高，新人要花很多時間熟悉系統，這都是隱形成本。而且，當初寫程式的人都走光了，後面接手的人光看懂程式碼就要半天，更別說修改了。

4. 使用者數量與業務關鍵性
一個 500 人在用的內部系統，跟一個有 50 萬會員的線上服務，對穩定性的要求完全不同。 使用者越多，伺服器負載、資料庫壓力就越大，需要投入更多資源在監控和效能調校上。而且，如果這個軟體是公司的生財工具（例如訂票系統），那一分鐘都不能停，你就得花更多錢在備援、監控和快速反應的服務上。

5. 維護合約的類型與服務水準 (SLA)
你跟廠商簽什麼樣的合約，當然直接影響價格。 是按時計費 (Time & Materials) 還是固定年費 (Fixed Price)？ 合約有沒有保證「服務水準協議 (SLA)」，例如保證問題發生後 4 小時內要回應、24 小時內要解決？ 這些保證背後都需要人力和資源待命，自然會反映在報價上。

預算怎麼規劃？一個務實的思路

知道了影響因素，那到底要怎麼編預算？這裡提供一個我自己覺得比較實際的思考流程，而不是只用一個簡單的百分比。

首先，得接受一個事實：軟體維護跟開發是兩回事。 開發是一次性的專案，有明確的開始和結束；維護是持續性的營運，是為了讓軟體「活下去」並且「活得好」。

再來，可以參考一下國際研究機構像 Gartner 的數據當作一個大方向的 benchmark。Gartner 提到，軟體生命週期不同階段的維護費用佔比也不同：

• 早期 (1-2 年): 每年約佔開發成本的 10-25%。這階段通常 Bug 比較多，需要密集的修正性維護。
• 中期 (3-5 年): 每年約 15-30%。系統穩定下來，但可能需要配合業務成長做功能增強（完善性維護）或環境升級（適應性維護）。
• 成熟期 (6 年以上): 可能高達 20-40%。這時候技術可能開始過時，技術債慢慢浮現，需要花更多錢做預防性維護，或是為了跟上時代做大的架構調整。

這就帶到一個在地化的差異點。國外的顧問公司（如 Gartner, ScienceSoft）很習慣用這種生命週期和 TCO (總持有成本) 的模型來做長期規劃。 他們把維護視為一項策略投資。但在台灣，特別是一些中小企業或政府標案，我觀察到比較傾向「一年一簽」的合約模式，有時更重視當下的「維護人力成本」而不是長期的「系統健康」。

例如，我查到中華民國資訊軟體協會的《資訊服務委外經費估算原則》，裡面就詳細列出了工程師的薪資、管理費、公費等計算基準。 這比較像是一種「成本法」，算出我投入多少人力、所以值多少錢。而國外顧問的模型更像是「價值法」，思考這個系統為我帶來多少價值，我願意花多少錢去保護和提升這個價值。兩種沒有絕對好壞，但思考的出發點很不一樣。

再舉個例子，行政院公共工程委員會對於資訊服務採購的規範，也比較著重在計價辦法和契約範本的標準化，確保採購流程的公平性。 這跟台灣的採購文化有關，強調「依法行政」、「公開透明」，所以會有比較詳細的人月計價標準。 但這也可能導致廠商為了得標而低價搶標，先把技術債欠著，後續維護再追加預算，這都是實務上常見的狀況。

不同維護合約類型的比較

簽合約的時候，廠商通常會提供幾種選項，這裡快速筆記一下優缺點，這對預算影響很大。

常見錯誤與修正：別再這樣想了！

最後，整理幾個在規劃維護預算時，大家最容易踩的坑。

• 錯誤一：把維護當成「保險」，沒事就不用花錢。
  很多人覺得，我付了維護費，系統都沒出事，錢是不是白花了？ 這是大錯特錯。好的維護，就是讓你「感覺不到它的存在」。預防性維護就是一直在幫你打掃家裡，所以你家才不會變成垃圾屋。 等到你看到蟑螂老鼠（系統崩潰）才要處理，那花的錢更多。
• 錯誤二：為了省錢，能不升級就不升級。
  「這系統還能用啊，幹嘛花錢升級？」這就是標準的在累積技術債。 舊的作業系統、舊的資料庫、舊的程式語言框架，都有潛在的安全漏洞。等到被駭客入侵、資料外洩，那損失絕對不是一年幾萬塊的維護費可以比的。
• 錯誤三：文件不重要，程式能跑就好。
  軟體開發商有時候為了趕快交差，系統文件（例如架構圖、API 規格書、部署手冊）都隨便寫寫，甚至不寫。 這超級危險！如果哪天你換了維護廠商，或是原廠的工程師離職了，沒有文件，新的團隊等於要從零開始摸索，這調查的時間成本都會算在你的頭上。簽約時一定要要求廠商提供完整的技術文件。
• 錯誤四：只看報價總額，不看服務細項。
  A 廠商報 10 萬，B 廠商報 12 萬，所以 A 比較便宜？不一定。你要看這筆錢包含了什麼。 有沒有包含緊急支援？有沒有包含效能調校？每年提供幾次的功能更新？這些都要問清楚。很多時候，便宜的報價只是因為它把很多你未來會需要的服務都當成「額外收費」項目了。

總結來說，軟體維護費用的評估，是一個需要從技術、商業、管理多個角度去思考的立體問題。別再被「開發成本的 15%」這個數字綁架了。好好檢視你的軟體現況、未來的業務需求，還有你願意為「穩定」和「成長」付出多少代價，才能規劃出真正合理的維護預算。