工程師最討厭的就是技術債了（尤其不是自己寫的程式）。既然是「債務」，就如同財務上的債務一樣，是需要管理的，所以技術債也是技術管理所需要處理的範疇之一。
我覺得技術債最適切的比喻是 Gipi 的這篇文章。如果把技術債比對到財務的債務的話，有的時候為了加速或槓桿出成長，會需要借錢來發展而欠下債務，這樣的欠債其實是良性的投資，當投資有收益（產品產生的效益）後，就能夠安排資源來還債。
欠債的時機
那什麼時候應該要欠下技術債（採用替代方案 Workaround）呢？我認為有幾個好時機點：
欠債的成本很低：這個替代方案很容易拆除掉，且對客戶體驗與資料的乾淨程度影響很低。
我有個經驗是在實作帳號的系統時，原有帳號系統並沒有審核的機制，會需要增加一個審核的流程，但審核的標準與流程還需要實際嘗試過才會知道是否存在沒有考慮到的問題。
於是我在中間加了一個線上試算表 (Google Spreadsheet) ，先不開發機制，而是讓審核的同事可以先用試算表審核，審核過了之後再定期匯入系統。
這樣當未來要加入審核機制時，原本的替代方案很容易拆除，且對資料的正確性與乾淨程度影響也很低。另外相對於審核機制，使用者不會感受到服務水準降低（審核通過的時間沒有因此拉長）。欠債的效益很高：這個替代方案能夠大幅降低開發時間，更早對客戶產生效益。
未來變動性很大，欠技術債能延遲作技術決策的時間點：這是從 Clean Architecture 這本書的觀點延伸出來的。延遲決策可以幫助收集更多資料，來決定最適合這個產品的技術細節。
舉例來說，開發系統時先把資料以 JSON 格式儲存在檔案裡（這是一個技術債），到快要上線前再來決定要用哪一套 RDBMS 或是 NoSQL 資料庫來儲存。
何時還債
我覺得從還債的價值與開發新功能的價值來比較，對應到商業上的營收或成本，是一個很好的決策方式。
之前的經驗，我認為有幾個好時機點：
還債的價值是目前所有工作清單中效益最高的：例如改善帳號審核機制，可以少聘審核的工讀生，能節省成本。
技術債可以拆成好幾個階段還，逐步交付，而先進行第一個階段效益很明顯（例如可以大幅縮短未來的開發時程）。
有新的工程師加入，需要讓他熟悉商業模式與產品流程：建議需有對應的自動化測試來保護，讓工程師不會有太大的心理障礙。
只要是以技術開發產品來創造價值的公司，一定會有技術債。產品沒有活下來的話，也不會有技術債。因此，技術債是必然會發生的事情，我們必須正面的看待它才能好好的管理並加速產品的發展。
#技術管理閒聊 系列不定期出刊，如果您覺得有幫助，歡迎分享出去讓更多人看到。
如果你除了本系列文章，還想收到定期出刊的 #技術管理觀點 系列，歡迎輸入 Email 訂閱電子報。
技術管理閒聊：技術債