課程介紹

黃喆PMP特訓班

目標：3個月考上

PMP考試內容

  • 40% 計劃管理 + 60% Agile敏捷管理
  • 230分鐘、180題（單選、複選、配對、選圖）
  • 5題不計分（沒有特別標示），提供未來出題參考
  • 175計分，答對196題（61%正確率）通過考試

什麼是專案

定義

  • 特定性、獨特性、臨時性
  • 臨時性：
    • 達成專案目標，申請終止
    • 無法達到目標或缺乏資金，申請終止（實務上不可能，考試依據長期性、道德心）
    • 預算、時間、資源不足：討論如何守住（而非延後）
  • 專案的交付成果或活動可能會重複，但不會改變專案整體的獨特性。例如：興建大樓，每層的主體結構重複，但整體仍具獨特性。

專案目標：

  • 滿足user的需求，並且讓其它利害關係人都要參與
  • 創造商業價值：有形、無形
  • 能帶來改變（change）的產品專案：為達成組織的策略目標，推動專案改變組織現況
    • 改變小：計劃性
    • 改變大：敏捷性
    • 改變中：Hybrid
  • 專案組合（portfolio）：組合價值最大化之專案、計劃和運營，優先配置資源
  • 組合、計劃、專案管理：
    • 組合管理注重：正確選擇
    • 計劃、專案管理注重：正確執行

專案生命週期

交付頻率 增量 敏捷
預測 迭代
變動程度

適應型生命週期（Adaptive Life Cycle）

  • 預測型（predictive）：
    • 注重管理成本
    • 越完整計劃預測越好
  • 增量型（incremental）：
    • 及時交付速度
    • 小批量分批生產
  • 迭代型（iterative ）：
    • 有效解決單一方案
    • 階段性，存在與金額大、或與人命安全相關項目，快不了
  • 敏捷型（agile）：
    • 解決客戶價值
    • 創新產品、跨領域
  • 混合式（hybrid）
    • 專案中同時動態混合不同方法來達成
    • 專案不完全採用

專案管理流程

專案管理流程群組（Process Group）可分為IPEMC → 生命週期

  • 起始流程群組（Initiating Process Group）
  • 規劃流程群組（Planning Process Group） ←↑ 1. 偏差
  • 執行流程群組（Executing Process Group） ↑ 2. 評估
  • 監控流程群組（Monitoring and Controlling Process Group）→↑ 3. 方案
  • 結束流程群組（Closing Process Group）

專案文件

商業企劃案（business case）：

  • 經濟可行性評估，專案成本與效益分析，決定是否授權專案啟動
  • 專案進行中要持續確認，判斷是否要繼續或終止專案

專案章程（project charter）：

  • 由專案發起人（sponsor）發布
  • 正式批准專案成立，並授權專案經理動用組織資源開展專案活動的文件

專案管理計劃（project management plan）：

  • 描述如何執行、監督、控制專案的文件

效益管理計劃（benefits management plan）：

  • 說明如何及何時能取得效益，管理及衡量專案效益

專案環境與組織影響

  • 2.1 專案環境
  • 2.2 企業環境因素（內、外環境）
  • 2.3 組織流程資產（流程、歷史資料）
  • 2.4 組織系統（專案治理、組織架構、PMO）

專案環境

內 ← 外：道德 < 社會認同責任 < 法律 < 客戶 < 公司 < PM < PMT 規劃、監控 < PT 執行

外部的商业环境（PESTLE）：

  • 政治（political）
  • 经济（economic）
  • 社会（social）
  • 技术（technical）
  • 法律（legal）
  • 环境（enviroment）

内部：

  • 文化
  • 设备
  • 员工

組織系統

功能型 Functional 矩陣式 Matrix 專案型 Projectized
成員效忠 功能部門 功能部門及專案
成员各半有衝突		 專案
成員隸屬 功能經理 功能經理及專案經理
成员各半有衝突		 專案經理
PM角色 兼職 全職 全職
成員角色 兼職 兼職 全職
管控程度 低 中 高

補充：

  1. 在專案組織裡，專案團隊【沒有固定組織】，因專案團隊向PM報告即可，效忠於專案，結束專案則各自解散。
  2. 專案管理辦公室（Project Management Office, PMO）
    • 制定專案管理政策、流程、工具、範本、最佳實務和標準
    • 透過稽核，監督遵守程度
    • 跨專案協調，共用資源管理（e.g. 專案治理指導委員會）

專案經理

定義

分類：

  • 專案經理（project manager）：由組織委外，領導團隊實現專案目標
  • 職能經理（functional manager）：專業職的主管
  • 營運經理（operations manager）：營運職主管

目標：

  • 滿足利害關係人（USER）的需求
  • 好的溝通、積極的態度
  • 應主動尋求權利

領導風格：

  • 放任型：無為而治
  • 交易型：關注目標、回饋成果，進行獎勵
  • 僕人型：敏捷專案團隊自我管理

執行整合

專案整合時，專案經理承擔雙重角色：

  • 確保專案目標與策略一致
  • 指導團隊整合流程、知識和人員

專案整合

架構

流程：啟始、規劃、執行、監視控制、結束

知識領域：整合、範疇、時間、成本、品質、資源、溝通、風險、採購、關係人

筆記

1 人員績效不好 -> 沒有合適人選 參加培訓

Agile

Agile 12項原則：最有價值、面對面談話、專職穩定、持續迭代、自我管理

  1. 優先交付對客戶最有價值（即使技術有難度）的產品/功能
  2. 歡迎對客戶有競爭優勢的變更：客戶經常參與、分段開發、架構彈性才能面對變更
  3. 經常交付可用產品：有初步的產品或原型，先讓客戶檢視，再持續強化
  4. 需求單位與開發單位人員，必須天天一起工作
  5. 挑選積極的成員參與專案，給予環境及資源：創新產品各單位要派最優秀的人，進入戰情室專職參與
  6. 面對面談話是最有效的溝通方式：每天在戰情室（war room）一起面對面溝通直接透明
  7. 可用的或有價值（而非半成品）的產品，才能認列進度
  8. 贊助人、需求及開發單位人員，應穩定且專職持續的開發，培養信任及技術
  9. 持續強化優越的技術與設計
  10. 精簡，減少多工，專注最重要工作
  11. 最佳的需求與設計，來自自我管理的團隊
  12. 持續改善績效及團隊合作

agile team 3個角色：

  1. product owner (po)
    • 固定1人且專職
    • 收集及排序需求價值
  2. scrum master (sm)
    • 固定1人且專職
    • 僕人管理、引導溝通
  3. developers
    • 專職
    • 自我管理

敏捷開發：

  • 因不確定性，所以無經驗較豐富著，所以全員一起討論（如工期估算）

衝刺

名詞說明：

  • 故事點是一個度量單位，用於表示完成一個產品待辦項或者其他任何某項工作所需的所有工作量的估算結果
  • 故事點（story point）和預估時間（estimated）不一樣，故事點是一種相對的估計，它並不能和類似“人/天”這樣的單位畫等號，因為每個人完成同樣複雜度的工作所需的時間是不同的
  • 考慮股市相對複雜度，使用哪一種方法？ 【規劃撲克 planning poker】

ref:

衝刺子事件：

  1. sprint planning（衝刺規劃會議）：
    • 決定需求故事是否納入衝刺
    • 估算需求的相對複雜度
  2. daily scrum:
    • 看板會議，討論三個問題：
      • 昨天做了什麼
      • 今天打算做什麼
      • 過程中碰到那些阻礙、什麼事情阻礙工資
    • 如果討論過程出現主題外的問題，應該另外安排時間進行討論，而非更換主題
  3. product review（產品審查會議）:
    • 產品增量、需求故事是否被產品負責人（PO）允收
    • 如果不被允收，或是有人提出變更，應先放回產品代辦清單，由 PO 依價值重新排序之後，在放入衝刺
  4. retrospective（回顧會議）:
    • 如何改善流程與工作效率

衝刺結束後：須user確認產品符合需求

總結

總結：

  • 考試比較偏向如何預防、避免
  • 通常要有行動，而不是只是看
  • 選正面

敏捷：

  • 原型（prototype） → 迭代型專案
  • x PM報告給主觀 → 請主管去see看板

變更

  • 變更 → 更動baseline → STC
  • 以考試而言，先分析，不得已再變更

風險：

  • 遇到非預期內的issue或風險 → 不在PM範圍 → 呈報長官 → 【不需要追踪】，如果有影響專案要【變更申請】
  • 風險已確定不會發生 → 風險登錄表移出/修訂原高風險 → 重新評估風險排序
  • 【題目keyword】 > 主動消除風險 > 減輕風險 > 監督風險
  • 考試：如果遇到風險，PM不必出錢，都是老闆出錢

擔心無法滿足USER需求 / 需求太多 → 利害關係人分析 → 確認所有利害關係人的需求

回饋：

  • 問卷調查用於人多
  • 請使用者作經驗分享（LLR）

團隊缺乏技能：

  • 制度/文化/管理：為【所有人】培訓，而非有些人、有能力的人
  • 細節技術：部分人培訓
  • 人的技能 > 新的工具

溝通：

  • 溝通問題就制定/更新/促進溝通管理計劃

人：

  • 發起人：
    • 決定項目要不要部署上線
    • 範圍變更審批
    • 階段末評審
    • 當風險很大時對項目是否繼續進行做出決定
  • 利害關係人：
    • 項目管理計劃批准