🎯 什麼情境該想到我
當你「行事曆被新功能塞滿，重構與自動化永遠排不進去」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：把償還技術債變成常態預算，而不是每次都要重新去爭取的例外。
做法要點：
- 先理解為什麼會惡性循環：最需要改善的組織，往往正是最沒時間改善的組織。技術債讓這件事在技術組織裡格外嚴重。（L3217–3220）
- 財務債的類比：只付利息、從不還本金的組織，最後會落到連利息都付不出來。技術債一樣——組織被日常的 workaround 壓垮到再也做不了任何新工作，等於只在付利息。（L3221–3227）
- 硬性配額：至少 20%。主動管理技術債的方式，是確保投入所有 Development 與 Operations cycles 的至少 20% 在重構、自動化工作、架構，以及非功能需求（NFRs）。（L3229–3233）
- NFR 就是那些 “the ilities”：maintainability、manageability、scalability、reliability、testability、deployability、security。（L3231–3233）
- Marty Cagan／eBay 版本（源自 eBay 1990 年代末的瀕死經驗，L3245–3256）：
- 產品管理與工程之間的協議是——產品管理從團隊產能的頂端直接拿走 20%，交給工程照他們認為合適的方式運用。
- 工程可以拿它去改寫、重新架構、或重構程式碼中有問題的部分——任何他們認為必要、能避免有天得回頭跟團隊說「我們必須停下來把所有程式碼重寫」的事。
- 如果現在狀況真的很糟，可能需要拉到 30% 甚至更多；而 Cagan 說，看到有團隊以為自己能用遠低於 20% 的比例過關時，他會很緊張。
- 不繳「20% 稅」的後果：技術債會累積到組織把所有 cycles 都花在還債；服務脆弱到功能交付完全停擺，因為工程師全在處理可靠性問題或繞過問題。（L3258–3262）
原文：「We will actively manage this technical debt by ensuring that we invest at least 20% of all Development and Operations cycles on refactoring, investing in automation work and architecture and non-functional requirements」（L3229–3232）
原文：「Product management takes 20% of the team’s capacity right off the top and gives this to engineering to spend as they see fit.」（L3248–3250）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 這 20% 產生的是正向但使用者看不見的價值（書中圖 11 的標題就是這樣寫的），不會出現在功能清單上——所以必須事先講好、由制度保障，不能靠臨時爭取。（L3238）
- 從產能頂端先扣是關鍵動作。若改成「有空再做」，這一節描述的惡性循環會照樣發生。
- 30% 不是預設值，是「狀況真的很糟」時的例外；書中的下限守則是不要低於 20%。
- 附帶效果：把技術債的額外壓力從工作者身上移開，也能降低 burnout。（L3267–3268）
🔗 相關工具
- 工具-技術債功能凍結（《獨角獸專案》的強力版本：債大到還不動時直接凍結新功能；本條是日常版的固定配額）
- 價值流圖（用圖上的數字證明技術債正在拖慢哪一段，才要得到這 20%）
- 演進式架構（20% 產能常常就是拿去做絞殺者式的漸進重構）
- DevOps手冊