Mgmt. Tool（管理工具）

前面的筆記談的大多是觀念——專案與產品的差異、方法論的選擇、角色職責的分工，以及 Waterfall 的流程。這一章會將這些觀念轉成可落地執行的具體作法，也就是使用專案管理工具。

下面是專案管理常用的工具，實際上當然不只這些，下面幾項工具只是根據之前的經驗統整出來，且可以按層級區分使用情境的部分：

WBS（Work Breakdown Structure）

結構特性

• 樹狀結構：專案總目標 → 主要交付物 → 子交付物 → 工作包
• 100% Rule：子節點總和必須等於父節點的全部範圍，同時也包含總工時
• 以「交付物 / 成果」為導向，而非以「動作」為導向（避免拆成一堆動詞清單）

拆解的粒度

一個末端工作包的工時建議落在 8 ～ 80 小時之間：

• 太大 → 難以估時與追蹤，風險被掩蓋
• 太細 → 管理成本超過實際產出價值
• 理想 → 能被一個負責人扛起，且驗收標準明確

為什麼 PM 需要 WBS

• 確認範圍（Scope）：未列入 WBS 的東西，預設就不在這次專案內
• 估算的基礎：沒有拆解就沒有估時與成本估算
• 風險識別：拆解過程會浮現原本沒想到的依賴與盲點
• 指派責任：每個工作包都應有明確負責人（呼應 專案管理系列：第三章 - Role & Responsibility (R&R) RACI 中的 R）
• 承接後續工具：Gantt、Kanban、Task 都是以末端工作包為基礎再展開

範例：DutyMate 值日生排班系統

以我們現在在跑的 Side Project「DutyMate」（值日生排班 App）為例，把 PRDProduct Requirement Document，產品需求文件：在動工前定義專案要做什麼的依據文件，通常包含問題背景、目標、使用者角色、功能規格與驗收標準、時程等。它界定了專案範圍，正好是 WBS 拆解的輸入來源。 的範圍拆成 WBS：

DutyMate 值日生排班系統
├── 1. 需求與規劃
│   ├── 1.1 痛點訪談與需求確認
│   ├── 1.2 PRD 定稿與待釐清項確認
│   └── 1.3 範圍與里程碑確認
├── 2. 設計
│   ├── 2.1 業務流程與 Use Case
│   ├── 2.2 資料庫 Schema 設計
│   ├── 2.3 API 規格設計
│   └── 2.4 UI Mockup
├── 3. 開發
│   ├── 3.1 基礎建設與權限（專案骨架、登入、用戶管理、角色權限）
│   ├── 3.2 活動設定與排除時段（活動設定、排除時段、排班限制表）
│   ├── 3.3 草稿班表與推薦演算法（推薦演算法、排班統計、班表發布）
│   ├── 3.4 正式班表與檢視（篩選值日生、工作任務備註、無法出勤標記）
│   └── 3.5 出勤統計與過往班表匯入
├── 4. 測試
│   ├── 4.1 單元測試（Jest）
│   ├── 4.2 系統整合測試（SIT）
│   └── 4.3 使用者驗收測試（UAT）
└── 5. 上線
    ├── 5.1 Docker 部署設定
    ├── 5.2 Cutover 與 Go-Live
    └── 5.3 上線後監控與保固

我個人習慣在 WBS 上直接加上負責人（PIC）欄位，還有進度欄位。這樣在排程與指派時就能一併完成。下面的示意圖就是結合 WBS 與 Gantt 的樣子， 但礙於版面限制，只留工作項目、PIC、工時和開始日期的欄位：

這邊也提供了一個用 Excel 建立的 WBS 模板，已經套用好基礎欄位，未來有機會使用到也可以下載

Kanban（看板）

基本元素

核心精神

• 視覺化（Visualize）：所有人一眼看到目前狀態與卡關處
• 限制 WIP：強迫團隊「先完成、再開始」，避免同時推太多卻沒一件結案
• 管理流動（Manage Flow）：關注 Lead Time前置時間：從任務「被建立 / 提出」到「完成交付」的總耗時，反映的是需求方（顧客）從開口到拿到成果一共等了多久。 與 Cycle Time週期時間：從「實際開始動工」到「完成」的耗時，反映團隊真正處理一件事的速度；它是 Lead Time 的子區段（扣掉排隊等待的部分）。。後面的章節會專門講指標，這裡只先提一下它們是 Kanban 的核心指標，用來反推流程上的瓶頸與改善效果
• 明確的流程政策：每個欄位的進入條件與完成的定義要寫清楚，例如說，推進到 Done 的條件是開發團隊完成功能開發與交付技術文件，與 PM 通過功能測試，而不是「我覺得我做完了」
• 持續改善：定期檢視瓶頸、調整欄位與 WIP 上限

為什麼 PM 適合用 Kanban

• 進度透明：不必開會問進度，看板本身就是進度
• 瓶頸可視化：哪個欄位卡片堆積，就是當前瓶頸（通常是 Review 或驗收）
• 與 WBS 搭配：WBS 末端工作包展開出的 Task任務：最末端、可被執行與追蹤的工作單元，記錄負責人、時間與狀態等細節。本篇最後一節「Task（任務）」會專門介紹。，可一張張變成卡片直接進入流動

我的看板狀態設計

我自己的 Kanban Task任務：最末端、可被執行與追蹤的工作單元，記錄負責人、時間與狀態等細節。本篇最後一節「Task（任務）」會專門介紹。 的狀態流， 會按以下方式設計：

Open ──→ On Going ──→ Done ──→ Verified ──→ Closed
(待辦)    (進行中)    (待驗收)   (待結案)     (已結案)

Task（任務）

一個任務需要包含足夠資訊，才有助於追蹤管理。

狀態

一般作法較精簡，推到「已完成」即收尾；我自己則把「驗收」與「結案」獨立成可追蹤的狀態。

兩套狀態的對照

這兩套其實是同一條流程，差別在後段的細緻度。一般的狀態是任務推到「Done」就結束，因為 Done 的狀態表示驗收與結案被涵括在內進行處理。

換句話說，我多出來的 Verified 與 Closed，是把壓在「Done」裡的「驗收」與「結案」獨立拉出來成為可追蹤的狀態。 代價是流程看起來變長，好處是「完成 → 驗收」「驗收 → 上線」這兩段耗時能被量化，瓶頸才看得見。

為什麼要這麼多時間欄位

對使用者而言，最關心的往往只有一個時間點——什麼時候上線。但對 PM 來說，上線時間只是其中一個要素； 若把眼光拉到產品的長期推進，重點就不只是「準時上線」，而是讓每一次的規劃都比上一次更準。

這正是為什麼光是「完成時間」，都要拆成「預計」與「實際」兩欄：兩者的差距就是估時誤差， 長期記錄下來，團隊才能逐步縮小落差，讓往後的時程估算越來越可靠。

把時間欄位攤開後，真正的價值在於反推每一段的耗時，找出流程瓶頸：

當能看出「卡的不是開發、而是驗收」或「估時總是低估」這類模式時，這些時間欄位才從單純的紀錄，變成可以拿來改善流程與校正估時的依據。

發現瓶頸後的下一步

時間欄位幫你指出瓶頸卡在哪一段，但這只是第一步。更現實的問題是：很多時候，瓶頸根本不會有人主動講出來。

一般工程師常常埋頭苦幹，也容易報喜不報憂（其實就是在說我自己 🤡）——卡關了不一定會主動反應，問起來還會說「再一下就好」，結果一路拖到火燒屁股、一發不可收拾才被發現。等到那時候，往往已經錯過最便宜的處理時機。

所以瓶頸數據真正的價值，是讓 PM 不必等人開口就能及早發現異常：

• 看趨勢、不只看單點：某一段的耗時連續幾次都在拉長，就算當事人說「沒事」，數據已經先示警了。
• 主動把問題攤開來談：與其等對方求救，不如 PM 拿著數據先問「這段最近卡比較久，是不是遇到什麼困難？」——把「報憂」的責任從個人轉移到流程上。
• 早一點介入、便宜一點解決：瓶頸越早抓到，可動用的選項（補人、調範圍、改順序）越多；拖到最後，常常就只剩硬扛一條路。

發現瓶頸之後，四種瓶頸的病因不同、藥方也就不同。下面這張互動處方手冊，把前置擁塞 / 估時失準 / 驗收塞車 / 上線延宕逐一拆開：點 tab 切換情境，再沿「介入前 → 介入中 → 介入後」三階段，依序看到察覺症狀、診斷病因、開立處方。

小結

這幾項工具不是各做各的，而是互相輔助：