力量 ， 使 大家 朝 共同 目標 努力 。 團隊 本身 的 能量 ， 使得 團隊 生產力 大於 每 一 位 成員 的 生產力 總和 。 一 位 同時 參與 多 項 專案 的 團員 ， 無法 和 任何 團隊 緊密 結合 ， 因此 也 無法 享受 生產力 提高 的 好處 。 任務 轉換 成本 = 轉換 的 機械 成本 ＋ 重複 的 工作 ＋ 進入 狀況 的 時間 ＋ 挫折 代價 ︵ 平靜 情緒 ︶ ＋ 團隊 能量 的 損失 量化 任務 轉換 成本 到 目前 為止 ， 我 只有 列出 任務 轉換 的 各 項 成本 ， 現在 讓 我們 來 量化 它 的 總 影響 。 我 的 經驗 告訴 我 ， 讓 知識型 員工 在 兩 個 以上 的 任務 之間 轉換 ， 成本 至少 是 一五％ 。 也就是說 ， 讓 一 個 原本 只 做 一 件 任務 的 員工 ， 兼做 兩 件 任務 ， 每 週 至少 要 損失 六 小時 。 身兼 的 任務 愈 多 ， 損失 愈 大 。 這 只 限於 知識型 員工 ， 因為 藍領 員工 並 不會 發生 某些 轉換 成本 ， 或者 成本 較 低 。 對 知識型 員工 而言 ， 轉換 成本 至少 是 一五％ 。 我 為 一五％ 這 個 數字 所 提出 的 佐證 ， 是 一 種 稱 之為 ﹁ 以 重複 敘述 來 證明 ﹂ ︵ proof by repeated assertion ︶ 的 古老 方法 。 我 先 說 一五％ 是 最 起碼 的 成本 ， 然後 再 說 一 次 … … 就 這樣 重複 地 說 。 雖然 這 是 廣 被 使用 的 方法 ， 你 可以 說 它 不 夠 嚴謹 。 我 的 回答 是 ： ﹁ 與 什麼 相比 ？ ﹂ 在 我 開始 說明 之前 ， 任務 轉換 看起來 似乎 沒有 成本 。 我們 看見 ， 許多 公司 讓 知識型 員工 同時 做 八 件 或 十 件 任務 。 這 個 現象 的 普遍性 ， 等於 是 宣告 任務 轉換 不 是 沒有 成本 ， 就 是 成本 小 得 可以 被 忽略 。 就算 沒有 其他 事實 證明 ○％ 或 一五％ 那 一 個 較 正確 ， 我 希望 你 至少 認為 ○％ 是 不 太 可能 的 。 我 的確 有 某些 佐證 。 從 一九八四年 開始 ， 我 和 大西洋 系統 指導 的 同事 開始 針對 軟體 程式 設計師 ， 展開 一 項 為期 三 年 的 研究 ︵ 注 一 ︶ 。 我們 從 一百多 個 不同 的 組織 找 了 六百 位 程式 設計師 ， 把 他們 的 技能 與 程式 設計 標竿 相 比較 。 受 試 者 可以 自由 地 在 自己 待 的 地方 工作 ， 使用 自己 的 設備 。 他們 工作 時 有 正常 的 干擾 、 任務 轉換 ， 及 背景 噪音 。 我們 蒐集 環境 資料 ， 並 記錄 每 一 次 的 任務 轉換 。 我們 發現 ， 干擾 最 小 的 人 表現 最好 。 我們 把 工作 表現 與 任務 交換 頻率 相 比較 ， 得出 的 結論 是 ， 由於 注意力 被 打斷 ， 每 一 次 任務 轉換 損失 的 時間 略 高於 二十 分鐘 。 我們 還 注意到 ， 平均 每 小時 有 ○．四 次 轉換 ， 也 就 是 每 天 損失 一 個 多 小時 。 轉換 成本 的 含意 過去 十 年 ， 組織 重組 的 主要 任務 就 是 裁員 ， 而 把 被 裁 者 的 工作 分攤給 其他 人 ， 這 使得 工作 被 切割 得 更 破碎 。 這 種 作法 ， 只有 當 轉換 成本 小於 所 節省下來 的 人事 成本 時 ， 才 有 意義 。 在 實務 上 ， 只有 當 轉換 成本 幾乎 等於 零時 才 有用 ， 但 事實 從來 不 是 這樣 。 隱藏 的 任務 轉換 成本 吞噬 了 組織 的 資源 。 在 分割 過度 的 組織 中 ， 用人 成本 的 節省 只 是 人們 的 一 種 錯覺 。 同時 從事 多 項 任務 的 知識型 員工 表面 上 顯得 忙碌 ， 但 他們 只是 忙碌 地 在 不同 任務 之間 轉換 罷了 。 更 糟糕 的 是 ， 人員 的 去留 通常 取決 於 工作 績效 。 但 工作 績效 不 是 一 件 抽象 的 事情 ： 你 不能 說 泰德 是 一 位 績效 高 的 員工 ， 除非 他 能 證明 自己 擅於 做 某 一些 特別 的 工作 。 而 同時 要 做 多 項 任務 ， 使得 泰德 少有 時間 做 自己 擅長 的 事 ， 因為 其他 事情 分去 了 他 的 時間 。 即便 不 計算 任務 轉換 成本 ， 泰德 的 工作 表現 也 將 因此 被 打折扣 。 知識型 員工 不 是 可 取代 資源 。 把 他們 視為 這樣 的 資源 來 使用 ， 只是 徒然 地 製造 忙碌 ， 使 他們 無法 做 有用 的 工作 。 注 一 ： 該 研究 發表 的 報告 之 一 是 ： 涑 rogrammer Performance and the Effects of the Workplace , ?
 
Proceedings of the 8th International Conference on Software Engineering ( London: IEEE Computer Society Press , 1985 ) 。 第四 章 當 ﹁ 快 一點 ﹂ 其實 代表 ﹁ 慢 一點 ﹂ __UNDEF__ 故事 進展到 了 這裡 ： 組織 有時候 會 因為 效率 掛帥 ， 而 讓 自己 過分 忙碌 ， 使得 反應 能力 降低 ， 成效 反而 打折扣 。 這 種 現象 幾乎 總是 重組 或 組織 ﹁ 改進 ﹂ 出 了 毛病 的 結果 。 因此 ， 我 稱 他們 為 ﹁ 改進 過度 ﹂ 的 組織 。 快 一點 聽到 每 一 個 人 大談 自己 有 多麼 忙碌 ， 你 可能 會 推斷 ， 許多 企業 有 改進 過度 的 毛病 。 像 我 一 年 通常 需要 拜訪 十來 家 的 公司 、 機構 ， 或 非 營利 組織 ， 還 要 與 數百 家 公司 的 員工 舉行 會議 或 座談 。 我 從 我 的 訪談 或 蒐集到 的 資料 中 研判 ， 三分之一 到 二分之一 的 企業 有 改進 過度 的 毛病 。 也就是說 ， 他們 的 員工 已 忙碌 、 緊張 到 病態 的 地步 ， 而且 或多或少 都 處在 恐懼 中 。 這 一 種 組織 的 典型 口頭禪 是 ： ﹁ 快 一點 ， 快 一點 ， 快 一點 ， 快 一點 ， 快 一點 … … ﹂ 我 承認 ， 當 我 還 是 一 位 年輕 、 無 經驗 的 主管 時 ， 也 喜歡 用 這 一 句 口頭禪 ， 它 讓 我 覺得 自己 很 有 影響力 。 現在 ， 我 認為 它 是 企業 走入 歧途 的 聲音 。 我們 如何 分工合作 我 關心 的 是 ， 當 ﹁ 快 一點 ﹂ 其實 代表 著 ﹁ 慢 一點 ﹂ 的 時候 。 為了 了 解 這 一 個 可能性 ， 讓 我們 回到 第二 章 的 組織 模式 ， 把 組織 視為 一 串 相連 的 任務 ， 其中 每 一 個 人 都 是 一 個 節點 ， 節點 之間 的 連結 就 是 流通 的 資訊 、 產品 與 副產品 。 任務 發生 頻率 的 自然 不 平均 狀態 ， 造成 某些 無 效率 現象 ： 例如 ， 艾蓮娜 必須 等 哈利 完成 工作 ， 才 能 接著 往 下 做 。 過度 改進 的 組織 以 減少 每 一 個 節點 上 的 人力 來 增加 效率 ︵ 或 忙碌 ︶ — — 我們 讓 員工 身兼 數 職