軟體專案管理的核心循環是：釐清需求 → 拆解任務 → 估算時間 → Sprint 規劃 → 執行與追蹤 → Review → Retrospective，然後回到下一輪。每一步都有可能出錯，而大部分專案 delay 不是因為工程師寫程式慢，而是需求沒搞清楚、估時太樂觀、或 scope creep。這篇把 project-mgmt、process、system-design 三個系列裡跟專案管理相關的文章串成一個完整的循環。
Level 0：全景圖
flowchart LR A[需求] --> B[拆解] B --> C[估算] C --> D[Sprint 規劃] D --> E[執行 & 追蹤] E --> F[Review] F --> G[Retrospective] G -->|下一輪| A style A fill:#e3f2fd,stroke:#1976d2 style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3c style D fill:#e8f5e9,stroke:#388e3c style E fill:#ede7f6,stroke:#5e35b1 style F fill:#fff3e0,stroke:#f57c00 style G fill:#fce4ec,stroke:#c62828
需求 → 拆解 → 估算 → Sprint 規劃 → 執行追蹤 → Review → Retro，循環往復。每一輪的 Retro 結論會改善下一輪的流程。
看起來很簡單？每一步展開都有很多眉角。
Level 1：需求——搞清楚「到底要做什麼」
大部分專案 delay 的根本原因不是技術問題，是需求沒搞清楚。Stakeholder 說「做一個購物車」，工程師聽到的是「加入購物車的按鈕」，PM 想的是「包含優惠碼、運費計算、庫存檢查的完整購物流程」。
→ 需求拆解：Epic → Story → Task 的拆法
產品定義 — 在寫程式之前，先確認「為什麼要做這個」。 → 產品定義（一）：使用者需求到 PRD → 產品定義（二） → 產品定義（三） → 產品定義（四） → 產品定義（五）
系統規劃 — 需求轉成技術方案。 → 系統規劃（一）：從需求到架構 → 原型規劃（一）：快速驗證可行性 → 原型規劃（二） → 原型規劃（三）
Level 1：估算——為什麼永遠不準
工程師被問「這個要做多久」的時候，想的是最順利的情況。但現實有文件不全的 API、莫名其妙的 bug、突然插進來的緊急需求。
→ 工時估算：Story Points、Planning Poker、歷史速率
估算不準不是你的問題——這是整個軟體業的問題。重點不是估「準」，而是估完之後有機制來應對偏差（buffer、scope 調整、風險管理）。
Level 1：優先排序——不是所有東西都要做
Backlog 永遠比你的產能多。學會說「不」，或者更精確地說，學會排「先做什麼」。
→ Backlog 優先排序：RICE、MoSCoW、Impact/Effort Matrix
Level 1：Sprint 規劃與執行
兩週一個 Sprint，每個 Sprint 要有明確的目標、拆好的 task、估好的 points。
flowchart TD SP[Sprint Planning] --> GOAL[Sprint Goal] SP --> TASKS[Task 分配] TASKS --> DAILY[Daily Standup] DAILY --> TRACK[進度追蹤] TRACK --> BLOCK{有阻塞？} BLOCK -->|是| RESOLVE[排除阻塞] BLOCK -->|否| CONTINUE[繼續開發] RESOLVE --> DAILY CONTINUE --> REVIEW[Sprint Review] style SP fill:#e8f5e9,stroke:#388e3c style GOAL fill:#e8f5e9,stroke:#388e3c style DAILY fill:#ede7f6,stroke:#5e35b1 style TRACK fill:#ede7f6,stroke:#5e35b1 style REVIEW fill:#fff3e0,stroke:#f57c00
Sprint Planning 定目標和分 task，Daily Standup 同步進度和阻塞，有阻塞就排除，最後 Sprint Review 展示成果。
規劃與追蹤： → Sprint 規劃：怎麼規劃一個兩週的 Sprint → 進度追蹤：Burndown Chart、風險指標、進度儀表板 → Agile 實務：Scrum 和 Kanban 的差異和實際操作
開發流程 — Sprint 裡的工程實踐。 → Feature Lifecycle：一個功能從 branch 到上線 → Feature Lifecycle（二） → Feature Lifecycle（三） → 環境規劃：Dev / Staging / Production → Release 方法論：版本發布策略 → Release 方法論（二） → Monorepo vs Multi-repo：專案結構決策
品質保證 — 不能只追速度，品質掉了後面會花更多時間修。 → 測試策略：測試金字塔 → 測試策略（二） → Commit Lint：規範化的 commit → Code Review：有效的 review 流程 → SDD：測試驅動開發
Level 1：Stakeholder 溝通
專案管理有一半是「管理期望」。老闆問「做完了嗎」的時候，最好的回答不是「快了」，而是「還有三個 API、一個頁面、測試還沒跑」。
→ Stakeholder 溝通：向上管理、期望管理、進度報告
Level 1：Review & Retrospective
Sprint 結束後兩件事：Review（展示成果給 stakeholder 看）和 Retro（團隊內部檢討流程）。
→ Postmortem & Retro：事後檢討和持續改進
事故管理 — 線上出事了怎麼辦。 → 事故管理（一）：事故分級、On-call → 事故管理（二）：根因分析 → 事故管理（三）：Blameless Postmortem
Level 1：支撐工具——CI/CD、監控、技術債
專案管理不只是流程，還需要工具和基礎設施的支撐。
CI/CD — 自動化測試和部署，減少人為失誤。 → CD Pipeline → CD 核心：概念和工具鏈 → Git + CI + Release：從 commit 到上線
監控 — 上線之後才是開始。 → 好的監控系統 → Alerts & ChatOps：告警分級和通知
技術債 — 每個專案都有，關鍵是「什麼時候還」。 → 技術債：辨識、量化、排優先 → 取捨框架：在速度和品質之間做決定
閱讀路徑
新手 PM / 剛開始管專案
從 需求拆解 開始，學會把模糊的需求變成可執行的 task。然後看 Agile 實務 了解 Scrum 的基本運作。
工程師想了解 PM 在幹嘛
看 Sprint 規劃 和 工時估算。理解「為什麼 PM 一直追你進度」背後的邏輯。
Tech Lead 想改善團隊流程
從 Postmortem & Retro 開始——先搞清楚現在的問題在哪。然後看 Feature Lifecycle 設計從需求到上線的標準流程。
知識缺口
| 缺口 | 為什麼重要 | 建議放在哪 |
|---|---|---|
| ⚠️ 遠端團隊的專案管理 | 後疫情時代的必備能力 | project-mgmt/ |
| ⚠️ OKR 實務 | 目標管理框架，很多公司在用 | project-mgmt/ |
| ⚠️ 跨部門協作 | 前端 / 後端 / 設計 / QA 怎麼協作 | project-mgmt/ |
| ⚠️ 專案管理工具比較 | Jira vs Linear vs Notion vs ClickUp | project-mgmt/ |
| ⚠️ 接手爛專案 | 新上任的 PM / Tech Lead 最常遇到的情況 | project-mgmt/ 或 career/ |
FAQ
Q: Scrum 跟 Kanban 差在哪？ A: Scrum 有固定的 Sprint（通常 2 週），有角色（PO、Scrum Master），有儀式（Planning、Daily、Review、Retro）。Kanban 更彈性——沒有固定週期，用 WIP limit 控制在做的事不會太多。需求穩定的產品開發適合 Scrum，變動大的維運或支援團隊適合 Kanban。詳見 Agile 實務。
Q: 怎麼估時間？ A: 別估時間，改估複雜度（Story Points）。用 Planning Poker 讓團隊一起估，避免一個人的盲點。跑幾個 Sprint 之後，看團隊的 velocity（每個 Sprint 完成幾個 points），就能用 velocity 推算時間。詳見 工時估算。
Q: Stakeholder 不講清楚需求怎麼辦？ A: 別等他講清楚——主動去問。用「你要的是 A 還是 B」的二選一問法取代「你想要什麼」。或者先做一個簡單的 prototype 給他看，讓他說「不是這個」也比「我不知道」有用。詳見 Stakeholder 溝通。
Q: 專案一直加需求（scope creep）怎麼辦？ A: 三個做法：（1）所有新需求都進 Backlog，不直接塞進 Sprint；（2）每次加需求就問「那你要砍哪個」；（3）在 Sprint Planning 時明確定義 Sprint Goal，超出 Goal 的一律不做。詳見 Backlog 排序。
Q: Daily Standup 一直開超時怎麼辦？ A: Daily 只回答三個問題：昨天做了什麼、今天要做什麼、有沒有阻塞。細節和討論移到會後。如果每天都有很多阻塞要討論，問題可能不在 standup，而在 Sprint Planning 時 task 拆得不夠細。
Q: 怎麼處理技術債？ A: 每個 Sprint 留 15-20% 的 capacity 給技術債。不要開一個「技術債 Sprint」——那永遠排不到。把技術債當作普通的 task，跟 feature 一起排優先。詳見 技術債。