管理 · 專案管理 · AI 流程管理（A2A）
30 年實戰 · 一個團隊深耕

30 年陪 5 家公司做組織重整，3 家在 6 個月內退回到原狀。失敗率 60–90%（視統計口徑），但共同點只有 3 個。

共同點 1：把組織重整當作「畫新組織圖」

這是最大的錯誤。組織圖是結果，不是起點。

問題是「為什麼現在這個結構撐不住？」沒回答這題，新圖只是把同樣的人放到不一樣的格子裡。3 個月後組織氣氛沒變、KPI 沒變、員工行為沒變，唯一變的是名片上的頭銜。然後退回原狀。

組織重整的起點不是「新圖」，是「舊圖撐不住的原因」。

共同點 2：忽略了「非正式權力結構」

組織圖畫的是匯報線，員工真正聽誰的常常不是直屬主管。

我們陪某電子廠重整時發現，研發部副總的影響力比研發部總監大 3 倍 — 因為他跟業務部總監是 20 年同梯。每次跨部門衝突，最後都是「兩個老朋友去喝咖啡」收尾，組織圖一點用都沒有。

重整後組織圖變了，但「誰說話算話」沒變。重整就只是改了牆上的圖。

共同點 3：沒有「30 天可見的第一波改變」

高階主管期待的是 3 個月後整個組織煥然一新。員工期待的是「下週我老闆換人了嗎？」中間落差太大，3 個月後主管失去信心，員工失去耐性，整個專案被「再等等看」拖死。

30 年心得：撐得住的 3 件事

1. 先回答「為什麼現在這個結構撐不住」 — 不是「我們想變得更敏捷」，是「這個結構下，Q3 的那個專案為什麼 delay 了 6 週」。
2. 盤點非正式權力結構 — 列出 5 個最有影響力的「地下主管」，看他們在新結構下的位置。
3. 設計 30 天可見的第一波改變 — 不是「3 個月後組織煥然一新」，是「下週所有主管每週開 1 次 30 分鐘對齊會議」。

30 年電子製造業，沒遇過 delay 是不可能的事。但我看到的 delay 95% 都不是執行問題，是前期計劃沒做對。這篇列 5 個最常見的盲點，每個都附「為什麼這樣」+「怎麼救」。

盲點 1：WBS 只到第 3 層

業界 WBS 普遍只到 3 層 — 一級「做產品」、二級「RD / 製造 / 業務」、三級「各部門內部 task」。3 層不夠細，看不出「誰負責什麼、能 delay 多少天、能驗收什麼」。等於你看到一棵樹的枝幹，沒看到葉子。當枝幹生病時（delay），你已經救不回了。

解方：至少 5–6 層，且每層有「驗收條件」（不是「做完」，是「看到 X = 做完」）。

盲點 2：風險評估只看「機率 × 影響」

傳統風險矩陣是 2D — 機率 × 影響。但真正會殺死專案的是「低機率 × 高影響 × 低可偵測性」的風險 — 因為它會在你沒注意的時候爆。

解方：3D 風險矩陣，加「可偵測性」軸。低可偵測性風險優先處理（即使機率低、影響小）。

盲點 3：資源盤點沒做「calendar reality check」

很多 PM 會列出「誰負責什麼」，但沒做 calendar reality check — 這個人下週其實在出差、6 月有個產品發表佔滿他時間。

解方：每個關鍵資源的 calendar 必須做雙重確認（跟本人 + 跟他的主管），發現衝突當場調整，不是開工前一天才發現。

盲點 4：沒有「設計凍結點」

專案最怕的不是「改需求」，是「一直改需求」。

解方：設 3 個凍結點 — 設計凍結、開發凍結、測試凍結。凍結點之後要改，要走「變更控制委員會」（CCB）流程，不是傳 LINE 給 PM。

CCB 不是要擋住改變，是要讓每次改變「被看見、被評估、被記錄」。3 個月後回頭看，你就會發現「原來 Q2 的 80% delay 是 4 月的 6 個小改累積出來的」。

盲點 5：沒有「當責節點」

傳統 project charter 列了 20 個 stakeholder，沒人當責。當 delay 發生時，每個人都說「不是我」。

解方：每個 milestone 必須有 1 個 DRI（Directly Responsible Individual）+ 1 個備援 + 1 個審核者。DRI 出問題備援上、審核者問責。

前期計劃省下的 2 週，會換來執行期省下的 2 個月。

這 5 個盲點，看起來都不難，但 95% 的專案沒做。原因不是不懂，是「前期計劃很難量化 KPI」 — 老闆看不到你做的 WBS，但看得到你 delay 的專案。所以 PM 都把時間花在救火，不花在預防火。

當 5 個 AI agent 一起跑一個企業流程，output 錯了誰負責？這是我們用 mtBot agent team 親身實踐 6 個月後整理的 3 個 governance 最小可行元件（Minimum Viable Governance）。

元件 1：Decision Log（決策日誌）

每個 agent 做的每個 decision 都要 log — 不是 log 整個對話，是 log「decision + 為什麼 + 用什麼資料」。當結果出問題時，能 trace back 到「哪個 agent 的哪個 decision 是錯的」。如果沒有 log，你只看到「流程跑完結果錯」，看不到「為什麼錯」。

我們的實作：每個 agent 在做出 irreversible decision（不可逆決策）前，會呼叫 decision.log(decision, rationale, sources)。這個 log 寫到 immutable storage（append-only），audit 時不能改也不能刪。

元件 2：Authority Boundary（權限邊界）

不是所有 agent 都能做所有事。我們用 3 層權限：

• L1 Read：讀資料（所有 agent）
• L2 Propose：建議行動（所有 agent）
• L3 Execute：執行行動（限特定 agent + 必須有 L1 審核 agent 蓋章）

範例：mthr 發現某個 skill 有 bug，L2 — 它可以提議「更新 skill」。但實際「更新 skill」需要 mtsecurity L3 蓋章。mtsecurity 看 mthr 的 rationale + source code 確認沒問題才放行。這樣設計的好處：agent 可以自由探索、提議，但不能自己亂動 production。

元件 3：Human Override（人工覆寫）

不管 governance 設計多好，總會有意外。每個流程必須有一個「人工覆寫按鈕」，讓人類可以：

• 暫停某個 agent
• 退回某個 decision
• 強制重新跑某個 step

關鍵：這個按鈕要 1-click 可用，不是「打 ticket 等 3 天」。

我們的實作：每個流程都有 human.pause(agent_id) endpoint，按下去所有 in-flight agent call 立刻 abort。然後會自動通知 owner（人），讓人可以介入。

A2A governance 的核心不是「管住 agent」，是「出包時有人踩煞車」。

為什麼這 3 個元件是「最小可行」

我們試過更多設計 — token budget cap、agent role hierarchy、cross-agent veto — 但 6 個月實踐後發現，這 3 個是「沒有就出事，有了能撐住 90% 場景」的關鍵。其他都是 nice-to-have。

A2A governance 不是「管 AI」這麼空泛，是「讓 AI 進到企業流程裡跑、不出大事、出大事有人踩煞車」。這 3 個元件做到，企業就能放心導入大量協作的 AI agents。

矩陣組織失敗率 70%（Harvard Business Review 經典研究）。但我們陪 3 家公司導入矩陣，2 家失敗 1 家勉強成功。失敗的 2 家不是矩陣設計錯，是溝通協議沒跟上。

命令鏈的極限

傳統組織是「命令鏈」 — 誰直屬、誰匯報、誰拍板。優點是責任清晰，缺點是跨部門協作需要層層上報，一個決策 delay 2 週。你想做一件事，要先跟直屬主管報告 → 主管跟跨部門主管報告 → 跨部門主管跟他的直屬報告 → ... 一圈下來 2 週過去了。

矩陣組織為什麼失敗

矩陣試圖解決這個問題，讓員工有「雙重匯報」 — 對功能主管（RD / 業務）也對專案主管。理論上好，實務上 70% 失敗。原因：當兩個主管意見衝突，員工不知道聽誰的。會議從 1 個變 4 個，決策反而更慢。

矩陣組織失敗不是結構問題，是協議設計問題。

對話鏈：protocol-based 協作

新解方不是再加一層匯報，是用「協議」取代「匯報」。

我們陪某 SaaS 公司導入的設計：

• 每個跨部門專案有一份「協議書」 — 明確列出誰在什麼情境下拍板、誰在什麼情境下 escalate、誰在什麼情境下退出
• 協議書每月 review 一次，不是每次衝突才討論
• 衝突發生時，先看協議書，沒有就 escalate，不是傳 LINE 給老闆

協議書範例（節錄）：

§3.2 當業務部承諾給客戶的交期 < 研發部可達交期 - 2 週：
· 業務部必須 24 小時內 escalate 到業務 + 研發 + PMO 三方會議
· PMO 在 48 小時內必須做出「接受 delay」或「找替代方案」的決定
· 決定做出後 7 天內不可逆（除非客戶主動修改需求）

這份協議書不是「規矩」，是「當衝突發生時，不用再從頭討論」。

從「誰的匯報線」到「誰的對話協議」

矩陣組織失敗的 2 家，共同點：協議書寫得不夠明確、escalation 流程不夠 1-click。勉強成功的 1 家，共同點：每月 30 分鐘 review 一次協議書，把上個月發生的衝突補進協議書。

組織設計的下一步不是「新結構」，是「新規矩」。

業界 WBS 普遍只到 3 層。30 年經驗告訴我，能防 delay 的 WBS 至少要到 5–6 層，且每層要有「驗收條件」。這篇講為什麼 + 怎麼做。

為什麼 3 層 WBS 防不了 delay

3 層 WBS 的問題是看不出「誰負責什麼、能 delay 多少天、能驗收什麼」。等於你看到一棵樹的枝幹，沒看到葉子。當枝幹生病時（delay），你已經救不回了。

3 層 WBS 還有個問題：沒辦法做 risk-based 排程。當某個 task 有高風險（依賴外部 supplier、需要特殊 skill、需要老闆簽核），你看不出來要 buffer 多少天。

5–6 層 WBS 的設計原則

原則 1：每層都有 DRI — 不是群體負責，是 1 個人負責 + 1 個備援。

原則 2：每層都有「驗收條件」 — 不是「做完」，是「看到 X = 做完」。「做完」是主觀的，「看到 X」是客觀的。

原則 3：每層都有「buffer」 — 不是 HOF (high optimism factor)，是 30% time buffer at leaf level。HOF 是把每個 task 估短 20%，leaf buffer 是每個 leaf task 加 30% 時間。實務上 leaf buffer 比較不會被砍掉。

範例：電子製造業新產品導入

• L1：導入新產品
• L2：RD / 製造 / 業務 / 品保
• L3：機構設計 / 電路設計 / 模具開發 / 試產 / 量產準備
• L4：機構圖完成 / 電路圖完成 / 模具 T0 完成 / 試產 100 顆完成 / 量產良率 95% 達標
• L5：每個 L4 項目拆成 5–7 個 sub-task，每個有 DRI + 驗收條件 + buffer

L5 範例（模具 T0 完成）：

• 模具設計圖確認（DRI: 王小明，驗收: 模具供應商回簽 + RD 主管蓋章）
• CNC 程式撰寫（DRI: 李大華，驗收: 程式跑出 NC code + 主任工程師 review）
• 第一次試模（DRI: 張小芳，驗收: T0 件尺寸報告出來）
• 第一次試模檢討（DRI: PM，驗收: 會議結論 email 給所有 stakeholder）
• 修模 + 第二次試模（DRI: 張小芳，buffer: +5 天）

每個 L5 task 都有「誰負責 + 什麼叫做完 + 多少時間」。Delay 發生時，PM 不用從頭 review 整個專案，只要看哪個 L5 task 的 buffer 被吃光。

為什麼 5–6 層剛好

• 3 層太粗，看不出誰負責什麼
• 7 層以上太細，變成 micro-management，PM 整天在追 task
• 5–6 層是 sweet spot — 能看出誰負責、能驗收、能 delay 多少天，但又不會讓 PM 變成 task tracker

WBS 深度不是「做得細一點」就好，是「做到能防 delay 的深度」。

mtBot 有 5 個 agent — captain / coco / mthr / mtmedia / mtecho。我們故意讓某些 agent 對特定決策有「合理反對」的能力。這不是 bug，是 governance 設計的一部分。

agent 都乖乖聽話的組織會出大事

如果每個 agent 都 say yes，那跟「沒有 agent」沒兩樣 — 全部都是執行工具，沒人幫忙 catch mistake。我們看過太多企業導入 AI 的失敗案例：AI 出錯沒人 catch，因為大家覺得「AI 講的應該對」。等到出包了才發現 — 「那個判斷明明有問題，當初怎麼沒人說？」

會吵架的 agent 才是健康的 agent 組織。

mtBot 的 tension 機制

Tension 1：mtsecurity 可以 veto 任何「會動 production」的決策

不是問它 yes/no — 是它可以說「我不蓋章，這個決策不能執行」。這個 veto 在 30 秒內要決定，不能拖。我們故意把這個時間壓得很短，避免 mtsecurity 被「那就等你想清楚再決定」拖累流程。

Tension 2：mthr 可以「合理反對」skill 安裝

mthr 是 skill curator，但它不是「裝越多越好」。如果某個 skill 安裝理由不夠強，mthr 可以說「我反對這個安裝」。Captain 必須 review 反對理由才能強制通過。這個機制讓 skill 安裝有「反對票」存在 — 不是「裝不裝」的二元決定，是「為什麼裝、為什麼不裝」的對話。

Tension 3：coco 可以 escalate 任何「會動 token budget」的決策

coco 是 PM，她對 token cost 有發球權。任何會大量消耗 token 的決策，coco 可以 escalate 給 michael（owner）。這個機制讓「token 預算」有 human-in-the-loop，不是 agent 們自己決定花多少就花多少。

為什麼這是 governance 的一部分

傳統 governance 是「出事後 audit」 — 等到出問題才回頭查 log。tension 機制是「出事前 catch」 — 當 5 個 agent 一起跑流程，至少有一個會 catch mistake。

錯誤率從「5 個都錯」降到「5 個全錯才出包」 — 機率大幅下降。

mtBot 6 個月實踐的數字

• mtsecurity veto 過 2 次「會動 production」的決策（後來發現都是好決策）
• mthr 反對過 3 次 skill 安裝（其中 1 次後來被 Captain 強制通過，但安裝後確實造成問題，被 rollback）
• coco escalate 過 1 次「會動 token budget」的決策（michael 看完決定暫緩）

會吵架的 agent 才是健康的 agent 組織。我們把 tension 機制寫進 A2A protocol — 不是 nice-to-have，是 must-have。