你的軟體怎麼可以有 bug ! 聊聊軟體維護的成本及觀念

忻旅科技 https://www.revtel.tech/
Sam Huang https://www.sam-huang.info/

幾年前有次去談案子，業主想要透過整合資訊工具來替自己的產業做些商業模式的新嘗試。但隨著討論的逐漸深入，默默覺得有些違和感，總覺得有一層窗戶紙沒有捅破。

意識到是業主對於系統開發後的維護認知有點奇怪，點破之後聽到一句有趣的話：

「為什麼要維護？有 bug 你們就要負責啊，你們怎麼可以給我們有 bug 的東西！」

一瞬間我也是愣了一下，還差點被說服（？）。仔細想軟體維護好像還真的是不太好理解。

https://pixabay.com/photos/stones-zen-white-spa-alternative-2764287/

系統正常運作是結果而非手段

軟體維護的目的其實很單純 — 讓系統能夠正常的運作。

有句話說「幸福的家庭都是相似的 不幸的家庭各有各的不幸」，放到軟體上也是一樣。程式有 bug？流量超乎預期？雲端系統更新？版本控制錯誤？每個點都可能局部甚至全局造成系統失效。

而所謂的「正常運作」其實更是結果。站在終點規劃從起點該如何走來往往會是顧了這個漏了那個。

那該怎辦才好？

與其把視角放在具體的每一個任務上，不如去思考最基本的出發點 — 也就是風險的轉移及專業承擔。

維護的範圍不清楚，面臨的問題也是百百種

有些朋友可能會覺得，所謂的「維護」指的單純是 bug 的修復，超出的部分應該一律都叫「開發」（在此概念下，開發指的是功能的增刪修改）。但我們可以試著就風險轉移的角度來重新思考看看。

Johari Window : https://en.wikipedia.org/wiki/Johari_window

用 Johari Window 來思考在維護上的四個象限，那應該會是這樣：

1. 已知的已知：維護功能的「合理」運作。
   比如當用戶按了登入按鈕後就該觸發要求輸入的視窗。
2. 已知的未知：修復功能的「合理但不正確」運作。
   比如當登入視窗在新版作業系統中因 css 寫法而造成跑版。
3. 未知的已知：處理功能的「合理但未必需要」的運作。
   比如當登入視窗未被關閉但因為某些理由不可視卻遮蓋住主畫面。
4. 未知的未知：解決超出開發功能，但商業上卻需要解決的問題。
   比如忘記密碼的功能應該要搭配某些配套避免有人惡意使用。

等等 … 有些問題感覺應該是「新功能」而非「舊維護」，而有些問題更像是「需求沒有被完整釐清」。

是的，問題其實就在於軟體系統的開發及生存是連續性的，擷取當中片段並硬將任務切分成開發及維護本來就是很難做到的。或者換句話說，如果把 bug 的修復或者把系統從錯誤中回復視為是「優化」，那所有事情都都是開發了。

所以我們該怎樣規劃成本 … ?

很多時候維護費的計算可能還比開發估算來的困難。

事實上除了做哪些事情要討論，工程人力也存在隱性成本，比如當一個系統越久沒出問題通常也代表團隊對程式碼的熟悉度會漸漸下降。

但總得有些算法吧？不妨可以先建立以下理解

1. 固定成本：系統自然的複雜度及維運團隊的維護成本，負責的是「已知的已知」。這裡坊間有個大致算法是原開發成本的 10 ~ 30%。
2. 變動成本：保持彈性來封裝不可知的問題，負責的是「已知的未知」及「未知的已知」。這裡可以簡單大致的人天成本。
3. 優化成本：系統是活的，本來就需要定期檢視整個系統健康度，負責的是「未知的未知」。這裡應當是以擴充專案角度來應對，甚至更直接的排入開發計畫。

維護就像是買保險，保費該值得多少本來就該因時制宜且因地制宜。

結語：事情總是比我們想的更複雜

軟體系統的正常運作是環境、用戶及軟體三方順利協同的結果。任何一方情境改變都會造成這個和諧關係被破壞。

因此維護是勢必存在的，可以不理解，但無法不面對。

費用及資源的花費是嚴肅的事情，但也正因為如此，抱持積極的心態去面對這些不確定性才會是比較好的態度。

或者可以這樣說，可以不在其上花費用，但要好好注意風險承擔。

忻旅科技 https://www.revtel.tech/
Sam Huang https://www.sam-huang.info/