🎯 什麼情境該想到我
當「技術債已經讓交付速度掉一個數量級、每個人都知道該停下來整理，但功能永遠排在前面」時。
這張卡回答的是最難的那部分：怎麼真的喊得動停、停多久、停下來的時候到底做什麼。
⚙️ 怎麼用（書中的 Project Inversion）
- 先算出痛的數字，別用形容詞。書中 Kirsten 抽樣統計：實作一個功能平均要動用 4.2 個團隊、很多要跟 8 個以上團隊互動；同一級別的功能兩年前只要 2–4 週，現在要 20–40 週。有這種數字才談得動。
- 設明確且短的期限——書中是 30 天。不是「這一季有空就做」，是有終點的全力衝刺。
- 要一份高層具名的正式備忘錄，而且功能與部署同時凍結（緊急變更除外）。書中 Chris 的信原文：
“Effective immediately, as part of Project Inversion, there will be a feature freeze for the Phoenix Project. We will make a maximum effort for thirty days to increase the stability and reliability of Phoenix, as well as all supporting systems.”
- 用一個問題產出清單：「如果有人給我們授權、而且一個月內資源無限，我們會做什麼？」書中當場列出的答案很值得抄——
- 每個開發者用共用的建置環境
- 每個開發者都有持續建置與整合系統撐著
- 每個人都能在類生產環境跑自己的程式
- 用自動化測試套件取代手動測試，把 QA 的人釋放去做更高價值的事
- 解耦架構，讓功能團隊能各自獨立交付
- 團隊需要的資料都用好用的 API 提供
- 保護約束點上的那個人，要保護到近乎誇張。書中 Brent 被移出 pager 輪值、退出所有郵件列表、關掉所有聊天室通知、不准接電話，連故障會議都不准去，去了就開除；另外指派專人替他擋掉所有email與電話。目的不是特權，是確保他不把時間浪費在不該他做的事上。
🧪 我實際套用的紀錄
- 2026-08-02：（待填）
⚠️ 注意 / 什麼時候不適用
- 書中寫明的失敗模式：頭一週會被拿去吵範圍，而且多數團隊照常在做功能。所以「發了備忘錄」不等於「凍結生效」，要真的去查。
- 一定會有人政治性反彈。書中 Sarah 的說法是「這些閒著的開發者正在危及公司對顧客和華爾街的承諾」——要預期這種攻擊並準備好回應。
- 這是一次性的 stand-down，不是「每週固定還債時段」。書中並沒有講後者，別把兩者混為一談。
- 適用前提是債已經大到讓正常交付停擺。債還可控時，用日常的持續改善處理更划算。
🔗 相關工具
- 工具-五大理想 —— 上位診斷框架：功能凍結是把第三理想「改善日常工作」從口號變成排程的一次性手段
- 工具-找出並管理約束點 —— 凍結期間的核心動作：把資源集中到約束點，並用近乎極端的手段保護它不被打斷
- 工具-部署管線與持續交付 —— 凍結期間清單上最常見的一批工程投資：共用建置環境、CI、類生產環境、自動化測試
- 工具-降低在製品WIP —— 同一招在專案層級的版本：《鳳凰專案》的「專案全面凍結 → 分批解凍」跟這裡的功能凍結是同一個思路