🎯 什麼情境該想到我
當你「所有人都知道那塊爛東西該修，但它永遠排不進下一個 sprint」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：來自豐田生產系統的 improvement blitz（又稱 kaizen blitz）——一段專門且集中的時間，用來處理某個特定問題，通常橫跨數天。Dr. Spear 的描述：一群人被聚集起來密集聚焦在一個有問題的流程上，閃電戰持續幾天，目標是流程改善，手段是集中使用流程外部的人來給流程內部的人建議。
做法要點
- 排定一段專門時間（一天到一週），團隊（或整個組織）自組織去修他們在意的問題——可能是一塊有問題的程式碼、環境、架構或工具。
- 這段期間不允許做功能工作（no feature work is allowed）。這是這個儀式的硬性條件。
- 團隊要跨越整個價值流，通常混編 Development、Operations 與 Infosec 工程師；讓那些平常不會一起工作的團隊把技能與努力合起來改善某個選定領域。
- 管理起來很簡單：選定一週，技術組織裡的每個人同時投入改善活動。
- 期末每個團隊向同儕做一次簡報，說明他們處理的問題以及他們做出了什麼。
- 力量來源：賦權給離工作最近的人，讓他們持續指認並解決自己的問題。Dr. Spear 的蜘蛛網比喻——蜘蛛在破洞出現時就修補，不會等到失效累積起來才動手。
別名：除了 kaizen blitz 與 improvement blitz，也被稱為 spring／fall cleanings、ticket queue inversion weeks。
Target DevOps Dojo（實例）
- Dojo 佔用約 18,000 平方英尺的開放辦公空間，DevOps 教練協助整個 Target 技術組織的團隊提升實踐水準。
- 30-Day Challenge（最密集的形式）：內部開發團隊進駐一個月，與專任的 Dojo 教練與工程師共事；團隊帶著自己的工作進來，目標是解決一個他們一直卡住的內部問題並在三十天內取得突破。全程與教練密集合作，以兩天為一個 sprint 進行規劃、施作與 demo。挑戰結束後團隊帶著新學習回到自己的業務線。
- 規模：Ross Clanton 說他們目前的容量是同時容納八個團隊做 30-Day Challenges，因此聚焦在組織最具策略性的專案（POS、Inventory、Pricing、Promotion 等關鍵能力都跑過 Dojo）。累積成果是兩百位學員通過 Dojo，完成十四個挑戰，而且「團隊在數天內達成平常要花三到六個月的事並不罕見」。
- 效果的具體數字：Target 開發經理 Ravi Pandey——「以前我們要等六週才能拿到測試環境。現在我們幾分鐘內就拿到，而且我們和 Ops 工程師肩並肩工作。」
- 較輕量的形式：Flash Builds（團隊聚在一起一到三天，目標是活動結束前交付一個 MVP 或一項能力）、Open Labs（每兩週一次，任何人都可以來 Dojo 找教練聊、看 demo 或受訓）。
Facebook hackathon → HipHop 編譯器
2008 年 Facebook 面臨嚴重容量問題（活躍使用者超過一億且快速成長）。在一次 hack day，資深伺服器工程師 Haiping Zhao 開始實驗把 PHP 轉成可編譯的 C++。接下來兩年組成小團隊做出 HipHop 編譯器，把所有 Facebook 生產服務從直譯 PHP 轉成編譯後的 C++ 二進位——HipHop 讓 Facebook 平台能處理的生產負載達到原生 PHP 的六倍。（後續 HHVM 以 JIT 取徑在 2012 年完全取代了 HipHop 編譯器。）
原文（硬性條件）：「schedule and conduct day- or week-long improvement blitzes, where everyone on a team (or in the entire organization) self-organizes to fix problems they care about—no feature work is allowed.」（L11143–11146）
原文（目標的界線）：「Our goal during these blitzes is not to simply experiment and innovate for the sake of testing out new technologies, but to improve our daily work, such as solving our daily workarounds.」（L11161–11163）
原文（Target 的等待時間）：「In the old days, we would have to wait six weeks to get a test environment. Now, we get it in minutes」（L11120–11121）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 這不是 hackathon。 書中明確把 hack days、hackathons、20% innovation time 列為「有時被拿來當作同義詞、但實際上不同」的儀式——它們經常聚焦在產品創新與新市場點子的原型，而非改善工作；更糟的是它們往往只限開發者參加，書中直言這「與 improvement blitz 的目標大不相同」。
- 目標是改善日常工作、解決日常的 workaround，不是為了試玩新技術而實驗。實驗當然也可能帶來改善，但 improvement blitz 是非常聚焦在解決我們日常工作中遇到的具體問題。
- 若期末沒有向同儕簡報，這個儀式很快會退化成「放假一週」——簡報是把區域改善轉成組織學習的那一步。
- 「不允許功能工作」需要管理層真的守住；一旦破例，這個機制的可信度就沒了。
🔗 相關工具
- 工具-技術債功能凍結（更長、更劇烈的版本：整段時間都不做功能）
- 保留20%產能給非功能需求（常態化的做法；improvement blitz 是集中式的儀式）
- 價值流圖（用來決定這次閃電戰該打哪個環節）
- 自助服務平台（Target 案例中「六週 → 幾分鐘」的實質產物）
- 工具-三步工作法（第三步「持續學習與實驗」的具體儀式）
- DevOps手冊