第五章：Work in Process（在製品）#
本章是理解看板核心原則的關鍵章節。WIP（Work in Process，在製品）是看板社群中最常被提及的概念之一，而「限制 WIP」更是看板方法的核心實踐。本章將幫助你理解什麼是 WIP、過多 WIP 會帶來什麼後果，以及為什麼限制 WIP 能讓工作更順暢。
WIP 限制不是要你做更少的工作，而是要你在同一時間做更少的工作。限制 WIP 反而能幫助你更快地完成更多工作。
5.1 理解 Work in Process#
WIP 的兩種解讀#
WIP 這個縮寫至少有兩種常見的含義：
- Work in Progress（進行中的工作）
- Work in Process（流程中的工作）
這兩種用法在精實（Lean）文獻中都很常見。本書選擇使用「Work in Process」，但你可以根據自己的偏好互換使用。
5.1.1 什麼是 Work in Process？#
Work in Process 指的是你目前手上所有正在進行的工作，包括：
- 你正在積極處理的工作
- 等待驗證或部署的工作項目
- 收件匣中尚未開始但需要處理的工作
- 所有尚未完成、但需要完成才能為最終客戶交付價值的事項
簡而言之，任何尚未完成的工作都是 WIP。它不僅僅是你「正在做」的事情，也包括那些卡在流程中某處等待下一步處理的工作。
WIP 與 Lead Time 的關係#
書中回顧了導論中 Kanbaneros 團隊玩的「Pass the Pennies」遊戲。這個遊戲的關鍵發現是：
- 當每位工人翻轉 20 枚硬幣再傳遞時（WIP = 20），整體 lead time 很高
- 當 WIP 降低到 5（每人翻 5 枚再傳遞），lead time 明顯下降
- 當 WIP 降低到 1（每人翻 1 枚就傳遞），lead time 大幅縮短
作者分享了寫書時的親身經歷：他們一度同時撰寫八個章節，後來決定重新調整目錄結構。在 WIP 為八個章節的情況下，這個調整比只有兩個章節時困難得多、耗時更久、也更痛苦。
Little’s Law（利特爾定律）#
WIP 與 lead time 之間的關係可以用數學來表達，這就是排隊理論中的 Little’s Law，由 John D.C. Little 所提出：
Cycle Time = WIP / Throughput- Cycle Time（週期時間）：每個工作項目通過流程所需的時間
- WIP：同時進行的工作項目數量
- Throughput（吞吐量）：完成每個項目的平均速率
具體數字範例#
假設你的團隊每月完成 12 個項目（throughput = 12/月）：
| WIP | Throughput | Cycle Time |
|---|---|---|
| 12 項 | 12 項/月 | 1 個月 |
| 6 項 | 12 項/月 | 半個月 |
| 24 項 | 12 項/月 | 2 個月 |
僅僅是減少同時進行的工作項目數量（從 12 降到 6），週期時間就從一個月縮短為半個月——而你什麼都不需要改變！反之，將 WIP 加倍到 24，週期時間就會膨脹到兩個月。
透過限制 WIP，你可以：
- 降低週期時間，讓每個工作項目更快完成
- 讓工作更快通過整個流程
- 更快獲得回饋，了解工作的品質和效果
- 更快學習並改善流程，形成正向循環
- 而且你現在就可以做到——不需要改變其他任何東西
如果你的 WIP 已經很低，繼續降低可能無法讓 Little’s Law 中的其他變數保持穩定。例如，讓兩個人同時處理一個任務可能無法達到同樣的效率，降低 WIP 可能會對平均完成率產生負面影響。
但這不一定是壞事——這正是看板的強項之一，因為它會提出改善挑戰：你需要改變什麼工作方式，才能在降低 WIP 的同時維持完成率？
5.1.2 軟體開發中的 WIP 表現形式#
在精實製造中，WIP 很容易辨識，因為它通常以實體形式呈現：堆積在機器前等待加工的物品、地板上等待搬運到下一工序的成品。
但在知識工作中，WIP 是不可見的。這正是為什麼我們要視覺化工作——用看板和便利貼讓工作項目及其狀態變得清楚可見。工作本身一直存在，只是你看不到它。
在軟體開發中，WIP 的表現形式遠不止「同時進行的工作項目數量」這麼簡單。以下是幾種常見的 WIP 形式：
尚未實作的規格書（Specifications Not Being Implemented Yet）#
規格書有「保鮮期」。如果你今天寫了一份規格書然後放著不管：
- 六個月後有人拿起來就能開始開發的機率有多高？幾乎為零
- 即使只過了兩個月，機率也很低
- 商業環境在變化，系統本身也在變化
- 至少需要重新審查規格書以確認其仍然有效
閒置的規格書就是流程中的 WIP。盡量縮短從撰寫規格到開始實作的時間，避免規格書「腐爛」。
尚未整合的程式碼（Code That Isn’t Integrated）#
寫好但尚未 check in 並與他人程式碼整合的程式碼，也是 WIP。你不知道在完成這個工作項目之前還需要多少額外工作。
如果你聽過「It works on my computer」這句話，你就明白了。在你的電腦上可以運行，使用你的設定、在你的環境下——但這不代表它在整合後也能正常運作。未與他人的工作整合之前，你根本不知道程式碼是否真的能運作，因為你還沒面對整合時可能出現的衝突和問題。
頻繁地 check in 和整合程式碼是避免累積大量整合工作的好方法，也能快速獲得你目前工作品質的回饋。
未測試的程式碼（Untested Code）#
寫了程式碼卻沒有快速方法確認它是否能正常運作，是累積未完成工作庫存的絕佳方式。你可能會說「完成了 95%」，但如果沒有經過測試，你其實不知道真正完成了多少。
自動化測試是應對這個問題的關鍵手段。書中提到了兩種方法：
- Test-Driven Development（TDD，測試驅動開發）：在寫程式碼之前先寫一個小測試，作為下一小段程式碼的微規格（micro-specification）。副產品是你會得到所有程式碼的測試套件，能快速回饋是否引入了缺陷。TDD 是關於「正確地開發東西」（developing things right）。
- Specification by Example / BDD（行為驅動開發）：本質上是把規格書寫成可執行的測試案例。透過在流程早期使用具體範例來描述功能，增加所有人對功能理解一致的可能性。如果做得不好，會花費大量時間在來回確認上。BDD 是關於「開發正確的東西」（developing the right thing）。
TDD 和 BDD 關注的面向不同但互補：TDD 確保你用正確的方式開發（developing things right），BDD 確保你開發正確的東西（developing the right thing）。兩者都能有效減少「未測試程式碼」這種形式的 WIP。
尚未上線的程式碼（Code Not in Production）#
已開發、已測試，但尚未進入生產環境的程式碼也是 WIP：
- 你還有工作要做
- 你不知道功能是否正常運作
- 你不知道它是否會對系統其他部分產生不良影響
- 最重要的是，它還沒有為使用者提供任何價值
更深一層思考：即使程式碼已經在生產環境中運行，工作也不一定就「完成」了。真正重要的是使用者如何接受它、是否從中受益、以及你的軟體是否達到了預期的商業影響。如果使用者行為沒有受到影響，你真的完成了嗎？
5.2 過多 WIP 的影響#
了解了什麼是 WIP 之後，接下來看看過多的 WIP 會造成哪些問題。這些後果讀起來令人沮喪，但好消息是你已經知道解決方法：限制 WIP！
5.2.1 Context Switching（情境切換）#
Context switching 原本是計算機科學的概念，描述電腦在切換不同進程時如何儲存和恢復狀態。人類在任務之間切換時也會經歷同樣的事情——你需要在腦中重建之前任務的「狀態」。
這就像工廠裡機器的設置時間。如果機器設定為生產 Model A，要切換到 Model B 需要一段調整時間。如果每隔一件就要交替生產 A 和 B，大量時間就浪費在設置上。
研究數據#
根據 Gerald Weinberg 的研究，每增加一個同時進行的專案，就會損失約 10% 的工作時間用於情境切換：
| 同時進行的專案數 | 每個專案可用的工作時間 | 因情境切換損失的時間 |
|---|---|---|
| 1 | 100% | 0% |
| 2 | 40% | 20% |
| 3 | 20% | 40% |
| 4 | 10% | 60% |
| 5 | 5% | 75% |
另一項研究顯示，情境切換造成的 IQ 下降幅度達 10 分——這是吸食大麻影響的兩倍以上！
該怎麼辦？#
- 你參與的專案和任務就是你的 WIP
- 限制它！保持在最低限度
- 如果必須同時進行多項任務，盡量減少數量
- 試著完成一項再開始另一項
- 這將幫助你避免情境切換，並根據 Little’s Law 更快完成每項任務
5.2.2 延遲造成額外工作（Delay Causes Extra Work）#
想像你在應用程式中引入了一個 bug：
- 如果幾分鐘內就被通知：修復簡單，你還記得剛才做了什麼，沒有不良後果
- 如果兩個月後才被發現：工作量大幅增加
- 首先，你需要回想那個功能是什麼、你當時做了什麼、以及如何修復
- 然後，你可能需要將系統恢復到當時的狀態才能重現 bug
- 同時，系統其他部分很可能已經改變，使 bug 更難且更複雜地修復
- 而且，你可能需要其他人的協助（測試人員、系統管理員、DBA 等）來設置正確的系統狀態以重現缺陷
- 這還只是考慮你個人的情況——實際上可能涉及更多人和更多協調
所有這些額外工作都是由延遲造成的——從你引入 bug 到被通知之間的時間差。延遲本身會產生更多的 WIP。
回饋迴路的惡性循環#
這個問題的本質是回饋迴路（feedback loop）被拉長了：
- 大量 WIP 導致每個項目進展更慢
- 每個工作項目在生產環境中的表現回饋也需要更長時間才能收到
- 回饋是每個敏捷流程的核心部分，是知識的創造者
- 回饋告訴你工作品質和工作流程的品質：什麼有效？什麼該改變？什麼不該改變？
- 你越快獲得回饋，就越快能把不好的流程變成稍好一點的流程
- 延遲的回饋會使你難以將結果連結到原因，讓學習變得非常困難甚至不可能
高 WIP 會形成一個惡性循環：
高 WIP → 回饋變慢 → 延遲 → 產生更多工作 → WIP 更高 → 回饋更慢 → ...flowchart LR A[高 WIP] --> B[回饋變慢] B --> C[延遲] C --> D[產生更多工作] D --> A
透過降低 WIP，你可以掌控這個問題，讓小型工作項目快速通過完整的工作流程，從而快速獲得回饋。
5.2.3 風險增加（Increased Risk）#
更多同時進行的工作意味著更高的風險。這與你無法快速改變、因而對周遭環境變化更加敏感有關。
具體來說：
- 如果流程的 lead time 很長，客戶要求的功能變更需要很久才能交付
- 在等待期間，功能可能已經過時，或競爭對手可能已經率先實現
- 例如社群媒體登入整合——如果你的 lead time 長達一年，競爭對手可能早已推出帶有該功能的服務
風險涉及的面向包括：
- 技術面：所使用的框架或技術可能變得不受支援
- 商業環境面：趨勢、法規、法律的變化
- 競爭面：如果你無法快速交付新功能或變更，就有失去客戶的風險
如果你無法快速應變並迅速將新功能或變更交付給客戶，你將面臨失去客戶關聯性、服務過時、甚至被競爭對手超越的風險。
5.2.4 更多額外開銷（More Overhead）#
大量 WIP 的一個特別惡劣的後果是：為了協調所有工作，會產生更多工作。這是一個惡性循環，可能很快失控，最終你把所有時間都花在協調上。
想像你同時參與三個不同的專案：
- 你需要為三個專案做報告、時間追蹤和規劃
- 因為你不斷進出各專案，需要大量的交接和協調工作
- 這些額外工作完全是因為你同時做多個專案才產生的
- 如果你只被分配到一個專案，這些協調工作根本不會存在
這種情況常發生在極度重視「資源利用率」的組織中（這裡的「資源」往往就是指人）。如果組織改為聚焦於縮短 lead time、讓工作項目順暢流向客戶，那麼許多額外的協調任務就會被視為浪費，並努力消除它們。
書中分享了一個關於時間報告的實務案例。作者 Marcus 在其雇主 Aptitud 採用了偏差報告法：如果他被分配到一個專案 60% 的時間，而他實際工作的時間也是 60%，就不需要填報告。只有當實際工時與預期有偏差時，才報告偏差的部分。這大幅減少了時間報告的浪費。
5.2.5 品質下降（Lower Quality）#
如果你是開發人員，長 lead time 會損害程式碼品質。這與從你寫程式碼到知道它在生產環境中如何被接受、如何運作之間的回饋迴路延長直接相關。
書中舉了一個具體的例子：假設你在開發時認為客戶只有一個名字欄位，但實際上應該有名和姓兩個欄位。這個錯誤一開始沒被發現，因為目前系統中的客戶都是公司，使用單一名稱欄位。幾個月後，第一個「個人」客戶嘗試登入時才發現問題——但此時已經有大量程式碼依賴於客戶只有一個名字屬性，修復變得困難重重。
Scott Bellware 的「疝氣」比喻#
Scott Bellware 曾將這種情況比喻為在系統中引入一個「疝氣」（hernia）：
- 起初：系統整潔有序
- 引入 bug：有一條線被扭曲了
- 在不知道 bug 的情況下繼續開發：你會繞過問題寫程式碼，創造出補償性的壞程式碼
- 最終修復：才能回到正軌，擁有一個良好對齊的系統
對比另一種情境：你在引入 bug 後幾小時內就被通知並能修復它。沒有疝氣、沒有麻煩：簡單又快速。
這兩種情境的差異就在於 lead time：從引入 bug 到被告知之間的時間。在這段時間裡，你的程式碼品質在持續下降，這意味著修復 bug 將需要更長時間、更加困難。
5.2.6 動力下降（Decreased Motivation）#
長 lead time 也會打擊團隊的士氣。書中用了一個生動的情境來說明：
- Daphne 拚命趕工，甚至熬夜，按照 Adam 要求的時間完成了一個功能
- 但當她第二天到達時，發現她的工作項目排在測試佇列的最後面，前面還有 24 個項目
- Adam 告訴她「一兩週後」才能處理
- 兩週後 Adam 終於回來做測試回饋時，Daphne 早已不在乎結果了——她已經投入其他工作，Adam 的回饋反而成了打斷
在這個例子中，問題出在 Adam 身上——他同時有太多事情在進行（高 WIP），導致他無法及時給 Daphne 回饋。Daphne 的幹勁因此受到嚴重打擊。而當 Adam 兩週後終於回來時，他反而打斷了 Daphne 正在進行的其他工作——因為她早已轉移注意力了。
這裡揭示了追求更低 WIP 和更短 lead time 的真正原因：它會暴露問題（或者用書中更優雅的說法：「未實現的改善機會」）。如果你嘗試修復這些被暴露的問題，你的工作流會變得更快、更順暢。雖然看板本身並不告訴你如何解決這些問題，但它會幫助你看到問題所在，讓你一次抓住一個改善機會。關於如何發現和實施流程改善，可以參考第 10 章的詳細討論。
5.3 本章總結#
本章討論了 Work in Process，特別是限制 WIP 以獲得更短 lead time 的重要性：
WIP 的定義#
- WIP 是常見縮寫，至少有兩種含義：Work in Progress 和 Work in Process
- 本書使用 Work in Process
Little’s Law 的啟示#
- Little’s Law 以數學確定性告訴我們：WIP 越多，每個工作項目的週期時間就越長
- 應該限制 WIP 以獲得更快的流動和更短的 lead time
軟體開發中的 WIP 形式#
- 尚未實作的規格書——會隨時間「腐爛」
- 未整合的程式碼——「在我的電腦上可以跑」
- 未測試的程式碼——可能符合也可能不符合你的標準
- 未上線的程式碼——等待下次發佈
過多 WIP 的負面影響#
- 情境切換（Context Switching）——每增加一個專案損失約 10% 工作時間
- 回饋迴路延長（Prolonged Feedback Loop）——延遲會造成更多額外工作
- 風險增加（Increased Risk）——無法快速應對變化
- 額外開銷增加（More Overhead）——協調工作本身消耗大量時間
- 品質下降（Lower Quality）——延遲回饋導致程式碼品質惡化（疝氣效應）
- 動力下降（Decreased Motivation）——長等待時間打擊團隊士氣
核心訊息：限制 WIP 不只是為了「做少一點」，而是為了暴露流程中的問題。當你降低 WIP 時，問題會浮出水面，而嘗試解決這些問題會讓你的工作流變得更快、更順暢。這是一個持續改善的過程。
下一章將進入更實際的層面，探討如何為你的團隊設定 WIP 限制。