系統思考,全局思考,是困難的;即使是貌似常識的場域,亦然。

最近在看 Lean Thinking 原典時,感觸更深。

精實革命 (Lean Thinking)

精實革命 (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 局部的判斷,委實不能等閒視之呀。