系統思考，全局思考，是困難的；即使是貌似常識的場域，亦然。
最近在看 Lean Thinking 原典時，感觸更深。
Lean Thinking 倡議小批量 (small batch)、單件流 (one piece flow) 工作方式；這種工作方式，會觸及到多工、工作切換的議題。
以常識來說，多工、工作切換，代價是 context switch 的 overhead。因此，近代敏捷開發方法論，總是希望在制度設計上盡量降低工作切換：
當知識工作者有三件或四件以上的工作要做，他們花費在工作切換時，所需重新設定工作模式的時間，會比實際花費在每件工作上的時間還要來的長。 — 《笑談軟體工程：敏捷開發法的逆襲》 p.180
多工是一種浪費，給員工同時間分配多種工作是專案產生浪費的一個根源。軟體開發人員每次在轉換工作時都會浪費大量的調換時間，因為他必須調整思路以便投入新的任務流程。當然，若是你同時參與多個開
發團隊的話，自然會造成更多的停頓，從而引起更多的任務調換而浪費更多時間。 — 《精實開發與看板方法》 p.11
原本我也把它當成不證自明的常識。不過，偶然看到 Lean Thinking 提到的一項實驗，大大顛覆我的成見。
先看一段 Ron Pereira 根據 Lean Thinking 書中所提的實驗，錄的一段影片：
單一動作，反覆做，練成不經大腦思考的機械式反應時，理論上，單一動作的效率會極大化。這也是科學管理之夫泰勒的觀點。
所以，看了這段實驗，真是令人咋舌。
兩年後，他又重做了一次實驗：
實驗設計上，瑕疵當然很多，就連隨機對照實驗都沒做。不過，個人認為，實驗設計完美與否，並不是此例想彰顯的重點。它想彰顯的，都在第一段影片的小標上。
我們當然可以坐下來徹底分析：違反直覺的第二種方法，為什麼反而比較快（儘管這可能只是後見之明）。不過，這實驗已經突顯一件事：「工作切換」這件事情的影響，可能需要重新思考；不能只從微觀的局部角度，更要從整體、flow 的角度去檢視。
單純以「工作切換」這件事，換個 Lean Thinking 思維角度，就能得出違反直覺的結果。天知道還有多少尚未被推翻的「不證自明的常識」呢？
整體 vs 局部的判斷，委實不能等閒視之呀。