專案管理的本質，不是填表，而是駕馭未來的不確定性
無論是需求變動、時程壓力、資源衝突，還是利害關係人的期待落差，PM 的核心任務始終是把模糊與風險轉成可管理、可溝通、可交付的節奏。
這門課以「一個本質、兩種典型、五大流程、十大知識領域」為骨架，再搭配 AI 工具箱，幫你把專案治理、風險預判與實戰文件生成串成一套完整方法。
理解瀑布式與敏捷式（Scrum）的差異，知道什麼類型的專案應該用什麼節奏來管理。
瀑布式用章程、WBS、關鍵路徑、PPA、EVM 與變更管制；敏捷式用 Product Backlog、Sprint 與燃盡圖，把專案轉成可執行、可監控的計畫。
把 AI 用在草擬章程、拆解工作、分析風險與判讀績效，縮短第一版產出的時間。
PM 真正要處理的不是文件本身，而是未來會怎麼變、出了狀況怎麼應對、團隊如何持續對齊。
需求穩定時適合瀑布式，變化快速時更需要敏捷式。選錯節奏，專案成本會被放大。
從草擬章程、WBS、PPA 到 EVM 解讀，AI 能加速你完成第一輪分析與溝通準備。
專案管理鳥瞰
管理未來的不確定性，讓團隊在有限資源下仍能穩定靠近目標。
瀑布式重規劃與控制，敏捷式重迭代與回饋，兩者各有最適用場景。
範疇、時程、成本彼此牽動，任何一邊變動都會影響整體平衡。
起始、規劃、執行、監控、結案，形成專案持續校正的循環節奏。
從整合、範疇到利害關係人，建立一套系統性治理專案的視角。
別把 PM 想成「催進度的人」。真正的 PM 是組織中的對齊者、風險預判者、資源整合者與價值交付推動者。
章程與範疇 → WBS → 任務依賴 → 甘特圖與關鍵路徑 → Phase Gate → 資源與成本 → PPA 風險 → 基準與變更 → Kick-off。對應本頁「起始、規劃、監控」三個分頁。
敏捷式 Scrum 看板願景與團隊 → Product Backlog → Sprint 看板 → 燃盡圖 → Scrum 事件 → 速率與發布預測。對應本頁「敏捷 Scrum」分頁。
兩套工具都是單一 HTML 檔，可下載離線使用、不需安裝。建議先讀本頁觀念，再到工具裡動手做一次。
核心觀念測驗
Knowledge Check1. 你的團隊正在開發一款全新的手機 App，市場需求尚不明朗，功能可能隨時需要調整。請問哪種專案管理方法更適合？
2. 在專案管理中，被稱為「三重限制（Triple Constraint）」的三個關鍵要素是什麼？
課程 AI 使用方式
在每個實戰演練按「📋 複製提示詞」，貼到你慣用的 AI 即可。不需要申請帳號或金鑰，也不需要任何設定。
① 複製提示詞
在起始、規劃、監控任一實戰演練，或敏捷 Scrum、AI 工具箱七個分析模型任一項填好欄位，按「📋 複製提示詞」。系統會依 VIBE ＋ TICOE 架構把提示詞組好。
② 貼到你的 AI
ChatGPT／Gemini／Claude／Copilot／DeepSeek／公司內部 AI 都可以。專案的預算、工期、客戶與人力資料留在公司核准的工具裡。
③ 把 HTML 貼回來看
AI 回一段 HTML，整段複製後貼到「HTML 檢視」分頁即可渲染。報表在獨立沙箱中執行。
課後帶走：下載 Skill 檔
每個工具都能匯出一份 SKILL.md，內容就是 VIBE × TICOE 對照表：角色設定、語氣風格、輸出格式、Task／Input／Constraint／Output／Evaluation 全部寫好。Claude 放進 ~/.claude/skills/，Codex 放進 ~/.agents/skills/，ChatGPT／Gemini 則直接把內容貼進對話當系統提示。下次啟動新專案，叫出 skill 就能跑同一套章程與風險邏輯。
⚠️ 機密資料檢查 — 每次複製前都做一次
- 先把要貼的內容分級：公開、內部、機密。內部以上一律不進公開的 AI 服務。
- 先去識別化：客戶與供應商名稱改成 A 公司／B 公司，合約金額、報價、真實預算與人員姓名改成代表性數字或角色；尚未公告的專案、標案與併購計畫一律不要放進去。
- 去識別化之後方法照樣跑得動。你在練的是章程、WBS、風險與 EVM 的思路，不是那組數字。
把專案管理從抽象名詞，變成可操作的治理地圖
五大流程告訴你專案在哪個階段該做什麼，十大知識領域則提醒你有哪些關鍵面向不能漏掉。
起始
確認商業目的、建立專案章程、授權專案經理，定義為什麼值得做。
規劃
把目標拆成 WBS、時程、成本、風險與資源配置，讓專案真正具備可執行性。
執行
推動團隊落地、處理協作與溝通，把規劃轉成可見成果與可用增量。
監控
用 EVM 與變異分析追蹤進度與成本，及早修正偏差，避免專案後段失控。
結案
交付成果、萃取經驗與完成移交，讓組織把這次專案轉成下次的能力資產。
因為很多專案只重執行，不重起始與規劃；或只看進度，不看風險與利害關係人。框架的價值就在於幫你「不漏看關鍵」。
串起所有流程與決策，確保專案不是一堆碎片化活動。
先定義做什麼與不做什麼，避免需求膨脹拖垮專案。
安排工作順序與節點，讓專案節奏可以被追蹤與修正。
掌握資源消耗與預算健康，避免交付前才發現嚴重超支。
不只要交付，更要交付可用、可靠、符合期待的成果。
確保人力、設備與能力配置合理，不讓瓶頸拖垮交付。
把對的人在對的時間拉到同一頁，很多風險其實是溝通失效。
預先思考可能出事的點，建立 Plan A 與 Plan B，降低被動挨打。
當成果仰賴外部供應商時，採購策略會直接影響專案品質與時程。
專案常常不是技術做不出來，而是人沒對齊、期待沒被管理好。
會，只是尺度不同。瀑布式把起始、規劃、執行、監控、結案沿著整個專案走一次；敏捷式在每個 Sprint 裡小規模地重複「規劃 → 執行 →檢視 → 調整」，詳見「敏捷 Scrum」分頁。十大知識領域在兩種做法中都適用。
專案的出師表：Project Charter
起始不是喊一聲開始，而是讓組織確認為何值得做、誰負責推動、什麼算成功。
專案章程是正式批准專案成立的文件，如同諸葛亮的《出師表》。它賦予專案經理權力，也讓所有人知道這個專案的商業意義與邊界。
沒有章程的專案，往往會在開始後才不斷重談目的、角色與目標，導致團隊疲於修補認知落差。
專案緣起與目標：為何要做？要解決什麼商業問題？
專案範疇：包含什麼、不包含什麼？
交付成果與里程碑：最後會交出什麼？重要節點在哪？
利害關係人與高階風險：誰影響成敗？最大的威脅是什麼？
範疇外項目寫清楚，才擋得住開工後的「順便做一下」。例如開店專案：包含店面設計、客源開發、測試營運；不包含二號店選址與線上商城。
每個範疇項目都要有至少一個 WBS 工作包承接。沒有工作包承接的範疇，就是沒有人負責的承諾。
進入條件：商業論證已提出；發起人已指派專案經理。
退出條件：專案章程經發起人簽核；必要條件逐項確認；Kick-off 完成且會議紀錄已發布。
核決人：發起人。
✓ 目標與成功標準可衡量，大家理解一致
✓ 範疇（含不包含）已確認，並對應到 WBS
✓ 每個工作包都有負責人
✓ 各階段審查的條件與核決人已公布
✓ 溝通節奏、會議紀錄與計畫簽核方式已約定
AI 輔助撰寫專案章程
AI Charter Draft起始流程測驗
Initiating Drill1. 專案章程（Project Charter）的最主要作用是什麼？
2. 下列何者「不」是專案章程（Project Charter）通常會包含的內容？
化整為零的藝術：WBS、時程、成本與風險
規劃流程的關鍵，不只是把事情排滿，而是把事情拆清楚，並對可能出錯的地方提早設計應對。
WBS 是規劃流程的核心工具。它依循 MECE 原則，把專案總體工作層層分解成更小、更容易管理與估算的工作包。
拆得夠清楚，時程、成本、資源與責任才能被準確分派；拆不清楚，後面很多問題都會被放大。
工作包要有明確的完成條件；同一個交付物不要在兩個分支重複計算。摘要活動的日期與成本，由底下的工作包彙總而來。
PPA 是專案中的超前部署思維。Plan A 是為可能原因先做預防，Plan B 則是為可能後果先設定 Trigger 與應變方案。
好的 PM 不是等風險發生後再應對，而是先替專案準備第二條路。
如果起始解決的是「值不值得做」，那規劃解決的就是「怎麼做才不會一路救火」。WBS 與 PPA 剛好分別處理「工作拆解」與「風險預判」。
WBS 回答「要做哪些工作」，前置關係回答「先做哪個、再做哪個」。WBS 的上下階層不會自動產生依賴，排程一定要另外連結。
最常用的是 FS（完成→開始）：前一項完成，後一項才能開始，必要時可加延遲天數。工期以工作天計，週末與假日不算。
總浮時＝最晚開始 − 最早開始，代表這項工作能延後多久而不影響計畫完成日。浮時為 0 的工作串起來就是關鍵路徑，任何一天延誤都會直接延後完工日。
緩衝是 PM 主動加進活動的保護時間，會佔用時程；浮時則是由依賴網路算出來的餘裕。兩者不要混為一談。
範例：四項任務的時程網路（單位：工作天）
| 任務 | 工期 | 前置（FS） | 最早開始–完成 | 最晚開始–完成 | 總浮時 |
|---|---|---|---|---|---|
| A 確認需求 | 3 | — | 0–3 | 0–3 | 0（關鍵） |
| B 詳細設計 | 5 | A | 3–8 | 3–8 | 0（關鍵） |
| C 採購備料 | 2 | A | 3–5 | 6–8 | 3 |
| D 施工組裝 | 4 | B、C | 8–12 | 8–12 | 0（關鍵） |
C 有 3 天浮時：延後 2 天，完工日不變；B 只要延後 1 天，完工日就延後 1 天。所以趕工要投在關鍵路徑上，投在非關鍵任務上不會讓專案提早完成。
把資源分成人力、材料、設備、費用四類，每項寫下單位、單價或日費率與可用數量。WBS 回答「做什麼」，RBS 回答「用什麼做」。
人力成本 ＝ 工期（工作天）× 每日費率 × 投入人數。例：設計師日費率 6,000 元，投入 5 天，人力成本 30,000 元。材料、設備與費用另外逐項列計。
1. 預算檢查：計畫總成本是否在預算上限內？超過就要回頭調整範疇、做法或資源，而不是祈禱執行時會省下來。
2. 尖峰檢查：同一時段需要的人數，有沒有超過可用人數？加了緩衝的期間，人員仍被佔用。超載時要手動做資源平衡：利用非關鍵任務的浮時往後挪，或調整順序、增加人力。
AI 輔助建立 WBS
WBS Builder每個潛在問題以 1–10 分評估三個面向：S 嚴重度（發生後的衝擊）、O 發生度（發生的可能性）、D 難偵測度（越難提早發現分數越高）。
RPN ＝ S × O × D，取分數最高的前 5 項優先佈局，其他列入觀察清單。
Plan A（預防）針對可能原因下手，用來降低 O。
觸發條件／偵測讓問題提早被看見，並決定何時啟動 Plan B，用來降低 D。
Plan B（應變）在問題發生後降低衝擊，用來降低 S 的實際影響。
| 潛在問題 | S | O | D | RPN | 觸發條件 |
|---|---|---|---|---|---|
| 關鍵設備延遲到貨 | 8 | 5 | 6 | 240 | 出貨前 10 天供應商仍未提供出貨單 |
| 主要設計人員臨時請假 | 6 | 4 | 3 | 72 | 同一人負責的關鍵工作包超過 2 個 |
| 測試營運客源不足 | 7 | 5 | 5 | 175 | 開幕前 2 週預約數低於目標的 60% |
AI 輔助風險分析（PPA）
PPA Analyst規劃流程測驗
Planning Drill1. 在建立 WBS 時，MECE 原則指的是什麼？
2. 在 PPA 風險分析中，「為可能發生的原因，預先採取預防措施」屬於哪一類行動？
3. 任務 C 的總浮時是 3 天。若 C 延後 2 天開始，專案的計畫完成日會如何？
4. 某潛在問題的嚴重度 S＝8、發生度 O＝5、難偵測度 D＝7，其 RPN 是多少？
專案的儀表板：EVM、變更管制與階段審查
監控的本質不是事後報告，而是提早看出偏差、提早修正，讓專案還有機會回到正軌。
EVM 將範疇、時程與成本整合在一起衡量，讓 PM 不只是知道花了多少錢，而是知道花出去的錢換回了多少價值。
這是 PM 從「感覺有點落後」走向「能量化指出問題」的重要工具。
SV = EV - PV：負值代表時程落後。
CV = EV - AC：負值代表成本超支。
SPI = EV / PV：小於 1 代表時程效率不佳。
CPI = EV / AC：小於 1 代表成本效率不佳。
因為只在追任務完成數，卻沒把計畫值、實獲值與實際成本放進同一張表。EVM 的價值就在於把「有沒有做完」升級成「做出的價值是否符合成本與進度」。
AI 輔助 EVM 分析
EVM Interpreter基準（Baseline）是經核准的範疇、時程與成本，是 EVM 計算 PV 與判斷偏差的比較依據。基準一旦建立就凍結：不得直接修改，也不接受口頭變更。
計畫健檢全部通過，才建立基準 v1，凍結範疇、時程與成本。
任何變更都以書面變更請求（CR）提出並編號，寫清楚內容與理由。
評估時程（是否在關鍵路徑上、浮時吸收得了嗎）、成本、風險與品質影響。
變更管制委員會決定核准、駁回或有條件核准。
核准就更新基準並升版為 v2、通知相關人；駁回就將計畫還原至基準。
AI 輔助變更影響分析
CR Impact每個階段結束前，用可驗證的進入與退出條件決定能不能往下走，並指定核決人。條件寫成「已簽核」「為 0」「在門檻內」，而不是「大致完成」。
| 關卡 | 進入條件 | 退出條件 | 核決人 |
|---|---|---|---|
| G1 立案審查 | 商業論證已提出；發起人已指派專案經理 | 專案章程經發起人簽核；必要條件逐項確認；Kick-off 完成且會議紀錄已發布 | 發起人 |
| G2 設計審查（基準核准） | G1 通過；需求與限制已確認 | 設計經審查核定且無重大未結議題；範疇、時程、成本基準經核准並凍結 | 發起人、專案經理 |
| G3 建置完成審查 | G2 通過，基準已凍結；資源到位 | 執行類工作包完成並通過內部驗證；已核准變更全數納入 | 專案經理 |
| G4 上線審查（Go/No-Go） | G3 通過；驗收標準已核准 | 測試與驗收簽核；重大問題為 0；時程與成本偏差在門檻內；上線準備度檢核通過 | 發起人 |
| G5 結案審查 | G4 通過並完成導入 | 交付物正式驗收；營運移交完成；財務結清；經驗學習與結案報告發布 | 發起人 |
監控流程測驗
Controlling Drill1. 在 EVM 中，如果你的專案成本績效指標（CPI）為 0.8，這代表什麼？
2. 如果專案的時程變異（SV）為負值（-10,000），這明確表示？
3. 基準已核准凍結後，客戶在會議中口頭要求增加一項功能。專案經理應該怎麼做？
4. 下列哪一個最適合寫成 Phase Gate 的退出條件？
需求會變的時候：用 Scrum 短週期交付
瀑布式靠前期把計畫做完整，敏捷式則承認一開始想不清楚，靠每 1–4 週交付一次可用成果、收集回饋，再決定下一步。
| 比較面向 | 瀑布式（Waterfall） | 敏捷式（Scrum） |
|---|---|---|
| 適用情境 | 範疇明確、變更代價高、受法規或合約約束 | 需求多變、可以早期試用並取得回饋 |
| 規劃方式 | 前期完整規劃：WBS、甘特圖、關鍵路徑、基準 | 逐步細化：Product Backlog 持續排序，每個 Sprint 只細規劃近期工作 |
| 交付節奏 | 依階段推進，由 Phase Gate 放行 | 每個 Sprint 產出符合 DoD 的 Increment |
| 變更處理 | CR → 影響分析 → CCB 核准 → 基準升版 | 新需求進 Product Backlog，由 Product Owner 重新排序；Sprint 中不得危及 Sprint 目標 |
| 進度衡量 | EVM（SPI、CPI）、里程碑、關鍵路徑 | Sprint 目標達成、燃盡圖、速率 |
| 角色重心 | 專案經理統籌計畫與控制 | Product Owner 管價值、Scrum Master 管成效、Developers 管交付 |
| 典型例子 | 廠房擴建、開設門市、設備導入、法規認證 | App 與數位服務、內部系統改善、新產品探索 |
外層用 Phase Gate 管預算、里程碑與上線決策；內層的開發或改善工作用 Sprint 迭代。重點是每一層都清楚「誰決定範疇、用什麼衡量進度」。
Product Owner：為產品價值負責，決定 Product Backlog 的排序。
Scrum Master：為 Scrum 的成效負責，協助排除障礙、引導團隊改善。
Developers：為每個 Sprint 交付可用的 Increment 負責，自己估計工作大小並規劃做法。
Sprint：1–4 週固定長度，裝載其他所有事件。
Sprint Planning：最多 8 小時，決定為什麼做、做什麼、怎麼做。
Daily Scrum：固定 15 分鐘，Developers 檢視朝 Sprint 目標的進展並調整當天計畫。
Sprint Review：最多 4 小時，和利害關係人檢視成果、收集回饋。
Sprint Retrospective：最多 3 小時，選出具體的改善行動。
Product Backlog → 產品目標：所有待辦工作依價值排序，指向同一個長期目標。
Sprint Backlog → Sprint 目標：團隊承諾的是 Sprint 目標，選入的項目只是預測。
Increment → 完成的定義（DoD）：符合 DoD 的項目才算 Increment 的一部分。
故事點數、費氏數列、Epic、看板欄位與燃盡圖不是 Scrum 本身的規定，而是常見、可採用的工具慣例。
格式：身為〈使用者〉，我想要〈功能〉，以便〈價值〉。例：身為門市顧客，我想要線上預約服務時段，以便不必到店排隊。
驗收條件描述這一則故事必須符合的行為，例如：「選擇已額滿的時段時，系統顯示其他可預約時段」。
故事太大就往下拆。常用 INVEST 檢查：獨立、可協商、有價值、可估計、夠小、可測試。
排序：Product Owner 依價值、風險與依賴排序，越上面越優先、也越要拆得細。
估點：由 Developers 用相對大小估計，課堂常用費氏數列 1、2、3、5、8、13、21；資訊不足就標「?」，先補資訊再估。
點數 ≠ 工時：點數用於相對大小與團隊預測，工時用於拆解任務與討論產能，不要互相換算。
驗收條件 vs DoD：驗收條件只屬於單一故事；DoD 是所有項目共同的品質標準，例如「通過驗收條件、程式已審查、已部署到測試環境」。
用一句話說明這個 Sprint 要創造的價值，例如「顧客可以完成線上預約並收到確認通知」。
參考近幾個 Sprint 的平均速率與本次可用工時。例：平均 28 點，選入 7 項共 30 點；規劃超過平均速率的 120% 就要警覺過度承諾。
Developers 把故事拆成任務並估計工時，開始 Sprint 後每天更新剩餘工時。
看板欄位常見為「待辦 → 進行中 → 完成」。卡片只有符合 DoD 才能移到完成。
卡住的事記在卡片的「障礙」欄，Daily Scrum 時提出；Scrum Master 協助排除，必要時與 Product Owner 協商範疇。
未完成的項目退回 Product Backlog，由 Product Owner 重新排序，不給部分完成點數。
Sprint Review 是和利害關係人檢視成果、調整 Backlog 的場合，不是驗收關卡；是否發布是另一個商業決定。
第 5 天 Product Owner 加入一則 5 點的故事，曲線因此上升；第 10 天仍剩 3 點，未完成的故事退回 Product Backlog。曲線平平不動，通常代表有障礙或故事拆得太大。
速率＝一個 Sprint 內符合 DoD 的故事點數總和。
例：剩餘 Product Backlog 約 120 點，近三個 Sprint 速率 26、30、28 點。
120 ÷ 30 ＝ 4.0；120 ÷ 26 ≈ 4.6 → 預測需要 約 4–5 個 Sprint。用區間表達，不要只給一個數字。
預測的前提是團隊成員、Sprint 長度與估點尺度不變；Backlog 一改，預測就跟著變。只有 1–2 個 Sprint 的資料時，預測非常粗略。
✗ 用速率比較個人或團隊績效（點數尺度各團隊不同，一比就會開始灌點數） ✗ 把點數換算成工時 ✗ 給未完成的故事部分點數 ✗ Sprint 中途硬塞需求而犧牲 Sprint 目標 ✗ 把 Daily Scrum 開成向主管報告進度的會議
AI 輔助建立 Product Backlog
Backlog BuilderAI 輔助 Sprint 健檢與回顧
Sprint Health Check敏捷 Scrum 測驗
Scrum Drill1. 在 Scrum 中，Developers 在 Sprint 開始時「承諾」的是什麼？
2. 關於「驗收條件」與「完成的定義（DoD）」，下列何者正確？
3. 剩餘 Product Backlog 約 120 點，近三個 Sprint 速率為 26、30、28 點。較合理的發布預測是？
4. Sprint 結束時，一則 8 點的故事完成了大約 80%，應如何處理？
把 PM 的重複性思考，交給 AI 加速第一輪輸出
用 AI 幫你產出專案章程、WBS、PPA、EVM 解讀、利害關係人策略、變更影響分析與 Scrum Backlog，但保留最終判斷在 PM 自己手上。
快速整理專案緣起、目標、範疇、里程碑與高階風險。
把大型專案拆成層次清楚的工作包，方便估時、估資源與指派責任。
針對潛在問題先想好 Plan A 與 Plan B，降低專案出事時的混亂程度。
協助快速解讀 SV、CV、SPI、CPI，抓出時程與成本偏差的重點。
幫你整理利害關係人、影響力與對應的溝通節奏，降低協作摩擦。
評估 CR 對範疇、關鍵路徑、成本與風險的影響，整理給 CCB 的核決建議。
把需求轉成使用者故事、驗收條件與排序建議，並草擬團隊的 DoD。
快速產出一頁式專案章程草稿，方便你先對齊專案目的與邊界。
把 AI 產出的 HTML 貼進來，立刻看到報表
手機不用存檔、不用找檔案 App。貼上就渲染，圖表與表格直接呈現。
為什麼需要這個？
ChatGPT、Gemini 這類平台只會把 HTML 當「一段程式碼」回給你，不會產生可下載的檔案。在 iPhone 上要把那段程式碼變成能開的網頁幾乎不可能——所以我們把渲染器直接做在課程網站裡。
複製提示詞
在任一實戰演練區塊按「📋 複製提示詞」，貼到你慣用的 AI。
複製 AI 的回覆
AI 會回一段 HTML 程式碼。整段複製即可——前後多帶了說明文字也沒關係，系統會自動抓出程式碼。
貼到下方，按「渲染報表」
報表立刻出現。可全螢幕檢視，也能下載成 .html 保存。
貼上 AI 回覆
支援整段回覆（含 ``` 程式碼圍欄與前後說明），也支援只貼純 HTML。
安全說明：報表在獨立沙箱中執行，無法讀取本頁面的任何資料。內容只留在你的瀏覽器，不會上傳。
下載說明：電腦端會直接存檔；iPhone 會跳出分享選單，可選「儲存到檔案」。
從 PM 管理者，進化成 AI 強化型交付領導者
AI 不會取代 PM 的判斷力，但會明顯拉高 PM 在規劃、分析、整理與溝通上的速度與一致性。
課程總結心智圖（點擊放大）
Project Management Nano Banana（點擊放大）
- ✓一個本質： 專案管理的核心是管理未來的不確定性。
- ✓兩種典型： 依專案特性靈活運用瀑布式與敏捷式的不同節奏。
- ✓五大流程： 依照起始、規劃、執行、監控、結案的順序持續校正與交付。
- ✓十大知識領域： 從整合、時程、成本到利害關係人，建立系統性治理能力。
- ✓瀑布式治理： 關鍵路徑看時程、RBS 看成本、SOD／RPN 排風險，基準與 CR 管變更，Phase Gate 決定放行。
- ✓敏捷式交付： 以 Sprint 目標、DoD、燃盡圖與速率，在需求多變時穩定交付並持續調整。
- ✓AI 賦能： 在專案章程、WBS、PPA、EVM、變更分析、Backlog 與溝通策略上大幅提升第一輪產出速度。
- ✓PMBOK 7 展望： 更強調價值交付、僕人式領導與系統思維，值得持續關注。
- ✓最終目標： 用人腦的策略智慧與批判性思維，駕馭 AI 的分析與執行速度。
下載課程練習檔，搭配本頁的 EVM 與專案分析工具一起使用。
瀑布式專案計畫從章程、WBS、關鍵路徑到基準與變更，完整演練一份可核准的計畫。
敏捷式 Scrum 看板從 Product Backlog、Sprint 看板到燃盡圖與速率預測，跑完一個 Sprint。
PM 的價值不是幫團隊填更多表，而是幫組織更穩地把價值交出去。