Ch11 — 考前衝刺 Day 2 (253 min)

講師: Richard | 對應 PDF: — 影片: C:\Users\User\Desktop\PGMP Video\2026-05-10 09-06-40.mp4 回到 [[MOC-PgMP-精講筆記]]

產製方式: 章節切 3 段交給 3 個 agent 平行逐段精煉, 共 137 個 §N (Part A: §1-45, Part B: §46-85, Part C: §86-137).

Part A (00:00:33 - 01:25:40) 綜述

Day 2 上半天 Richard 把 Day 1 講過的「八大原則 + 協作績效域」放下，改用「橫向拉一遍 Standard 第7章與第8章」的方式幫考生重新組織知識結構。Richard 的核心邏輯是：標準書按「階段」縱向構建（定義/交付/收尾），但答題時要用「知識領域」橫向看才能準。前半段 (00:00 - 00:24) 拆解第7章核心活動的三個過程：建立基礎設施 (3P = Program Team / PMO / PMIS)、Program Delivery Management (只管元件增刪改)、Program Performance Monitoring & Control (主要看報告與預測)，並補上收尾的 knowledge transfer 和 final report 兩件事。中段 (00:24 - 00:38) 帶過第8章十個支援領域的階段對應與 Program Management Plan 的 14 個子計劃結構，並給出「階段關口看 PMP/收益管理計劃，過程中看資源/變更等子計劃」、「階段關口看績效報告，日常看狀態報告」這兩條超高頻答題判準。後半段 (00:38 - 01:14) 用「重要性星等」橫掃 10 個知識領域，重點落在財務 (兩星)、風險 (兩星)、資源/質量/採購 (一星)，財務管理講得最細：初始估算→估算→框架→計劃→管理→收尾的順序、Component 預算「上而下撥」而不是「下而上報」這個與實踐相反的考點、以及財務管理計劃裡的 Budget Baseline。最後 (01:14 - 01:25:40) 以 Q&A 收尾並啟動 EVM 主題，介紹 Earned Value Management 的歷史背景 (CSCSC) 與基本邏輯：基準 (baseline) 是經批准的計劃，正值方法用於把不同規模/不同行業的專案放在同一個衡量平面上。

§1 開場：階段隔離 + PgMP 思路答題 (00:00:33)

核心: 答題時把生命週期和戰略/收益/治理「分開思考」，不要揉成一團。

• Standard 把生命週期 (範圍/進度/財務/質量/資源/溝通/風險/採購/干係人/資訊/變更) 跟戰略、收益、治理刻意做了大量隔離
• 答題時也要先分開讀，不要混在一起
• 如果分不開就用 PMP 思路答範圍/進度，「也能做的七七八八」但不夠精準
• 第7章核心活動完全沿用第4版，今天只挑重點串
• 第8章換順序講：橫向以「變更管理從頭到尾怎麼做」、「範圍管理從頭到尾怎麼做」串

講師原話：「答題的時候，先不要把它揉在一起，把它分開，這樣的話你答起來會更容易。」

§2 第7章核心活動：前三個過程是 80-90% 考點 (00:02:33)

核心: 第7章五個過程裡，前三個 (基礎設施 / Delivery Management / Performance Monitoring) 涵蓋 80-90% 題目。

• 後兩個過程 (Program Transition、Program Closure) 題目很少，可以暫時 pass
• 三個過程其實邏輯都很簡單，只是名字長
• Richard 強調：時間有限的人只搞清楚這前三個就夠
• 後面 close 階段最容易考點是 knowledge transfer 和 final report 的關係

講師原話：「你就花時間把這三個過程搞明白，基本上涵蓋了 80% 到 90% 以上的題目。」

§3 第一個過程：建立 Program 基礎設施 = 3P (00:03:09)

核心: 第一個過程「建立專案級基礎設施」翻來覆去就是三個 P 開頭的東西。

• Program Team：專案級團隊（program manager 的核心參謀）
• PMO：專案級管理辦公室（基礎設施中最核心的能力）
• PMIS：專案級管理資訊系統（軟體+背後的政策/流程/規章制度）
• 「無形的」規則制度流程都包在 PMIS 的描述裡
• PMIS 不只是個軟體，背後一定是一套流程的集合體

PMI 術語: Program Team ↔ 專案級團隊 / PMO ↔ 專案級管理辦公室 / PMIS ↔ 專案級管理資訊系統

§4 Program Delivery：phase vs management 一字之差 (00:04:43)

核心: 帶不帶 management 決定它是「階段」還是「活動」，這個區分是高頻考點。

• Program Delivery (沒有 management) = 階段名稱，可以叫 program delivery phase
• Program Delivery Management (加 management) = 活動，發生在 program delivery phase 裡
• 兩者長得很像但概念不同，題目會故意混淆
• 整本標準看到「+management」就知道是動作/活動
• 沒有 management 就是個 phase

講師原話：「看它帶不帶 management，帶的話它就是個活動，不帶的就是個階段。」

PMI 術語: Program Delivery Phase ↔ 專案集交付階段 / Program Delivery Management ↔ 專案集交付管理（活動）

§5 Program Delivery Management 只做元件級變更 (00:05:46)

核心: 這個過程裡的「變更」全部是元件層級的，不碰範圍/成本/質量這種微觀變更。

• 在這個過程裡的變更 = 增加元件、停止元件、修改元件、終止元件
• 範圍/進度/成本的變更「他根本就一概都沒提」
• PgMP 的變更流程性比 PMP 弱很多，「不像 PMP 那麼強調流程」
• Program 要擁抱變化，所以變更管控不嚴格
• 考試碰不到「微觀範圍/成本/質量」變更題

講師原話：「它的變更全部都是元件，跟 PMP 當中那麼強的流程性，完全不一樣。」

§6 第三過程：Performance Monitoring 主要產出報告 (00:07:53)

核心: 第三個過程「專案級績效監督與控制」最重要的就是「績效報告」。

• 後來改名叫 Program Performance Management，把 controlling 和 monitoring 合一
• 它做的就是「比較計劃和實際的差別」
• 不關心具體的範圍/成本/質量內容，只關心整體績效
• 變更內容沒那麼清晰，但會輸出大量報告 (reports)
• 預測 (forecast) 也是這個過程的重要動作

講師原話：「它主要是報告的那一部分。一個是它的績效報告，第二個就是做預測，它一共是兩個。」

PMI 術語: Program Performance Monitoring & Control ↔ 專案級績效監督與控制 / Performance Report ↔ 績效報告

§7 Program Manager 與發起人是「越早確定越好」(00:10:24)

核心: Program Manager 在「定義階段的構建子階段」就要和發起人一起確定，而 Program Team / PMO 則晚一些（規劃子階段）。

• Program Manager + Sponsor → 構建子階段確定
• Program Team + PMO → 規劃子階段確定
• 強調發起人和 Program Manager 越早確定越好
• 「Initiate Program」這個過程在第4版被刪掉，因為和章程過程重複
• 所以整合過程現在是不完整的，少了「啟動」

PMI 術語: Formulation/Definition Phase ↔ 定義階段 / Planning Sub-phase ↔ 規劃子階段

§8 Program Team 不包括 Project Manager (00:13:22)

核心: Program Team 是 Program Manager 的「師部參謀」，Project Manager 是「下面的旅長」，不在 Program Team 裡。

• Project Manager 不屬於 Program Team
• Project Manager 的事 Program Manager「最好都不要管」
• 用軍隊比喻：Program Manager = 師長；Program Team = 師部參謀；Project Manager = 旅長 (在前線)
• 這個區分直接影響做題方向

講師原話：「軍隊裡面我是一個軍部或者是師部，師長周圍是不是有他自己的一班人嘛，有他的參謀，而專案經理就相對底下的。」

§9 Program Manager 何時介入 Project 層級事務 (00:14:14)

核心: Program Manager 介入 Project 事務只有兩種情形：突破升級門線、影響跨專案 / Benefit。

• 第一種：專案層面嚴重到突破升級標準 (escalation)，向上升級到 Program 層級
• 第二種：題目出現「影響到 program benefit」這個詞，立刻是 Program Manager 的事
• 跨專案間問題：兩個專案互相影響時，「不允許 Project Manager 自己協調」，Program Manager 必須介入
• 升級必須有標準，達不到標準不要升級
• 沒影響收益、沒影響其他專案 → 讓 Project Manager 自己解決

講師原話：「只要是兩個專案之間的事，不允許專案經理兩個人相互協調解決，你得介入，因為只要是跨專案的事，都談不上升級，那就是你專案級經理的事。」

PMI 術語: Escalation ↔ 升級 / Program Benefit ↔ 專案集收益

§10 Program Delivery Management 顆粒度全是元件級 (00:16:36)

核心: Program Delivery Management 的工作顆粒度全部是「專案/元件級」，不是範圍/進度/成本級。

• 啟動元件、關閉元件、移交元件、修改元件 → 都是這個活動
• 千萬不要把 Program Delivery Management 想得太寬泛
• 它「只管元件」這四個字要記牢
• 「不是範圍/進度/成本這種級別的」

§11 Program Performance Management 看輸出 (00:17:40)

核心: 績效管理過程的考點就在「輸出」(output)，不要去管裡面的細節步驟。

• 兩個輸出：1) 績效報告 (按計劃/沒按計劃做)、2) 預測
• 過程內動作都不重要，看輸出就夠
• 這跟 Delivery Management 相反 — Delivery 看「動作」(增加/減少/變更)，Performance 看「輸出」
• 第四第五個過程 (Transition、Closure) 不是考試重點

§12 Program Closure：知識移交 ≠ Final Report 內容 (00:18:48)

核心: Knowledge Transfer 是個動作，不是 final report 的一部分；兩者都是 closure 的活動但彼此不包含。

• 收尾的三個重點：最終報告 (final report)、知識移交 (knowledge transfer)、資源釋放
• 知識移交 = 把 program 的操作經驗、技能教給接收方，使他們能把 benefit 維持下去
• 「知識」不只是顯性 (文件)，還包括隱性 (操作經驗、skills)
• Transition 階段相當一部分指的就是這 — 把產品交給接收方 + 教會他怎麼用
• 考點：知識移交「不在最終報告裡」，是平行動作

講師原話：「最終報告他得有，知識移交其實就是技能移交，但是他倆之間，他不是互相的包含關係。」

PMI 術語: Knowledge Transfer ↔ 知識移交 / Final Report ↔ 最終報告 / Transition ↔ 移交（階段）

§13 第8章結構：3 大階段 + 1+10 個知識領域 (00:21:24)

核心: 第8章是「1 個整合活動 + 10 個分領域 (支援活動)」橫跨「3 大階段 (細分為7個子階段)」。

• 第7章 = Core Activities / 整合管理（總體）
• 第8章 = Program Activities / Program Supporting Activities（分領域）
• 3 大階段：定義 + 交付 + 收尾
• 細分 7 個子階段：定義 (構建 + 規劃)、交付 (組建授權與規劃 + 監督與整合 + 移交與關閉)、收尾 (移交 + 關閉)
• 10 個領域：變更、溝通、財務、資訊、採購、質量、資源、風險、進度、範圍
• 跟 PMP 主要差別：多了「資訊管理」(從溝通管理剝離)

PMI 術語: Program Activities ↔ 專案集活動 / Supporting Activities ↔ 支援活動

§14 構建子階段：所有活動都為了商業論證 + 章程 (00:25:36)

核心: 構建子階段裡的所有 10 個領域動作，都服務於「商業論證」和「專案集章程」這兩份檔案的生成。

• 所有動作收斂到兩個輸出：Business Case (商業論證) + Program Charter (章程)
• 先有商業論證，後有章程 (有先後關係)
• Roadmap 是「搗亂的東西」— 它和 Charter 的先後關係不固定，有 3 種變體
• 但 Business Case 和 Roadmap 的關係是固定的：先有商業論證，後有路線圖

講師原話：「load map 是一個搗亂的東西，給大家擾亂了你的知識結構... roadmap 跟 charter 的關係是不固定的。」

PMI 術語: Business Case ↔ 商業論證 / Charter ↔ 章程 / Roadmap ↔ 路線圖

§15 規劃子階段：所有規劃匯入 Program Management Plan (00:27:21)

核心: 規劃子階段的所有 12 個動作 (10 個領域規劃 + 額外幾個) 全部生成 Program Management Plan 的子計劃。

• 變更/溝通/質量/資源/...任何一個 _Planning 動作的輸出都是 _Plan
• 每個 Plan 都會變成 Program Management Plan 的子計劃
• 所以 Program Management Plan 是「集合體」
• 答題判準：題目只說某一個方面 (如資源)，不要選 Program Management Plan，要選 Resource Management Plan
• Program Management Plan 內容太廣泛，針對性不足

講師原話：「題目當中說了什麼，只說資源，那你就別選專案級管理計劃，你要選專案級的資源管理計劃。」

PMI 術語: Program Management Plan ↔ 專案集管理計劃（PMP，這裡指 Program 不是 Project）

§16 Program Management Plan 包括 14 份子文件 (00:29:43)

核心: Program Management Plan 是 14 份子計劃 (10 領域 + 收益管理 + 治理 + 干係人爭取 + Roadmap) 的集合。

• 10 個知識領域子計劃
• • Benefits Management Plan
• • Governance Plan
• • Stakeholder Engagement Plan
• • Roadmap (路線圖)
• = 14 個子文件

講師原話：「再加一個路線圖，路線圖也在其中，一共是十四個。」

PMI 術語: Benefits Management Plan ↔ 收益管理計劃 / Governance Plan ↔ 治理計劃 / Stakeholder Engagement Plan ↔ 干係人爭取計劃

§17 階段關口 vs Ongoing：兩套答案模型 (00:31:13)

核心: 階段關口 (stage gate) 看全域性檔案；日常 (ongoing) 看區域性檔案。

• 階段關口：必須看「最全的」計劃 → Program Management Plan；如果沒這個選項，就退選 Benefits Management Plan
• 階段關口的實際情況：首選「Performance Report」(績效報告)；次選「Benefits Register」(收益登記冊)
• Ongoing 日常：選 Status Report (狀態報告)；選具體領域的 Register
• 階段關口要看「全貌」，日常看「具體事」
• 收益登記冊是「區域性」的，所以階段關口次選

PMI 術語: Performance Report ↔ 績效報告 / Status Report ↔ 狀態報告 / Benefits Register ↔ 收益登記冊 / Stage Gate ↔ 階段關口

§18 Final Report 只用於最終結束 (00:36:01)

核心: 結束時用 Final Report，階段關口時用 Performance Report，兩者不能混用。

• Final Report = 整個 Program 結束時的最終報告
• Performance Report = 階段關口時的績效報告
• Status Report = 日常的狀態報告
• 結束時不要選 Performance Report 或 Status Report，必選 Final Report

§19 Program Delivery Phase 大量產生 reports (00:37:10)

核心: Program Delivery Phase 不只執行交付活動，更會產生大量報告給治理委員會看。

• 交付階段對應大量 monitoring & controlling 動作
• 所有專案級報告最終都要呈現給治理委員會 (Governance Board)
• 元件的「從生到死」都發生在 Program Delivery Phase
• Program Delivery Management 活動聚焦元件啟動/關閉/修改

§20 Program Closure：5 個動作分 3 類 (00:39:34)

核心: 收尾的 5 個動作分成 3 類處理：錢、資源、風險，三者都不能「不了了之」。

• 第一類：把錢的事處理完 (合同支付 + 財務報銷)
• 第二類：資源/資產 (resource release)
• 第三類：未消除的風險責任 (risk transition)
• 「五個動作分成了三類」這個結構有助於記憶
• 採購收尾跟錢有關，財務收尾要把該支付的支出去

§21 知識領域重要性星等 (00:40:53)

核心: 10 個知識領域不平等，重點按星等：財務 ★★、風險 ★★、資源/質量/採購 ★、其他幾乎不考。

• 變更管理：不是重點 (流程性弱)
• 溝通管理：不是重點，但有一個高頻考點 (Communication Plan 必在 Stakeholder Engagement Plan 之後)
• 財務管理 ★★：最重點、最難、跟實踐差別最大
• 資訊管理：不重點
• 採購管理 ★：有點重點 (RFQ/RFP/IFB)
• 質量管理 ★：一星
• 資源管理 ★：一星 (resource interdependency)
• 風險管理 ★★：題目最多
• 進度管理 + 範圍管理：不重點 (各只有3個動作)

講師原話：「重點是在這兒，在財務這裡，也是難點...風險的題目應該最多。」

§22 變更管理三動作 + Change Log (00:43:05)

核心: 變更管理就三個動作：評估 (構建) → 規劃 (規劃) → 監督控制 (交付)，輸出主要是 reports + change log。

• Assessment 動作的輸出叫 Assessment (動詞名詞同形)，內容納入商業論證/章程
• Planning 動作的輸出叫 Plan
• 監督控制全是報告或變更日誌 (change log)
• 這裡沒太多重點，知道對應關係即可

PMI 術語: Change Assessment ↔ 變更評估 / Change Log ↔ 變更日誌

§23 溝通考點：先 Stakeholder Plan 後 Communication Plan (00:44:27)

核心: 高頻考點 — 專案級溝通管理計劃必須在干係人爭取計劃之後才產生，再之後才是「爭取干係人」這個動作。

• 順序：Stakeholder Engagement Plan → Communication Plan → Engage Stakeholders (動作)
• 題目陷阱：問「Stakeholder Engagement Plan 完成了，下一步做什麼？」直覺會選「Engage Stakeholders」，正確答案是「制定 Communication Plan」
• Engage Stakeholders 的三個工具/動作：溝通、談判、衝突解決，全部依據 Communication Plan
• 「沒有溝通管理計劃的生成，你的溝通是不是都沒有一個參考」

講師原話：「下一步是制定溝通管理計劃，它比爭取干係人這個動作還要早。」

PMI 術語: Stakeholder Engagement Plan ↔ 干係人爭取計劃 / Engage Stakeholders ↔ 爭取干係人 / Communication Management Plan ↔ 溝通管理計劃

§24 Communication 三動作 + Information 兩子過程 (00:48:40)

核心: 溝通三動作 (評估 → 規劃 → 執行) 跟其他領域同構；Communication 強調動作，Information 強調載體。

• 溝通：先評估，再規劃，再執行 (但執行強調的是「做」而非「監督」)
• Communication 動作的結論變成 Information (檔案、錄音錄影、操作記錄)
• Information 兩個子過程：資訊釋出方法、彙報
• 跟 Communication 區別：Communication = 動作；Information = 載體/檔案

§25 財務管理：六步骤序列 (00:49:16)

核心: Program Financial Management 六步嚴格順序：初始成本估算 → 成本估算 → 財務框架 → 財務管理計劃 → 財務管理 → 財務收尾。

• 第1步 (構建子)：Initial Cost Estimation — 對應商業論證 (CBA / Cost-Benefit Analysis)
• 第2步 (規劃子)：Program Cost Estimate — 細化到具體數字
• 第3步 (規劃子)：Financial Framework — 建立融資框架 (錢從哪來：銀行/母公司/社會融資)
• 第4步 (規劃子)：Financial Management Plan — 框架的細化
• 第5步 (交付)：Program Financial Management — 真正管錢
• 第6步 (收尾)：Financial Closure — 結算收尾
• Initial 這個詞一出現就對應構建子階段

PMI 術語: Cost Benefit Analysis (CBA) ↔ 成本收益分析 / Financial Framework ↔ 財務框架 / Financial Management Plan ↔ 財務管理計劃

§26 Financial Framework：高頻時點考點 (00:53:35)

核心: 「專案級財務框架的制定發生在哪個階段？」答案 = 定義階段的規劃子階段。

• 框架建立過程會反過來修正先前的判斷 (商業論證、干係人爭取、溝通計劃都可能變)
• 不同出資人有不同訴求，會反向影響其他計劃
• 「資金到不了位」這種發現可能讓商業論證重新評估
• 但簡化記憶：建立 Framework 的輸出就叫 Framework

§27 Financial Plan 內含 Budget Baseline (00:55:05)

核心: Financial Management Plan 最重要的內容是 Budget Baseline / 財務基準 / 財務指標。

• 標準書這裡用「指標」，後面用「基準」，其實是同一概念
• Program Budget Baseline Update 發生在管錢過程中，因為實際情況會偏離計劃
• 兩種處理方式：1) 管住不超預算 2) 接受現實，更新基準
• 「財務指標 = 財務基準的核心內容」

PMI 術語: Program Budget Baseline ↔ 專案集預算基準 / Budget Baseline Update ↔ 預算基準更新

§28 財務管理高頻考點：自上而下撥款 (00:57:42)

核心: PgMP 考試的財務邏輯跟實踐相反 — Project 的預算是 Program「撥下去」的約束，不是 Project「報上來」的需求。

• 實踐中：Project Manager 跟 Program Manager 要錢
• PgMP 考試中：Program 給 Project 的錢叫 Cost Constraint，Project 必須在這個約束內完成
• 自下而上 (bottom-up) 報預算 = 不是 PgMP 思想
• 自上而下 (top-down) 管理 = PgMP 的標準路子
• 例題情境：你跟老闆要 1000 萬，他只給 800 萬，那你只能在 800 萬內完成
• Component Cost Estimate 必然落在 Program 撥的預算範圍內

講師原話：「他給了你多少預算，你專案幹多少活，或者他給你的錢叫約束，叫 cost constrain，你在它的約束之內，把你的專案做下去。」

PMI 術語: Cost Constraint ↔ 成本約束 / Component Cost Estimate ↔ 元件成本估算

§29 為何考試 vs 實踐相反：高層管理能力 (01:00:40)

核心: 大部分公司高階管理能力不足，靠基層上報；而 PgMP 標準是「高階能設定方向」的成熟組織模型。

• 實踐中靠下層報是因為高層看不清方向
• 體現在資金管理上 = 自下而上
• PgMP 標準假設高階有戰略屬性，能自上而下下達
• 這是公司戰略屬性強弱的體現
• 「導致大家可能答不對這方面題目的一個原因」

§30 Financial Closure：對外宣告凍結報銷 (01:02:55)

核心: 財務收尾不只是把帳算完，更要對外宣告「不能再報銷」，把資金活動凍結。

• 把整個 Program 的花費盤一盤，寫進 Final Report
• 對外宣告：所有費用不準再報銷
• 公司年底通知「2023 票據必須在 2024 年 X 月底前報銷完畢」就是類似邏輯
• 報銷成本 = Expenditure
• Program 資金活動的關閉 = 不準再發生費用

§31 資訊管理 + RFQ/RFP/IFB (01:03:46)

核心: 資訊管理沒重點；採購管理的考點是三類標書的差別。

• 資訊管理：評估 → 規劃 → 管理 (主要是檔案文件)
• 採購四步：估算 → 規劃 → 管理 → 收尾
• 三類標書：
• RFQ (Request for Quotation) = 要報價
• RFP (Request for Proposal) = 要技術 + 商務方案
• IFB (Invitation for Bid) = 投標邀請函
• 評標標準 = Proposal Evaluation Criteria
• 最終籤合同 = Sign Agreement，可以在 Program 級或 Project 級籤

PMI 術語: RFQ ↔ 報價請求 / RFP ↔ 提案請求 / IFB ↔ 投標邀請

§32 質量管理：Audit (過程) vs Inspection (物理) (01:05:20)

核心: 質量管理講得清楚 — 早期估算服務於商業論證 + 章程，計劃服務於 PMP；保證 vs 控制用不同工具。

• 早期 Quality Assessment：判斷 program 質量能否滿足要求，做不到就否決商業論證
• Program Quality Management Plan 變成 PMP 的子計劃
• Quality Assurance ↔ Audit (審計) — 看「過程」
• Quality Control ↔ Inspection (檢查) — 看「具體物理結果」
• 跟 PMP 邏輯一致

PMI 術語: Quality Assurance ↔ 質量保證 / Quality Control ↔ 質量控制 / Audit ↔ 審計 / Inspection ↔ 檢查

§33 Resource Interdependency Management (01:06:18)

核心: 資源管理裡唯一的考點是「資源依賴關係管理」，包含元件間依賴和資源間依賴兩類。

• 第一類：Program Component 間的 interdependency
• 第二類：資源之間本身的依賴關係 (A 用完才能用 B)
• 為什麼重要：資源無限時誰都能分配；要把資源用「好」必須關注 interdependency
• 收尾時資源要 release 回原組織單元 (來源部門)，由該部門再分配

講師原話：「資源管理的面更廣，資源依賴管理是更具體，如果要讓我選，我就首先選資源依賴管理。」

PMI 術語: Resource Interdependency Management ↔ 資源依賴關係管理 / Resource Released to Other Organization Element ↔ 資源釋放回組織單元

§34 Risk Management 五動作 + Risk Transition (01:08:02)

核心: 風險管理動作多但好記：初始評估 → 規劃 → 識別/分析/應對 (三合一) → 移交。

• Initial Risk Assessment 在構建子階段，服務於商業論證 + 章程
• 然後是 Risk Planning
• 然後是 Monitor and Control (代替「管理」這個詞)，內含三個小活動：
• 風險識別 (Identification)
• 風險分析 (Analysis - 定量/定性)
• 風險應對管理 (Response Management)
• 結束時新概念：Risk Transition = 風險管理責任從 Program 轉移到接收方
• 風險題目最多，要花時間

PMI 術語: Risk Transition ↔ 風險移交（管理責任轉移）/ Initial Risk Assessment ↔ 初始風險評估

§35 Schedule：Master Schedule vs Roadmap (01:08:20)

核心: Master Schedule 是 Roadmap 的「中低版本」，更細節，兩者必須隨時保持一致。

• Roadmap = high level
• Program Master Schedule = 中等層次
• Master Schedule 也算 high level planning，但比 Roadmap 細
• 「兩個檔案要隨時保持一致」是高頻考點

PMI 術語: Master Schedule ↔ 主進度計劃 / Roadmap ↔ 路線圖

§36 Program WBS：最多收兩層元件 WBS (01:09:52)

核心: Program WBS 要收元件 WBS，但「最多到前兩層」，再往下分就跟 Project Manager 搶活了。

• WBS = Work Breakdown Structure (工作分解結構)
• BBS = Benefit Breakdown Structure (收益分解結構，新概念)
• BDM = Benefit Dependency Map (收益依賴地圖)
• Program WBS 答題提醒：不要跟 Program Benefit 產生聯想
• WBS 是物理拆分，跟 Project 邏輯一致
• 真正在 Program 層發揮作用的是 BBS / BDM
• 「在專案級觀點當中，WBS 這條線非常弱」

PMI 術語: WBS (Work Breakdown Structure) ↔ 工作分解結構 / BBS (Benefit Breakdown Structure) ↔ 收益分解結構 / BDM (Benefit Dependency Map) ↔ 收益依賴地圖

§37 Scope Statement → WBS 順序 (01:11:30)

核心: Program Scope Statement → Program WBS，順序跟 PMP 一致。

• 先有 Program Scope Statement，再有 Program WBS
• WBS 分解的就是 Scope Statement，把它做細
• 不要想到收益，「一想收益就亂套了」
• 收益是獨立的一條線

PMI 術語: Program Scope Statement ↔ 專案集範圍說明書

§38 Q&A：複習指引 + 補充細節 (01:14:48)

核心: Richard 給時間有限的考生開複習單：財務最重要、其次風險、再到收尾 5 動作 + WBS + Master Schedule。

• 第一優先：財務（兩個動作 cost estimate / component cost estimate 是難點，先框架後規劃可合併）
• 第二優先：風險
• 第三優先：資源 / 質量 (相對輕鬆)
• 第四優先：收尾 5 動作
• 重點細節：WBS 兩層 + Master Schedule
• 資金來源識別 (Source Identification) 跟建立 Financial Framework 有關但實際提早做了

§39 Q&A：Resource Interdependency vs Resource Management 選哪個 (01:16:33)

核心: 題目情境若提到元件間資源依賴，優先選 Resource Interdependency Management，次選 Resource Management。

• Resource Management 包含 Resource Interdependency Management
• Resource Management 面更廣，Resource Interdependency 更具體
• 答題優先選具體 (Interdependency)，更精準
• 沒有具體選項才退選 Resource Management

§40 Q&A：Stakeholder Register 何時產生 (01:16:45)

核心: 干係人登記冊極早出現 — 在商業論證階段 (構建子) 就由發起人 (Sponsor) 維護。

• 早到構建子階段就有
• 由 Sponsor 負責維護
• 後續不斷重新整理

PMI 術語: Stakeholder Register ↔ 干係人登記冊

§41 EVM 起源：跨行業可比較的訴求 (01:17:45)

核心: 正值 (EVM) 來自二戰時期美國政府要求 — 跨行業/跨規模專案要能用統一格式比績效。

• EV 算成本「比較準」、算進度「不準」(因為時間不能直接相加，錢可以)
• EVM 在 ISO 標準和 PMI 標準裡都有獨立的標準
• 起源：Taylor / Gilbreth / Gantt 三位管理學家+實踐者
• 美國政府訴求：1000 萬專案偏差 10% 可能比 100 萬專案的損失還大，需要橫向比
• 原名 CSCSC = Cost Schedule Control System Criteria (成本進度控制系統的標準)
• 後來被簡稱為 EVM (Earned Value Management)

講師原話：「正值算成本是比較準的，算進度是非常不準的...因為錢是可以累加的，時間不是。」

PMI 術語: Earned Value Management (EVM) ↔ 正值管理 / CSCSC ↔ 成本進度控制系統標準

§42 EVM 命名邏輯：Earned + Value (01:21:00)

核心: 「正值」這個名稱直接來自最重要的引數 EV (Earned Value) — 掙得的價值。

• EV = Earned Value
• Earn 跟「掙錢」(earn money) 同字根
• 用最重要的引數命名整套方法，凸顯 EV 的核心地位
• EV 在所有 EVM 引數裡是最重要的

§43 EVM 原理：實際 vs 計劃 兩套資料對比 (01:22:14)

核心: EVM 原理就是「實際完成的工作 + 實際花的錢」對比「計劃完成的工作 + 計劃花的錢」。

• 計劃的進度 + 計劃的預算 = 一套
• 實際的進度 + 實際的預算 = 另一套
• 計劃通常「比較完美」(紙面上)
• 實際比較現實
• 兩套對比就是 EVM 的全部邏輯
• 計劃要有特定的稱呼

§44 Baseline = 比較的基礎 (01:23:38)

核心: 計劃經批准後就成為 Baseline (基準)，「基準 = 比較的基礎」。

• Plan 不等於 Baseline，必須經出錢/管資源的 stakeholder 批准
• Baseline = 「基準化」(Baselining) 之後的 Plan
• 兩週的專案要規劃到每一天 (進度 + 成本)，這樣每天都有對比基礎
• 計劃越細，能對比的時點越多
• 如果按月做計劃，月中任何一天都沒法對比 — 「沒有基準」
• EVM 必須建立在「規劃到天」這種顆粒度上才有意義

講師原話：「所謂基準化就是把我們做的計劃，讓出錢的、管資源的那些大佬們批准一下，批准完之後，這就成為了一個我們比較的基礎。基準的含義就是比較的基礎。」

PMI 術語: Baseline ↔ 基準 / Baselining ↔ 基準化

§45 EVM 計劃顆粒度的重要性 (01:24:59)

核心: 規劃顆粒度決定 EVM 能否運作 — 規劃到天才能任意一天對比，按月規劃只能月末對比。

• 兩套資料：計劃進度+成本、實際進度+成本
• 大量企業舉例：兩個月的專案，財務人員會要做預算
• EVM 是「特別樸素」的思想，但建立在「事先充分規劃」這個前提上
• 如果規劃不夠細 → 沒辦法用 EVM
• Part A 在這裡結束，EVM 細節留待 Part B

Part B (01:25:40 - 02:51:05) 綜述

這 85 分鐘 Richard 集中火力打兩座大山:EVM 掙值管理 與 風險管理。前半段 (01:25:40 - 02:03:00 約 38 分鐘) 用「兩個月 20 萬,第一個月花 15 萬卻幹完兩個月活」的悖論引入 EVM,把 PV/EV/AC/BAC/EAC/SPI/CPI 全套基本變數和公式從零推到能算題;核心觀點是「只有 EV 是要實測的,所有 EVM 公式必須含 EV,否則直接錯」。後半段 (02:03:00 - 02:51:05 約 48 分鐘) 進入風險管理,從「風險是中性詞」「風險三要素 (E+P+I) /四要素 (Cause+E+P+I)」「已知未知 vs 未知未知 vs 已知已知」「應急計劃 vs 應急儲備 vs 權變措施 vs 管理儲備」「風險態度 (Appetite/Tolerance/Threshold/Attitude)」一路講到 PMBOK 第 6 版風險管理 7 個過程 (規劃/識別/定性/定量/規劃應對/實施應對/監督) 與 PMI-RMP 5 過程的對照。Richard 的應試金句:「PgMP/PfMP/RMP 的風險概念完全一樣,差別只在實施對象;單一專案用範圍/進度/成本/質量,專案集用收益,組合用價值。」整段 EVM 與 Risk 都不靠死背公式,而是建立「為什麼要發明這個概念」的底層邏輯,讓考場上能反推。

§46 EVM 引入悖論:兩個月 20 萬,第一月花 15 萬卻把兩個月活幹完 (01:25:40)

核心: 只比較「花的錢 vs 預算」是錯的立足點,必須先看完成了多少工作 (進度),才能判斷有沒有真的超支。

• 第一個月應該花 10 萬,你花了 15 萬,財務第一反應是「成本超支」
• 但你實際把第二個月的活也都幹完了 → 表面超支,實際提前
• 「不能拿錢直接和錢比較,一定要看這個錢背後完成的工作」
• 這就是 Earned Value (掙值) 概念被發明出來的理由

講師原話: 「政治 (掙值) 它的立足點就是,我們不能夠直接把錢和錢做比較,一定要看這個錢背後完成的工作。」

PMI 術語: Schedule ↔ 進度 (含時間+工作量) ↔ Richard 強調「不是 time,而是 schedule」

§47 為什麼用 schedule 不用 time:工作量的概念才是進度 (01:27:30)

核心: time 是純時間流逝,schedule 同時含時間和工作量 → EVM 衡量的是「在這段時間裡幹了多少活」。

• time = 時間概念,schedule = 時間 + 工作量
• 講師強調: 「schedule 不僅僅是時間」,既有時間概念也有工作量概念
• 完成的工作百分比 = 進度 (不是時間流逝)
• 後面所有 PV/EV 的設計,都基於「工作量」這個基本變數

§48 EVM 四個基本維度:計劃/實際 × 工作量/單價 (01:29:00)

核心: EVM 的所有公式都從這四個基本量推導:計劃工作量 / 實際工作量 / 計劃單價 / 實際單價。

• 上方 (橫軸): 計劃工作量、實際工作量
• 左方 (縱軸): 計劃單價、實際單價
• 預算時可能一人天 500,實際雇人變 600 或 400 — 單價會浮動
• 工作量也會浮動 — 範圍變更、加班、提前完成
• 實際的招聘策略: 計劃單價做高一點,留安全邊際

PMI 術語: Planned Cost ↔ 計劃成本 / Actual Cost ↔ 實際成本

§49 PV (Planned Value) 計劃價值的定義 (01:30:50)

核心: PV = 計劃工作量 × 計劃單價,代表「計劃到此時間點應該完成工作的預算價值」,永遠是已知量。

• P = Planned, V = Value
• BAC (Budget at Completion) = 整個專案的總預算 = 所有 PV 加總
• 例: 兩個月各 10 萬 → BAC = 20 萬;到第一個月底 PV = 10 萬
• 「只要你把計劃做到那麼小的顆粒度,每一個時間點這個數都是已知的」

PMI 術語: Planned Value (PV) ↔ 計劃價值 / Budget at Completion (BAC) ↔ 完工預算

§50 AC (Actual Cost) 實際成本的定義 (01:32:50)

核心: AC = 實際工作量 × 實際單價,即「我實際做了這些工作,花的錢」,永遠是已知量。

• AC 是會計能算出來的數字 — 你花了多少錢自己肯定知道
• 但 AC 跟 PV 直接比沒意義 (錢和錢比缺工作量這個維度)
• 講師重複: 「AC 和 PV 這倆數根本就不能直接比較」

PMI 術語: Actual Cost (AC) ↔ 實際成本

§51 EV (Earned Value) 掙值的發明動機 (01:34:00)

核心: EV = 實際工作量 × 計劃單價 = 「我做完這些活,在我的預算體系裡值多少錢」,是 EVM 真正的核心橋接量。

• EV 把「實際完成的工作」放回「計劃單價」框架,化解 PV vs AC 的悖論
• EV 是唯一需要實測的變數 (PV 計劃時已定,AC 會計算得出)
• 講師: 「為什麼以掙值來命名這套方法?就是因為它是核心的量」
• 所有 EVM 公式都必含 EV — 沒 EV 就只剩 AC vs PV,一算就錯

講師原話: 「沒有 EV 這個公式根本就不會正確,因為沒有 EV 就變成了 AC 跟 PV 那種,它倆之間只要一算肯定就錯了。」

PMI 術語: Earned Value (EV) ↔ 掙值 / 實際完成工作的預算價值

§52 為什麼計劃單價要做高一點:預算戰術 (01:38:00)

核心: 做預算時把計劃單價做高一點 (甚至虛報工作量),實踐中手頭會寬裕很多 — 這是 EVM 表現出來的真實人性。

• 領導/甲方一定會往下砍計劃單價
• 砍得太低 → 實際單價 > 計劃單價 → 「你乾的越多,欠的越多」
• 反向操作: 預算單價高一點 → 實際雇人時錢還夠
• Richard: 「這個特別佛甦的道理」(俚語,意指這個道理過來人才懂)

§53 SPI 進度績效指數的推導 (01:40:00)

核心: SPI = EV / PV,本質上等於實際工作量 / 計劃工作量 (因為單價約掉)。SPI > 1 進度超前,< 1 進度落後。

• EV 和 PV 共用「計劃單價」 → 相除時計劃單價約掉 → 剩下實際工作量比計劃工作量
• 實際完成工作量比計劃多 → 進度超前 → SPI > 1
• SPI 看的是「跟 1 的關係」,不是看絕對值

PMI 術語: Schedule Performance Index (SPI) ↔ 進度績效指數

§54 CPI 成本績效指數的推導 (01:43:30)

核心: CPI = EV / AC,本質上等於計劃單價 / 實際單價。CPI > 1 成本節約,< 1 成本超支。

• EV 和 AC 共用「實際工作量」 → 相除時實際工作量約掉 → 剩下計劃單價比實際單價
• 計劃單價 > 實際單價 → 你預算做高了實際更省 → CPI > 1
• C = Cost, P = Performance, I = Indicator/Index

PMI 術語: Cost Performance Index (CPI) ↔ 成本績效指數

§55 SPI 與 CPI 的考試判讀技巧 (01:46:30)

核心: SPI/CPI 是比值,只要記住「跟 1 的關係」即可:= 1 剛好,> 1 好,< 1 壞 (對成本是超支,對進度是落後)。

• SPI = 1 → 剛好按計劃進度
• SPI > 1 → 進度超前;SPI < 1 → 進度落後
• CPI = 1 → 剛好按預算花;CPI > 1 → 成本節約;CPI < 1 → 成本超支
• 差值 (SV、CV) 對應的是「跟 0 的關係」(節省的時間/錢是正值)

§56 EVM 三條 S 曲線:PV/EV/AC 在圖上的相對位置 (01:50:00)

核心: 三條線都呈 S 型 (執行階段花錢/做事速率最快),從相對位置可一眼判讀進度與成本表現。

• 累積花費呈 S 曲線:啟動慢、執行快、收尾慢
• EV 在最下面 → 跟誰比都小 → SPI < 1 且 CPI < 1 → 進度延誤 + 成本超支
• 考試會給類似圖,讓你判讀此時專案是好是壞
• 一旦前面出現延誤+超支,「原理上後面永遠趕不回來」(除非用快速跟進)

§57 EVM 例題:增量值 vs 累積值的讀圖方法 (01:51:30)

核心: 看 EVM 圖時注意數字是「增量值」還是「累積值」— 增量是當月新增,累積是到該時點總和。

• 例: 計劃第一月 91、第二月 142、第三月 88 (增量)
• 累積: 第一月 91、第二月 233、第三月 321
• 藍色預算柱永遠已知,紅色 (AC) 與綠色 (EV) 進行中才陸續知道
• 第三個月時間還沒到 → 那兩柱還沒有

§58 一旦延誤超支就回不來:除非快速跟進 (01:53:30)

核心: 專案前期出現延誤+超支,要趕進度只能加人加錢 (趕工),但這會讓成本進一步超支 → 死循環。唯一解法是改變工作順序 (快速跟進)。

• 趕工 (Crashing) = 加人加錢加資源 → 成本必然進一步上升
• 快速跟進 (Fast Tracking) = 改變工作順序 → 不加錢不加人也能搶回進度
• 這是 PMP 考點延伸,PgMP 也常用同邏輯
• Richard: 「除非你是高手,你不用這種加人加錢的方式」

PMI 術語: Crashing ↔ 趕工 / Fast Tracking ↔ 快速跟進

§59 EVM 公式表的考試重點:只記三個就夠 (01:55:00)

核心: 表上一堆公式很煩人,但考試重點只有 CPI、SPI、EAC = BAC/CPI 三個。

• 必記: SPI = EV/PV、CPI = EV/AC
• 第三個重點: EAC (Estimate at Completion) 估算公式
• 「就這個公式把它記住,後面都好辦」
• 所有公式必含 EV,缺 EV 就一定錯

§60 EAC 完工估算的概念 (01:55:30)

核心: EAC = 基於目前表現,預測完成整個專案最終要花多少錢。它不是規劃時的 BAC,是執行中重新估算。

• BAC = 完工預算 (Budget at Completion,規劃時定下)
• EAC = 完工估算 (Estimate at Completion,執行中根據實績重算)
• 前面延誤超支 → 預期 EAC > BAC
• 「完工估算一定是基於我們做了一段時間,有了過去的資料和趨勢」

PMI 術語: Estimate at Completion (EAC) ↔ 完工估算 / Budget at Completion (BAC) ↔ 完工預算

§61 EAC 公式變體:典型偏差用 BAC/CPI (01:58:00)

核心: EAC 的多個公式對應不同假設,最常見:EAC = BAC / CPI (假設後面照當前 CPI 趨勢繼續)。

• 公式 1: EAC = BAC / CPI (典型偏差,後面繼續按目前 CPI 表現)
• 公式 2: EAC = AC + (BAC − EV) (非典型偏差,後面按預算速率)
• 公式 3: EAC = AC + ETC (一般式,要 ETC 自己估)
• ETC (Estimate to Complete) = 剩下的工作還要花多少錢
• VAC (Variance at Completion) = BAC − EAC,預測會超預算多少

PMI 術語: Estimate to Complete (ETC) ↔ 完工尚需估算 / Variance at Completion (VAC) ↔ 完工偏差

§62 EVM 在 PgMP 考試的位置:基本不考但底層邏輯要懂 (02:03:00)

核心: PgMP 基本不考 EVM 公式計算,但要懂「掙值是基於過去趨勢預測未來」的邏輯,這跟收益管理思路相通。

• Richard: 「在 PG 當中不會考,太複雜了;在 PMP 當中考的時候也極少」
• 但前面講的所有概念都建議反覆理解
• PMI 系列 (PMP/PgMP/PfMP/RMP) 之間關聯度未來會越來越高
• 後面學 PfMP 時,PgMP 知識短板會是麻煩 — 要打底

§63 風險管理開場:風險是中性詞 (02:06:00)

核心: PMP/PgMP/PfMP/RMP 四個認證對風險的定義完全一樣 — 風險是中性詞,負面叫威脅 (Threat),正面叫機會 (Opportunity)。

• 一說「風險 / risk」就是中性,不帶情緒
• 負面風險 = 威脅 (Threat)
• 正面風險 = 機會 (Opportunity)
• 風險管理目的: 降低消極風險的機率與影響,提升積極風險的機率與影響
• 雙向都要管,不只防守

講師原話: 「風險是一箇中性詞語,這個大家要特別清楚。」

PMI 術語: Risk ↔ 風險 (中性) / Threat ↔ 威脅 / Opportunity ↔ 機會

§64 風險的兩大內嵌特徵:不確定性 + 對目標有影響 (02:08:30)

核心: 風險定義有兩個必要條件:(1) 內嵌不確定性 (機率) (2) 一定指向目標,對目標有影響。沒對目標有影響的不算風險。

• 第一層: 風險 = 不確定性 + 可能性,確定的東西不叫風險
• 第二層: 一定影響專案/專案集/專案組合的目標
• 專案目標 = 範圍 + 進度 + 成本 + 質量
• 專案集目標 = 收益 (Benefit)
• 專案組合目標 = 價值 (Value)
• 同一個事件對不同層級可能不算風險 (如果不影響該層目標)

§65 風險描述的格式:三要素 vs 四要素 (02:11:00)

核心: 描述風險本身就難,所以要統一格式。三要素 = 事件 + 機率 + 影響 (E+P+I);四要素 = 原因 + 事件 + 機率 + 影響 (Cause+E+P+I)。

• 三要素: Event + Probability + Impact (常見、簡潔)
• 四要素: Cause + Event + Probability + Impact (前面加風險原因)
• 描述格式不統一 = 大家對風險理解就不一致 → 反而放大風險本身
• 「描述風險本身就是一件很困難的事情」 → 必須先建立統一描述

PMI 術語: Cause + Event + Probability + Impact ↔ 風險四要素

§66 風險暴露值 = 機率 × 影響 (02:13:00)

核心: 從計算角度,風險的優先級 = 機率 × 影響 = 風險暴露值 (PI 值)。乘積越大等級越高,放在機率影響矩陣的深紅區。

• 風險暴露值 (Risk Exposure) = P × I
• 也叫 PI 值
• 高機率 + 高影響 → 機率影響矩陣的深紅色區 → 高等級風險
• 低機率 + 低影響 → 淺色區 → 低等級風險
• 後面所有風險分級、應對策略選擇,都從這個結構衍生

PMI 術語: Risk Exposure ↔ 風險暴露值 / Probability × Impact ↔ 風險等級

§67 已知未知 vs 未知未知:風險可管理的邊界 (02:15:00)

核心: 兩個「知/不知」分別指事件 (E) 和機率影響 (P/I)。已知未知 = 事件知道但機率影響不確定 (可管理);未知未知 = 事件都不知道 (只能事後處理)。

• 第一個字: 事件 (E) 是否已知
• 第二個字: 機率 + 影響是否已知
• 已知-未知: 事件知,機率影響不知 → 風險管理的主戰場
• 未知-未知: 事件都不知 → 簡稱「未知風險」,只能 walkaround
• 已知-已知: 事件機率影響都知 → 嚴格說不算風險,該變成專案活動

§68 應急計劃 vs 權變措施:時機差別決定本質 (02:16:30)

核心: 應急計劃 (Contingency Plan) 是提前制定的方案;權變措施 (Walk-around) 是事後臨時想辦法。對應的是「已知未知」與「未知未知」兩類風險。

• 應急計劃 = 提前制定 = 對應「已知未知」風險
• 權變措施 = 臨時想辦法 = 對應「未知未知」風險
• 中文「應急」容易讓人誤解為臨時 — 不對,應急 = 提前準備好應對方案
• 講師強調: 「應急不是臨時,是拿一筆錢放在那」

PMI 術語: Contingency Plan ↔ 應急計劃 (提前) / Workaround ↔ 權變措施 (臨時)

§69 應急儲備 vs 管理儲備:錢時間從哪出 (02:18:30)

核心: 應急儲備 (Contingency Reserve) 配對應急計劃,屬於專案經理權限;管理儲備 (Management Reserve) 對應未知風險,屬於組織財務權限。

• Contingency Reserve = 為已知未知風險預留的錢/時間/物資
• Management Reserve = 為未知未知風險預留 (公司財務動用)
• 應急儲備 PM 可動,管理儲備 PM 不可動
• 儲備不只是錢,時間餘量、物資 (糧食) 都算

講師原話: 「全變動用的資金和時間,那是公司財務留的,叫管理儲備。」

PMI 術語: Contingency Reserve ↔ 應急儲備 / Management Reserve ↔ 管理儲備

§70 已知已知不算風險:該直接變成專案活動 (02:21:00)

核心: 事件、機率、影響都知道的「已知-已知」,理論上已不算風險 — 你應該直接把它做成專案計劃裡的活動,不要再等它發生。

• 都知道會發生,知道影響 → 「還等什麼,趕緊做成專案活動」
• 把它放到 WBS 和進度計劃裡 — 這就是預防最徹底的辦法
• 對應的處理叫「應對措施」(Response),不再叫應急
• 衍生出: 椅子位置類風險 (一椅 = 事件,位置 = 機率/影響)

§71 風險無處不在:核心觀念三步出發 (02:22:30)

核心: 三步建立風險認識 — (1) 風險是中性 (2) 描述用三/四要素 (3) 機率影響構成等級。掌握這三步,後面所有風險術語都好懂。

• 第一步: 風險 = 中性詞語
• 第二步: 描述格式 = 事件 + 機率 + 影響 (+原因)
• 第三步: 機率 × 影響 = 風險等級 → 衍生一系列術語
• 「只要把底層的東西搞清楚,後面都特別容易」

§72 整體風險 vs 單個風險 (Overall vs Individual) (02:24:00)

核心: 單個風險 (Individual) 影響單一目標元素;整體風險 (Overall) 是系統性風險,影響整個體系。

• 單個風險: 影響進度的單一要素 (即使構成元素多個)
• 整體風險 = 系統性風險,免疫系統壞了所有系統都壞
• 比喻: 身體免疫系統垮 → 血液/神經/運動/消化全部受波及
• 在專案集 (Program) 層面,組件之間依賴關係越多,整體風險越難處理 → 雪崩效應/漣漪效應/混沌效應 (chaos)

PMI 術語: Overall Risk ↔ 整體風險 / Individual Risk ↔ 單個風險

§73 風險態度的四個概念:Attitude 含 Appetite/Tolerance/Threshold (02:26:30)

核心: Attitude (態度) 是大概念,內含 Appetite (偏好,主觀)、Tolerance (承受力,極值)、Threshold (臨界值,理性值)。

• Attitude = 風險態度 (大傘)
• Appetite = 風險偏好 (主觀,難量化)
• Tolerance = 風險承受力 (組織能承受的最大值,極值)
• Threshold = 風險臨界值 (基於經驗設定的觸發點,介於極值之間)
• 四個英文詞: Attitude / Appetite / Tolerance / Threshold

PMI 術語: Risk Attitude / Appetite / Tolerance / Threshold ↔ 風險態度/偏好/承受力/臨界值

§74 PgM 核心工作:把主觀偏好轉成客觀臨界值 (02:28:30)

核心: 專案/專案集/組合經理最重要的工作之一,就是把重要干係人和組織的「主觀風險偏好」轉化為「客觀的臨界值與承受力」(可量化)。

• 偏好 = 主觀感性,難量化
• 不能量化 = 不能管理
• PM/PgM/PfM 要不斷試探,把組織能承受的損失量化成數字 (時間/資金/人頭數)
• 臨界值是觸發條件:碰到就採取行動,不要等到承受力極限
• 「臨界值的存在意義就在於,如果比臨界值低就在區間內,我可以不管 (接受);如果超過了上限或低於下限,就必須採取行動」

講師原話: 「臨界值是個理性值,承受力是個最大值,偏好是個主觀值,這是它們的區分。」

§75 韌性 (Resilience):安全空間越大越能扛 (02:34:00)

核心: 個人和組織的韌性 (Resilience) = 受外界衝擊後能恢復原狀的能力。安全空間越大 (現金、餘量、時間),韌性越足。

• 「為大機率事件堅持,為小機率事件做好準備」
• 韌性 = 抗衝擊能力 + 恢復能力
• 安全空間具體例子: 現金儲備、時間餘量、物資儲備
• 這是 Richard 的個人風險管理建議,引申到生活理財層面

§76 PMBOK 第 6 版風險管理 7 過程 (02:36:00)

核心: 7 個過程依序為:規劃風險管理 → 識別風險 → 定性分析 → 定量分析 → 規劃風險應對 → 實施風險應對 → 監督風險。

1. 規劃風險管理 (Plan Risk Management): 確定風險管理策略、方法、分工、決策機制
2. 識別風險 (Identify Risks)
3. 實施定性風險分析 (Perform Qualitative Risk Analysis)
4. 實施定量風險分析 (Perform Quantitative Risk Analysis)
5. 規劃風險應對 (Plan Risk Responses)
6. 實施風險應對 (Implement Risk Responses)
7. 監督風險 (Monitor Risks)

PMI 術語: Risk Management 7 Processes ↔ 風險管理七過程

§77 識別風險的核心原則:三越 (02:38:00)

核心: 識別風險「三越」:越早越好、越全越好、參與的人越多越好。不是只有團隊識別,而是全員 + 干係人。

• 越早識別越好 (時間維度)
• 越全面識別越好 (覆蓋維度)
• 參與的人越多越好 (人員維度)
• 不只團隊成員 — 是「所有跟專案有關的人」
• 組織層面要有風險庫 / 風險清單,可降低從零開始的成本

§78 風險登記冊的最簡格式 (02:39:30)

核心: 最簡風險登記冊 = 編號 + 事件 + 機率 + 影響 + (擴充: 原因/緊迫程度/責任人/等級/應對措施)。

• 必填: ID + Event + Probability + Impact
• 擴充: Cause / Urgency / Owner / Rate / Response
• 「參數越多,其實越不好理解;參數少越容易,但可能不全面 — 所以是個平衡」
• 加一個風險編號方便後續追蹤

PMI 術語: Risk Register ↔ 風險登記冊

§79 定性 → 定量的順序與篩選關係 (02:41:00)

核心: 必先定性後定量。所有識別的風險都要做定性分析給高中低等級;只有「等級高」且「有條件量化」的才走定量。

• 定性風險分析 = 主觀判斷,給每個風險高/中/低
• 定量風險分析 = 客觀計算,需要數據
• 兩個進入定量的條件: (1) 等級比較高 (2) 具備量化條件
• 它們是「協作關係」,不是平行關係

PMI 術語: Qualitative ↔ 定性 / Quantitative ↔ 定量

§80 規劃應對 vs 殘餘風險 vs 次生風險 (02:43:00)

核心: 規劃應對時要假定應對計劃被執行後,會殘留哪些風險 (Residue) 和產生哪些新風險 (Secondary),並對它們也做應對計劃 — 但會在某個層級停下來。

• 殘餘風險 (Residual Risk): 應對措施執行後仍剩餘的部分
• 次生風險 (Secondary Risk): 應對措施本身引發的新風險
• 這些都要在規劃階段預先分析
• 可以可接受程度為止 — 不必無限往下展開

PMI 術語: Residual Risk ↔ 殘餘風險 / Secondary Risk ↔ 次生風險

§81 風險 vs 問題的本質區別:時序不同 (02:46:00)

核心: 風險 = 假定還沒發生,提前做計劃;問題 = 已經發生,事後處理。風險管理的所有動作都是「提前做好」。

• 風險: 提前 → 有備無患
• 問題: 事後 → 救火
• 「風險全部都是假定它會發生,我要怎麼做;問題都是已經發生了,你要怎麼做」
• 後面所有邏輯都不一樣

講師原話: 「風險管理的動作全都是提前做好的,發生了你才有備無患。」

§82 職場潛規則:處理問題 vs 處理風險哪個被認可 (02:47:30)

核心: 現實中組織更認可「處理問題的人」(看得見功勞);但真正高手是「處理風險的人」 — 讓問題消失於無形,卻無人看見。

• 引「善戰者無赫赫之功」(《孫子兵法》)
• 「井田制」古文比喻: 中間沒人耕種好的地都種不好,因為都不是自己的事
• Richard 的真實體會: 處理風險的價值最大,但組織難以衡量
• 對個人事業: 「那一定是風險消失於無形的人,你價值最大」

§83 規劃風險應對 → 進入監督狀態 (02:49:00)

核心: 規劃完應對後不是直接執行,而是「進入監督風險的狀態」— 隨時觀察,風險苗頭出現才啟動應對。

• 規劃應對 → 監督風險 (等候)
• 監督期間發現苗頭 → 啟動應對計劃
• 沒發生 → 把該風險和預案從登記冊刪除
• 5 (定量) 和 6 (規劃應對) 的順序固定;6 (規劃應對) → 7 (監督) → 實施應對 才是真正執行流

§84 啟動應對要走變更請求:應急計劃變專案活動 (02:50:00)

核心: 啟動應急計劃時不能直接執行,要走變更請求 (Change Request),把計劃裡的時間、資源變成專案活動才能用。權變措施 (walk-around) 不需走變更,直接執行。

• 應急計劃 → 提變更請求 → 批准 → 變成專案活動 → 執行
• 權變措施 → 臨時起意,直接做,事後可能補流程
• 規劃應對的責任人 ≠ 實施應對的責任人 (常常分開)
• 比喻: 消防演練計劃不是你定的,但你是執行者

PMI 術語: Change Request ↔ 變更請求

§85 RMP vs PMBOK 6:七過程合併為五過程的對照 (02:50:50)

核心: PMI-RMP 把 7 過程合併成 5 過程 — 定性+定量合為「分析」、規劃應對+實施應對合為「應對」,加一個「關閉風險」收尾。

• RMP 5 過程: 風險策略與規劃 / 風險識別 / 風險分析 / 風險應對 / 監督與關閉
• PMBOK 6: 規劃 / 識別 / 定性 / 定量 / 規劃應對 / 實施應對 / 監督
• 邏輯一模一樣,只是分組不同
• PgMP/PfMP 風險概念跟這些都通,差別只在實施對象 (專案 vs 專案集 vs 組合)

講師原話: 「邏輯是一模一樣的,只是你風險管理的物件不同。」

PMI 術語: PMI-RMP 5 Processes ↔ 風險管理專業人士五過程

Part C (02:51:05 - 04:12:26) 綜述

本段是 Day 2 衝刺的最後 81 分鐘,跨越兩個獨立 session: (1) 風險管理收尾 (約 16 分鐘,延續 Part B);(2) 敏捷補充 (約 65 分鐘,獨立小節,以 11:21:7s 處 Richard 重新打招呼「大家晚上好」為起點)。

風險段落聚焦於規劃風險應對的「四要素三步驟」(應急計劃 → 預警訊號 → 突發條件 → 預算/時間估算)、風險策略 5+5 (威脅:迴避/轉移/減輕/接受/上報;機會:提高/分享/開拓/接受/上報) 及「迴避針對事件、減輕針對機率與影響」這個高考點;並以地震為例說明「機率失控時只能降低影響」。Richard 反覆強調「PgMP 風險管理不要侷限在 team 層面,要 stakeholders 都拉進來」。

敏捷段落是全 Day 2 最重的補充課:從敏捷起源(2001 年宣言、原為輕量級管理)、四大價值觀 + 12 原則、預測/迭代/混合三型,進到「敏捷鐵三角:範圍進度成本是約束,價值與質量才是目標」這個與 PgMP 收益思維最相通的概念。中段重點解 Scrum 3-5-3 框架(三角色 Scrum Master/PO/Team、五會議規劃/日站/評審/回顧/出資、三產出 product backlog/sprint backlog/increment)、看板拉動式生產與 WIP 限制、80 小時原則(2 週 = 一個迭代)、DoD 完工定義、敏捷在範圍/進度/成本/質量/資源/溝通/採購/風險各 KA 的對映。

最後 7 分鐘的考場策略總結三個重點: (1) 敏捷不僅是快,核心是「對變化敏感並做出應對」(reactive/adaptive); (2) PgMP 考敏捷以提幹「詞語認得就行」、不深考實踐; (3) 唯一與 PgMP 高度結合的是「專案級的範圍也是靈活的」。並以學員提問「敏捷需要明天的結像在哪裡定義?」收尾,Richard 回答:敏捷其實不太關心「結像 vs 不結像」,反正每次做的都是優先順序最高的事——與 PgMP 收益實現的「範圍可以讓位」哲學完全呼應。最終以「謝謝大家」結束整個 Day 2 衝刺。

§86 風險高低分級與類別 (02:51:05)

核心: 風險識別後,要按嚴重度分級(高/中/低)、按類別歸類(商務/物流/自然環境)、再加 Urgency 緊迫性。

• 100-90 分稱「超高等級」,90 以下分 P (Probability) × I (Impact) 的高/中/低
• 高等級風險 → 要制定預備措施;低等級 → 觀察就好不用管
• 機率 × 影響之外,可加 U (Urgency 緊迫性) 作為第三維度
• 風險類別: 商務類、物流類、自然環境類、組織環境類

PMI 術語: Urgency ↔ 緊迫性,Richard 縮寫為 U

§87 應急計劃與彈回計劃 (02:52:00)

核心: 高等級風險不止一個方案,要備有應急計劃 + 彈回計劃,還要分析殘餘與次生風險。

• 應急計劃: 風險發生後啟動的方案 (一般是 1 個)
• 彈回計劃 (fallback plan): 應急計劃實施後若無效,下一個備案
• 殘餘風險: 應對之後仍剩下的部分
• 次生風險: 應對行動本身引發的新風險
• 對重大風險不能等發生才啟動,要按嚴重程度與臨界值決定要不要進一步應對

講師原話: 「有了應急還不夠,一旦這應急計劃實施之後,發現效果不好或者說無效,還要有彈回計劃。」

PMI 術語: Fallback Plan ↔ 彈回計劃 ; Residual Risk ↔ 殘餘風險 ; Secondary Risk ↔ 次生風險

§88 預警訊號與突發條件 (02:53:30)

核心: 即使風險未發生,也要在登記冊中寫明「預警訊號」與「觸發條件」,提前 2-5 天啟動應對。

• 雖然有應對計劃,但有時可以提前知道風險訊號(自然環境、網路狀態)
• 把預警訊號寫在風險登記冊裡:「明天 12 點之前一定會出現這種事」
• 預設「突發條件」(觸發條件) → 一旦觸發直接啟用應對計劃
• 為這些預設行動做好預算與時間估計
• 一旦觸發 → 把預算拿出來、時間讀進行動計劃

講師原話: 「預警訊號是什麼,都要在我的登記者網路把它寫明白。」

PMI 術語: Warning Signs ↔ 預警訊號 ; Trigger Condition ↔ 觸發條件/突發條件

§89 規劃風險應對是難度最高的過程 (02:55:00)

核心: 規劃風險應對是整個風險管理過程裡難度最高的,前面所有分析都要在這裡產生方案。

• 前面所有的分析(識別、定性、定量),最終都要在「規劃應對」這收斂成一個方案
• 你可以選擇不管它,但你必須知道它的嚴重程度
• 北京前年 7.31 暴雨 = 沒辦法案例 (你計劃沒有,也沒想到那麼大)
• 正常下雨 = 提前啟動案例 (汛期前地鐵會放沙包)
• 不一定非得是發生之後才開始,可以提前啟動

講師原話: 「規劃風險應對,應該是整個風險管理過程當中,難度最高的一個。」

§90 風險規劃要拉相關方進來 (02:56:30)

核心: 規劃風險用到「相關方登記冊、訪談、人際關係」三組工具,風險管理千萬不要侷限在 team 層面。

• 規劃風險的工具: 相關方登記冊 + 訪談 + 人際關係 + 影響力
• 監督的時候用: 經驗教訓 + 風險登記冊
• 我參與寫第七版,他不是隱含,他就告訴你「風險管理要讓所有人都參與進來」
• Team 只是你直接管理的人,Stakeholders 包含很多非團隊成員
• PgMP 考題很多用 stakeholders,而不是 teams

講師原話: 「風險管理千萬不要侷限在 team 層面,團隊只是你自己可以直接管理的那些人,而我們這說的相關方叫 stakeholders。」

PMI 術語: Stakeholders ↔ 相關方 (有別於 Team 團隊)

§91 風險應對策略 5+5 (02:57:30)

核心: 風險應對策略一共 10 種 = 威脅 5 + 機會 5,其中接受、上報是兩者共有的。

• 威脅(壞風險)5 種: 規避(回避)、轉移、減輕、接受、上報
• 機會(好風險)5 種: 提高、分享、開拓、接受、上報
• 接受 + 上報 = 兩邊都有 (共 4 個)
• 看到「規避/轉移/減輕」→ 是針對威脅
• 看到「提高/分享/開拓」→ 是針對機會
• 這些詞背後都告訴你它是好的還是壞的

講師原話: 「五加五,一共是十種。」

PMI 術語: Avoid/Transfer/Mitigate/Accept/Escalate ↔ 規避/轉移/減輕/接受/上報 ; Exploit/Share/Enhance/Accept/Escalate ↔ 開拓/分享/提高/接受/上報

§92 迴避 vs 減輕 - 對象不同 (02:58:30)

核心: 迴避是「100% 把事件幹掉」針對事件本身;減輕是針對「機率與影響」。這是高頻考點。

• 迴避(回避) Avoid: 一定是針對事件,把事件 100% 幹掉,才叫回避
• 減輕 Mitigate: 不是針對事件,而是針對機率跟影響
• 減輕的對象 = 機率 + 影響,不是事件
• 這個區別在做題時極重要

講師原話: 「規避或者叫回避,一定是針對事件的,百分之百把這個事件給我幹掉,這才叫回避。」

§93 地震例:災難只能降低影響 (02:59:30)

核心: 地震發生機率不是 100%,但人類無法降低其機率,只能在「災後降低影響」。

• 地震不是 100% 發生 → 屬於風險
• 你能不能迴避地震?除非旅行可以躲開,但發生在你所在地方就無法
• 地震、洪水都是「災後減少它的影響」,因為機率完全失控
• 地震只能提前 3-5 秒預測,「沒有什麼意義」
• 結論: 「在機率和事件上做文章是沒辦法的」→ 只能接受 + 把影響降到最低
• 一般地震策略都在「降低影響」上

講師原話: 「地震這種風險,一般它的策略都是在降低影響上,因為對機率和對事件,你都無能為力。」

§94 十策略 + 應急/彈回/儲備 全家福 (03:01:00)

核心: 風險全部知識點 = 10 策略 + 應急/彈回計劃 + 應急/管理儲備 + 已知未知/未知未知 + 三/四要素 + 七過程。

• 10 個應對策略
• 應急計劃 (Contingency Plan) + 彈回計劃 (Fallback Plan)
• 應急儲備 (Contingency Reserve) + 管理儲備 (Management Reserve)
• 已知未知 = 已識別風險 / 未知未知 = 沒識別到的風險
• 風險的三要素 / 四要素方法
• 加上前面講的 7 個過程 → 「風險的全部東西大家都應該一切盡在掌握」

PMI 術語: Contingency Reserve ↔ 應急儲備 (應對已知未知) ; Management Reserve ↔ 管理儲備 (應對未知未知)

§95 PgMP 風險管理講得亂,但要回到第六版概念 (03:01:30)

核心: PgMP 標準把風險管理講得「一個亂」,但構成要素沒變,做題要回去用 PMBOK 第六版的清晰概念。

• PgMP 標準裡的「初始風險評估」 = 對應 PMBOK 的風險偏好變成臨界值
• PgMP 4 步驟(Standard 第四版風格): 初始評估 → 規劃 → 監督控制 → 移交
• 但 Richard 認為 PgMP 把「風險識別/分析/應對」放到監督裡是不對的
• PgMP 考試「不會考你一個過程下一個過程是什麼」,基本全是概念題
• 這個概念你放到 PMBOK 第六版裡去,把它理清楚,在這你就應用它就行

講師原話: 「在專案級管理考試當中呢,風險它不會考你一個過程下一個過程是什麼,它不考這個,基本全是概念。」

§96 PgMP 風險生命週期對映:四過程 vs 子階段 (03:03:00)

核心: PgMP 風險 4 個過程對應到構建 → 規劃 → 交付 → 收尾子階段。

• 第一個 風險的初始評估 → 在 business case / charter 階段(構建子階段)
• 第二個 風險管理的規劃 → 在風險規劃子階段
• 第三個 風險的監督與控制 → 在交付階段(裡面包含識別/分析/規劃/應對)
• 第四個 風險的移交與關閉 → 在收尾階段
• PgMP 風險針對的是「專案級層面 + 組件層面的重大風險」
• 組件層面的一般風險,交給專案經理去管

§97 第一場結束 + RMP 與 PgMP 難度比較 (03:06:00)

核心: Day 2 第一場結束。8 月後 PMI 不接受個人考試,只能透過授權機構報名。

• 風險內容今天補充到這
• 8 月份以後 PMI 不接受個人考試,只能在授權機構報名,PMI 稽核完才考
• RMP 中等難度,比 PMP 簡單,跟 PgMP 不是一個量級
• PgMP 難度比 PMP 高很多
• RMP 只有一本實踐指南,而且還不考,基於考試大綱(短短 7 頁)
• 第七版 PMP 已經「天下大亂、亂糟糟、沒有結構」

講師原話: 「行,如果大家沒有進一步的問題,我們今天就到這。好,謝謝。」(第一場結束)

§98 第二場開場 - 敏捷補充 (03:07:30)

核心: 「大家晚上好」開始第二場。敏捷靠 1 小時只能講皮毛,敏捷與專案管理可並駕齊驅,算兩大領域。

• 時間非常緊湊,給大家補充關於敏捷的東西
• 敏捷靠這 1 小時,估計能講個皮毛就差不多
• 「敏捷和專案管理基本上可以並駕齊驅,算兩個大領域」
• 專案管理派認為「敏捷專案管理」是其下子集
• 敏捷派認為「敏捷就叫敏捷」,沒有什麼敏捷專案管理說
• 站在 PMI 角度,可以把敏捷吸納進來

講師原話: 「大家晚上好,我們今天不等,有時間非常緊湊,今天給大家補充一些關於敏捷的東西。」

§99 敏捷起源:從輕量級到 Agile (03:08:30)

核心: 敏捷原叫「輕量級管理」,2001 年敏捷大會才改名 Agile。

• 原來敏捷不叫這名字,叫 agile / 輕量級的管理
• 思想領袖認為「輕量級」很容易被輕視
• 後來才發明詞語「agile 敏捷」
• 2001 年每次敏捷的大會
• PgMP 考敏捷:不用看得太重,只要知道敏捷的基本概念就可以,不需要特別深入(不像偏 PMP 一樣)

PMI 術語: Agile ↔ 敏捷 (原為 Lightweight Management 輕量級管理)

§100 敏捷的多元家族:Scrum / XP / DevOps / SAFe (03:09:30)

核心: 敏捷實踐多達 2000+ 種,真正有代表性的就 Scrum / XP / DSDM / DevOps / SAFe / DA。

• 包括精益(Lean)的東西,比如「看板」就來自精益
• 還包括「流程化敏捷」、「規模化敏捷」(SAFe / LeSS)
• 最有代表性的是 Scrum(被廣泛接受、做得最成功)
• 其他: XP(極限程式設計)、DSDM、DevOps、SAFe、Disciplined Agile (DA)
• DA(規範敏捷)PMI 收購後想推廣但沒推起來
• 真正的敏捷:理念 → 原則 → 實踐(2000+ 種)

PMI 術語: Scrum / XP (eXtreme Programming) / DSDM / Disciplined Agile (DA/DASSM) / SAFe

§101 敏捷的核心:及早交付有價值的東西 + MVP (03:11:30)

核心: 敏捷聚焦在「及早交付一些有價值的東西」,而不是等全做完才上市。MVP = Minimum Viable Product。

• 不要等所有事都做完再拋到市場
• 像初創/創始型公司:先做大概可用產品 → 用戶反饋 → 不斷優化
• 小步快跑、迭代式增量式
• MVP 最小可靠產品 = Minimum Viable Product
• 有變種:最小可用功能、最小可靠產品
• 微信例子:剛上線時很簡單,現在已成大生態

PMI 術語: MVP (Minimum Viable Product) ↔ 最小可靠產品/最小可用產品

§102 預測 → 迭代/增量 → 敏捷 → 混合的演進 (03:13:30)

核心: 專案管理方法演進: 瀑布(預測) → 迭代/增量 → 敏捷 → 混合。

• 瀑布型 = 預測型(可以畫等號)
• 接下來是迭代型 + 增量型 → 融合在一起 = 敏捷型
• 再到 混合型 (Hybrid) = 預測 + 迭代 + 增量的組合
• 變化背景:工業化時代(產品週期 10-50 年)→ 互聯網 → 移動互聯網 → AI 浪潮(現在 2-3 年一個週期)
• 敏捷大發展的背景就是「變化太快」

PMI 術語: Predictive (Waterfall) ↔ 預測型/瀑布型 ; Iterative + Incremental = Agile ; Hybrid ↔ 混合型

§103 敏捷三層結構:理念 → 價值觀 → 原則 → 實踐 (03:14:30)

核心: 敏捷由上到下:理念(Mindset)→ 4 大價值觀 → 12 原則 → 數千實踐。

• 首先敏捷是一種 理念 (Mindset)
• 然後是 4 大價值觀 (敏捷宣言)
• 由此引發 12 大原則
• 再到數以千計的敏捷實踐
• 對專業人來說: 要能分辨對方談的是哪一層 (實踐 / 理念 / 價值觀 / 原則)
• 敏捷不單純指「快」,而是「對事情的變化及時做出反應、調整 (adaptive 適應性)」

PMI 術語: Mindset ↔ 理念 ; Adaptive ↔ 適應性 (反應變化的能力,不只是快)

§104 Scrum 核心詞:Sprint 與 Backlog (03:16:30)

核心: Scrum 中最廣為流行的概念: Sprint(衝刺)、Backlog(代辦事項列表)。

• Sprint = 衝刺
• Backlog = 代辦事項列表 = 還沒辦完事情的清單
• 種類: Sprint Backlog / Iteration Backlog / Product Backlog / Release Backlog
• 還有: 結對程式設計 (Pair Programming)、看板的「停止啟動聚焦完成」、拉動式生產
• 還有水晶方法、敏捷與精益的結合

講師原話: 「backlog 其實說簡單呢,就是我們還沒有辦完事情的清單。」

PMI 術語: Sprint ↔ 衝刺 ; Product Backlog ↔ 產品代辦事項列表 ; Sprint Backlog ↔ 衝刺代辦事項列表

§105 PgMP 考敏捷的策略:詞語認得即可 (03:17:30)

核心: 考試不會考很多敏捷概念,只看「讀題乾時能不能讀懂這是個有別於傳統的新方法」。

• 真正考試時不會考你這麼多敏捷概念
• 是看讀題乾時,能不能讀懂這在描述「有別於傳統專案管理的一種新方法」
• 這種方法 = 敏捷
• 敏捷英文單詞 Agile,大家記住這個詞
• 4 句話價值觀「PgMP 考的機率應該是很低的」,但背後理念要懂

講師原話: 「他不會說考你這麼多敏捷的概念,是看我們讀題乾的時候,能不能讀懂他正在給你描述的是一種有別於傳統專案管理的一種新方法。」

§106 敏捷 4 大價值觀深解 - 第一句 (03:18:30)

核心: 「個體與互動 高於 流程與工具」- 並非不要工具流程,而是優先級更高。

• 第一句:更強調個體之間的互動,而不是強調遵循流程和工具
• 並非不使用、不規範、不強調流程工具
• 只是認為「個體互動的優先級更高、關注度更高」
• IT 行業背景:過去軟體工程是瀑布、預測型,現在被拋棄差不多

講師原話: 「他並非說不使用、不規範、不強調流程、不強調工具,他也晴亮,只不過呢,他認為各地互動的優先順序更高。」

§107 敏捷 4 大價值觀 - 工作軟體與客戶協作 (03:19:30)

核心: 「能用的軟體 高於 詳細文件」「客戶協作 高於 合同談判」- 但工業級高鐵/飛機軟體不適用試錯。

• 工業級軟體(高鐵、飛機底層、通訊架構):不允許迭代試錯,試錯出人命
• 所以邊站的看它,但觀念非常好
• 「一個能用的東西,遠比你寫些說明文件寫得很詳細,要更重要一點」
• 客戶協作(collaboration):大家發自內心願意一起做事,高於合同談判
• 把用在談判的精力,用到更好處理工作上

PMI 術語: Collaboration ↔ 協作 (Richard 認為翻譯成「協作」會比較好,不要翻成「合作」)

§108 敏捷的核心原則:以人為本 + 創造價值 (03:21:30)

核心: 敏捷 12 原則的核心一點是「以人為本、以創造價值為主要出發點」。

• 12 個原則我們到後面隨意挑著講
• 核心一點: 以人為本 + 以創造價值為主要出發點
• 價值不一定等到最後才一次性交付,過程中也可以交付
• 敏捷對人的關心比傳統對人的關心要更多
• 傳統方法以計劃為主,敏捷方法要讓人開心
• 人開心、舒服 → 才能創造更多價值
• 人 = 我們自己 + 客戶
• 持續價值交付 → 客戶開心的次數和頻度更高

講師原話: 「以人為本,以創造價值為主要的這個出發點。」

§109 基於迭代 vs 基於流程的敏捷 (03:23:30)

核心: 基於迭代敏捷 = Scrum (時長固定 2-4 週);基於流程敏捷 = Lean/Kanban (時長不固定但 WIP 穩定)。

• 基於迭代的敏捷 (Iteration-based Agile) = 最典型代表 Scrum
• 每個迭代週期時長固定(通常 2 週,2-4 週)
• 強調節奏 (Pace),容易產生「心流」
• 不要輕易改變這個工作節奏
• 基於流程的敏捷 (Flow-based Agile) = 跟精益(Lean)很像
• 時長不固定,但每個環節「在製品 (WIP) 數量」穩定
• WIP = Work in Process
• 讓每個環節發揮最佳狀態,整個流就是最棒的
• 精益概念:不是骨瘦如柴,是身材完美沒多餘東西

PMI 術語: Iteration-based Agile ↔ 基於迭代的敏捷 ; Flow-based Agile ↔ 基於流程的敏捷 ; WIP (Work in Process) ↔ 在製品

§110 敏捷鐵三角:價值與質量是目標 (03:26:30)

核心: 傳統 = 範圍/進度/成本三大目標;敏捷 = 範圍/進度/成本是約束,價值和質量才是目標。

• 傳統方法:範圍/進度/成本是鐵三角 + 質量(三大目標、三大基準)
• 敏捷反過來:範圍/進度/成本作為約束條件,關注的是價值和質量
• DSDM (動態系統開發模式):與其鎖定範圍,不如鎖定成本/進度
• 「我就這麼多錢,你告訴我做哪幾個」
• 「我就這麼多時間,你告訴我做哪幾個」
• 給我優先級順序,我用更好方法處理
• 「價值是否可以理解為 PgMP 的收益?可以,沒問題」
• PgMP 也不特別想把範圍鎖定,想關注的是收益最大化 → 與敏捷高度相通

講師原話: 「價值是否可以理解為 PG 的收益?可以是沒問題的,這就是我們說的收益。專案級其實不是特別想把範圍鎖定,他想關注的是收益最大化。」

PMI 術語: Value + Quality (敏捷目標) vs Scope/Schedule/Cost (敏捷約束)

§111 鍍金 vs 質量過剩 (03:29:30)

核心: 鍍金 (Gold-plating) 講的是「範圍擴大」(做了客戶想要範圍之外的東西),不是質量。

• 質量 = 剛剛好最好,多了不好少了不好
• 鍍金說的是範圍擴大,在客戶想要範圍之外做的東西
• 但範圍和質量有沒有關係? 有
• 質量是一種特殊的範圍 → 達到某種特性的水準
• 進度跟成本之間有相似性 → 用「效率 (Efficiency)」描述
• 範圍跟質量 → 用「效果 (Effectiveness)」描述,不用效率
• 效果越好 = 質量成功度越高

PMI 術語: Gold-plating ↔ 鍍金 (= 範圍擴大,不是質量過度) ; Efficiency ↔ 效率 (進度+成本) ; Effectiveness ↔ 效果 (範圍+質量)

§112 整合領域的敏捷:讓團隊協作更好 (03:32:00)

核心: 整合領域談敏捷主要在「方法層面」: 迭代與敏捷方法能讓團隊更好合作。

• 整體觀點方法層面:迭代和敏捷方法能讓團隊「同源的合作」更好
• 敏捷對人非常尊重:人和機器/數據不同,情緒不好時效率低
• 大家以自己引以為傲的專家身份相互合作
• 敏捷團隊裡沒有誰是固定權威的、權力的集中者
• 每個人在他的領域內是最高高手 → 在被尊重環境下協作
• 指令型的環境下不會出現典型的敏捷狀態
• 適應性環境下:仍可有專案經理(對整體負責),但體現 領導力 (Leadership),授權團隊一起決策

PMI 術語: Servant Leadership ↔ 服務式/僕人式領導 ; Self-organizing Team ↔ 自組織團隊

§113 範圍領域的敏捷:擁抱變化、滾動規劃 (03:34:30)

核心: 敏捷把變化視為機會,最開始不關注遠期細節,只看眼下 2-3 公里。

• 想鎖定範圍/讓需求不變 → 已經不大可能
• 敏捷把範圍放一邊,把變化當成滿足客戶需求的機會
• 「不要看兩小時之外的事情,不要看三公里以外的事情,就看眼下要做好,一步一步做起來」
• 把變化視為完善產品/服務的機會
• 變更(變化)是敏捷常態,「敏捷是擁抱變化的」
• 變化甚至是帶來敏捷最終能交付價值的最主要因素
• 越接近結束時提出來的需要,越接近他最想要的東西

講師原話: 「變化是敏捷當中的固有部分,甚至變化是帶來敏捷這種方法最終能交付價值的最主要的那個因素。」

PMI 術語: Embrace Change ↔ 擁抱變化 ; Rolling Wave Planning ↔ 滾動式規劃

§114 變化處理:等量替換與優先級重排 (03:36:30)

核心: 新需求進來,把原來低優先級需求踢掉(等量替換),整體優先級重排。

• 有新需求進來 → 讓原來需求降到次要位置
• 等量替換:低優先級的需求讓出位置
• 例:原本 backlog 20 項,來第 21 項 → 把全部 21 項重新排列
• 排在前面的留下,甩到最後邊的就丟掉、不管它
• 用這種方式處理變化

§115 Scrum 框架 1:三角色 (Scrum Master / PO / Team) (03:38:30)

核心: Scrum 3 個角色 - Scrum Master(敏捷教練)、Product Owner(產品負責人)、Team(開發團隊)。

• 三個角色(沒有第四個)
• Scrum Master = 敏捷教練 = 為團隊排除組織內外、團隊間衝突這種障礙
• Product Owner (PO) = 產品負責人 = 面向客戶/市場,傳遞客戶需要,不干預團隊開發
• Team = 團隊 = 自己決定 sprint 內先做什麼後做什麼
• PMI 與 PMO 在敏捷裡都消失了
• Scrum Master 也不直接參與工作,只輔導/教練
• 你只要告訴團隊「兩週要做什麼」,內部排序由團隊負責

PMI 術語: Scrum Master ↔ 敏捷教練 ; Product Owner (PO) ↔ 產品負責人 ; Self-managing Team ↔ 自管理團隊

§116 Scrum 框架 2:三產出物 (03:42:30)

核心: 三個產出物 = Product Backlog + Sprint Backlog + Increment(增量)。

• 第一個 Product Backlog = 我有總需求,把它切成小段,小段就是「兩週是一段」
• 第二個 Sprint Backlog = 兩週要做的事情取出來、再排優先順序、交給 Team
• 第三個 Increment = 每兩週結束會交付一個「過程當中的增量」
• 增量必須 可用 (usable) - 「如果你交出來一個不可用的東西,那不算數」
• 切分時要切到兩週能完成的工作量,要可驗證
• 不需要準備大量文件,基本上就 Backlog 兩個

PMI 術語: Product Backlog ↔ 產品代辦清單 ; Sprint Backlog ↔ 衝刺代辦清單 ; Increment ↔ 增量

§117 Scrum 框架 3:四/五個會議 (03:46:30)

核心: 4 個核心會議 = 衝刺規劃會 + 每日站立會 + 評審會 + 回顧會;若加產品規劃會就 5 個。

• 衝刺規劃會 (Sprint Planning) - 規劃這 2 週做什麼
• 每日站立會 (Daily Stand-up) - 每天說昨天做了什麼、今天做什麼、碰到什麼問題;只展示不討論
• 評審會 (Sprint Review) - 主要展示階段成果給客戶/PO 看,有問題提出,提完之後加到下一個 sprint backlog
• 回顧會 (Sprint Retrospective) - 總結經驗
• 加上 產品規劃會 (Product Planning) = 5 個

PMI 術語: Sprint Planning ↔ 衝刺規劃會 ; Daily Stand-up ↔ 每日站立會 ; Sprint Review ↔ 評審會 ; Sprint Retrospective ↔ 回顧會

§118 Scrum 適用情境:小規模團隊 (03:50:30)

核心: Scrum 是「小規模團隊、團隊為基礎、兩週為顆粒度」的做事方法,最流行的敏捷實踐。

• 小規模團隊 + 以團隊為基礎 + 以兩週為顆粒度
• 它是最流行的敏捷實踐之一
• 推薦書: 《Scrum 敏捷革命》(作者:傑夫·薩瑟蘭 Jeff Sutherland 等),薄薄一本
• 兩位作者都是軍人出身

PMI 術語: Jeff Sutherland (Scrum 共同創始人,軍人背景)

§119 看板 (Kanban) - 拉動式生產 (03:51:30)

核心: 看板是視覺化物理/電子板,設定 WIP 限制,從後端向前端「拉」工作 = 拉動式生產。

• 看板 (Kanban Board) = 視覺化的物理版或電子版
• 上面標數字 (6/3/5/3) = 每個環節最大能處理的工作量
• 滿了就不要再傳遞過來
• 拉動式生產 (Pull-based) = 從後端向前端要工作
• vs 推動式生產 (Push-based) = 由前端向後端推
• 拉動式來自豐田生產方式 (Toyota Production System)

PMI 術語: Kanban Board ↔ 看板 ; Pull System ↔ 拉動式生產 ; Push System ↔ 推動式生產 ; WIP Limit ↔ 在製品上限

§120 進度領域:時間鎖死、範圍可變 (03:52:30)

核心: 敏捷進度: 範圍可變,時間鎖死;一旦定 2 週,後面全部都是兩週,保持團隊節奏。

• 敏捷方法當中:範圍可變,但時間要鎖死
• 一旦確定是兩週,後面全部都是兩週
• 保持團隊節奏 → 處理工作的能力 (活動點數 / 工作量)
• 經過 2-3 次迭代之後,團隊就有感覺了「兩週能做完多少事」
• 第 3、4 次規劃時,放進來的工作和能完成的工作就趨於穩定
• 直到把整個事情做完

講師原話: 「敏捷方法當中範圍可變,但時間要鎖死。」

PMI 術語: Velocity ↔ 速度/活動點數 ; Time-box ↔ 時間盒

§121 80 小時原則 + 路線圖 + 用戶故事 (03:55:30)

核心: 1 週 5 工作日 × 8 小時 = 40 小時; 2 週 = 80 小時原則。需求用 User Story 描述。

• 兩週 = 10 工作日 × 8 小時 = 80 小時 → 80 小時原則
• 路線圖 (Roadmap):版本 1、版本 2、版本 3
• 版本 2、3 太遙遠 → 只考慮版本 1
• 版本 1 切成多個迭代 (Iteration 0、1、2、...)
• 每個迭代完成功能 1A、1B、1C...
• 需求用 User Story 描述(敏捷),而傳統用「需求說明書 / 功能點數」
• 見機明細,遠期粗略,近期詳細

PMI 術語: User Story ↔ 用戶故事 ; 80-Hour Rule ↔ 80 小時原則 ; Roadmap ↔ 路線圖

§122 成本領域:進度對成本影響最大 (03:58:00)

核心: 傳統 = 範圍對成本影響最大;敏捷 = 進度對成本影響最大(因為時間鎖死,人員定 → 成本確定)。

• 傳統:範圍越大 → 成本越高、時間越長
• 敏捷:範圍我不管,你只告訴我接下來兩週幹什麼
• 做到第 5 個兩週就不幹了,沒幹完的「我也不管」
• 反正幾個兩週週期之內,最重要的事都做完了
• 它並非追求完美/完整,而是追求每次都做最重要的那幾件事
• 進度鎖死 → 人員數量定 + 工作量定 → 成本就確定了
• IT 領域人的成本是最大成本

講師原話: 「對於敏捷方法來說,進度對成本影響最大。傳統方法當中的範圍,對成本影響最大。」

§123 質量內嵌 + 戰略一致變化 (04:00:00)

核心: 質量在敏捷裡 內嵌在過程中(每個環節做最棒);傳統是獨立工作。DoD = Definition of Done。

• 傳統:質量擺在那大家檢查
• 敏捷:每個環節都做到最棒
• DoD = Definition of Done = 完工定義
• 「衝刺其實就是迭代」 - 兩週的時間 = 一個迭代/衝刺
• 早期衝刺階段返工成本比較低 → 對高風險特性開發測試 (試錯)
• 敏捷擁抱變化,但要與組織戰略保持一致 - 每個變化都要保持價值最高
• 新變化進來會對原工作產生影響 → 每次重排優先級
• 兩週時間盒之內不管這些事

PMI 術語: Definition of Done (DoD) ↔ 完工定義 ; Definition of Ready (DoR) ↔ 就緒定義

§124 Scrum 2-3-4-1 摘要記法 (04:02:30)

核心: Scrum 記法 = 2 文件 (Product/Sprint Backlog) + 3 角色 + 4 會議 + 1 中間成果 (Increment)。

• 三個角色:PO、Scrum Master、Team
• 四個會議:迭代計劃會、每日戰會、評審會、回顧會
• 兩個文件:Product Backlog + Sprint Backlog (都叫 Backlog,待辦事項清單/未完事項清單)
• 一個結果:Increment (每兩週要輸出可用的 MVP 或最小功能)
• 不允許「半完成」:要麼 0 要麼 1,不能用就等於沒做完
• 「不能等於 60%、80% 的工作量,這個就是不好衡量」

PMI 術語: Increment ↔ 增量 (中間成果)

§125 資源領域:7±2 團隊 + 自組織 + 不評價個人 (04:04:30)

核心: 敏捷團隊規模 7±2 + 最小化完整功能 + 評價團隊不評價個人 + 是長期團隊。

• 資源中最主要的是「人」
• 個體和互動高於流程和工具 → 特別尊重人,以人為中心
• 自組織自管理 - 沒有指定的中心節點,網絡式結構
• 這事誰最擅長 → 誰來帶領大家完成
• 團隊領袖是「合作過程中產生的,不是指定的」
• 儘量不評價個人,評價團隊 - 成敗都是整個團隊一起承擔
• 團隊裡是「最小化的完整功能」 - 我所要能力,團隊都具備,不外求
• 產品團隊 = 長期團隊 ; 專案團隊 = 臨時團隊
• 7±2 = 7 加減 2 的團隊規模原則 (5-9 人)

講師原話: 「敏捷強調的是長期團隊,我們說產品團隊是一個長期團隊,而專案團隊是一個臨時團隊。」

PMI 術語: 7±2 Rule ↔ 7 加減 2 團隊規模 ; Self-organizing Team ↔ 自組織團隊

§126 溝通領域:面對面 + 梅拉賓法則 + 恰到好處文件 (04:07:30)

核心: 敏捷強調 面對面溝通(梅拉賓法則),恰到好處的文件,用演示而非 PPT 展示成果。

• 敏捷 vs 傳統:更強調 面對面溝通是最佳方式
• 梅拉賓法則 (Mehrabian's Rule) - 面對面 = 文字 + 聲音 + 表情 + 動作 = 最大效果
• 敏捷強調:恰到好處的文件、不開沒用的會議、不寫沒用的文件
• 透過演示 (Demo) 展示工作完成情況,而不是文件 / PPT
• 你做完的事情讓大家用 → 能用就是完成,不能用就沒完成

PMI 術語: Mehrabian's Rule ↔ 梅拉賓法則 ; Just Enough Documentation ↔ 恰到好處的文件 ; Demo ↔ 演示

§127 願景使命戰略:敏捷只在產品層面談 (04:09:30)

核心: PgMP 談願景使命戰略;敏捷在團隊工作裡很少提這些宏大的東西,只在產品層面談 vision + roadmap。

• 敏捷在團隊工作中很少提願景使命
• 敏捷起到效果最好的是「小型團隊」,規模化敏捷有悖論
• 規模越大 → 敏捷難度越高
• 大團隊有 Scrum of Scrums + 多個敏捷的構成
• 敏捷在 產品層面談 vision + roadmap (運鏡)
• MVV = Mission + Vision + Values = 願景 + 使命 + 價值觀

PMI 術語: Scrum of Scrums ↔ 規模化 Scrum ; MVV (Mission/Vision/Values) ↔ 願景使命價值觀 ; Roadmap ↔ 路線圖/運鏡

§128 風險領域:敏捷天生分散風險 - 衛青與霍去病的比喻 (04:11:00)

核心: 敏捷本身就是應對變化,快速失措 → 換方式,基本可避免災難性損失。像霍去病的閃擊戰 vs 衛青的陣地戰。

• 敏捷方法本身就是為了應對不斷變化的東西
• 它基本可以 避免災難性的損失 - 因為快速失敗 → 不行就換方式
• 像 打游擊戰;傳統方法 = 陣地戰、殲滅戰(大規模大團隊)
• 比喻:漢朝衛青(陣地戰 No.1) vs 霍去病(敏捷戰 No.1,飄搖校尉,出其不意)
• 兩個都成功:大象式 vs 猴子式
• 把壓迫性工作切成小塊 → 就在分散風險,避免最後承擔整體失敗的風險
• 增量交付這個優先級最高的價值和需求

講師原話: 「打陣地戰肯定是衛青是 No.1,但打敏捷戰肯定是霍去病。」

§129 採購領域:敏捷合同 - 主體固定 + 增量靈活 (04:11:30)

核心: 敏捷合同:不變部分簽固定合同,可變部分簽增量合同,保證主體穩定。

• 採購裡跟敏捷有關也比較多
• 採購敏捷起來 → 合同是不好籤的
• 敏捷合同類型:用新增進來的內容 替換掉不要的東西(類似需求等量替換)
• 注意:不變部分籤固定合同 + 可變部分籤增量 → 保證主體穩定
• 增加部分可以隨意/靈活調整
• 防止靈活變化給整個採購帶來問題
• 採購過程:自己決定要採購什麼,而不是公司集中採購處理
• 大規模工程類專案不適用 IT 類腦力勞動敏捷方法

PMI 術語: Agile Contract ↔ 敏捷合同 ; Fixed-Price + T&M Hybrid ↔ 固定價 + 計時計費混合

§130 採購流程詳解 - 從招標到籤合同 (04:13:00)

核心: PgMP 採購題目用國際專案流程: 採購方/潛在賣方 → 標書 → 開標 → 出股評估 → 短名單 → 現場考察 → 籤合同。

• PgMP/PfMP 都是國際專案背景
• 採購方 + 潛在賣方 (簽合同前) → 甲乙方 (簽合同後)
• 流程順序:
• 買方組建採購團隊
• 制定招標書 + 評標標準 (專家參與)
• 標書不發給市場所有公司 → 先做初步篩選
• 釋出招標檔案 (tender)
• 投標前澄清/說明會
• 賣方準備技術方案 + 商務方案 (標書) 提交
• 公開場合開標 (Bid Opening) - 宣佈每家公司報價、技術方案
• 出股評估 (Bid Evaluation)
• 公佈評估結果 - 國際上可有「兩次投標或會議宣佈」
• 供應商短名單 (Shortlist) - 例 10 家選 3 家
• 現場參觀與演示考察工廠/類似專案
• 從 3 家中選 1 家進入細節談判
• 簽訂合同

講師原話: 「對大家做選擇題,做我們的這個這樣,採購的題目是有點幫助的。」

PMI 術語: Tender Documents ↔ 招標檔案 ; Bid Opening ↔ 開標 ; Shortlist ↔ 短名單 ; Bid Evaluation ↔ 出股/標書評估

§131 團隊溝通透明化:特種兵類比 + 看板 (04:18:00)

核心: 敏捷團隊強調 資訊高度透明,直接互動避免層層傳遞損失。看板用視覺化迴避語言文字障礙。

• 適應團隊 = 大家之間互通交流,比有管理屬性中心節點要好得多
• 適應傳遞 = 相關方直接互動,不需透過一層一層傳遞
• 「只要有傳遞就會有損失」 - 加上認知層次、思維模型、邏輯、情緒文化背景都不同
• 多一個環節 → 損失指數放大,溝通漏洞有時非常巨大
• 保持高度資訊透明 + 資訊分享
• 想像 特種兵執行任務 - 每個人把看到的及時同步到所有人,高度透明
• 看板 = 視覺化方式,迴避語言和文字障礙
• 「你看到的東西,有時候比你用語言描述更準確」

講師原話: 「只要有傳遞,溝通是有漏走的,只要有傳遞的資訊就會有損失。」

§132 考場策略總結 1:敏捷 = 對變化敏感 (04:24:00)

核心: 敏捷在 PgMP 提幹: 要做到「認得詞」+ 理解到「對變化敏感的方法」,核心不是「快」。

• 敏捷在 PgMP 中很容易這樣考
• 敏捷不僅僅是快,核心是「讓你做出應對和反應、對變化敏感」
• 敏感 = 你看到了、感受到變化,行為方式可能需要立即應對或感知到就好
• = reactive 反應性 + adaptive 適應性
• 「好像似乎跟快有點關係,但如果只把敏捷理解為快,那就是真偏了」
• 第一個需要做到:看到敏捷詞語不陌生
• 第二個需要做到:理解這是有別於傳統的新方法

講師原話: 「敏捷不僅僅是快,其實是讓你做出應對和反應,要對變化敏感。」

PMI 術語: Reactive ↔ 反應性 ; Adaptive ↔ 適應性

§133 考場策略總結 2:傳統重 WBS,敏捷重時間節奏 (04:25:30)

核心: 傳統重 WBS(範圍要搞清楚);敏捷重進度節奏(時間節奏要保持好)。

• 傳統(預測):WBS 看得很重、考得很重 - 範圍要搞清楚
• 敏捷:進度 = 時間節奏要把握好、保持好
• 變更在敏捷中基本上不嚴格限制走那種僵化流程
• 有變化 → 大家去應對就行,不是說非要審批完再去做
• 拋棄那種僵化做法 → 相信團隊的判斷是準確的
• 團隊每個人對自己工作高度投入和高度自信

講師原話: 「傳統的更關注範圍,所以他 WBS 看得很重考得很重。然後如果敏捷觀眾的進度,那進度就是時間節奏要把握好。」

§134 考場策略總結 3:敏捷對人的素質要求很高 (04:27:00)

核心: 如果團隊都不成熟、新手 → 敏捷不起來,反而會亂套。敏捷需要「極客精神」。

• 如果團隊成員都不成熟、都是新手/外行 → 敏捷不起來,反而亂套
• 敏捷對人的素質要求很高
• 你要是非常極致的人、做事情有 極客精神 (Geek Spirit) 的人 → 在敏捷團隊上會 如魚得水
• 「敏捷需要明天的結像在哪裡定義?完成的進度但範圍沒完成,他是這樣的」(學員提問)

講師原話: 「敏捷對人的素質要求很高。你要是一個非常極致的人,做事情有極客精神的人,在敏捷團隊上會如魚得水。」

§135 學員問答:敏捷能不能不做完範圍就結束? (04:28:30)

核心: 敏捷原理上 可以不做完範圍就結束 - 因為每次做的都是優先級最高的事,結束時最重要的事都完成了。

• 敏捷原則上可以不把範圍都做完就結束
• 只要外面說結束了,就可以結束
• 結束時有個特別好的現象:不管什麼時候結束,最重要的事在過去都已經做完了
• 因為每次做的都是優先級最高的那些事情
• 所以 敏捷把「結像 vs 不結像」這件事,不放在最主要的考慮範圍裡邊
• 反而是享受整個過程,隨時可以結像
• 前提假設:每個需求之間應該是相互獨立、解耦的關係
• 一旦需求/故事之間有關聯/耦合 → 敏捷方法就失去優勢

講師原話: 「不管他什麼時候結束,最重要的事情在過去都已經做完了,因為你每次做的都是優先順序最高的那些事情。」

(這裡與 §25 「PgMP 收益最大化、範圍可以讓位」 完全呼應)

§136 敏捷在中國的應用現況 (04:31:00)

核心: 最終敏捷加傳統方法要結合;客戶不懂敏捷時,用敏捷管過程,但管結果會跟現實有衝突。

• 客戶他如果不懂敏捷,你跟他玩這套東西他不理你
• 實踐中:用敏捷管過程比較常見,管結果會跟現實有衝突
• 大家處理問題時要快速從我傳到你,每個環節發揮最大效果 → 用得多
• 完整用敏捷做所有事情的,在傳統行業甚至在大多數行業不多
• 在極致行業裡可能有一些「我不關心後邊,我先看眼前」的情形,也不多
• 敏捷在中國大地上用得不是特別好
• 都願意談這個理念,領導管理層一聽到很興奮
• 區域性還可以,一到大規模層面就有問題
• 比較成功在團隊層面,一到團隊對外、面向客戶/部門間合作 → 敏捷方法可能就發揮不了太大作用
• 「因為你是那樣,別人不那樣做,你也很難被接受」

§137 結尾:謝謝大家 (04:12:25)

核心: Day 2 衝刺到此結束。

• 「好的,那我們就要到這了」
• 「謝謝大家」

講師原話: 「好的,那我們就要到這了。謝謝大家。」

Part C 收束筆記 (供 Freddie 考前複習用)

Day 2 必背 5 件事: 1. 風險策略 5+5 + 接受/上報共有 (§6) - 看到「規避/轉移/減輕」=威脅,「提高/分享/開拓」=機會 2. 迴避針對事件,減輕針對機率與影響 (§7) - 高頻考點區別 3. PgMP 風險拉 stakeholders,不只 team (§5) - 提幹關鍵詞 4. 敏捷鐵三角 = 範圍進度成本是約束,價值與質量才是目標 (§25) - 與 PgMP 收益思維高度相通 5. 敏捷不僅是快,核心是「對變化敏感、做出應對」(reactive/adaptive) (§47) - 提幹關鍵字判別

Day 2 加分概念: - DoD (Definition of Done) = 完工定義 - 不允許半完成 - 80 小時原則 = 兩週 = 一個迭代 - Scrum 3-3-4-1: 3 角色 + 3 產出 + 4 會議 + 1 (5 個會議含產品規劃會) + 2 文件 + 1 中間成果 - WIP Limit = 在製品上限,看板拉動式生產 - 7±2 團隊規模 + 評價團隊不評價個人

Day 2 與 PgMP 強連結點: - 敏捷「價值優先」= PgMP「收益實現」 - 敏捷「擁抱變化、範圍讓位」= PgMP「範圍可以為收益讓位」(Ch10 §4 收益實現原則) - 敏捷「相關方協作」= PgMP「相關方參與績效域」