EP63｜當每件事都很重要但卻一事無成｜ 曼報
後設資料
- URL：https://mailchi.mp/manny-li.com/063-16297881
- 來源：曼報 EP63（圖文好讀版；曼報為「轉介 + 編譯」模式，原作為英文）
- 原作：Roman Kudryashov，When Everything is Important But Nothing is Getting Done
- 作者背景：政治哲學 / 服務設計出身；醫療、軟體、電商產業逾十年行銷與產品經理經驗
- 發表日：曼報轉介日期不詳；原文發表年份不詳；ingest 日 2026-05-01
- 語言：繁體中文（曼報轉述）；原文英文
- 閱讀時間：曼報版 10 分鐘 / 約 3,866 字
- vault 中的脈絡：vault 中第二期 曼報 ingest（前一期 EP38 七大市場力量）+ 第一個處理「組織任務超載 / 同時推太多優先項目」場景的來源 + 與既有 專案管理（單專案 / Delivery 預防）/ 管理（組織長期經營）/ 領導與管理 形成「單專案 → 多專案組合 → 組織體質」三層完整對位
一句話濃縮
當組織同時把「每件事都很重要」當成預設值，結果就是一事無成 + 高離職率——解法不是更努力，而是 (1) 全員承認失能 → (2) 取得任務全貌 → (3) 用「影響度 × 緊急度」二維矩陣分類 → (4)「開火車」聚焦最重要單一項目 → (5) 必要時組織重組打破跨團隊依賴 → (6) 明定「完成」三條件（用戶問題解了 / 解法交付了 / 收齊回饋了）→ (7) 持續維護——人類組織的問題從來不會「一勞永逸」地被解決。
提取要點
出發點：「每件事都很重要」是組織失能的徵兆
中型公司同時推進多個「都很關鍵」的專案，缺乏組織層級的盤點與監督。結果：
- 成果差、士氣低
- 50% 員工離職率
- 任務分散在 Jira / 試算表 / 口頭請求，沒有單一視圖
→ 與 管理 既有「沒有管理，決策容易缺資料、靠直覺或偶然成功」呼應；本期把這個論點具體化到「同時推太多優先項目」場景。
七步框架
1. 承認問題
「解決問題的第一步是讓所有人都承認有問題」——這是元命題等級的論述。
- 沒有共識前，後續所有改革會被「我們其實沒那麼糟」的內部敘事抵消。
- 對位 領導與管理：領導者的第一個艱難決策不是給方向，而是讓組織停止對自己說謊。
2. 取得完整視圖（Visibility）
- 該團隊40 人 / 清出 300+ 任務 → 清理冗餘後剩 140 件
- 任務散落 Jira、試算表、各種非正式請求；先讓所有任務「能被同時看見」
- 對位 管理 「呈現狀況、暴露問題」：透明度是後續決策的前提
3. 適當的優先順序方法（優先順序矩陣）
高 / 中 / 低三級分類沒用——所有東西最後都會被人主張「這是高」。
改用二維矩陣：
| 緊急度高 | 緊急度低 | |
|---|---|---|
| 影響度高 | 立即執行（這象限才該做） | 過度樂觀（容易拖成空想） |
| 影響度低 | 潛在浪費（為何要做？） | 跳過 |
- 核心觀察：「影響度高 × 緊急度低」象限是組織最容易自我欺騙的地方——大家覺得「這很重要但不急」，最後變成「永遠不做」的殭屍專案。
- 對位 Delay-Box：個人版本是 Delay Box（「該做但現在做反而干擾」）；本矩陣是組織版本。
4. 打破組織內部限制（「開火車」）
「開火車」：聚焦組織當前單一最重要倡議，移除阻礙、吸納協助資源，像火車一樣推進。
5. 必要時組織重組（Reorg）
跨團隊依賴是「同時推太多事」的根本結構性原因之一。Reorg 的執行注意：
- 預先準備：高層共識 + 工作坊
- 個別訪談：與關鍵利害關係人一對一對話
- 全員宣布：訊息一致，避免內部解讀分歧
- 參考框架：Lippitt-Knoster model（管理複雜組織變革的 6 要素：vision / consensus / skills / incentives / resources / action plan，缺一個就會失敗）
→ 對位 領導與管理：reorg 是領導者「承受不受歡迎的決策」的具體場景。
6. 明定「完成」的條件（完成的定義）
三個問題判定一個專案是否真正完成：
- 使用者的問題真的被解決了嗎？
- 解法真的被交付到使用者手上了嗎？
- 是否經過足夠時間收集到足夠的回饋？
→ 沒有這三項共識，組織會在「寫完 code 就算完成」/「上線就算完成」/「功能 demo 就算完成」之間漂移；專案永遠是 80% 完成的殭屍。
7. 持續維護
「人類組織的問題從不會被永久解決」——這是元命題。
- 七步不是一次性 SOP；是組織需要持續執行的治理節奏
- 對位 管理「讓任務可重複執行」核心功能——治理本身也是可重複任務
配套概念（曼報補充）
- WIP（Work in Progress）限制：同時進行中的事項要有上限；對位看板法的 WIP limit
- 任務切換成本：context switching 是「同時做太多」的隱形稅
- 跨團隊依賴：常被低估的延遲源
- Scope creep（範圍漂移）+ 殭屍專案：沒人敢殺、沒人在做的「半活著」專案
- Maker’s schedule vs Manager’s schedule（Paul Graham 經典）：製作者需要長段不被打擾的時間區塊；管理者習慣切割成 30 分鐘會議；強迫所有人用 manager schedule 會殺死 maker 產能
引用的外部資源
- Paul Graham：Maker’s Schedule, Manager’s Schedule（2009 經典短文）
- Sergio Caredda：Lippitt-Knoster model 的整理文
- 50 分鐘 podcast：曼報團隊對本文的延伸討論
提取概念
連結到此來源衍生 / 更新的 wiki 頁：
- 優先順序矩陣 — 新建：影響度 × 緊急度二維分類；vault 中第一個明確的組織任務優先順序框架；對位 Delay-Box（個人 vs 組織尺度）+ 12個問題法則（PKM 篩選）+ 檢核提案的-10-個問題(提案自檢) 構成「結構化篩選清單家族」第 8 條
- 完成的定義 — 新建：三問完成判定（用戶問題解了 / 解法交付了 / 回饋收齊了）；vault 中第一個明確的 Definition of Done 概念；對位 INVEST原則（敏捷 user story 驗收）+ Goal-Signal-Metric（指標拆解）構成「驗收清單家族」延伸
- Maker-vs-Manager-Schedule — 新建：Paul Graham 經典時程二分；vault 中第一個明確處理「注意力區塊大小」的概念；對位 時間箱（個人時程設計）+ 蕃茄鐘工作法（短週期專注）形成「時間結構工具」家族
- 曼報 — 更新（第 2 期 ingest）：曼報內容主軸從 EP38 純商業策略擴展到「組織管理 / 治理工法」；EP38 + EP63 顯示曼報的內容範疇是商業策略 + 組織治理雙線。
- 管理 — 更新：補入「任務超載與優先順序失靈」段——七步框架是 vault 中第一個系統處理「同時做太多」失能模式的論述；補入「組織尺度的優先順序矩陣」對位
- 領導與管理 — 更新：補入「承認問題是領導的第一動作」元命題段——對位既有「真正的領導要做不受歡迎的決策」
- 執行力 — 更新：補入「反 case：每件事都很重要 = 沒有執行力」段——執行力的反例是同時推太多優先項目導致的慢性癱瘓
- 專案管理 — 更新：補入 完成的定義 對位（單專案層級的「完成」共識）+ 多專案組合層級的「開火車」聚焦原則對位「預防勝於治療」（事先決定唯一聚焦項目）
- Delay-Box — 更新：補入「個人 Delay Box 對位組織優先順序矩陣」段——同樣是「該做但不該現在做」的延後機制，個人版以時間錨點延後，組織版以影響度 × 緊急度矩陣延後
主觀立場標記
本文是框架介紹 + 案例改寫，曼報轉介時保留 Roman Kudryashov 原意；曼報自身的詮釋層較輕（vs EP38「AI 是大公司的超級大外掛」這類曼報自有觀點）。
「Lippitt-Knoster model」、「Maker’s schedule vs Manager’s schedule」、「WIP limits」是文中外部引用，本期 vault 只把 Maker/Manager Schedule 升為獨立概念頁；其餘列入觀察清單。
原文（節錄保存）
七步框架
- 承認問題——解決問題的第一步是讓所有人都承認有問題
- 取得完整視圖——盤點所有任務（300+ 任務 → 清理後 140 件）
- 適當的優先順序方法——高 / 中 / 低分類沒用，改用「影響度 × 緊急度」二維矩陣
- 打破組織內部限制——「開火車」：聚焦單一最重要倡議
- 必要時組織重組——預先工作坊 + 個別訪談 + 全員宣布；參考 Lippitt-Knoster model
- 明定「完成」的條件——使用者問題真的被解決了嗎？解法被交付了嗎？回饋收齊了嗎？
- 持續維護——人類組織的問題從不會被永久解決
配套
- WIP（Work in Progress）限制
- 任務切換成本
- Maker’s schedule vs Manager’s schedule（Paul Graham）
- Scope creep + 殭屍專案