軟體維護成本：沒人編進預算的部分

軟體維護成本，就是那個讓一個成功專案在十八個月後變成一場尷尬談話的數字。開發階段有預算、有簽核，也如期交付了。可是上線之後會發生什麼事，被一句「技術支援」草草帶過，再配上一個有人憑感覺喊出來的金額，而那個金額幾乎每次都太小。

原因出在結構，不是誰不用心。開發有一個可以報價的範圍。維護沒有範圍，因為決定它的是還沒發生的事：某個相依套件爆出漏洞、某家供應商改掉自己的介接規格、某位使用者碰上當初誰都沒想到的狀況。

人人都在引用的經驗法則是每年抓開發成本的 15 到 20 個百分點，而它之所以危險，正是因為它離正確答案不遠。 它對的次數多到讓人安心，錯的時候又總是往同一個方向錯：它低估了缺陷集中浮現的第一年，而在有法遵義務或外部介接很多的系統上，它會整個失準，因為在那樣的系統裡，推動工作發生的是外部事件，而不是你自己的程式碼。

軟體維護成本實際包含什麼

一共五類性質不同的工作，把它們混為一談，正是錯誤數字的來源。

修正性工作。 修掉缺陷。它集中在前期，因為多數問題會在真實使用的頭幾個月浮出來，這也是百分比法則唯一處理得還算像樣的一類。但每一件的分量事先都看不出來，本以為只是小修，最後卻牽動到設計的重新檢視。

調適性工作。 跟上那些不由你決定的變化。某個相依套件釋出資安修補。某家金流服務商停用一個介接版本。某個瀏覽器改了行為。這些都不會替產品加上任何新功能，但每一項都非做不可。

預防性工作。 在被逼著升級之前先升級。跳過它並不會讓開銷消失，只是往後遞延並且繼續變大，一次尋常的框架升級最後拖成三個月的工程，走的就是這條路。

日常維運。 主機託管、監控、備份、憑證，以及盯著這些東西的人所花的時間。它常常單獨記帳，這沒什麼問題，只要真的有人在記。

小幅異動。 系統一旦有了真實使用者，就會源源不絕地產生調整需求。單看每一件都無關緊要，加起來在多數年份卻是最大的一類。每一件看起來十分鐘就能處理完，可是把核對、上線與回覆都算進去，半天也就沒了。

大家平常講的維護，只指第一類。預算不夠用的原因，落在另外四類身上。

百分比法則為何會誤導人

因為它錨定錯了量。維護的工作量取決於活動零件有多少，以及外部世界改動它們的速度有多快，而不是當初開發剛好花了多少錢。

兩套用同樣預算做出來的系統，投入可以差到三倍。一個自成一體、只有兩個相依套件、不受法規約束的應用，維持運作很便宜。一個串接六個第三方服務、處理個資、還要遵守產業規範的系統就不是這樣，因為其中每一個介接，都是一處你排不進自己行事曆的工作來源。

百分比還假設有一種穩定狀態，而第一年根本不存在這種狀態。真實使用會把缺陷找出來，上線後的頭六個月通常遠高於全年平均，之後才慢慢落下來。

更好的估算從活動零件開始。數一數介接的數量、要承擔的法遵義務，以及會產生詢問與報修的使用者規模，再替這些事情實際吃掉的時間報價。我們談客製軟體開發成本 的指南，講的是同一道算術題的開發那一側。

團隊漏掉的支出項目

相依套件升級。 這不是選配，因為沒有修補的套件正是系統被入侵的通道，而工作量真的難以預料，因為它取決於上游維護者做了什麼。

第三方介接變更。 供應商停用一個版本，並且給你一個期限。時間不是你訂的，你也沒辦法拒絕。

憑證與網域續約。 微不足道的小事，直到其中一個在週末到期，網站跟著打不開。

監控，以及對監控的回應。 沒有人去回應，警示就毫無用處，而那份隨時能接手的待命狀態是實實在在的成本，不管那個月有沒有出事。

知識交接。 人是會離開的。下一個人把系統搞懂所要付出的代價，就是一筆維護成本，而且當初寫下來的東西越少，這筆代價越高。

資料成長。 儲存費用往上走，原本很快的查詢開始變慢，而處理這些問題的工作，會照著你自己成功的節奏找上門。我們談資料庫效能 的指南，講的是這件事在實務上的樣子。

在英國大概要花多少

維護一套客製系統的大致年度區間，假設交給外部服務商而不是自己養人。

這些數字不含主機託管與授權費，兩者分開計費，差異極大。它們同時假設系統處在還過得去的狀態。如果要接手的是一套沒人寫過文件、沒有測試、只有一個人看得懂的系統，費用會更高，而且帶著任何合約都消不掉的風險。

該怎麼安排合作方式

約定工時的定額合約適合工作量大致可預測的情況。你買到的是隨時可用的回應能力，而你付的錢多半正是為此；沒用完的工時並不算浪費，因為另一個選項是根本找不到人。

依工時與實際投入計費適合變動很少的系統，但回應速度就是服務商其他承諾所允許的速度，這是你接受的取捨。

固定價格的支援合約把風險移到服務商那邊，服務商則會把這份風險算進費用裡。對於可預測性比利潤率更值錢的關鍵系統，這是合理的選擇。

不管選哪一種，都要在真正需要之前，先談好什麼算維護、什麼算新功能。這條界線是支援關係中幾乎所有爭執的源頭，而在一開始把它講清楚不花一毛錢。

作為軟體開發 業務的一部分，Mecanik 既維護自己做的系統，也維護不是自己做的系統。任何一次接手，第一個月通常都花在文件上：把運作歷程、已知缺陷與外部介接清單一條條寫下來。因為正是這份文件決定了之後每個月的成本。

延伸閱讀： 固定價格合約還是依工時計費？ 、怎麼寫出能拿到有用報價的軟體需求書 、軟體原始碼信託：到底誰真的需要 以及MVP 軟體開發：範圍、成本與時程 。

常見問題

軟體維護每年要花多少錢？ 常見的經驗法則是每年抓開發成本的 15 到 20 個百分點，但它低估了缺陷集中浮現的第一年，在介接很多或帶有法遵義務的系統上更是完全失準。英國的大致區間是：介接很少的小型內部工具每年 £6,000 到 £15,000，受法規管制或高流量的平台則在 £60,000 以上，都不含主機託管費用。

軟體維護實際上包含哪些內容？ 五類：修掉缺陷的修正性工作、跟上相依套件與第三方介接變化的調適性工作、在被逼之前先升級的預防性工作、主機託管與監控這類日常維運，以及線上系統源源不絕產生的小幅異動。多數人所說的維護，只指第一類。

用開發成本的百分比估算為什麼不可靠？ 因為它錨定錯了量。維護工作量取決於活動零件的數量，以及外部世界改動它們的速度，而不是開發花了多少錢。兩套用同樣預算做出來的系統，可能因為介接數量、法規約束與報修量的差異而相差三倍。

團隊最常漏掉哪些維護支出？ 相依套件升級、第三方介接停用並附上你無權決定的期限、憑證與網域續約、監控警示背後那份隨時能接手的人力、人員離職時的知識交接，以及資料成長對儲存費用與查詢速度的影響。

該選定額合約還是按需付費？ 約定工時的定額合約適合可預測的工作量，買到的是隨時可用的回應能力，而你付的錢多半正是為此。依工時與實際投入計費適合變動很少的系統，但回應速度取決於服務商的其他承諾。不管選哪一種，都要在真正需要之前，先定義清楚什麼算維護、什麼算新功能。