PMP 考试 - 考前笔记

基本概念、考试小坑和从未碰到但重要的知识点，考前翻看巩固用。

基本概念

【敏捷、团队基本原则】➡️ 敏捷团队一起定义《团队基本规则》。
【项目管理流程、PMO】➡️ 公司的项目管理流程（其中就有质量流程）、框架正常由 PMO 提供，如果项目经理发现这些流程、框架不符合项目特点、要求，可以要求 PMO 修改、变更。
【绩效、能力、信任】➡️ 团队绩效不好，有可能是能力问题（通过培训改进），也有可能是配合、信任问题（通过团队建设改进）。
【需求功能遗漏、干系人参与】➡️ 关键需求或功能被遗漏，多与未让干系人尽早参与有关，并可以通过让干系人参与项目来解决。而非单纯的沟通问题。
【获得干系人认可、范围管理、干系人参与定义范围】让干系人参与定义范围来获得干系人对项目结果的认可和批准。
【管理团队、资源管理计划】➡️ 管理团队的核心计划是资源管理计划。它也是能提高多元文化团队绩效的计划。
【团队章程】➡️ 团队章程中包括：
- 团队价值观
- 沟通指南
- 决策标准和过程
- 冲突处理过程
- 会议指南
- 团队共识
需要注意的是，不包含项目目标和团队职业与角色定义。
🌟【敏捷、回顾会议、解决障碍/问题】➡️ 敏捷中的回顾会议，可以用来讨论、解决问题、障碍。
【敏捷、团队章程、就绪的定义 (DOR)、完成的定义 (DOD)】➡️ 敏捷团队章程中出了团队共识、价值观和基本规则之外，还应包含就绪的定义 (DOR) 和完成的定义 (DOD)。
【敏捷、就绪的定义 (DOD)】➡️ 可以确保质量、确保达到了商业价值。
【项目目标、与干系人确保目标一致】➡️ 项目目标应包含一系列的成功标准，如时间、成本、范围、质量等，主要干系人和项目经理应就这些问题达成共识并予以记录。
【绩效、KPIs】➡️ 能帮助干系人、高管全面地了解项目执行情况，绩效好坏；KPIs 可以针对项目、组织、团队（成员），不针对可交付成果。
【绩效、绩效管理制度】➡️ 是考核标准，有助于帮助团队提高绩效，项目经理应该向团队成员公开并提供反馈。
【项目经理没有经验】➡️ 先查看组织过程资产，再获取主题专家 (SEMs) 的帮助。
【新人项目经理】➡️ 先查看项目管理计划，再查看绩效信息 (SPI 和 CPI 等)，再找团队成员了解。

如果题干强调“项目具有不稳定性”时，需要检查风险登记册。
【敏捷、看板、在制品 (WIP)】➡️ 维持较小的在制品 (WIP) 限制，有利于团队集中力量办大事，推动进展，加快交付。
【敏捷、累积流量图】➡️ 包含三类：正在开发的工作、已经完成的工作、计划开展的工作。可以用来评估项目状态。
【按需的进度计划及其扩展】➡️ 先执行确定的工作，不确定的工作可以先放在待办项列表中。

旧的按需的进度计划：敏捷下特殊情况可以调整进度（资源不可用时，优先开展资源可用的活动）。
例如：① 政府将出台法规影响项目的工作，法规没出台活动没法开展，先做别的。
② 开发方法有争议，先做别的。
【风险管理、事业环境因素】➡️ 严重影响项目的内外部事业环境因素：政府新法规、公司新政策、竞争对手新产品、市场或项目商业价值新变化、其他未知 - 未知风险发生等。
- 应对：① 当成已知 - 未知风险进行识别（记录、更新风险登记册）、或当前未知 - 未知风险发生（更新问题日志），之后（和干系人一起）一起分析影响，制定应对策略。
  ② 重新进行商业论证或成本效益分析，并上报干系人。
- 避免：事先识别风险，识别事业环境因素、假设条件。
- 思路：记录 -> 分析 -> 上报 -> 制定或实施措施 -> 提出变更请求。
【工件更新、工件管理】➡️ 定期更新项目计划，确保工件都是最新版本，并且与所有干系人共享。

工件包括项目管理过程、输入、工具、技术、输出、事业环境因素和组织过程资产。
【合规要求】➡️ 将合规要求纳入项目管理计划（质量管理计划），或纳入产品待办项，或融入开发工具。
【跟踪验证项目的收益】➡️ 预测方法使用效益管理计划；敏捷方法使用冲刺评审会议（演示证明收益实现）。
【依赖关系、项目之间】➡️ 参考整体进度计划，或与其他项目经理了解情况，或查看其他项目的项目管理计划。
【依赖关系、活动之间】➡️ 记录在进度计划中，或当成制约因素。
🌟🌟🌟【依赖关系、团队之间】➡️ 预测方式使用 RAM/RACI 和项目状态评审会（项目状态审查会议）；敏捷方法使用每日站会和 Scrum on Scrum (SOS)。
【项目目标、效益管理计划】➡️ 项目目标是根据效益管理计划制定的。
【敏捷、产品待办列表优先级】➡️ 敏捷项目，三种情况下需要重排产品待办项列表的优先级：预算减少、时间提前和资源减少。因为这三种情况下，能完成的工作范围会减少，因此要重排优先级。
【敏捷、好工具、好技术】➡️ 好方法、好建议或好工具，要积极支持、尝试。
【敏捷、范围】➡️ 敏捷没有范围基准，这与敏捷拥抱变更的概念一致。

考试小坑

压缩项目进度计划 (Crash the project schedule) 等于赶工，即增加资源缩短工期。
冲突解决类培训有助于在管理干系人的期望时，提高项目经理的人际关系能力。
延长进度属于风险的规避策略。
开发原型（原型法）主要目的是收集需求，而非展示“解决方案的可行性”。

原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。
原型法能使相关（干系人）可以体验最终产品的模型（完整的用户体验），而不是仅限于讨论抽象的需求描述。
虽然要考虑到干系人情绪，要进行解释、说服工作，但是具体行为任然应该按照规章办事。

例如：服务部门因未能参与供应商评估过程感到沮丧，这时应进行会面、审核过程，而非直接将他们纳入过程。
有固定交付时间的项目，更适合使用敏捷方法执行。
配置管理问题包括：术语不一致、使用了错误版本的文件等，就事论事解决即可。

例如：术语不一致就规范术语；使用了错误版本的文件就为所有项目文档保留一个唯一的存储库。
社区反对需要干系人参与；实际对社区造成了污染等影响，需要实际面对。
已知 - 未知风险发生，优先实施应对措施，之后再更新风险登记册。
项目收尾后，运营过程出现问题由运营支持部门解决，项目经理只记录经验教训即可。
收集需求的会议，要尽量和所有干系人一起开（因为需求可能存在冲突）。有人无法参会应向他会前了解需求；与会人员过少考虑重新召开。
采购中的风险管理参考采购管理计划。因为风险管理计划中不涉及采购工作，而采购管理计划中包含了风险管理事项。
获得干系人对项目结果的认可和批准属于范围管理问题。
里程碑信息最早出现在项目章程中。干系人问什么时候可以提供里程碑信息，那么就是在项目启动过程中。
资源冲突导致的进度延迟，应该找资源的职能经理解决。

最差的情况需要将干系人认识为职能经理，总之优先于查看资源管理计划。
工作重叠（工作撞车），是责任分配的问题，预测型项目的责任分配通过 RAM、RACI 来实现，包含在资源管理计划中。
敏捷最后一次迭代有交付物无法按时完成，要么忽略该可交付成果，要么延长迭代时间。无论哪一项，都要征求关键干系人的意见。
工作包确定后，在现实项目中，资源是核心的制约因素，因此大多是先确定可用资源，再根据资源估算成本。
冲刺未达到产品负责人的期望，说明该冲刺的目标有误，应在迭代开始时明确目标。
项目经理对团队的整合重点应在早期形成阶段，而非震荡阶段。

团队文化、风格、规则的形成和建立，越早越能起到事半功倍的作用。
全面考虑干系人的需求是原则问题，比查看组织过程资产优先。
资源没有时间也优先找资源的职能经理谈，而不是之间找资源本人谈。
自组织团队的能力问题也属于仆人式领导需要参与解决的障碍。
数量级（估算）等于类比估算，适用于之前有成功交付项目、且本次预算需要紧急提交的情况。
产品规格可以引申为质量要求。
干系人（相关方）对最终产品提出了担忧可以引申为可交付成果有问题，即验收问题。
需求跟踪矩阵提供了一个全面的需求清单，并为每个需求设定了验收标准。

从未碰到

【干系人、无法参与会议】➡️ 重要干系人没时间出席重要会议时，可以让其排代表参加。
【角色、职责】➡️ RACI、RAM 中包含角色和职责。
【权力、职责】➡️ 资源管理计划中包含权力和职责。
【用户故事】➡️ 三要素：角色、活动、价值。
【自组织团队】➡️ 不需要过于强势的团队成员，也不需要团队成员有领导力、影响力。
【进度风险管理】➡️ 进度风险管理问题，可以选假设情景分析，以及蒙特卡罗模拟（也是假设情景分析中的一种）。
【预测方法、削减预算】➡️ 需要参考成本效益分析先削减范围（消减价值低、成本高的工作）。