概念地圖・技術債與它的利息
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：系統
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
技術債與它的利息：當初省下的兩週，每個月都在還
一家系統櫃工廠的出圖系統，改一個板材尺寸要動七張表。五年前為了趕上那一波裝潢潮，有人把板材規格直接壓進報價單裡——當時省下兩個禮拜，現在每個月都在還。技術債要畫的，是一件比「哪裡寫得爛」更冷的事：省下來的時間是本金，之後每個月多繞的那幾天是利息，而利息會自己長大。這一頁把它拆成上下兩層——下層看本金怎麼一段一段堆高，上層看交付速度怎麼隨著年份岔成兩條。
把上下兩層讀成一張帳單
圖上每一格，都能換成一句話。
| 時間 | 本金堆（累積工作天） | 不還債的交付天數 | 第 2 年起還債的交付天數 |
|---|---|---|---|
| 第 1 年 | ＋10 天，累積 10 天 | 8 天 | 8 天（同一個起點） |
| 第 2 年 | ＋6 天，累積 16 天 | 11 天 | 13 天（還債期間更慢） |
| 第 3 年 | ＋12 天，累積 28 天 | 15 天 | 9 天 |
| 第 4 年 | ＋4 天，累積 32 天 | 20 天 | 8 天 |
| 第 5 年 | 沒再抄，仍是 32 天 | 26 天 | 7 天 |
最刺人的是第 5 年那一列：同一個功能，一邊要等 26 天，一邊 7 天。而分岔點早在第 2 年——那一年，還債的那條反而更慢，13 天對 11 天。願意吃下那一年的人，第 3 年就開始領回來。本金那一欄的數字愈堆愈高，真正決定命運的卻是右邊兩欄什麼時候岔開。
怎麼看出一筆債正在收你多少利息
一、本金：當初到底省下多少。本金是這張圖上唯一能被準確算出來的一格，因為它發生在你眼前。系統櫃工廠那一刀省下 10 個工作天，當時有人記得。麻煩的是，本金一被算出來，大家就以為債務規模就是這麼大——它只是入場費。自問：這段程式當初趕的是哪一個死線？省下的天數，現在還有人說得出來嗎？
二、利率：現在每個月被扣走幾天。利率是每個月因為這段程式而多花掉的時間。它不會出現在任何報表上，只出現在工程師的口頭禪裡：「這裡不能亂動」「要改的話兩邊都要改」。把這種話出現的次數，乘上每次多花的半天，你就有一個粗略的月利率。自問：最近一季，有多少次改動因為這段程式而被迫變成兩份工？
三、還款期：停下來還，要慢多久才回得來。還債要收費。圖上綠線在第 2 年頂到 13 天，比同一年不還債的 11 天還慢——那段時間你得向老闆解釋為什麼交付變慢了。還款期的長度決定這筆債值不值得現在還，也決定你需要多少政治資本才撐得住。自問：如果接下來一季交付明顯變慢，你手上有沒有東西可以拿去換？
四、到期日：這段程式還會活多久。有些債永遠不必還。那條產品線半年後要收掉、那段報價邏輯明年就要整個換掉——它的利息會跟著歸零。到期日是這張圖上唯一能讓你合法不還的一格，也是最少人去查的一格。自問：一年後，還會有人動到這段程式嗎？根據是什麼？
一家系統櫃工廠，把出圖系統這五年的帳攤開
- 第 1 年・下那一刀：為了趕裝潢潮的交期，板材規格被直接壓進報價單的計算式裡，省下 10 個工作天。趕上了那一季的檔期
- 第 2 年・第一次繞路：設計師想加一種封邊，工程師得同時動報價與出圖兩邊，本金再堆 6 天上去。改一邊忘了另一邊，展示間的報價單印錯過一次
- 第 3 年・加碼：為了接一批急單，五金編碼又被塞進同一段計算式，堆上 12 天。從此沒有人敢一個人動這段
- 第 4 年・利息變成固定支出：每個月固定 3 個工作天，花在「同一件事要改兩個地方」。本金補上最後 4 天，累積 32 天。一年十二個月就是 36 天，是當初省下那 10 天的 3.6 倍
- 第 5 年・岔路口：什麼都不動，一個功能從提出到上線要 26 天；如果第 2 年就停下來還，這一年只要 7 天。兩條路的起點，都是第 1 年那個 8 天
五年下來，這家工廠的本金堆到 32 天，數字看起來還好——真正把人拖住的是利息。每個月 3 個工作天，一年十二個月就是 36 天，比四次捷徑加起來省下的 32 天還多。也就是說，光第一年的利息，就已經把整堆本金付完還有剩。更難算的在後面：交付從 8 天變成 26 天，中間流失的除了工時，還有設計師等報價時跑掉的案子、工程師每次動手前先確認七張表的那口氣。這張圖真正的用途，是把「要不要現在停下來」從一句年年被押後的良心話，換成一個有數字的決定。以上為說明結構用的示意情境，僅供理解框架之用。
這框架什麼時候會騙你
- 「技術債」這個比喻本身就會騙人。真正的債有明確的利率與到期日，技術債兩樣都沒有。它的利息會隨著碰那段程式的人數與頻率上下浮動——團隊一擴編，同一段程式的利息就跟著往上；而且有些債永遠不必還，那段程式再也沒人碰、那條產品線本來就要收掉。把每一筆債都當成必須還的，跟完全不還一樣糟：前者把工程師的時間花在替死人守墓，後者讓還活著的部分愈跑愈慢。用這個詞的時候，記得它是借來的比喻，不是會計科目。
- 把「寫得醜」都算進債裡，帳就沒法對了。命名難看、縮排不一致、函式偏長——這些多半只是風格，沒有人因為它們每個月多吃掉 3 個工作天。技術債的定義窄得多：它必須產生可觀測的重複工，同一件事要在兩個以上的地方做完才算數。分不清這兩件事的團隊，通常會生出一張兩百項的待重構清單，然後永遠不會開始，因為那張清單看起來像一個還不完的無底洞。
- 只算得出本金，就會低估整件事。大部分團隊講技術債，講的是「當初省下多少」。但決定要不要還的，從來是利率與剩餘年限。一段每個月只被碰一次的舊模組，本金再大也可以放著；一段每週都要動、明年還要再接兩條產品線的計算式，本金再小也該排最前面。用本金排優先序，你會先修最顯眼的那一段，然後發現交付速度一點都沒變快。
這筆利息，記在誰的帳上
這筆利息從來沒有進過財報。
它記在客戶等待的天數上，記在工程師每次動手前先嘆的那口氣裡，最後記在離職單上。P.A.I.N. 的第一格問「誰在痛」——技術債最麻煩的地方，就在於付錢的人跟省錢的人從來不是同一批：當年砍掉那兩個禮拜的是趕檔期的專案經理，五年後每個月付掉 3 天的是三個接手的工程師，而真正吃下 26 天等待的，是那個下單前想再改一次規格的設計師。這張圖畫得出利息有多大，畫不出它被記在誰身上。所以看完圖之後真正該做的第一件事，是先找出那個一直替全公司付利息、卻沒有權力停下來還的人。今晚翻出最近三張拖最久的需求單，在每一張旁邊補一欄：多等了幾天。這一欄補上去，帳就開始有人在對了。
常見問題
技術債一定要還嗎？
不一定。判斷的關鍵是這段程式的剩餘壽命，以及它每個月實際吃掉多少時間。一段沒人碰、明年就要下架的舊邏輯，利息接近零，還它等於把工程師的時間丟進水裡。一段每週都被動到、還要再接新產品線的核心計算式，就算本金看起來很小，也應該排在最前面。先估利率跟到期日，再決定要不要動；把這個順序反過來的團隊，通常會把力氣花在最顯眼、卻最不痛的地方。
怎麼跟只看數字的老闆解釋技術債？
別從程式碼講起。把它換算成兩個他每天都在看的數字：一個功能從提出到上線要幾天，以及每個月有幾個工作天花在重複的修改上。系統櫃工廠那個例子裡，「每個月 3 天」比「這段程式耦合太重」好用得多——前者可以乘以十二、可以再乘上人力成本，後者只會換來一句「那你就去改啊」。老闆聽不懂技術債，但沒有主管聽不懂「同一件事我們每個月做兩次」。
打掉重寫算不算還債？
算，但它是最貴的一種還法，而且常常在借新債。重寫的本質，是把舊系統累積的所有隱性規則在有限時間內重新實作一次，而那些規則有一大半沒寫在任何文件上，只活在舊程式的分支裡。比較穩的還法是分期：挑一段每個月吃掉最多時間的邏輯，把它包成一個邊界清楚的模組，讓後續改動只需要動一邊。圖上綠線之所以在第 3 年就回到 9 天，靠的是這種分期還法，不必停機半年重來。
技術債的利息怎麼估才不會變成拍腦袋？
用三個可以直接數的東西：這一季有多少次改動需要同時動兩個以上的地方、每次多花幾個小時、以及有多少次上線後被退回重做。前兩項相乘就是這一季的利息，第三項是罰款。數字不必精準，只要能連續三個月用同一種方法數，趨勢就看得出來。價值也在趨勢：利息如果每一季都在變大，代表你除了付利息，還在繼續借。
五年後再回頭看，當初省下的那兩個禮拜早就沒人記得，記得的是每一次動手前要先確認七張表。同一筆改動放在專案的不同關卡，價差會拉開多少，可以接著看變更成本曲線；至於「晚一週上線」到底要付掉多少錢，延遲成本那頁把它拆成了幾種形狀。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。