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

 

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

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

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

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

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

瓶頸官僚主義：限制理論剖析 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 緩行，水管永滴。