忙碌的幻覺：為什麼「多工處理」是專案的殺手

 

忙碌的幻覺：為什麼「多工處理」是專案的殺手

我們總愛崇拜「多工處理」（Multitasking）這座神壇。在現代職場文化中，能同時兼顧五封郵件、兩場視訊會議，還能若無其事地填寫報表的員工，彷彿戴著某種英雄勳章。這當然是徹底的胡扯。事實上，我們所謂的多工，不過是注意力在無序的切換中快速流失，留下一堆半途而廢的殘骸。在專案管理中，這種「惡性多工」就是那個隱形的刺客，確保沒有任何重要任務能如期完成。

最近，有一支研究團隊深入挖掘了這項荒謬，他們利用「關鍵鏈專案管理」（CCPM）的原則，剝開了職場上對「忙碌」的虛榮與迷信。這或許是首次有團隊將CCPM視為研究的核心基石。他們的發現帶著一種冷峻的務實：多工處理並非單純是因為員工懶惰或個人能力不足，它是一種結構性的必然。當系統設計充滿了資源衝突與工作流程的不穩定，員工被迫陷入無止盡的切換，只為了讓專案不至於徹底停擺。

這裡的教訓很簡單：你無法透過要求被困在系統裡的人更加「專注」，來修復一個已經崩壞的系統。組織本身往往就是造成產能瓶頸的始作俑者。當我們將多工視為系統缺陷而非行為問題時，就會發現絕大多數的專案延宕，並非個人的過錯，而是那個獎勵慌亂、排斥線性節奏的環境所導致的結果。

因此，在責怪你的團隊不夠努力之前，先想想看：你是否設計出了一個讓他們注定失敗的系統？真正的效率不在於同時做多少事，而在於是否具備「一次只做一件事」的紀律，且無須擔心系統隨時會因為混亂而崩塌。

The Myth of the Busy Bee: Why Multitasking is Killing Your Project

 

The Myth of the Busy Bee: Why Multitasking is Killing Your Project

We love to worship at the altar of "multitasking." In our modern corporate culture, the ability to juggle five emails, two Zoom calls, and a spreadsheet while ostensibly "focusing" is treated as a badge of honor. It is, of course, complete nonsense. In reality, what we call multitasking is merely the rapid, chaotic switching of attention—a process that drains cognitive energy and leaves behind a trail of half-finished wreckage. When it comes to projects, this "bad multitasking" is the silent assassin, ensuring that nothing of significance is ever actually completed on time.

A recent academic team took a deep dive into this absurdity, utilizing the principles of Critical Chain Project Management (CCPM) to strip away the vanity of being "busy". They were the first of their kind to treat CCPM not as a theoretical curiosity, but as the bedrock of their research. What they discovered was refreshingly cynical: multitasking isn't just a personal failing of lazy employees; it is a structural inevitability. When systems are designed with conflicting resource requirements and inherent workflow instability, workers are forced into a constant state of context-switching just to keep the project's pulse from flatlining.

The lesson here is simple: you cannot fix a broken system by demanding more "focus" from people trapped within it. The organization itself often creates the very bottlenecks it then complains about. By treating multitasking as a systemic flaw rather than a behavioral one, we begin to see that most project delays are not the fault of the individual, but of the environment that rewards frantic, non-linear activity over steady, protected progress.

So, before you tell your team to work harder, consider whether you have designed a system that makes their failure inevitable. True efficiency isn't about doing more things at once; it's about having the discipline to do one thing at a time, without the system constantly setting your hair on fire.

瓶頸官僚主義：限制理論剖析 HMS Dragon 與倫敦水電工延遲

 瓶頸官僚主義：限制理論剖析 HMS Dragon 與倫敦水電工延遲

從限制理論（TOC，Eliyahu Goldratt 所創）觀點，HMS Dragon 部署塞浦路斯延誤，或召喚倫敦水電工，皆源於相同根源：未識別瓶頸扼殺產出。TOC 主張每個系統僅有一關鍵限制阻礙效能——提升它，否則永遠落後。對 HMS Dragon，瓶頸非船隻（Type 45 驅逐艦極具能力），而是準備碎片化：維護後重新裝填導彈、武器重置、樸茨茅斯上港焊接。這些任務形成非線性鏈，船員可用性、零件物流、系統檢查構成關鍵路徑。同樣，倫敦水電工瓶頸在排程超載——單一技工多頭燒，遠赴 Essex 取零件，無緩衝應急。兩案皆然，「工具」（船或扳手）已備；缺失在於狠抓優先、從屬一切的意願。

關鍵鏈專案管理（CCPM）即 TOC 解藥。此法將安全邊際彙整至專案末端緩衝，而非任務內填充，縮減工期 30-50%。對 HMS Dragon，繪製關鍵鏈（導彈裝填→測試→出航），斷絕多工（無雙重任務配置），以緩衝護航供應波動。水電工可借簡易 App 實踐 CCPM：依緊急批次作業，高優先維修鏈結，共享緩衝應付缺席，將等候從數週壓至數日。模擬顯示 CCPM 解決 80% 延誤，聚焦資源爭奪，而非加班英雄。

然，症結在此：這些方法在工廠、IT 屢試不爽——波音至英特爾皆然——卻在意志薄弱處失效。英國國防部陷預算緊縮、艦隊準備拖沓；水電工抗軟體，偏好現金混亂。工具比比皆是（海軍用 Primavera，技工用 Jobber）；缺失非工具，乃實作、衡量、強制的意願。未採 TOC 紀律，英國將繼續漂流——Dragon 緩行，水管永滴。

Bottlenecks of Bureaucracy: Theory of Constraints on HMS Dragon and London Plumbers

 Bottlenecks of Bureaucracy: Theory of Constraints on HMS Dragon and London Plumbers

From a Theory of Constraints (TOC) perspective, delays in deploying HMS Dragon to Cyprus or summoning a London plumber stem from the same root: unidentified bottlenecks choking throughput. TOC, pioneered by Eliyahu Goldratt, posits that every system has a single constraint limiting performance—elevate it, or suffer perpetual lag. For HMS Dragon, the constraint isn't the ship itself (a capable Type 45 destroyer), but fragmented preparation: post-maintenance rearming, weapon reconfiguration, and welding at Portsmouth's upper harbor. These tasks form a non-linear chain where crew availability, parts logistics, and system checks create the critical path. Similarly, London plumbers face their bottleneck in scheduling overload— one tradie juggling multiple jobs, sourcing obscure parts from Essex, with no buffer for emergencies. In both cases, the "tool" (ship or wrench) is ready; the deficiency lies in the will to ruthlessly prioritize and subordinate everything else.

Enter Critical Chain Project Management (CCPM), TOC's antidote to such chaos. CCPM aggregates safety margins into project buffers at the end, not per-task padding, cutting lead times by 30-50%. For HMS Dragon, map the critical chain (missile loading → testing → sail), cut multitasking (no dual mission fittings), and protect it with a buffer against supply hiccups. Plumbers could adopt CCPM via simple apps: batch jobs by urgency, chain high-priority fixes with shared buffers for no-shows, slashing wait times from weeks to days. Simulations show CCPM resolves 80% of delays by focusing on resource contention, not heroic overtime.

Yet, here's the rub: these methods work wonders in factories and IT—from Boeing to Intel—but falter where will is weak. UK's MoD dilly-dallies on fleet readiness amid budget squeezes; plumbers resist software, preferring cash-in-hand chaos. Tools abound (Primavera for navies, Jobber for trades); the deficiency is not the tool, but the will to implement, measure, and enforce. Until brass and blokes embrace TOC's discipline, Britain will drift—Dragon dawdling, pipes perpetually dripping.