Ch19 — 新版衝刺 EVM 風險 敏捷 採購 (175 min)
講師: Richard | 對應 PDF: — 影片:
C:\Users\User\Desktop\PGMP\PGMP Video\2026-10-02 06-14-49.mp4回到 [[MOC-PgMP-精講筆記]]產製方式: 章節切 2 段交給 2 個 agent 平行逐段精煉, 共 103 個 §N (Part A: §1-51, Part B: §52-103).
Part A (00:00:19 - 01:30:57) 綜述
這段分兩大塊:前 47 分鐘是實獲值管理 EVM(Earned Value Management),後 44 分鐘是風險管理基礎(本 part 尚未進入敏捷與採購,章名中的這兩項應在 part b)。EVM 部分講師從「錢可以相加、時間不能相加 → EVM 算成本準、算進度不準」切入,說明 EVM 起源(C/SCSC → EVM),再用「計劃/實際 × 工作量/單價」四維度推導 PV、AC、EV,核心是:EV = 實際工作量 × 計劃單價;EV/PV 約掉單價 → 進度(SPI),EV/AC 約掉工作量 → 成本(CPI);所有 EVM 公式都必然有 EV,PV 與 AC 直接比較沒有意義。接著用 S 曲線與柱狀圖判讀專案狀況,最後推導 EAC = AC + (BAC − EV) / CPI(講師說是考最多的公式,PgMP 基本只考 SPI、CPI、EAC)。風險部分以 PMBOK 第 6 版為底,強調概念在 PMP/PgMP/PfMP/RMP 通用,只是管理對象不同:風險是中性詞;本質=不確定性+對目標的影響;描述格式三要素(事件/機率/影響)與四要素(加原因);已知-未知 ↔ 應急計劃/應急儲備,未知-未知 ↔ 權變措施/管理儲備;風險態度=偏好(主觀)→承受力(極值)→臨界值(理性觸發點);7 個過程中「規劃應對後進入監督,出現才實施應對」、應急計劃啟用要走變更、權變措施不用;殘餘風險與次生風險在規劃應對時就要預估。
最重要考點判準:① EV 必在分子,比值看與 1 的關係;② EAC = AC + (BAC−EV)/CPI,(BAC−EV)=剩餘工作的價值;③ 已知-未知→應急儲備,未知-未知→權變措施/管理儲備;④ 臨界值 < 承受力,碰到臨界值就要行動;⑤ 識別風險越早、越全、參與者越多越好(全體干係人,不只團隊)。
§1 EVM 定位:算成本準、算進度不準 (00:00:19)

核心: EVM 是 PMP 延伸到 PgMP 的必考難點;用它算成本較準,算進度只能「看看就行」。
- 實獲值可以算進度(SPI),也可以算成本(CPI)
- 錢可以累加,時間不能直接累加:活動之間有邏輯關係、可以並行,同一時間內能做很多事,所以時間不是單純相加
- 因此「SPI 顯示進度超前/落後」的結論背後並不穩妥,只能作參考
- 從管理角度看,EVM 是一種計算,但不是特別精準的計算
PMI 術語: Earned Value (EV) ↔ 實獲值/掙值(逐字稿「正值/政治/正職」皆為「掙值」誤辨)
§2 EVM 起源:為了跨專案、跨行業比較績效 (00:01:26)

核心: EVM 的出發點是「讓規模、行業差異很大的專案,能用統一標準和格式呈現績效、橫向比較」。
- ISO 與 PMI 標準體系裡都有專門的 EVM 標準,權威性很高
- 難題:千萬級專案與幾十萬專案怎麼比?建築用建築語言、軟體用軟體語言描述進度,別人看不懂
- 泰勒、吉爾布雷斯(Gilbreth)、甘特應美國政府要求,建立統一的績效標準與計算方法
- 甲方/領導要橫向比較:千萬專案偏差 10% 可能比你整個專案總額還大
- 前身叫 C/SCSC(Cost/Schedule Control System Criteria,成本進度控制系統標準),後稱 EVM
- EV = Earned Value(掙得的價值,earn money 的 earn);以 EV 命名整套方法,凸顯 EV 是最重要參數
PMI 術語: Cost/Schedule Control System Criteria (C/SCSC) ↔ 成本進度控制系統標準
§3 EVM 原理:實際 vs 計劃,計劃批准後成為基準 (00:03:54)

核心: EVM 比較「到某時間點實際完成的工作與花的錢」vs「計劃應完成的工作與應花的錢」;計劃經批准就是基準(baseline),基準=比較的基礎。
- 每個專案都有兩套資料:計劃的進度與預算、實際的進度與成本
- 計劃是紙面上的、偏完美;實際是現實的
- 例:兩週(10 個工作日)專案,可以計劃到每一天該做多少、花多少 → 一組數字=計劃
- 計劃經出錢、管資源的「大佬」批准 → 基準化(baselining)
- 計劃顆粒度決定可比較性:計劃做到「天」,任何一天都有參照;只做到「月」,月中任何一天都沒有基準可比
PMI 術語: Baseline ↔ 基準 / Performance Measurement Baseline ↔ 績效測量基準
§4 財務悖論:只比錢會誤判「超支」 (00:07:58)

核心: 不能直接拿「實際花的錢」比「預算」,必須先看完成了多少工作。
- 例題情境:專案 2 個月,第一個月預算 10 萬、第二個月 10 萬,總預算 20 萬
- 第一個月結束時花了 15 萬 → 財務第一反應:「成本超支」
- 但若這 15 萬已經把兩個月的活全部做完,說他超支就很冤枉
- EVM 要解決的就是:比較成本與預算前,先看完成了多少工作(進度=工作完成百分比)
🎯 考點: 題目只給「預算 vs 實際花費」就下「超支」結論 → 錯,必須有 EV 才能判斷成本績效。
§5 為什麼用「進度 schedule」而不是「時間 time」 (00:10:31)

核心: schedule = 時間內完成了多少工作(時間+工作量),time 只是時間的自然流逝。
- 若不用 EVM,就只能財務跟財務比、時間跟時間比,很麻煩
- PMBOK 雖用 time,但較精確的表達是 schedule
- 進度同時包含時間概念與工作量概念
PMI 術語: Schedule ↔ 進度 / Time ↔ 時間
§6 四個基本維度與 PV、AC (00:10:59)

核心: 工作量(計劃/實際)× 單價(計劃/實際)交叉出 PV、AC、EV。
- 單價例:做預算時一人天 500,真正用人時可能變 600 或 400;不管單價多少,活還是要做那麼多
- 預算時單價做高(如 600),實際只要 500 → 實際執行時手頭寬鬆
- PV(Planned Value)= 計劃工作量 × 計劃單價(到該時間點應完成工作的預算)
- AC(Actual Cost)= 實際工作量 × 實際單價
- PV 是專案開始前依經驗與市場了解在紙面上做的;實際執行時工作量、單價都可能變多或變少
- AC 永遠是已知量;PV 只要計劃顆粒度夠細,也永遠是已知量
PMI 術語: Planned Value (PV) ↔ 計劃價值 / Actual Cost (AC) ↔ 實際成本
§7 EV 定義:實際工作量 × 計劃單價 (00:13:31)

核心: EV = 實際工作量 × 計劃單價 =「我做了這麼多活,這些活在原來預算體系中值多少錢」。
- 用到 EV,代表專案已在執行中
- 實際工作量例:完成一段軟體編程、挖了一米長的溝
- 同樣完成的工作:用實際花的錢衡量=AC;放進預算體系衡量=EV
- EV 是「發明出來」的概念,為了解決 §4 的悖論:PV 10 萬與 AC 15 萬根本不能直接比,必須看錢背後完成的工作
講師原話:「不能夠直接把錢和錢做比較,一定要看這個錢背後的完成的工作。」
§8 計劃單價 vs 實際單價:預算博弈 (00:15:39)

核心: 計劃單價=實際單價 → 預算剛好夠;計劃單價被砍得太低 → 做得越多虧得越多。
- 實務上領導/甲方會一刀刀砍預算,把計劃單價壓得很低,實際包不住
- 於是只能不斷壓實際成本、壓實際單價
- 所以大家做計劃時會把單價或工作量報高一點,手頭寬裕
- 實踐很殘酷:市場多少錢就多少錢;假設工作量穩定,單價波動就變得非常敏感
§9 PV、BAC、EV 的正式定義 (00:16:52)

核心: PV=為計劃工作分配的(到某時點)預算;全部計劃工作的預算總額=BAC。
- 例:第一個月 10 萬、第二個月 10 萬 → BAC = 20 萬
- 第一個月結束時應花的錢 = PV(10 萬);第二個月再花 10 萬,也是 PV(累計 20 萬)
- 到專案結束那一刻預計要花的總錢數 = BAC
- 回到例題:計劃第一個月底完成 50% 工作、花 10 萬;實際第一個月底花 15 萬,卻把全部工作做完 →「用 15 萬幹了值 20 萬的活」,且少花一個月時間
例題完整計算(第一個月底;講師只做文字推導,數字為筆記補算)
| 參數 | 算法 | 值 |
|---|---|---|
| BAC | 10 + 10 | 20 萬 |
| PV | 第一個月計劃 | 10 萬 |
| AC | 實際花費 | 15 萬 |
| EV | 完成 100% × BAC | 20 萬 |
| SPI | EV / PV = 20 / 10 | 2.0 → 進度超前 |
| CPI | EV / AC = 20 / 15 | 1.33 → 成本節約 |
| SV | EV − PV = 20 − 10 | +10 萬(>0 超前) |
| CV | EV − AC = 20 − 15 | +5 萬(>0 節約) |
→ 只看「15 > 10」會誤判超支;有了 EV 才知道其實成本績效良好。
講師原話:「用了 15 萬就幹了值 20 萬的活。」
PMI 術語: Budget at Completion (BAC) ↔ 完工預算
⚠ 講師口誤:00:19:54-00:19:56 說「計劃完成的工作……叫掙值」,正確應為「已完成工作的預算價值 = EV」(他隨後 00:20:00 即更正為「對已完成的工作」)。
§10 同一份已完成工作有兩個價值:EV 與 AC (00:20:00)

核心: 已完成的工作用計劃單價衡量=EV,用實際單價衡量=AC;EV=AC 代表計劃單價=實際單價,CPI=1。
- EV 必須是「已完成」的工作,不是紙面上的
- EV 與 AC 工作量相同,差別只在單價
- 舊稱:EV=BCWP(Budgeted Cost of Work Performed)等,現已基本棄用,只用 EV/PV/AC
PMI 術語: BCWP ↔ 已完成工作預算成本(=EV,舊稱)
§11 EV vs PV:單價約掉 → 代表進度 (00:21:40)

核心: EV 與 PV 的計劃單價相同,相除後剩「實際工作量 / 計劃工作量」→ 比值代表進度。
- 順序上是 EV 比 PV(EV 在分子)
- 實際完成工作量大於計劃 → 進度超前
- EV 與 AC 實際工作量相同,相除約掉工作量 → 代表成本表現
- 講師強調要從「概念解答」進到「公式理解」,公式抽象後思考更快
講師原話:「EV 和 PV 比較,代表的是進度。」
§12 SPI 與 CPI 公式推導 (00:24:49)

核心: SPI = EV / PV(進度績效指數),CPI = EV / AC(成本績效指數)。
推導步驟: 1. EV = 實際工作量 × 計劃單價;PV = 計劃工作量 × 計劃單價 2. EV / PV → 計劃單價約掉 = 實際工作量 / 計劃工作量 → SPI 3. EV = 實際工作量 × 計劃單價;AC = 實際工作量 × 實際單價 4. EV / AC → 工作量約掉 = 計劃單價 / 實際單價 → CPI 5. 分子(計劃單價)大比較好 → 所以實務上預算單價做高一點較安全;最好是完全相等
- 考試時 EV、PV 會直接給或間接給
- CPI:C=cost,P=performance,I=index/indicator 皆可
PMI 術語: Schedule Performance Index (SPI) ↔ 進度績效指數 / Cost Performance Index (CPI) ↔ 成本績效指數
§13 EV 是核心:所有 EVM 公式都必有 EV (00:27:35)

核心: PV、AC 實務上都是已知值,只有 EV 需要實際測量;沒有 EV 的公式一定錯。
- PV:計劃做到每天,一定已知;AC:花了多少錢一定知道
- EV 要測量:工作量要測出來,再用計劃單價換算
- 公式中分母老在換(PV 或 AC),但 EV 不能沒有
- 沒有 EV 就變成 AC 跟 PV 直接比 → 必錯
🎯 考點: 選項中出現「比較 AC 與 PV 判斷績效」→ 排除;任何 EVM 判斷都要有 EV。
§14 S 曲線三線圖判讀 (00:29:16)

核心: 看三線位置關係就能判斷:EV 在誰上面就比誰好。
- AC、PV、EV 都是累計 S 曲線:執行期花錢/完成工作的速率最快,斜率變大
- 規劃階段幾乎沒有「收穫」(EV),執行之後才增加
- EV 永遠在分子:EV > PV → 進度好;EV > AC → 成本節約
- 講師示例圖:EV 線同時低於 PV 與 AC → SPI < 1 且 CPI < 1 → 進度延誤、成本超支
🎯 考點: 題目給 S 曲線圖時,先找 EV 線,再分別與 PV(進度)、AC(成本)比高低。
§15 SPI/CPI 與 1 比,差值與 0 比 (00:32:19)

核心: 比值(指數)跟 1 比;差值(偏差)跟 0 比。
| 指標 | > 1 | = 1 | < 1 |
|---|---|---|---|
| SPI = EV/PV | 進度超前 | 與計劃一致 | 進度落後 |
| CPI = EV/AC | 成本節約 | 與計劃一致 | 成本超支 |
- 差值:SV = EV − PV、CV = EV − AC,與 0 比(講師提到但說「這個不講,下去讀」)
- 講師說 EVM 在課堂上至少要 1-2 小時才講得透
§16 柱狀圖例題:PV 91/142/88 (00:33:14)

核心: 柱狀圖中只能拿 EV(綠)分別比 PV(藍)與 AC(粉);PV 與 AC 直接比沒有意義。
- 圖例:預算=PV(藍,永遠已知)、實際花費=AC(粉)、實現價值=EV(綠)
- PV 為增量值(非累計):第 1 月 91、第 2 月 142、第 3 月 88
- 若換成累計:第 1 月 91、第 2 月 91+142=233、第 3 月 233+88=321(BAC=321,筆記補算)
- 第 3 月 AC、EV 都還沒有 → 現在是第 2 月結束
- 第 1 月:PV = 91、AC = 91 → 講師陷阱題:「相等意味著什麼?」→ 沒有意義,要看 91 背後完成了多少活
- 第 1 月 EV 小於 PV → 進度落後;EV 也小於 AC → 成本超支(逐字稿未唸出 EV 具體數字)
講師原話:「粉色跟藍色不要比,它兩個比沒有任何意義。」
🎯 考點: 「PV = AC 所以專案正常」是陷阱;沒有 EV 無法下結論。
§17 前期偏差原理上趕不回來 (00:35:33)

核心: 專案前期出現成本超支與進度延誤,後期原理上永遠趕不回來,除非改基準。
- 第 2 月比第 1 月更惡化:進度更延誤、成本更超支
- 趕進度就要加人加錢 → 成本更超;不改基準就會一直這樣下去
§18 快速跟進 vs 趕工 (00:36:52)

核心: 改變工作順序(不加人不加錢)=快速跟進;加錢加人加資源=趕工。
- 高手用改變工作順序的方式搶回進度,可不加人也不加錢 → 快速跟進(Fast Tracking)
- 用加錢、加人、加資源 → 趕工(Crashing),基本趕不回來,因為一加錢成本就冒了
- 除非改變大家工作方式,讓每個人效率提升
PMI 術語: Fast Tracking ↔ 快速跟進 / Crashing ↔ 趕工
🎯 考點: 「不增加成本壓縮進度」→ 快速跟進;「增加資源」→ 趕工(成本上升)。
§19 考試重點公式:SPI、CPI + EAC (00:37:34)

核心: 考試基本就是 CPI、SPI 兩個公式,再加記一個 EAC 公式就差不多了。
- 公式表看起來很煩人,重點掌握 CPI、SPI
- 再加一個「完工估算 EAC」公式
🎯 考點: PgMP 的 EVM 計算優先熟練 SPI、CPI、EAC 三個。
§20 EAC 概念:基於偏差與趨勢預測 (00:38:02)

核心: EAC(完工估算)是基於已發生的偏差與趨勢,預測完成整個專案要花的總錢數;BAC 是原始完工預算。
- 當前時間點:已知 AC(實際花的)、PV(應該花的)、EV(完成的工作在預算中值多少)
- 例圖現況:EV 最低 → 進度落後、成本超支
- 紅線 = BAC(紙面計劃的總預算)
- 前面已延誤、已超支 → 預測完工總成本必然高於 BAC
- 偏差=已發生的差距;趨勢=基於已發生偏差做預測
PMI 術語: Estimate at Completion (EAC) ↔ 完工估算(逐字稿「ESC」為誤辨) / Variance ↔ 偏差 / Trend ↔ 趨勢
⚠ 講師口誤:00:39:10 說「進度超支成本進度」,意指「進度延誤、成本超支」。
§21 EAC 公式拆解:EAC = AC + (BAC − EV) / CPI (00:40:44)

核心: EAC = AC + (BAC − EV) / CPI —— 已花的錢 + 剩餘工作按當前成本績效還需花的錢;這是考最多的公式。
拆解步驟(講師的記憶法): 1. AC = 已經花的錢(actual cost) 2. BAC = 專案開始前的總預算,背後對應總工作量 3. BAC − EV = 總工作量的價值 − 已完成工作的價值 = 剩餘工作的(預算)價值 4. ÷ CPI = 用過去一段時間的成本績效(花錢效率)來完成剩餘工作 → 剩餘工作還需要花多少錢(= ETC) 5. + AC = 預計完成整個專案要花的總錢數 = EAC
講師原話:「BAC 減 EV 叫剩餘的工作量,除以當前我的成本表現……還需要花多少錢,加上你已經花的錢,是不是預計完成這個專案我要花的總錢數。」
🎯 考點: 題目說「按當前(典型)績效繼續」→ 用 EAC = AC + (BAC − EV)/CPI(等價於 BAC/CPI)。
補充例題(非講師原題,筆記自擬供練習):BAC = 100 萬,目前 AC = 50 萬、EV = 40 萬、PV = 45 萬。 1. CPI = EV/AC = 40/50 = 0.8(超支);SPI = EV/PV = 40/45 ≈ 0.89(落後) 2. 剩餘工作價值 = BAC − EV = 100 − 40 = 60 萬 3. ETC = 60 / 0.8 = 75 萬 4. EAC = AC + ETC = 50 + 75 = 125 萬(驗算:BAC/CPI = 100/0.8 = 125 ✓) 5. VAC = BAC − EAC = 100 − 125 = −25 萬(預計超支 25 萬)
§22 CPI = 1 特例與 ETC (00:44:24)

核心: CPI = 1 時公式簡化為 EAC = AC + (BAC − EV)(剩餘工作按原預算完成);永遠成立的通式是 EAC = AC + ETC。
- CPI = 1 代表過去實際與計劃一模一樣(講師提醒:此時用「績效」一詞不太準,應說實際=計劃)
- 除以 1 等於沒除 → 就是公式表上面那條非典型公式
- ETC = (BAC − EV) / CPI = 剩餘工作還需花多少錢
- 講師說掌握這個公式,90% 的 EVM 題都能算;其他(更複雜的公式)在 PgMP 基本不會考,PMP 幾十年也沒考幾次
PMI 術語: Estimate to Complete (ETC) ↔ 完工尚需估算
🎯 考點: EAC = AC + ETC 是萬用通式;偏差被視為「非典型/一次性」時 CPI 視為 1 → EAC = AC + BAC − EV。
§23 考試變化:認證間關聯度提高、RMP (00:46:45)

核心: PgMP 考試有變化(講師說「三月份」最明顯),PMI 系列認證之間的關聯度越來越高,PMP 知識不牢會是 PgMP 的大短板。
- 學 PgMP 時 PMP 知識不牢 → 大短板;以後學 PfMP,PgMP 知識不牢也會麻煩
- PMI 另有 RMP(Risk Management Professional,風險管理專業人士)認證,今天會拿來對照
- 風險管理最根本的東西在 PMBOK 第 6 版(第 5 版差不多)
- PMP/PgMP/PfMP 在風險概念上沒有差別,差別在實施對象:專案層面 vs 專案集下的專案 vs 組合
⚠ 新版變化: 講師提及近期(三月起)PgMP 考題更強調跨認證知識整合(未說明具體內容)。
§24 風險是中性詞;風險管理目的是雙向的 (00:47:37)

核心: 風險(risk)是中性詞;負面風險=威脅,正面風險=機會;管理目的是降低威脅、提升機會的機率和影響。
- 在 PMP、PgMP、PfMP、RMP 四個認證中定義全都一樣
- 降低消極風險發生的機率和影響;提升積極風險發生的機率和影響
- 記住是「機率和影響」兩個維度、正負雙向
講師原話:「一說風險、一說 risk,它就是中性的。」
PMI 術語: Threat ↔ 威脅 / Opportunity ↔ 機會
🎯 考點: 「風險=負面事件」的選項錯;風險管理也要提升機會。
§25 風險內嵌不確定性;假設普遍存在 (00:49:27)

核心: 風險必然和不確定性(可能性)相關;專案/專案集/組合都是獨特的、充滿假設 → 風險無處不在。
- 機率本身就是不確定性,確定了就不叫機率
- 可能性(正面)與不確定性(反面)是同一件事
- 不可能做一件事所有事情都清楚 → 一定有假設
- 任何題目都可能跟風險有關,看是否考概念
PMI 術語: Uncertainty ↔ 不確定性 / Assumption ↔ 假設
§26 風險必然影響目標:三層級目標不同 (00:51:00)

核心: 不影響目標的不叫風險;專案目標=範圍/進度/成本/質量,專案集目標=收益,組合目標=價值。
- 風險內嵌兩件事:① 不確定性 ② 對目標有影響
- 專案:scope、schedule、cost、quality
- 專案集(program):benefits
- 專案組合(portfolio):value
🎯 考點: 專案集層級的風險要以「對收益(benefits)實現的影響」來判斷。
§27 為什麼要統一的風險描述格式 (00:52:00)

核心: 風險複雜、難描述;描述格式不統一會讓大家對風險認識不一致,本身就放大風險 → 必須統一結構。
- 語言、語序、結構不統一 → 組織內各種描述,無法判斷是否被清楚理解
- 認識不一致本身就是更大的風險
講師原話:「它本來就在那,結果大家還表達不清楚……那它會擴大或者放大這個風險本身。」
§28 三要素:事件 + 機率 + 影響;風險暴露值 (00:53:34)

核心: 常見描述格式=三要素:事件(Event)+機率(Probability)+影響(Impact);機率 × 影響 = 風險暴露值(PI 值)。
- 三要素不全面,但簡單易懂
- PI 值越大,風險等級越高 → 落在機率影響矩陣深紅區;越小落在淺色區
- 高等級/低等級風險說的就是這兩個參數相乘
PMI 術語: Risk Exposure ↔ 風險暴露值 / Probability and Impact Matrix ↔ 機率影響矩陣
§29 四要素:加上原因 (00:55:51)

核心: 四要素 = 原因(Cause)+ 事件 + 機率 + 影響;原因可分觸發條件與起因兩小類。
- 四要素說法較少見
- 參數越多越全面但越難理解,參數越少越易懂但可能不全 → 平衡
§30 已知-未知 vs 未知-未知;權變措施 (00:56:45)

核心: 第一個「已知/未知」指事件,第二個指機率或影響;未知-未知(未知風險)只能發生後臨時處理=權變措施。
- 事件都未知 → 機率和影響不可能知道 → 簡稱「未知風險」,完全不可知、無法提前預防
- 臨時想辦法 = 權變措施(Workaround)
- 已知-未知:事件知道,但何時發生、影響多大不清楚 → 風險管理最主要的對象,能預防、能提前準備
PMI 術語: Known-unknowns ↔ 已知-未知 / Unknown-unknowns ↔ 未知-未知 / Workaround ↔ 權變措施(逐字稿「全面/全變」誤辨)
§31 應急計劃與應急儲備 (00:58:32)

核心: 已知-未知風險 → 提前制定應急計劃(預案),並預留錢和時間=應急儲備。
- 應急計劃一定是提前制定;臨時制定的叫權變措施
- 應急計劃要耗錢耗人耗時間 → 預留出來的錢和時間 = 應急儲備
- 儲備不只是錢,時間、物資也算
- 「應急」不是「臨時」:是提前放在手裡的一筆錢、兩天時間餘量
- 一說應急儲備,背後就意味著事件已知、機率和影響(或其一)未知
PMI 術語: Contingency Plan ↔ 應急計劃 / Contingency Reserve ↔ 應急儲備
🎯 考點: 中文「應急」易誤解為臨時 → 看到 contingency 就是「提前準備」。
§32 已知-已知:直接做成專案活動 (01:00:24)

核心: 事件、機率、影響都已知,嚴格說不算風險;處理手段叫應對措施,應直接做成專案計劃中的活動。
- 都知道會發生、知道影響,還等它發生才處理不合理
§33 風險概念小結與管理儲備 (01:00:59)

核心: 已知-未知 ↔ 應急計劃 ↔ 應急儲備;未知-未知 ↔ 權變措施 ↔ 動用公司保留的管理儲備。
- 三步:① 風險中性 ② 描述格式 ③ 機率與影響
- 已知-未知:任一(機率或影響)未知就算未知
- 未知風險發生後臨時處理=權變措施,動用公司保留的資金與時間=管理儲備
- 只要底層概念清楚,後面衍生概念都容易
PMI 術語: Management Reserve ↔ 管理儲備(逐字稿「公立儲備」誤辨)
🎯 考點: 應急儲備在 PM 權限內、用於已識別風險;管理儲備在公司/管理層、用於未知風險。
§34 整體風險 vs 單個風險;專案集整體風險最難 (01:02:57)

核心: 風險管理要同時面對單個風險與整體風險;在專案集層面,元件間依賴使整體風險極難處理。
- 整體風險=系統性風險:例如免疫系統出問題,所有系統都受破壞
- 單個風險:單一要素/方面的影響(如影響進度的某個因素)
- 專案集:元件(component)之間依賴關係越多越複雜,風險機率與影響呈幾何級數增長,甚至無法預計
- 會產生雪崩/連鎖/耦合效應;混沌(chaos,蝴蝶效應)=完全未知的狀態
- 風險管理要隨時隨地、持續開展
PMI 術語: Overall Project Risk ↔ 整體風險 / Individual Risk ↔ 單個風險(逐字稿「耽擱風險」=單個風險)
🎯 考點: 專案集風險的特色=元件間依賴與互動產生的整體/聚合風險,要在專案集層面管理。
§35 風險臨界值不是針對單一風險,而是來自組織偏好 (01:05:02)

核心: 風險臨界值不是針對單個風險設的,而是先與組織和干係人協商其偏好後確定,再作為個別風險後續行動的標尺。
- 表面是數值,背後是與組織、干係人協商研究得來
- 風險態度(attitude)是大概念,包含偏好、承受力、臨界值三個彼此關聯的概念
- 個人也有風險喜好型/迴避型之分
PMI 術語: Risk Attitude ↔ 風險態度 / Risk Threshold ↔ 風險臨界值
§36 偏好 → 承受力 → 臨界值 (01:06:28)

核心: 偏好=主觀難量化;承受力=能承擔的最大值(極值);臨界值=理性設定、低於承受力的觸發點。管理者的主要工作是把主觀偏好轉化為客觀(量化)的承受力與臨界值。
- 無法量化就無法管理 → PM/PgM/組合經理與團隊要把重要干係人和組織的主觀偏好轉為量化值
- 承受力(tolerance):最高風險程度,突破了組織就完蛋、個人就破產
- 臨界值(threshold):比承受力低的理性值;在臨界值區間內可以接受(不管),超出上限或低於下限就必須採取行動 → 是觸發條件
- 量化最好是數字:時間、資金、人頭數
| 概念 | 性質 |
|---|---|
| 偏好 appetite | 主觀、感性 |
| 承受力 tolerance | 極值(最大/最小) |
| 臨界值 threshold | 理性、經驗設定、觸發行動 |
講師原話:「臨界值不是最高值……你碰到這個臨界值,你就得採取行動,不要等到達到最嚴重的程度。」
PMI 術語: Risk Appetite ↔ 風險偏好 / Risk Tolerance ↔ 風險承受力 / Risk Threshold ↔ 風險臨界值(講師口唸 resolve 實為 threshold)
🎯 考點: 風險達到臨界值 → 採取應對行動;題目問 PgM 的職責 → 把干係人偏好轉成可量化臨界值。
§37 風險理念:韌性與安全空間 (01:09:28)

核心: 為大機率事件堅持,為小機率事件做好準備,留足安全空間 → 提升韌性。
- 安全空間越大,承受不確定衝擊的能力越強=韌性(resilience)越足
- 韌性=受到外界衝擊能恢復原狀或不受影響(個人與組織皆然)
PMI 術語: Resilience ↔ 韌性
§38 七個風險管理過程:規劃風險管理 (01:10:50)

核心: PMBOK 第 6 版的 7 個風險過程是最經典框架;第一步規劃風險管理=確定策略、方法論、分工、決策/治理機制與風險資金安排。
- 7 過程:規劃風險管理 → 識別風險 → 定性分析 → 定量分析 → 規劃應對 → 實施應對 → 監督風險
- 規劃風險管理:方法論、角色分工、決策機制、治理機制、為風險準備多少資金與如何安排
PMI 術語: Plan Risk Management ↔ 規劃風險管理
§39 識別風險:越早、越全、參與者越多越好 (01:12:05)

核心: 識別風險最好借助組織的風險庫/經驗庫/清單,並發動所有相關人參與;越早識別越好、越全面越好、參與人越多越好。
- 從零開始耗精力且難免疏漏 → 好組織有風險資料庫(過去積累)
- 不只團隊成員(太有侷限)、也不只管理團隊,而是與專案有關的所有人
講師原話:「識別風險要越早越好,越全越好,參與的人越多越好。」
🎯 考點: 「誰應參與識別風險?」→ 所有干係人(不是只有團隊或 PM)。
§40 風險登記冊的欄位 (01:13:51)

核心: 最簡單的風險登記冊=編號+事件+機率+影響;可再加原因、緊迫性、責任人、等級、應對措施。
- 欄位:ID、cause、event、probability、impact、urgency(緊迫程度)、owner(責任人)、等級、應急措施
- 從零開始就填空表;有歷史經驗就拿來再加新風險
PMI 術語: Risk Register ↔ 風險登記冊 / Risk Owner ↔ 風險責任人 / Urgency ↔ 緊迫性
§41 先定性、再定量 (01:14:48)

核心: 所有識別出的風險都做定性分析(主觀高中低);只有等級較高且具備量化條件的才進入定量分析。
- 定性給出等級後,下一步決定什麼等級對應什麼應對策略
- 進入定量的兩條件:① 等級高 ② 可量化
PMI 術語: Qualitative Risk Analysis ↔ 定性風險分析 / Quantitative Risk Analysis ↔ 定量風險分析
§42 殘餘/次生風險在規劃應對時就要預估 (01:15:45)

核心: 殘餘與次生風險在「規劃風險應對」時就要預估(預期會產生的);實施應對後則是實際產生的。
- 規劃應對針對的是預計會發生的風險,並預估實施策略後的殘餘與次生風險
- 實施應對時才實際產生殘餘與次生風險
PMI 術語: Residual Risk ↔ 殘餘風險 / Secondary Risk ↔ 次生風險(逐字稿「參與風險」=殘餘)
§43 規劃應對:風險 vs 問題的根本差別 (01:16:54)

核心: 風險管理的動作全都是提前做好的(假定會發生);問題(issue)是已發生後才處理,兩者後續邏輯不同。
PMI 術語: Issue ↔ 問題
🎯 考點: 已發生 → 問題(issue log、處理);未發生 → 風險(登記冊、應對規劃)。
§44 職場討論:處理風險的人才是高手 (01:17:36)

核心: 組織往往更認可處理問題(救火)的人,但真正高手是讓風險消失於無形的人——「善戰者無赫赫之功」。
- 風險沒發生,別人看不到你做了什麼
- 講師延伸「公地悲劇」(井田制中間公田種不好)說明不是自己的事就沒人管
§45 規劃應對 → 應急計劃,並預估殘餘/次生風險 (01:20:26)

核心: 依分析等級制定相應級別的應對;應急計劃在規劃時提前制定並寫入風險登記冊,同時假定執行後的殘餘與次生風險,必要時再為其制定應對計劃,直到可接受為止。
- 高等級風險 → 應對措施級別高;低等級 → 準備度低
- 正向、負向風險事件都要提前制定方案
- 幾乎所有應對措施都有後遺症 → 不可能一次讓風險全部消失
- 層層制定應對會沒完沒了,停在殘餘/次生風險「可接受」的位置
§46 規劃完不是立即實施,而是進入監督 (01:22:38)

核心: 規劃應對完畢後進入監督風險狀態,監督已識別風險,一旦出現苗頭或發生才啟用預定的應對計劃。
- 已識別的風險(event 已知)→ 有應對計劃可啟用
- 突發/未識別的風險 → 登記冊中沒有應對計劃 → 只能權變措施
PMI 術語: Monitor Risks ↔ 監督風險 / Implement Risk Responses ↔ 實施風險應對
§47 實施應對要走變更;規劃者與執行者不同 (01:23:31)

核心: 啟用應急計劃要提出變更請求,把方案變成專案活動才能執行;執行後關注殘餘/次生風險並更新風險登記冊。制定預案的人和實施預案的人通常不是同一人。
- 例:消防演練計劃不是你制定的,但你是執行者
PMI 術語: Change Request ↔ 變更請求 / Risk Action Owner ↔ 風險應對責任人
§48 Q&A:順序是監督在前、實施在後 (01:25:14)

核心: PMBOK 排序把實施應對(第 6)放在監督(第 7)前,但實際邏輯是規劃應對後先監督,發生了才實施;沒發生就把該風險及預案刪掉(關閉)。
- 線性理解:規劃 → 識別 → 定性 → 定量 → 規劃應對 → 監督 →(出現)實施應對 /(不出現)刪除
- 這套邏輯 PgMP、PfMP 都適用,只是風險管理對象不同(專案/專案集/組合層面)
§49 Q&A:應急計劃要走變更,權變措施不用 (01:26:46)

核心: 應急計劃須透過正式變更流程確認行動與預算後才執行;權變措施是臨時的,不需變更流程,事後可能補流程。
- 書本邏輯如此;實務上常沒時間走流程,但考試按邏輯答
🎯 考點: 「啟用應急計劃前先做什麼?」→ 提交變更請求/走變更控制;權變措施→立即處理、事後補記錄。
§50 Q&A:殘餘/次生風險例子——原油洩漏 (01:27:36)

核心: 殘餘/次生風險是否還要應對,取決於其嚴重程度(是否在可接受範圍)。
- 應對方案:用浮在海面的圍欄把原油圍起回收,不能回收的用化學製劑分解
- 殘餘風險:無法 100% 清除,剩下一些原油
- 次生風險:化學製劑對海洋造成污染
- 再下一級應對:小範圍、更環保的手段處理 → 可能再產生殘餘/次生,直到可接受為止
- 延伸例:核污水排放同樣有殘餘與次生風險
§51 RMP 的五個過程 vs PMBOK 六版七個過程 (01:29:53)

核心: RMP 把 7 個過程簡化為 5 個:定性+定量合併為「分析」,規劃應對+實施應對合併為「應對」,並多了「關閉」。
- RMP 五過程:風險策略與規劃 → 風險識別 → 風險分析 → 風險應對 → 監督和關閉
- 專案集風險管理同樣有「關閉」
- 學好 PMBOK 經典風險管理,PgMP/PfMP 都通用
⚠ 新版變化: 講師指出 RMP(及專案集)框架多出「關閉(closing)」環節,與 PMBOK 6 七過程不同。
Part B (01:31:00 - 02:55:07) 綜述
這段分兩堂:前 19 分鐘收尾「風險管理」補充課,後 65 分鐘是「敏捷補充」課(其中穿插一段採購流程)。本段沒有講 EVM,也沒有提 ECO 權重。
風險部分以 PMBOK 第六版的 7 個風險過程為主線:風險登記冊怎麼一步步長出內容(識別→定性→定量→規劃應對),應急計畫、彈回計畫(fallback)、殘餘風險、次生風險、觸發條件,講師說「規劃風險應對」是整個風險管理最難的一步。他特別強調風險管理要讓相關方(stakeholders)都參與進來,不能只停在 team 層級;應對策略是新版的「5+5=10 種」(威脅、機會各 5 種,上報、接受兩邊共用),並用地震的例子說明規避和減輕怎麼分。最後回到 program 層級:標準裡的風險章節「寫得很亂」,考試不考過程順序,只考概念;program 管的是 program 層級加上元件層級的重大風險,元件層級的一般風險交給專案經理。
敏捷部分講的是基本素養:4 個價值觀、12 原則、MVP、基於迭代和基於流程(flow-based)的敏捷、傳統鐵三角和敏捷倒三角的對比、Scrum 的 3 角色/2 工件+1 增量/4 會議、看板拉動式生產、DoD,以及敏捷合同。講師把敏捷和 program 連起來:program 和敏捷一樣不鎖範圍、追求收益(價值)最大化,所以兩者相容度高。
最重要的考點判準: 1. 規避針對「事件」(把事件 100% 消掉),減輕針對「機率/影響」;天災類風險通常只能減輕影響。 2. 風險題的主角多半是 stakeholders,不是 team。 3. program 只管 program 層級和元件層級的重大風險,一般元件風險交給 PM;考概念,不考過程順序。 4. 敏捷的價值 ≈ program 的收益;program 和敏捷一樣讓範圍保持彈性,目標是收益最大化。 5. 在 PgMP 考試裡,敏捷只要求讀得懂題幹用語(sprint、backlog、retrospective、DoD 等),不會深考。
§52 風險管理總體邏輯:從計畫到登記冊 (01:31:00)

核心: 風險管理照「規劃 → 識別 → 定性 → 定量 → 規劃應對 → 實施應對 → 監督」走,單一風險記在登記冊,整體風險記在報告。
- 先有風險管理計畫(Risk Management Plan),後面每一步都照它的方法論做,定性和定量分析的依據也都是這份計畫。
- 識別出的風險寫進風險登記冊(Risk Register),定性、定量分析做完後,結果再一層層補進登記冊。
- 風險報告(Risk Report)是第六版新增的,反映整體項目風險;單一風險在登記冊裡。講師提醒不要把兩者搞混,否則邏輯會亂。
- 規劃風險應對的產出是應急計畫;風險真的發生時才「實施風險應對」,這時要提變更請求,把計畫裡的資源和時間正式排進進度。
PMI 術語: Risk Register ↔ 風險登記冊 / Risk Report ↔ 風險報告 / Implement Risk Responses ↔ 實施風險應對
§53 風險登記冊的演變:識別與定性分析 (01:32:48)

核心: 識別階段就寫入風險清單、初步責任人和潛在應對措施;定性分析再補上機率、影響、優先順序、分類和緊迫性。
- 識別風險後,登記冊裡有風險清單、風險應對責任人(先初步指定)和潛在應對措施。有些風險一識別出來,怎麼應對就已經很清楚了。
- 定性分析估出每個風險的機率和影響,再用這兩個值排出優先順序。
- 分數(score)對應等級(rating),例如 100~120 分算「超高」、90~100 分算「高」。
- 除了機率和影響,還可以加上緊迫性(Urgency),以及風險類別(商務、物流、自然環境等)。
- 高等級風險直接制定應對措施;低等級風險放進觀察清單就好。
PMI 術語: Probability and Impact ↔ 機率與影響 / Urgency ↔ 緊迫性 / Watch List ↔ 觀察清單
§54 規劃應對:應急、彈回、殘餘與次生風險 (01:34:29)

核心: 高等級風險要有應急計畫,應急計畫無效時再啟用彈回計畫;另外還要分析殘餘風險和次生風險,用臨界值決定要不要再制定應對。
- 應急計畫(contingency plan)不一定只有一個。
- 應急計畫執行後效果不好或無效,就啟用彈回計畫(fallback plan)。
- 還要分析應對之後剩下的殘餘風險(residual risk),以及應對本身帶出的次生風險(secondary risk)。
- 殘餘風險和次生風險要不要再做應對,看它們的嚴重程度和事先定好的臨界值(threshold)。
PMI 術語: Contingency Plan ↔ 應急計畫 / Fallback Plan ↔ 彈回計畫 / Residual Risk ↔ 殘餘風險 / Secondary Risk ↔ 次生風險 / Threshold ↔ 臨界值
§55 觸發條件與預算:為什麼規劃應對最難 (01:35:07)

核心: 重大風險不能等它發生才處理。要把預警訊號(觸發條件)寫進登記冊,並先替每個應對行動編好預算和時間估算。
- 如果能提前兩三天察覺訊號(例如環境狀態、網路狀態),就把觸發條件一條條寫進登記冊。
- 所有應對行動都要先估好預算和時間;風險一出現,就把預算拿出來、把時間排進行動計畫。
- 規劃風險應對是整個風險管理中難度最高的一步,因為前面所有的分析都要在這裡變成具體方案。
PMI 術語: Trigger Condition ↔ 觸發條件 / Warning Sign ↔ 預警訊號
§56 Q&A:應急計畫一定要等風險發生才執行嗎 (01:36:40)

核心: 一般情況下風險發生後才啟用應急計畫,但如果預警訊號已經出現,可以提前啟動。
- 風險報告反映的是整體風險狀況。
- 例子:地鐵在暴雨來臨前先放好沙袋。正常下雨可以預判,所以能提前啟動計畫。北京 7·31 那種罕見的特大暴雨,計畫根本沒想到,就無從啟動。
- 結論:應急計畫不一定要等風險發生後才啟動,觸發條件出現就可以啟動。
§57 7 個風險過程都看得到相關方分析 (01:37:51)

核心: 風險各過程的 ITTO 裡反覆出現相關方分析、相關方登記冊和人際關係技能。這代表風險管理不能只停在 team 層級。
- 講師說,這裡最能看出當初教你 PMP 的老師水準怎麼樣:為什麼規劃風險要做相關方分析?
- 相關方登記冊、訪談、人際關係技能、影響力、經驗教訓在多個風險過程裡都會出現。
- 風險管理千萬不要只管自己能直接管理的團隊成員。這裡說的是 stakeholders,其中很多人不在你的團隊裡。
§58 第七版明說:風險管理要讓所有相關方參與 (01:39:40)

核心: 講師參與過 PMBOK 第七版的編寫。他說第七版直接寫明:風險管理要讓所有人、至少大部分人參與進來。
- 舊版只是隱含這個意思,第七版明確寫出來了。
- 很多風險題的主角是 stakeholders,不是 teams。
⚠ 新版變化: 舊版只是隱含「相關方參與風險管理」;第七版改成明文要求。
🎯 考點: 風險題問「該讓誰參與/該找誰」時,優先選範圍更廣的 stakeholders,不要只選 team。
§59 風險應對策略 5+5=10 種 (01:40:06)

核心: 新版共 10 種策略:威脅有規避、轉移、減輕、上報、接受;機會有開拓、分享、提高、上報、接受。
- 上報和接受兩邊都有,所以共用的是 4 個(各 2),再加上各自獨有的 3 個。
- 看到用詞就能判斷是威脅還是機會:規避/轉移/減輕 = 威脅;提高/分享/開拓 = 機會。
- 題目選項的用詞本身就透露這個風險是好事還是壞事。
PMI 術語: Avoid / Transfer / Mitigate ↔ 規避/轉移/減輕 / Exploit / Share / Enhance ↔ 開拓/分享/提高 / Escalate / Accept ↔ 上報/接受
⚠ 新版變化: 上報(Escalate)是新加入的策略,所以每類從 4 種變成 5 種。
§60 規避 vs 減輕:地震的例子 (01:41:13)

核心: 規避針對「事件」,要把事件 100% 消掉;減輕針對「機率或影響」。地震這類天災無法規避,機率也控制不了,只能減輕影響。
- 風險有三要素:事件、機率、影響。
- 地震就發生在你所在的地方時,你沒辦法讓它不發生,所以不能規避。只有「搬走/不去旅行」這類情況才談得上規避。
- 地震目前無法 100% 預測,最多提前 3~5 秒預警,所以在事件和機率上花資源都沒用。
- 實務上都說「災後」,策略重點放在降低影響(減輕)。接受是當下承受,結束後還是要把影響降到最低。
🎯 考點: 判斷是規避還是減輕時,先問「能不能讓事件根本不發生」。不能的話就選減輕。天災類題目的答案通常是降低影響。
§61 風險概念全景清單 (01:43:41)

核心: 風險部分要掌握的概念:10 種策略、應急計畫、彈回計畫、應急儲備、管理儲備、已知-已知、已知-未知、未知-未知、風險三/四要素,以及 7 個過程。
- 應急儲備對應已知-未知(known-unknowns);管理儲備對應未知-未知(unknown-unknowns)。這是 PMI 的標準對應,講師只列了名詞,沒有展開說明。
- 講師說這些掌握了,風險就「一切盡在掌握」。
PMI 術語: Contingency Reserve ↔ 應急儲備 / Management Reserve ↔ 管理儲備 / Known-unknowns / Unknown-unknowns ↔ 已知未知/未知未知
§62 Program 層級風險:標準寫得亂,但概念不變 (01:44:10)

核心: Standard for Program Management 的風險章節「講得非常亂」,但基本概念和構成要素沒變。
- 初始風險評估對應 program 風險管理策略。講師之前講過這個策略分 4 步。
- 其中一步:在 business case 或 program charter 裡,把風險偏好(risk appetite)轉成臨界值(threshold)。
- 標準裡的流程是:program 風險管理規劃 → 風險監督與控制(包含識別、分析、應對管理)→ 風險移交。
PMI 術語: Risk Appetite ↔ 風險偏好 / Program Risk Management Strategy ↔ 專案集風險管理策略 / Program Charter ↔ 專案集章程
🎯 考點: 風險偏好是在 business case/charter 階段轉成臨界值的。
§63 考試不考過程順序;Program 只管重大風險 (01:45:21)

核心: PgMP 不會考「下一個過程是什麼」,幾乎全考概念。program 負責 program 層級和元件層級的重大風險,元件層級的一般風險交給專案經理。
- 概念用 PMBOK 第六版理清楚,考 program 時直接套用就行。
- 講師說「這個抓住就行」:program 經理不管元件層級的一般風險。
講師原話:「專案級的風險管理,針對的是專案級層面的,以及組件層面的重大風險;組件層面的一般風險,是交給專案經理去管的。」
🎯 考點: 題目是元件層級的一般風險時,program 經理應該讓 PM 去處理,不要自己接手;元件層級的重大風險或跨元件的風險,才由 program 層級管理。
§64 Program 風險 4 過程對應生命週期子階段 (01:45:58)

核心: program 風險共 4 個過程:初始評估和規劃在「構建」子階段,監督與控制在「交付」子階段,移交在「收尾」子階段。
- ① 風險初始評估、② 風險管理規劃:program 構建/規劃子階段。
- ③ 風險監督與控制:交付階段。
- ④ 風險移交與關閉:收尾階段。
- 講師批評標準把識別、分析、應對都塞進監督裡。他認為應該在前面就做識別、分析、規劃,交付階段只做應對和監督。
- 講師建議用第六版的風險過程來理解,會比讀 program 標準清楚很多。
⚠ 新版變化: Standard 5th 把 program 風險重新定義成 4 個過程,並對應到子階段。講師認為這個定義「沒有定好」。
§65 Q&A:RMP 難度與 PMI 報考制度 (01:47:33)

核心: 講師認為 RMP 是中等難度,和 PgMP 不在同一個量級,可能比現在的 PMP 還簡單。
- RMP 只有一本風險管理實踐指南,而且不直接考;題目依據考綱出,考綱只有約 7 頁。
- 現在的 PMP 偏難,因為要求提高,而第七版「已經天下大亂、沒有結構」。
- 講師提到「8 月份以後 PMI 不接受個人報考,只能經授權機構報名、經 PMI 稽核後才能考」。⚠ 這應該是講師所在地區(中國)的報考安排,不一定適用台灣考生,請自行查證。
§66 敏捷課開場:敏捷和專案管理是兩大領域 (01:49:47)

核心: 敏捷和專案管理是可以並駕齊驅的兩大領域。PMI 的做法是把敏捷吸納進來,稱為「敏捷專案管理」。
- 學敏捷、用敏捷的人認為「敏捷就是敏捷」,沒有所謂的敏捷專案管理。
- PMBOK 第七版改版後敏捷占比很高,約 50%,現在逐漸回落。
- 講師聽 PMI 的人說:PMBOK 第八版是對第六版的「回歸」,很多內容回到第六版的架構,編修工作已經開始。
⚠ 新版變化: 第七版敏捷占比約 50%;第八版據說回歸第六版的架構(講師轉述)。
§67 敏捷的由來與考試定位 (01:51:07)

核心: 敏捷原本叫「輕量級方法」,因為怕被輕視,2001 年改名 Agile。考試只要知道基本概念,不必深入。
- 在 PMI 的知識體系裡,敏捷包含來自精益(Lean)的東西,例如看板(Kanban),也包含流程化敏捷。
- 精益、專案管理、敏捷三方都認為另外兩方是自己的一部分。
- 講師說考試時「不用把它看得太重」。
PMI 術語: Agile ↔ 敏捷 / Lean ↔ 精益 / Kanban ↔ 看板
§68 敏捷的層次與代表性實踐 (01:52:19)

核心: 敏捷分層次:理念 → 原則 → 實踐。實踐多達兩三千種,最有代表性、最成功的是 Scrum。
- 其他代表性實踐:XP(極限程式設計)、DA(Disciplined Agile,規範敏捷)、DevOps。規模化敏捷有 SAFe、LeSS 等。
- 講師曾想在中國推廣 PMI 的 DA,沒推起來。他的解釋是敏捷的根源不在 PMI,PMI 收購了相關公司但整合困難;相比之下,PMO-CP 和 PMI 的整合度就高得多。
PMI 術語: Scrum / XP (eXtreme Programming) ↔ 極限程式設計 / Disciplined Agile (DA) ↔ 規範敏捷 / Scaled Agile ↔ 規模化敏捷
§69 敏捷的核心:儘早交付價值、MVP (01:54:01)

核心: 在 PMI 的視角,敏捷是一種專案管理方式,重點是儘早交付有價值的東西,小步快跑、迭代加增量,先交 MVP。
- 做題時不必區分「敏捷」和「敏捷專案管理」,一律叫敏捷。
- 比喻是新創公司:先推出一個大概能用的產品,邊用邊收集回饋、邊優化。
- MVP(minimum viable product)有很多變體,例如最小可用功能(MVF)。
- 例子:微信剛上線時功能很少,後來才長成一個大生態。
PMI 術語: MVP (Minimum Viable Product) ↔ 最小可行產品 / Iterative / Incremental ↔ 迭代式/增量式
§70 敏捷興起的背景與方法演進 (01:55:32)

核心: 時代變化快,產品生命週期從十幾二十年縮短到兩三年,管理方式也要跟著調整。方法演進是:預測型(瀑布)→ 迭代/增量(敏捷)→ 混合型。
- 背景:工業化時代 → 網際網路 → 行動網際網路 → AI 浪潮,顛覆性變化已經是常態。
- 瀑布型 ≈ 預測型;迭代加增量合起來 ≈ 敏捷型;混合型 = 預測加迭代加增量的組合。
PMI 術語: Predictive (Waterfall) ↔ 預測型 / Adaptive / Agile ↔ 適應型/敏捷 / Hybrid ↔ 混合型
§71 敏捷的層次:Mindset → 價值觀 → 原則 → 實踐 (01:56:53)

核心: 敏捷是一套理念(Mindset)、4 大價值觀、12 大原則加上千種實踐的集合體。敏捷不等於「快」,重點是對變化及時反應、調整(adaptive)。
- 專業的人要分辨別人談的是敏捷的實踐、理念、價值觀,還是原則。
- 建議的學習順序:核心理念 → 價值觀 → 原則 → 實踐。
PMI 術語: Agile Mindset ↔ 敏捷思維 / Adaptive ↔ 適應性
§72 Scrum 常用術語與考試閱讀要求 (01:58:26)

核心: 最普及的是 Scrum 的概念:衝刺(sprint)、待辦事項列表(backlog,分產品、衝刺、版本等)。考試不考細節,但要讀得懂題幹裡描述的是敏捷。
- backlog 就是「還沒做完的事情清單」。
- 其他實踐:結對程式設計、看板的「停止啟動、開始完成」、拉動式生產、水晶方法(Crystal)等。
- 考試的重點是讀題幹時能看出:它描述的是一種有別於傳統專案管理的新方法,也就是敏捷(agile)。
PMI 術語: Sprint ↔ 衝刺 / Product Backlog ↔ 產品待辦事項列表 / Sprint Backlog ↔ 衝刺待辦事項列表 / Pair Programming ↔ 結對程式設計
🎯 考點: 敏捷在 PgMP 的考法是「題幹用語」。看到 sprint、backlog、iteration 這類詞,知道情境是敏捷就夠了。
§73 敏捷價值觀(一):個體互動、可用的產品 (01:59:56)

核心: 4 句價值觀考到的機率很低,但要懂背後的理念:個體和互動高於流程和工具,可用的軟體高於詳盡的文件。
- 並不是不要流程和工具,而是個體互動的優先順序更高。
- 講師要大家辯證地看:高鐵、大飛機、通訊底層這類工業級軟體不允許迭代試錯,「會出人命」。
- 但這個觀念本身很好:一個能用的東西,遠比寫得很詳細的說明文件重要。這也符合 MVP 的精神。
講師原話:「一個能用的東西,遠比你寫一些說明文件寫得很詳細要更重要一點。」
§74 敏捷價值觀(二):客戶協作、回應變化 (02:01:29)

核心: 客戶協作(Customer Collaboration)高於合同談判,回應變化高於遵循計畫。講師認為敏捷比較務實。
- 合同談判容易讓雙方像仇人一樣逐條計較;協作是雙方發自內心願意一起做事。
- 敏捷更看重客戶、工作成果,以及對變化的感知和調整,而不是「不管怎樣計畫都不動」。
PMI 術語: Customer Collaboration ↔ 客戶協作 / Responding to Change ↔ 回應變化
§75 12 原則的核心:以人為本、持續交付價值 (02:02:33)

核心: 12 原則的核心是「以人為本、以創造價值為出發點」。價值不必等到最後一次交付,過程中就可以持續交付。
- 敏捷比傳統方法更關心人(包括團隊和客戶):人開心、舒服,才能創造更多價值。
- 及早並持續交付價值,客戶滿意的頻率會比最後一次交付更高。
§76 基於迭代 vs 基於流程的敏捷 (02:03:26)

核心: 基於迭代的敏捷(例如 Scrum)固定時長(2~4 週)、強調節奏;基於流程的敏捷(例如看板,源自精益)時長不固定,用在製品上限(WIP)讓流動不停頓。
- 固定時長讓團隊養成規律節奏(pace),容易進入心流狀態。
- 講師的判斷規則:在敏捷裡,時間對成本的影響最大;傳統方法裡則是範圍對成本的影響最大。
- flow-based 的每一步時長不固定,但每個環節可處理的工作量穩定。重點是用 WIP(Work in Process)上限讓每個環節保持最佳狀態。
- 精益的「瘦」不是骨瘦如柴,而是沒有多餘的東西、狀態最好。PMI 把迭代和流程兩種都歸為敏捷。
PMI 術語: Iteration-based Agile ↔ 基於迭代的敏捷 / Flow-based Agile ↔ 基於流程的敏捷 / WIP (Work in Process) ↔ 在製品 / Cadence/Pace ↔ 節奏
§77 傳統鐵三角 vs 敏捷倒三角 (02:06:18)

核心: 傳統方法是範圍決定進度和成本;敏捷把範圍、進度、成本都當成約束條件,目標是交付價值,質量則是不能偏離的底線。
- 傳統(預測型)方法:範圍、進度、成本加上中間的質量。
- 源自 DSDM(動態系統開發方法):鎖定成本或進度,放開範圍,依優先順序決定做哪些。意思是「我就這麼多錢、這麼多時間,你告訴我先做哪幾項」。
- 後來演進成敏捷三角:進度、成本、範圍都是約束,主要目標是交付可用的產品(價值)。
PMI 術語: Triple Constraint ↔ 三重約束 / DSDM (Dynamic Systems Development Method) ↔ 動態系統開發方法
§78 敏捷的價值 ≈ Program 的收益 (02:07:50)

核心: 敏捷的「價值」可以理解成 program 的「收益」。program 和敏捷一樣不想鎖死範圍,追求收益最大化,所以兩者相容度高。
- 講師之前說過:program 不特別想鎖定範圍,範圍可以開放,只要收益最大化就好,但不能犧牲質量。
- 價值指可發布的產品或功能(最小可用產品、最高價值功能);質量是「可靠、有彈性、有韌性」就好。
- 傳統專案把範圍、進度、成本當成三大基準和目標;敏捷只把它們當約束。所以敏捷和 program 管理相容。
講師原話:「專案集其實不是特別想把範圍鎖定,它想關注的是收益最大化。」
🎯 考點: program 題裡出現「範圍彈性、優先追求收益」這類敘述,通常是對的。program 範圍跟著收益走,不是固定基準。
§79 鍍金說的是範圍;範圍重效果、進度成本重效率 (02:08:40)

核心: 質量要「剛剛好」,太多或太少都不好。鍍金(gold plating)指的是在客戶要的範圍之外多做東西,說的是範圍擴大,不是質量。
- 範圍和質量有關聯:質量可以看成一種特殊的範圍,也就是某個特性要達到的水準。
- 範圍和質量看的是效果(effectiveness);進度和成本看的是效率(efficiency)。
PMI 術語: Gold Plating ↔ 鍍金 / Effectiveness ↔ 效果 / Efficiency ↔ 效率
🎯 考點: 鍍金 = 做了客戶沒要求的範圍。題目描述「額外加功能討好客戶」時,答案是鍍金,不算好的質量管理。
§80 整合領域:合作的團隊與服務型 PM (02:11:32)

核心: 迭代和敏捷方法讓團隊成員以專家身份合作、自行決定工作。在適應型環境裡仍然可以有 PM,但 PM 靠領導力和授權做事,不是靠發號施令。
- 敏捷團隊裡沒有固定的權威,每個人都是自己領域的高手,在被尊重的環境中合作。
- 等級森嚴、指令型的環境不會出現典型的敏捷。
- 適應型環境的 PM 仍然對專案成敗負最終責任,但會授權團隊、一起決策、分享權力。
PMI 術語: Adaptive Environment ↔ 適應型環境 / Empowerment ↔ 授權
§81 範圍領域:擁抱變化,新需求等量替換 (02:13:37)

核心: 敏捷把需求變化當成做出客戶真正想要的產品的機會。有新需求進來時,重新排優先順序,用新需求等量替換低優先順序的需求。
- 一開始不要管太多遠期細節,先看眼前、一步一步做。
- 變化是敏捷固有的一部分。越接近結束時提出的需求,往往越接近客戶最想要的東西。
- 例子:清單上原本有 20 項,來了第 21 項,就重新排 21 項的優先順序,排到最後的那項就丟掉。
§82 產品待辦與衝刺待辦:近細遠粗 (02:16:04)

核心: 產品待辦對應整個產品,衝刺待辦只對應眼前 2~4 週。用「先把最近兩週做好」的方式管理範圍。
- 一年 52 週,以兩週為單位就是 26 個衝刺。
- 遠期的事先擺著,只把接下來 2~4 週的事情和優先順序搞清楚。
§83 進度領域:Scrum 名稱由來與 3 個角色 (02:17:51)

核心: Scrum 這個詞來自英式橄欖球的爭球:大家朝同一個目標努力,場上沒有人指揮。三個角色是 Scrum Master、Product Owner、Team,沒有第四個。
- 教練在場邊管不到場上;隊長是大家認可的,不是上面指派的。
- PO 面向客戶和市場,傳遞需求並排優先順序,但不干預團隊怎麼開發。
- Scrum Master(敏捷教練)替團隊排除組織內外和人際之間的障礙,不直接參與開發,負責輔導。
- Team 自己決定兩週內先做什麼、後做什麼。
- Scrum 裡沒有 PMO 和專案經理這兩個名稱。
PMI 術語: Scrum Master ↔ 敏捷教練 / Product Owner (PO) ↔ 產品負責人 / Development Team ↔ 開發團隊
§84 Scrum 工件與節奏 (02:20:54)

核心: 工件有產品待辦事項列表、衝刺待辦事項列表,加上每個衝刺的產出:可交付且可用的產品增量(increment)。
- 把總需求切成兩週一段的小片,排好優先順序後交給團隊。
- 衝刺第一天用半天規劃接下來兩週,之後逐項完成。週期 2~4 週,兩週最常見。
- 每個衝刺結束時交出的增量必須可用,交出不能用的東西不算數。
- 文件很少,基本上就這兩份 backlog。
PMI 術語: Increment ↔ 產品增量
§85 Scrum 會議 (02:22:16)

核心: 會議包括衝刺規劃會、每日站會、評審會、回顧會。評審會向 PO 或客戶展示成果,回顧會總結經驗。
- 評審會上提出的問題和建議會加進下一輪 backlog,優先順序高的在下一個衝刺做。
- Scrum 適合小規模團隊、以兩週為粒度做事,是最流行的敏捷實踐。
- 推薦書:Jeff Sutherland 的《敏捷革命》(Scrum: The Art of Doing Twice the Work in Half the Time)。
PMI 術語: Sprint Planning ↔ 衝刺規劃會 / Daily Stand-up ↔ 每日站會 / Sprint Review ↔ 衝刺評審會 / Retrospective ↔ 回顧會
§86 看板與拉動式生產 (02:23:43)

核心: 看板把工作做成視覺化的實體或電子看板,每一欄設 WIP 上限。後面的環節有空才向前面「拉」工作,這就是拉動式生產,源自豐田生產方式。
- 某欄的上限是 3,已經放滿 3 項,就不能再傳工作過來;還有空位才拉新的工作。
- 對比:福特式的推動式生產是前端往後推。
PMI 術語: Kanban Board ↔ 看板 / Pull System ↔ 拉動式生產 / WIP Limit ↔ 在製品上限
§87 進度:時間盒鎖死,速度逐漸穩定 (02:25:15)

核心: 敏捷的範圍可變,但時間要鎖死。決定兩週一個衝刺之後就一直維持兩週,讓團隊的產能(故事點/工作量)經過 2~3 次迭代後穩定下來。
- 時間盒(timebox)就是那兩週。
- 頭幾次可能做不完或做太少,經過幾次迭代後,團隊就知道兩週能做多少。
PMI 術語: Timebox ↔ 時間盒 / Velocity ↔ 速度 / Story Points ↔ 故事點
§88 敏捷發布規劃與使用者故事 (02:26:20)

核心: 發布規劃是「遠期粗略、近期詳細」:路線圖 → 版本 1/2/3 → 只細化版本 1 的迭代 0、1 → 功能 → 使用者故事。
- 敏捷用使用者故事(user story)描述需求;傳統方法用需求說明書或功能點。
- 一個迭代 2 週 = 10 個工作日 × 8 小時 = 80 小時,所以也叫「80 小時原則」。
PMI 術語: Release Planning ↔ 發布規劃 / Roadmap ↔ 路線圖 / User Story ↔ 使用者故事
§89 成本:敏捷是進度決定成本 (02:27:45)

核心: 傳統方法是範圍對進度和成本影響最大;敏捷正好相反,進度對成本和範圍影響最大。時間鎖定、人數固定後,成本就確定了。
- IT 領域人力是最大的成本,所以時間一鎖定,成本跟著確定。
- 敏捷不追求完美和完整,追求每次都做最重要的那幾件事;任何時候停下來,最重要的事都已經做完。
- 新增需求要換掉等量的需求才能持續下去。講師也承認,現實中原本的需求常常還是要做完,這時就不好管。
🎯 考點: 傳統方法是範圍驅動成本;敏捷是時間(進度)驅動成本。
§90 質量:DoD 內嵌在每個衝刺 (02:30:21)

核心: 敏捷的質量內嵌在每個環節裡,用 DoD(Definition of Done,完工定義)確認每個衝刺做完的標準;傳統方法則把質量當成獨立的一項工作。
- 迭代和衝刺可以看成同一件事,就是那兩週。
- 在變更成本還低的早期衝刺,先開發、測試高風險、不確定性高的功能(試錯)。但有些情境不允許試錯。
PMI 術語: Definition of Done (DoD) ↔ 完工定義
§91 擁抱變化也要對齊組織戰略 (02:31:37)

核心: 敏捷擁抱變化,但變化也要和組織戰略一致。每次有變化進來都要重排優先順序,確保永遠在做價值最高的事;不過時間盒之內不接受變化。
- 兩週時間盒之內不處理新的變化,否則工作沒辦法推進。
🎯 考點: 敏捷題的「變化」也要對齊戰略、重排優先順序。衝刺進行中不隨意插單。
§92 Scrum 速記:3 角色、4 會議、2 文件、1 成果 (02:32:28)

核心: 講師的記法是 3 個角色、4 個會議、2 份文件、1 個成果。
- 角色:PO、Scrum Master、團隊。
- 會議:迭代規劃會、每日站會(只同步昨天做了什麼、今天要做什麼、遇到什麼障礙,會上不討論)、迭代評審會、迭代回顧會。有的說法是 5 個會,多一個產品規劃會。
- 文件:product backlog、迭代 backlog。
- 成果:每個週期交出可用的最小產品或功能。
- 敏捷沒有「完成 50%」的說法:進度只有 0 或 1,不能用的就等於沒做完。
講師原話:「在敏捷當中沒有 50% 的進度,要麼是零、要麼是一。」
🎯 考點: 敏捷的進度用可用的增量來衡量,不按完成百分比算。
§93 資源:自組織團隊與僕人式領導 (02:34:15)

核心: 敏捷以人為中心,團隊自組織、自管理。PM 或 Scrum Master 擔任僕人式領導者(servant leader);團隊是網狀結構,沒有指定的中心節點。
- 誰最擅長某件事,就由誰帶大家做。領袖在合作過程中自然產生,不是指派的。
- 盡量評價整個團隊,不評價個人。
- 團隊要具備完整的跨職能能力,不必向外求助。
- 產品團隊是長期團隊,專案團隊是臨時團隊。
- 團隊規模原則是 7±2。
PMI 術語: Servant Leadership ↔ 僕人式領導 / Self-organizing Team ↔ 自組織團隊 / Cross-functional ↔ 跨職能
§94 溝通:面對面、剛好夠用的文件、用演示代替報告 (02:36:23)

核心: 敏捷認為面對面溝通最好(可以參考 Mehrabian 法則:語調、肢體、文字同時傳遞)。文件剛好夠用,不開沒用的會,用演示可用成果代替文件或 PPT 匯報。
- 能用就是完成,不能用就是沒完成。
§95 敏捷很少談願景使命,規模化有悖論 (02:37:26)

核心: 敏捷很少談願景、使命、戰略這類宏大的東西,小型團隊的效果最好;規模化敏捷本身就有悖論,規模越大越難敏捷。
- 大團隊可以拆成多個小團隊,用 Scrum of Scrums 協調。
- 產品層面才談 roadmap、product vision,再往上是 MVV(Mission、Vision、Values)。
- Scrum 只涵蓋團隊接下任務後的後半段工作。
PMI 術語: Scrum of Scrums / Product Vision ↔ 產品願景 / MVV ↔ 使命、願景、價值觀
§96 敏捷中的風險:切小塊就是在分散風險 (02:39:08)

核心: 敏捷本身就是為了應對變化:快速失敗、換方法,基本上能避免災難性損失。把工作切成小塊就是在分散風險,增量交付優先順序最高的價值。
- 比喻:傳統方法像衛青打陣地戰、殲滅戰;敏捷像霍去病帶輕騎「小而快、小而美」,出其不意。
- 避免到最後才承擔整體失敗的風險。
§97 敏捷採購與合同 (02:40:36)

核心: 敏捷情境下合同不好簽,可以用敏捷合同:新增的內容替換掉不要的內容;穩定的部分簽固定總價,可變的部分簽彈性(例如按量計價),讓主體合同保持穩定。
- 敏捷採購可以由團隊自己決定買什麼,不經公司集中採購。這比較適合 IT 這類以腦力工作為主的專案,大型工程不適用。
- 每個迭代結束時評審可用的產品功能,和供應商的合作就能在更小的單元內完成。
PMI 術語: Agile Contracting ↔ 敏捷合同 / Fixed-price ↔ 固定總價
§98 國際招投標流程:發標前 (02:42:15)

核心: 採購題考得不多,但常出現。PMI 證照都是國際專案背景:簽約前只有「採購方」和「潛在賣方」,簽約後才有甲乙方。
- 買方發布招標(Tender),內部組成採購團隊,和潛在賣方還沒有任何關係。
- 採購團隊(常有專家參與)制定招標書和評標標準。
- 不會把標書發給市場上所有公司,先做市場調查和初步篩選,建立合格名單。
- 只把招標文件發給名單上的公司,並舉行澄清說明。
PMI 術語: Tender / RFP ↔ 招標書 / Source Selection Criteria ↔ 評標標準 / Qualified Seller List ↔ 合格賣方名單 / Bidder Conference ↔ 投標人會議
§99 投標、開標、評估、短名單、談判簽約 (02:44:04)

核心: 流程是:潛在賣方準備技術和商務標書並投標 → 公開開標、宣布報價 → 評估 → 短名單(2~3 家)→ 到現場參觀、看演示 → 選出 1 家 → 談判細節 → 簽約。
- 招標說明會(投標人會議)在交標書之前舉行,目的是讓大家對招標內容理解一致。
- 開標時公開宣布各家報價和技術方案,價格最重要。
- 進入短名單的廠商,要實地考察工廠,看他們有沒有做過類似專案的實績和演示。
- 國內的流程略有不同。
🎯 考點: 判斷採購題的順序:準備標書是買方的事 → 發標後潛在賣方才出現 → 投標人會議在投標之前 → 開標、評估 → 短名單 → 談判 → 簽約。
§100 團隊:直接互動、高度透明 (02:46:39)

核心: 適應型團隊直接和相關方互動,不經過一層層轉述。每多一個傳遞環節資訊就會流失,所以要保持高度透明,看板就是視覺化、透明的工具。
- 例子:特種兵執行任務時,每個人看到的情況都即時同步給所有人。
- 視覺化能避開語言和文字的障礙,加快資訊分享。
§101 敏捷在 PgMP 的考法回顧 (02:48:11)

核心: PgMP 考敏捷,通常是題幹裡出現敏捷用語,看到不陌生就達成目的了。和 PgMP 結合度最高的一點是:program 對範圍的看法也是靈活的。
- 要認得的詞:SCRUM、sprint、iteration、Retrospective、Review、Daily Stand-up Meeting。
- 12 原則和 4 價值觀要多讀幾遍,體會其中的精神(講師說會請班主任發資料)。
講師原話:「和 PG 結合度最高的,就是專案集管理對範圍,它認為也是靈活的。」
🎯 考點: program 範圍和敏捷一樣具彈性。敏捷題不會深考,讀懂題幹用語就夠。
§102 Q&A:敏捷不只是快;變更不走僵化流程 (02:50:37)

核心: 敏捷不只是快,重點是對變化敏感並及時應對(reactive/adaptive)。傳統方法重範圍(重視 WBS),敏捷重進度和時間節奏;變更不必先走完審批流程,相信團隊的判斷。
- 前提是團隊成熟、每個人都是行家而且高度投入。新手團隊做不起來,反而會亂。
- 敏捷對人的素質要求很高,有極客精神的人在敏捷團隊會如魚得水。
§103 Q&A:範圍沒做完能結案嗎?混合型才是現實 (02:52:29)

核心: 敏捷原則上不必把範圍做完就能結束,客戶說結束就結束。因為每次都做優先順序最高的事,不管什麼時候結束,最重要的事都已經完成。
- 前提假設是需求(使用者故事)之間相互獨立、低耦合。需求彼此耦合時,敏捷就失去優勢。
- 實務上多半是敏捷和傳統方法混合:用敏捷管過程很常見,完全用敏捷做所有事的很少。
- 敏捷在團隊層級比較成功;一旦面向客戶或跨部門合作,別人不用同一套方法,就很難發揮作用。