PMP考点，专门针对考试定制，全记下稳过无压力

1. 先分析、后行动
2. 先与第一责任人沟通
3. 避免问题升级，先礼后兵
4. 给机会，促改进
5. 有变更，走流程
6. 没有规矩，不成方圆
7. 积极主动，解决问题
8. 迭代途中，非紧急不中止
9. 有效解决问题，而不是只将问题罗列展示出来
10. WBS 工作分解结构与项目范围相关，与进度无关
11. 需求变更提交给项目经理，基准变更提交给变更委员会CCB
12. 项目组合是目标相同，但涉及到资源（优先级）的项目或项目集组合
13. 解决方案架构是记录问题的；
14. 待办事项列表是根据用户故事和价值排优先级的；
15. 工作说明书是项目可交付成果描述的；
16. 商业论证是关于成本、价值、效益分析、经济可行性分析的；
17. 成本效益分析是用来比较项目成本和收益的分析工具，在商业论证时会用到成本分析技术；
18. 效益管理计划包含效益、战略一致性、实现效益的时限、责任人、测量指标、风险；
19. 组织过程资产包括可用于执行治理项目的任何工件、实践、知识，还包括组织以往项目的经验教训、历史信息、成本标准等；
20. 项目章程记录了关于项目和预期交付产品、服务或成果的高层级信息，包含商业论证；
21. 团队章程是为团队创建团队价值观、共识、工作指南的文件
22. 项目管理计划可以帮助团队了解项目的范围、进度、成本、质量目标以及实现目标的方式；
23. 资源分解结构：资源依类别和类型的层级展现
24. 工作分解结构：团队为实现目标，创建所需可交付成果而需要实施的全部工作范围层级分解
25. RACI 矩阵：指导成员了解谁应该承担哪些任务和责任、谁应该被咨询、应该被知情、应该对什么任务负责；减少团队成员之间的混淆和冲突
26. 有曾经失败的经历，那优选吸取经验教训；
27. 风险是未发生的，记录在风险登记册；问题是已发生的，记录在问题登记册；
28. 留意题干中的“避免”“预防”“提前”“事先”等字眼，要选择前置措施；
29. 新出现的问题，优选可行性分析、适用性分析等；
30. 别动不动就选上报，百分之九十的题不会选择上报，只有题干中明确表示多次尝试解决无果，才会选上报；
31. 项目经理被要求执行有悖于常规的操作，即使是项目发起人提出的，也不能直接遵循，首选向上级寻求帮助
32. 事业环境因素：项目团队不可控，将对项目产生影响，可外可内；
33. 组织过程资产：执行组织特有并使用的计划，包括知识库、经验教训、历史信息等；
34. 管理储备应该应对未知-未知风险，不能用于已知风险，而且要走变更流程；
35. 项目的可行性应该由发起人或高级管理层来判断；
36. 项目经理的权限（大-小）：项目型、强矩阵、平衡矩阵、弱矩阵、职能型
37. 启动项目 - 需求评估 - 商业论证/成本效益分析
38. 人才三角：技术项目管理、领导力、战略和商务管理
39. 每日站会是团队内部同步信息的，不适合所有干系人都参与
40. 产品待办事项列表中的事项优先级是根据事项的价值来确定的
41. 敏捷四个会议：
    a. 迭代评审会议：演示完成的工作
    b. 每日站会：内部会议。做了什么、要做什么、有什么障碍
    c. 迭代回顾会议：检视自身，措施有效性、找出原因、提出改进
    d. 冲刺计划会议：决定本次交付成果和为了达成目标如何工作
42. 题干中出现“创新”等词汇，说明项目需求变更会频繁，会采用敏捷方式，特性：频繁小规模交付增量价值。分解为 sprint 逐步交付。
43. Dod 工作完成准则
44. 敏捷原则：最高目标，尽早、持续的交付有价值的软件来满足客户需求
45. 敏捷奉行理论：自我要求高、追求自身价值、自我激励，主动性、归属感、精神激励大于物质激励
46. CPI 成本绩效指数，小于一，超支，大于一，结余
47. SPI 进度绩效指数，小于一，落后，大于一，超前
48. 敏捷团队每日站会中团队成员抛出问题，项目经理不需要干涉，让他们自己去讨论就行（等待团队独立识别问题并解决）
49. 敏捷。自组织的速度本身是根据团队实际能力来承诺的，承诺应该与团队能力匹配，如果承诺无法定期交付，需要调整承诺以符合团队实际能力
50. 关键相关方的意见会影响整个项目，必要时可以找发起人协助
51. 赶工是加班，会有额外成本；快速跟进是并行，会有额外风险。
52. 敏捷——项目经理指导团队自主解决问题，而不是提供解决方案
53. 识别相关方 - 需求、期望未满足
54. 相关方分析 - 顺序、作用、优先级、权利、利益
55. 相关方登记册 - 变化、了解相关方信息
56. 相关方参与计划 - 规划参与策略
57. 相关方参与评估矩阵 - 参与状态，确保参与
58. 相关方参与计划 - 态度、冲突、输入相关方评估信息、相关方管理策略（包括沟通策略）
59. 关键相关方成为阻力 - 尽快让其参与进来
60. 相关方存在疑虑 - 展示（演示）有效信息
61. 相关方态度有问题 - 先分析后行动
62. 相关方存在需求冲突、抱怨、意见不合 - 沟通建立共识达成一致
63. 会议管理 - 混乱 - 规范会议章程
64. 会议 不积极 发言 - 鼓励
65. 沟通 - 需求与计划不一致 - 优选达成一致
66. 异地团队 - 重点考虑文化
67. 管理沟通 - 根据沟通管理计划进行信息传递
68. 审查沟通管理计划是否正确的实施以达成正确的效果
69. 敏捷 - 也需要即使更新文档
70. 敏捷 - 以价值为核心，小块交付 - 尽早 - 为 客户 - 持续 - 增量交付； 拥抱变化，即使后期也应该尽可能得满足客户需求，但是没价值的事不做（和客户解释原因）
71. 敏捷沟通 - 公开透明面对面
72. 产品负责人PO - 对接客户，收集需求，聚焦产品开发方向
    a. 产品待办事项列表
    ⅰ. （共同）创建PB并澄清需求
    ⅱ. 排序（根据价值，高于成员）
    ⅲ. 与团队或相关方共同讨论并梳理 PB
    ⅳ. 创建/调整 PB 要考虑风险
73. 敏捷 - 自组织团队
    a. 自我管理，自领任务，专注于一个项目
    b. 通才型专家，有效提升效率，减少孤岛、竖井
    c. 首选集中办公、远程结对
    d. 迭代待办事项列表（非特殊情况，不轻易变化，确保目标达成后再进行其他工作）
74. 敏捷教练 - 仆人
    a. 辅助、服务、解决问题、协助团队（不直接上手干活儿，不直接干预团队，但可以提出建议）
    b. 维护团队氛围、建立信任关系、鼓励探索、支持讨论
    c. 促进合作、了解状态、指导、激励、承担对团队成员的培训
    d. 需要出手：
    ⅰ. 相关方/团队 违反敏捷原则 - 指导学习了解敏捷原则
    ⅱ. 团队无法自行解决的障碍、外部障碍或影响绩效的障碍 - 清除
    e. 不出手：
    ⅰ. 碰到障碍问题 - 优先提倡团队自我纠正、团队合作
    ⅱ. 业务、技术问题 - 不插手，优先让团队自行解决，内部无法解决再出手
75. 五大过程：启动、规划、执行、监控、收尾
76. 客户讨论 - 达成共识 - （项目愿景 - 项目章程） - （产品路线图 = 用户故事） - 发布计划（产品待办事项列表） - 细化（估算优先级、DOD 认领）（迭代规划会议） - 迭代计划（迭代待办事项列表） - 开发执行（每日站会） - 已完成的用户故事 - 迭代评审会议 - 未完成的交付+可交付增量产品 **** 迭代回顾会议 - 改进措施
77. 启动（制定项目章程） - 参考组织过程资产，符合组织管理战略，整体目标、成功标准、高层需求、审批要求等。 需求与项目章程中内容不一致，上报发起人。 作用：正式启动项目，不可或缺，PM 的大保健
78. 规划（制定项目管理计划） - 传达目标、阐明角色和职责，获得团队承诺，树立团队信心
79. 执行（指导和管理项目工作） - 根据期望完成既定、超出权限上报
    a. 问题日志，有问题先更新，确保问题得到解决
    b. 解决问题：先分析，达成一致，确定措施，执行
    c. 重复问题：找到根本原因，对症下药
    d. 已知-已知风险 当做问题处理（还没有发生影响，但明确已知会发生影响的）
    ⅰ. ★ 已知-已知 ： 已知风险存在，已知风险影响（包含影响已发生的和未发生的，只要明确指导会发生影响，就是已知）
    e. 有问题：解决问题并考虑风险
    f. 与项目无关的需求，建议新开合同
80. 隐性知识优先通过人际交往分享，面对面 知识分享会议
81. 不论隐性&显性，经验教训应该在整个项目周期向相关方收集
82. 确保项目文件等经验教训存储在存储库或PMIS中
83. 监控：监控项目文件。监控让项目目标得以实现
84. 成本效益分析：不知道项目如何带来效益、通过成本效益分析来决策
85. 变更：涉及到 范围、进度、成本、权限 都要走变更流程
86. 变更流程提交给 PM
87. 法律导致的影响，也要提交变更请求，提交之前要分析可行性和影响
88. 批准变更后，相关方没有按照变更执行 - 没有通知到位
89. 变更控制流程，确保相关方了解正确的变更重要性
90. 未提交变更请求的情况下执行变更，即使是镀金，也需要补充变更流程
91. 特殊情况：基准确定之前，无需变更流程；部分题目中，非 范围、进度、成本、权限等，且由项目经理来做的，会默认通过了变更流程审批这个步骤（因为本身就是提交给项目经理审批）
92. 收尾，先验收通过， 可交付成果转移，测量相关方满意度，评估交付价值，访谈获取准确数据
93. 最终版项目文件报告包含未能实现的效益后续监控方案
94. 收尾 - 组织过程资产更新，需要更新，责任人 pm，提前终止也要收尾（包括组织过程资产更新）
95. 收尾 - 上报 - 通过验收标准，但相关方拒收 - 寻求发起人帮助
96. 收尾 - 上报 - 成果移交后不满足商业论证 - 上报处理
97. 收尾 - 上报 - 提前终止，项目无法实现业务价值 - 上报重新评估商业价值获得审批后终止
98. 收集需求 - 怎么做：
99. 需求跟踪矩阵 - 需求&结果
100. 定义范围 - 先收集需求，后定义范围
     a. 专家判断 - 引导
     b. 内容： 可交付成果，验收标准
101. WBS - 定义范围的下一步，以可交付成果为导向
102. 确认范围：正式验收，验收的依据 - 范围说明书、合同
103. 可交付成果流向 - 控制质量 - 确认范围 - 收尾之间的顺序
104. 控制范围：监督范围状态、管理范围基准变更。拒绝镀金，拒绝蔓延
105. 成本：估算，前期粗略，后期确定
106. 类比：参考类似，快速估算
107. 上而下：精准估算，基于 WBS
108. 三点估算：默认贝塔 悲 + 4 可 + 乐 /6
109. 制定预算：
     a. 参考相关方建议
     b. 成本基准包括应急储备
     c. 应急储备使用场景 - 已知风险，未知影响
110. 偏差分析， < 0 或 < 1 的是不好的走向
111. 成本绩效 CPI = EV /AV
112. 进度： 赶工&快速跟进，赶工就是加班（高成本，低风险），快速跟进就是并行（低成本，高风险）
113. 保证关键路径避免延期
114. 进度落后，考虑时间储备
115. 管理质量的重要性 - 过程
116. 控制质量的重要性 - 结果
117. 帕累托图 28 原则 找主要原因的
118. 采购管理计划 指导采购活动和步骤
119. 协议或合同，明确验收标准，约束供应商，有争议，先审查合同或采购说明书（SOW）
120. 控制采购：谈判（首选）、ADR、仲裁、诉讼
121. 合同内容与实际不一致，需变更合同
122. 采购模块遇到问题，与采购部门沟通协商解决
123. SWOT 识别风险的工具
124. 定量风险，概率x收益
125. 应对策略： 减轻 、 转移 、 接受
126. 已识别风险：更新风险登记册，准备应对方案
127. 未识别风险：先分析影响和风险，后行动
128. 监督风险：持续监督，确保风险管理过程的有效性
129. 出现偏差：与相关方沟通合作
130. 迭代，不轻易改变
131. 滚动式规划、愿景、产品路线图、、发布计划、迭代计划、每日计划
132. 用户故事：
     a. 故事不清晰，与用户沟通，有必要重写
     b. MVP 最小可行产品
     c. 故事太大：功能复杂、估算不准、需要拆分用户故事
     d. 根据故事点估算来控制项目范围，预算或进度，计划扑克
     e. DoD 确保产品增量满足需求（PO 确定和评估）
     f. 以用户故事的价值为核心进行优先级排序
     g. 不能通过完成的故事节点来评估不同团队的绩效
133. 敏捷风险 - 持续监控、反馈、评估，原则上越早发现越好
134. 团队绩效：挣值分析
135. 速度
     a. 越稳定越好：规划迭代工作事项时应该考虑以往迭代的速度
     b. 燃尽图，了解速度和进度
     c. 预期速度未达到 - 调整速度，发布计划
     d. 依照速度计算所需要的迭代数： 迭代次数 = 总故事 ÷ 速度 结果向上取整
136. 敏捷 - 五个事件：
     a. 迭代冲刺：迭代规模应适合迭代持续时间
     b. 迭代规划：接下来要进行的迭代及输入PB（迭代计划）输出SB（迭代目标）
     c. 每日站会：同步信息，提出障碍（不解决），强调规则、共同讨论、共识优选；
     ⅰ. 缺： 缺乏彼此了解
     d. 迭代评审：演示/展示价值，获得相关方反馈；减少返工，找准方向；会后的问题解决
     e. 迭代回顾：总结、改进、反思、找到根本原因提出解决办法
137. 和预测相比：更提倡及时解决、轻文档、轻流程（轻不代表没有）
138. 项目集合：依赖
139. 项目组合：优先级
140. 商业论证：确定经济可行性（PM无权拍板）
141. 效益管理计划：分析商业价值（有形、无形）；目标效益、战略一致性、实现效益的时间；净现值、投资回收期（同时出现优选净现值）
142. 事业环境因素：不可控
143. 组织过程资产：内部，避免失败、未来参考、新人参考
144. 特殊情况可以找 PMO
145. 考虑合规影响，避免后续问题
146. 根据项目特点选择生命周期类型
147. 转型：
     a. 预测不适用，转敏捷 === 混合过渡
     b. 自上而下逆转思维、频繁沟通、蚕食、事先沟通、解决障碍、分享决策、设定愿景
     c. 评估是否适合转型。PM 先分析，不站队
     d. 相关方不支持，无敏捷经验 === 指导相关方，不强迫，获得相关方认可，宣传转型的好处
148. 混合：
     a. 混合项目的 PM：鼓励、支持、指导、解决障碍（偏向敏捷）
     b. 建立团队章程、加强沟通、促进协作、优选沟通、合作、共同决定
     c. 混合变更：根据题干背景判断走流程还是和 PO 合作或同时进行
     d. 混合资源管理：先内后外，新人 == 帮助； 老人 ==共识
149. 看板：可视化工作流动、共识信息、促进沟通（仪表盘、冲刺板、障碍板）
     a. 限制在制品（WIP），任务过重或积压过多、出现瓶颈，考虑限制WIP
150. 结对编程：知识分享、老带新培养新人，激发工作热情
151. 技术债务：跳过测试，可能会导致技术债务增加
     a. scrums of scrums： 类比项目集管理， 问题 首选
152. 内部提出的变更（先评估，走流程，评估不可行就不用走流程），外部提出的变更（记录，走流程，无论最终是否批准都要走变更请求）
153. 合规的优先级高
154. 敏捷 ====== 价值为导向。没有价值的提议，忽略，有价值的提议（不管是成本，还是进度）就让关系人参与进来一起讨论
155. 分析协议边界的意思是，分析对方可以接受的范围，通过谈判，给项目团队一定范围内的特殊的规定
156. 敏捷的成本和进度一般都是固定的，对于已经超支的，可以通过缩减范围或增加预算来满足进度
157. 能解决的问题就先解决方案，不要当做风险来对待，风险有点消极处理
158. 产品待办事项列表式产品负责人去搞的哦，项目经理不要瞎搞，至少也要和产品负责人一起
159. 需要高度专业专家说明团队自组织能力强，向团队解释高层级目标，更清晰的了解情况，双方达成共识
160. 报告： 整理数据 准备 纳入报告阶段， SOP 创建报告（包含数据分析、统计、解释）
161. 预算、确定、数量 级估算 都是对项目的估算等级
162. 故事点估算，是估算技术
163. 趋势分析： 预测未来
164. 进度分析： 检查进度是否符合预期
165. 质量分析： 核对可交付成果和质量标准
166. 根本原本分析：识别偏差
167. 产品交付后的支持 === 就是售后！
168. 敏捷中遇到变更，联系产品负责人、更新产品待办事项列表，重新进行优先级排序。
169. 评审过程中 2 个重点： 可交付成果本身（质量、进展）、项目整体状态（绩效、成本、进度、风险）
170. 风险管理计划是指南性文件，里面没有风险应对措施等等，区分风险登记册