导图社区 PMP知识考点
- 17
- 0
- 0
- 举报
PMP知识考点
这是一篇关于PMP知识考点的思维导图，主要内容包括：敏捷，项目管理计划，五大过程组、十大过程组。对于学习者来说是一份非常有价值的学习资料。
编辑于2025-02-03 17:42:54- PMP
- 五大过程组
- 相似推荐
- 大纲
PMP知识考点
五大过程组
五大过程组
启动
规划
执行
监控
收尾
项目
单个项目具有独特性（项目有不确定性和风险）
临时性（明确的起止时间）
渐进明细（滚动式规划）
项目集
统一协调管理 相互关联有 依赖关系项目 获得额外的收益
项目组合管理
基于战略选择项目 给项目集排列优先级 再根据项目的优先级来分配资源
预测型
瀑布型生命周期 需要在项目早期花费大量时间来计划 按计划驱动项目
迭代型
原型确认或者是概念验证
增量型
渐进地增加产品功能
适应型
敏捷方法、变更驱动型生命周期 每个迭代都能够完成一定的产品增量 通过每次发布来交付价值
混合型
包含迭代型和增量型 开发过程使用敏捷 但是最后一次性交付
（如果组织要转型 从预测 型向敏捷转型过程中 使用混合型作为过渡）
项目商业文件
在项目启动之前产生 并不是项目经理或项目团队编写 由发起人提供 后续如果需要更新商业论证 一定是由发起人来完成 项目经理可 以针对商业论证的内容提供建议
事业环境因素
（组织内、组织外 有限制性） 如政府、行业协会、公司的管理层 是用来遵守的 被动接受
组织过程资产
（组织内）历史项目团队及项目相关部门 是用来使用和借鉴的 主动参与更新维护
项目管理办公室
PMO（项目管理办公室）：是一个组织级的常设部门提供组织内的项目管理流程和制度 编制项目中使用的各种模板和表格 也可以对项目进行 审计 还可以称为项目的发起人
组织结构
职能型：无全职 PM 兼职 几乎没有权力 团队成员唯一的领导 FM（PM充当联络员 ）
职能型：无全职 PM 兼职 几乎没有权力 团队成员唯一的领导 FM（PM充当联络员 ）
弱矩阵：PM＜FM 无全职 PM 兼职（PM充当协调员）
均衡矩阵：PM=FM PM 的直属领导还是 FM
强矩阵：PM＞FM 全职 PM 和团队成员 PM 可以掌控资源和预算 默认都是采用强矩阵型组织
组织
项目型：无 FM 团队成员唯一的领导 PM
放任型：一般成熟的团队使用
交易型：为了让团队成员更好的完成工作
服务型：仆人式 适用于敏捷团队
项目章程
制定项目章程
正常情况下制定项目章程工作应该由发起人来做 需要发起人编写并发布项目章程 （发起人也可以授权项目经理代为编写）
项目章程作用
标志着项目的正式开始/启动
任命项目经理
授权项目经理使 用组织内的资源
项目预算
定义项目的开支预算，包括人力资源、物资采购、运输和设备等费用支出的详细预算计划
关键风险
识别和分析项目的关键风险，以及应对措施计划，帮助团队了解潜在的关键风险和挑战，并提前做好应对计划
商业论证
是否值得投资
项目启动会和项目开工会议
项目启动会和项目开工会议（也叫开踢会）召开时间不同 目的和任务也不同 启动会：召开时间为启动阶段结束 规划阶段开始前目的和任务
启动会
启动会：召开时间为启动阶段结束 规划阶段开始前目的和任务 1、发布批准的项目章程 2、任命项目经理 3、授权项目经理动用组织资源的权利
开工会
开工会：召开时间为规划阶段结束 执行阶段开始前 1、项目团队成员互相认识 2、介绍项目背景及计划 3、发布批准的项目管理计划 4、上下级互相承诺、达成共识
项目管理计划
10 个子计划
范围、进度、成本、质量、资源、沟通、风险、采购、干系人
其他组件
项目生命周期（阶段是如何划分的）、开发方法（采用预测型、适应型还是 混合型）、变更管理计划
其他组件
项目生命周期（阶段是如何划分的）、开发方法（采用预测型、适应型还是 混合型）、变更管理计划
显性知识
使用文字、图片和数字进行编撰知识
隐性知识
个体知识以及难以明确表达的知识 如信念、洞察力、经验和诀窍
经验教训登记册
实际上项目开始之后该文档即可存在 并在产生经验教训后马上更新在项目或阶段收尾时 将相关内容存储到 OPA 中的经验教训知识库
变更管理流程步骤
请求
评估
提交
更新
通知
批准变更请求： 1、项目管理计划或组织流程制定责任人 2、CCB审批 3、题中无以上选择可选PMO、发起人、项目经理
需求跟踪矩阵
考试：在确认范围正式验收时 项目团队确认已经按范围 进度和成本交付 可是客户不满意这时 可以审查需求跟踪矩阵
镀金
往往是项目人员为了"讨好"客户而做的不解决实际问题、没有应用价值的项目活动 范围蔓延
范围蔓延
是指未得到控制的变更，常表现为在未分析对进度、成本、质量和资源等的影响下或未得到关键干系人批准的情况下添加产品的功能和特性
结束项目或阶段
提前终止的流程：
1、 记录提前终止的原因（通常是基于发起人的正式决策进行的）
2、 验收并移交已完成的可交付成果
3、 经验教训总结并存档
4、 解散团队释放资源
正常收尾流程：
1、制定收尾程序
2、完成采购合同收尾
3、确认项目工作完成 符合要求
4、确认已获得产品的验收并移交
5、最终绩效报告
6、更新项目记录
7、更新经验教训存档
8、庆功会
9、解散团队
收集需求
所有干系人参与，收集到全部的需求
工具
头脑风暴：短时间获得大量创意，不作分类排序
焦点小组：有主持人，和专家开的会议，比头脑风暴更专业
访谈：一对一，一对多，获取机密信息
标杆对照：本组织实践VS可比组织，以形成改进意见，适合做决策
引导：跨职能，有助于达成一致；联合应用开发、质量功能部署（展开）、用户故事
亲和图：分组、分类
名义小组：投票、优先排序、5分钟制、数轮
多标准决策分析：决策矩阵、多种标准、评估和排序
系统交互图：拓扑图、可视化
原型法：渐进明细、能减轻返工风险
用户故事：
需求研讨会、角色、目标、动机
投票
大多数原则：2 选 1，选择超过 50%
相对多数原则：3/多选 1，选择相对最多，但是可能不足 50%
( 在正式验收时，项目符合要求，但是客户仍然不满意，需要查看需求跟踪矩阵)
创建 WBS
项目可交付成果和项目工作→更小的更易于管理的组件→工作包
WBS 定义了项目的全部范围
滚动式规划：规划包→暂时不需要做的工作，暂时也不需要详细的分解
范围基准=WBS+WBS 词典+项目范围说明书，需要关键干系人的审批批准
估算活动持续时间
工具
类比估算 ：早期/启动/开始使用 需要使用历史信息 好处就是快 缺点就是可能不准 "过去类似”
参数估算 ：需要使用历史信息 单位数据值 统计方法
三点估算 ：来源于计划评审技术（pert 分析），考虑了风险的影响最悲观、最可能、最乐观
自下而上估算： 最准确的 需要有详细的信息
储备分析
应急储备：基准内，已知-未知风险
管理储备：基准外，未知-未知风险
资源优化
资源平衡：改变关键路劲 通常是导致变长
资源平滑：不改变关键路径 在TF和FF范围内进行调整
进度压缩：不缩减范围
赶工：额外增加资源、批准加班 导致成本增加 最小代价
快速跟进：调整逻辑关系，把串→并 活动之间必须是选择性依赖 当前项目风险水平不高 如果两种方法都可行，优先考虑使用快速跟进
如果两种方法都可行，优先考虑使用快速跟进
敏捷发布规划：产品愿景→产品路线图→发布计划→迭代计划
进度管理
活动之间的依赖关系
1、FS：A活动完成-B活动才能开始
2、SS：A活动开始-B活动才能开始
3、FF：A活动结束-B活动才能结束
4、SF：B活动完成-A活动才能开始
三种浮动时间
1、自由浮动时间：不影响后续工作最早开始，活动可以拖延的时间
2、总浮动时间：不影响项目总工期，活动可以拖延的时间
3、项目浮动时间：在总工期的基础上，甲方或领导主动多给让出来的时间
规划质量管理
质量七工具
因果图：根本原因
流程图：展示一系列步骤
帕累托图：主要原因
核对单：避免遗漏
控制图：监控任何过程
直方图：确定频次
散点图：两个变量关系
质量成本
一致性成本
预防成本
培训、设备、流程文档化、选择正确时间
评价成本
检查、测试、破坏性测试
（擦屁股）非一致性成本
内部失败成本
返工、废品
外部失败成本
债务、保修、业务流失
质量优化
PDCA循环：戴明环，最常用 （虽然叫戴明环但是是沃特·阿曼德·休哈特（Walter A. Shewhart）首先提出的）
六西格玛：度量过程的质量 不是产品的质量 西格玛值越高 缺陷概率就越低 六西格玛的缺陷率百万分之3.4
获取资源
优先选择组织内部的资源
内部资源→找FM 和资源经理
外部资源→找供应商
建设团队塔克曼模型
形成：了解
震荡：开始工作，出现冲突
规范：开始相互信任、开始协同工作、开始调整自己的习惯
成熟：组织有序
解散：项目完成，团队解散
考试：通过题干描述很像成熟的团队 但是没有组织有序 选规范阶段 只要加入新的团队成员，一律回到形成阶段
管理团队
如果有团队成员无法继续为项目工作，PM该咋做？
1、 审查资源管理计划/评估影响 2、 审查/更新风险登记册 3、 提交变更请求
冲突解决：使用团队章程 责任人—冲突双方（团队成员）→PM→FM→发起人 （求助 FM 和发起人之前 项目经理必须先自行尝试解决 解决不了再求助） （在考试中，选项里直接出现上报的 几乎都不是正确答案 积极的态度：“等待”通常也不是正确答案）
合作/解决问题：首选，效果最好的。PM 和冲突双方协商出都满意的结果，双赢模式，长期 解决问题
妥协/调解：双方各退一步，一定程度满意，双输模式
缓和/包容：求同存异，强调一致而非差异，和稀泥
回避/拖延：当前不解决未来再解决
强制/命令：推行一方否定一方，赢输模式，破坏氛围，紧急情况下使用
项目沟通管理
1、交互式沟通：包括会议、电话、即时通信、视频会议等
2、推式沟通：包括信件、备忘录、报告、电子邮件、传真、语音邮件、日志、新闻稿、广播、博客等
3、拉式沟通：包括企业内网、电子在线课程、经验教训数据库、知识库、订阅，下载、百科、文库、在线影音等
项目风险管理
实施定性风险分析
单个项目风险→严重性等级排序确定每个风险的责任人
三个评估：风险数据质量评估、概率和影响评估、其他参数评估
风险分类：WBS、RBS、阶段
概率影响矩阵：严重性等级最高的需要做定量分析，最低的记录在观察清单风险分值=概 率值×影响值
层级图：气泡图，三个维度综合分析进行排序
实施定量风险分析
整体项目风险 量化风险敞口
工具：访谈—不确定性表现方式（概率分布）--模拟（蒙特卡洛分析）
进度风险：输入进度网络图和持续时间估算
成本风险：输入成本估算
敏感性分析：排序，最大潜在影响 龙卷风图
决策树分析：输入预期货币价值分析的数据，路径净值（毛利润）=沿路径用收益-成本
项目风险应对策略
威胁应对策略
上报：【发现风险采取措施，上报后不再管理】
规避：【发现风险采取措施，风险不发生】
转移：【发现风险采取措施，概率影响没有变化，责任方变更】
减轻【发现风险采取措施，降低概率或者减轻影响】
接受：【发现风险不采取措施，发生时候才采取，主动接受做应急储备，被动接受做记录和监控】
机会应对策略
上报，见威胁应对策略
开拓：【最有能力的资源，或采用全新技术】
分享：【机会一起担当，题目没讲明是机会就是转移】
提高：【增加资源，不是牛人资源】
接受：见威胁应对策略
应急应对策略：根据具体事项制定策略
整体项目风险应对策略：规避、开拓、转移或分享、减轻或提高、接受
接受包括：主动接受和被动接受
主动接受是指：制定风险应对措施
被动接受是指：不主动采取措施，任其发生，只对产生的威胁进行审查，确保不发生重大改变
项目采购管理
采购合同的基本类型
总价类：
1、固定总价合同：适用于边界清晰、设计完整的中小型项目。节省还是超支，风险都有乙方承担
2、总价加激励费用合同：激励规则需要甲乙双方事先约定，有公式可计算
3、总价加经济价格调控合同：适用于履约期较长（数年），对通货膨胀，材料价格等外部条件无法准确预测的情况
成本类：
成本加固定费用合同：成本实报实销，项目的不确定性由甲方承担。适用于前期无法判断项目是否成功，更无法估算项目成本的项目，如创新研发类项目
成本加激励费用合同：成本按预算控制另加约定费用。例如，成本超支或节约，按约定的比例分担或分享
成本加奖励费用合同：成本实报实销，奖励数额完全由甲方主管判断决定，一般不允许申诉
工料类
按实际消耗的工时和材料支付费用，适用于工作内容明确，但工作量不容易准确评估的项目
敏捷
3个角色
产品负责人PO（Product Onwer）
1、定义和排序产品代办列表、用户故事
2、决定发布时间和发布内容、验证需求
3、负责产品的商业论证，比如ROI
开发团队DT （Develop Team）
1、交叉职能，负责交付
2、自组织性：管理个人, 增加达成承诺的自觉性
3、一般 3-9 人
敏捷教练SM（Scrum Master）
1、帮助采用Scrum流程以及建设自组织团队
2、移除在接口上的障碍
3、仆人式领导：帮助提高团队绩效
3个工件
产品待办列表（Product Backlog）
迭代冲刺列表（SprintBacklog）
产品增量（Increment）
5个事件
前期准备（产品待办列表）
PO：
1、记录、澄清、拆分需求
2、验收需要
3、指定发布计划
服务型领导：
1、仆人式领导
2、培养团队
3、消除障碍
DT：
1、自组织
2、交叉
3、5-9人
细化大会Refinement（心愿列表）
PO主持，团队参与
1、由po介绍愿望列表中的需求
2、团队提问，并负责估算故事点
3、根据排序公式对User Story排序
4、形成愿望清单（wish list）
人员
PO，SM，DEV
时间
一周多次
冲刺计划Sprint Planning（冲刺待办列表）
第一部分：PO主持，团队参与
1、根据团队的容量选择本次迭代的工作量
2、速度 Velocity：团队在一个迭代完成的工作量（故事点）
3、输出：本次迭代的最终范围基准
第二部分：SCM主持、团队参与
1、自行选择用户故事
2、定义活动-排列活动顺序-估算活动时间（人/小时）
3、输出：看板
人员
PO，SM，DEV
一周一次
每日站会Daily Scrum Meeting（看板：信息发射源）
1、燃尽图：剩余工作量
2、燃烧图：已完成工作量
3、比看板更深入了解进度
人员
SM，DEV（可选PO）
每天召开
审查/演示Review/Demo（变更请求）
PO主持，团队参与
1、验收开发的产品增量
2、提出反馈，变更请求
敏捷变更流程
1、记录-产品待办列表
2、分析-变更的价值
3、规划-冲刺计划
人员
PO、SM、DEV
时间
一迭代周期一次
回顾会议Retrospective（改进计划）
SCM主持，团队参与
1、持续改进
2、检视本次迭代的工作流程，识别待改进的计划
3、输出：改进计划
人员
SM，DEV（可选PO）
时间
一迭代周期一次
仆人式领导
行为
消除障碍：通过消除进展中的障碍因素来最大化地交付商业价值
避免分心：使团队免受内部和外部分心
鼓励和发展机会：提供相关工具和鼓励，让项目团队保持满意度且工作富有成效
三大特征
增量
迭代
适应性
冲刺（Sprint）
迭代周期，是团队成员开发产品增量的一个时间盒（Timebox，有开始和结束的固定期限），冲刺的长短取决于PO对于变更的容忍度
团队的容量（Capacity）
指团队在冲刺中的理想工作天数，即团队不缺席的天数，用于冲刺规划会如何选取 适当的开发任务时使用
理想小时数
指团队一个工作日内能专心做开发的小时，去除无关的小时（如午餐、开会、休息等），通常有4-5小时
团队的速率（Velocity）
指团队在一个冲刺能完成的实际故事点，这个速率是检查团队效率的一个指标
燃烧图（Burn up chart）
当举行每日站会时，根据团队的更新，可以对每天完成的故事点进行统计叠加，这 样就形成了燃烧图，燃烧图是检查每日完成工作量的一张图
燃尽图（Burn Down chart）
当举行每日站会时，根据团队的更新，可以对每天完成的故事点进行统计叠加，用整个迭代需要完成的故事点与该数字相减，这样就形成了燃尽图，燃尽图是检查每日剩余工作量的一张图
敏捷拥抱的变更，是将其放入产品代办列表里，在细化会对其进行排序，并决定下一个迭代周期是否执行的过程，和PMP的变更流程有着大相径庭的做法