PMP学习，半年备考，2022年7月考已通过。
以下本人学习笔记，思维导图转的word。实际考试大量敏捷题、场景题，占到90%左右。
- 项目引论
1.1. 项目运行环境
1.1.1. 事业环境因素
• 不可控、须遵守
• 制度、信息技术软件、资源可用性、员工能力、商业数据库行业标准、组织已有的沟通渠道
1.1.2. 组织过程资产
• 可裁剪、多积累
• 指南、模板、供应商清单和合同协议、程序、组织对沟通的要求、财务数据库
1.2. 项目生命周期
1.2.1. 增量式
• 快速交付、频繁，短周期
1.2.2. 迭代式
• 适合不断交付正确的产品，长周期
• 范围通常早期确定，成本和时间定期修改
1.2.3. 适应性/敏捷
• 兼具增量和迭代，短周期，需求不断变化
• 敏捷方法重沟通轻文档，重点考虑团队能否在同一地点办公
1.3. 治理框架
1.3.1. 组织目标的设定和实现方式
1.4. 管理要素
1.4.1. 组织内部关键职能部门或一般管理原则的组成部分
• 组织根据其选择的治理框架和组织结构类型分配一般管理要素。
1.4.2. 在正确的时间让正确的人用正确的方法做正确的事 - 质量管理
2.1. 质量成本
2.1.1. 先分析质量成本，再确定是否选择部分样本抽检
2.1.2. 一致性成本
• 预防成本
• 包括质量培训费、质量管理活动费、质量改进措施费、质量评审费和工资及福利基金
• 评估成本
• 测试试验检验费、质量检验部门办公费、工资及福利基金和检验设备维护折旧费
2.1.3. 非一致成本
• 内部失败
• 保修费、退货、索赔
• 外部失败
• 报废、返工、停工损失和内部事故处理费
2.2. 规划：规划质量管理
2.2.1. 质量测量指标
• 对质量管理计划中的高层级质量标准的具体化，项目团队通
过量化过程来达到这些标准
• 项目的质量政策、质量目标
• 控制质量过程将如何验证符合程度，确认合规性
• 描述的是项目或产品属性
2.2.2. 属性抽样VS变量抽样
• 属性抽样是结果合格不合格，变量抽样关注程度
2.2.3. 克罗斯比零缺陷、朱兰fitness for use 适用就好
2.3. 执行：管理质量
2.3.1. 管理质量过程是把质量管理计划中的内容细化成可执行的质量管理活动，并
加以执行，在项目上落实组织的质量政策。
2.3.2. 质量保证（管理质量）
• 关键词“价值活动”
2.3.3. 事中“做”质量
• 针对过程
2.3.4. 工具
• 流程图
• 分析问题是如何产生的，各步骤之间的关系、回退根本原因分析，预测可能发生的质量问题
• 完整地呈现项目中的所有步骤，防止遗漏
• 直方图
• 描述集中趋势、特定组内的频率、分散程度和统计分布形式
• 帕累托图
• 关键字：28定律，优先排序，有重点的采取纠正措施
• 找主要原因，造成大多数问题的少数重要原因，是一种按发生频率排序的特殊的直方图
• 质量审计
• 看看有没有按照组织规定的过程做质量，确定项目活动是否遵循了组织和项目的政策、过程与程序
• 目标
• 识别良好做法、最佳实践、违规、差距、不足，预防出现缺陷和不足
• 分享类似项目的良好实践
• 协助过程改进、提高生产效率
• 积累经验教训，可用于补充现有的控制质量活动
• 确认已批准的变更实施情况
• 审计后发现问题，创建变更请求，遵循整体变更控制流程
• 还可以审查被批准的变更请求实施情况
• 过程改进方法
• PDCA循环、六西格玛
• 面向x的设计
• 专门为了预防不符合某一要求而设计，designed for X，为了什么专门设计的，质量成本可能增加可能降低
• 旨在优化设计的特定方面，可以控制或提高产品最终特性。DfX 中的“X”可以是产品开发的不同方面，例如可靠性、调配、装配、制造、成本、服务、可用性、安全性和质量。使用 DfX 可以降低成本、改进质量、提高绩效和客户满意度。
• 问题解决
• 发现解决问题或应对挑战的解决方案，先弄清楚是什么问题，下一步再做分析
• 检查表
• 计数表，收集和问题相关的属性数据
• 核对单
• 清单，用于核对和提醒
• 确保任务执行一致
• 实验设计
• 使用统计方法，综合权衡各种因素对成本的影响，得到最优组合
• 散点图
• 两个变量之间的关系，分析产生两个问题的共同原因。
2.3.5. 输出
• 变更请求
• 修改质量管理体系
• 质量报告
• 质量问题、改善建议、纠正措施建议、情况概述
• 目的：根据报告判断是否需要修改质量管理计划帮助其他过程或部门采取纠正措施
• 测试与评估文件
• 根据……参考……编制……，以便进行详细测评
2.4. 监控：控制质量
2.4.1. 质量控制（控制质量）
2.4.2. 事后“检查”质量
• 针对可交付成果
2.4.3. 输出
• 质量控制测量结果
• 变更请求
• 解决具体的工作过程或可
交付成果中存在的质量问题
2.4.4. 工具技术
• 控制图
• 规格上限、下限
• 根据要求制定，可允许的最大最小值
• 超出界限-不合格
• 控制上限、下限±3σ
• 统计计算得出，波动范围
• 7点原则或超出界限-失控
• 判断过程稳定、预测未来情况
• 检查
• 可能建议更新标准（变更请求）
2.5. 质量特征
2.5.1. 是设计和测试产品的具体特性，用来衡量产品是否合格
2.5.2. 质量概念既是主观的也是客观的
2.5.3. 质量问题，85%管理层负责（质量管理责任），15%团队成员负责（把事情做对的成果责任）
2.6. 规划质量VS管理质量VS控制质量
2.6.1. 规划
• 确定质量基准，如何达到质量指标
2.6.2. 管理
• 针对过程。过程改进、质量改善
• 避免质量缺陷，通过过程监控来预防
• 编制质量控制测评文件，便于提高实现质量目标的可能性
2.6.3. 控制
• 针对结果。检查管理工作结果、交付成果是否符合质量标准，提出变更请求 - 资源管理
3.1. 补充
3.1.1. 几种理论
• 马斯洛
• 生理-安全-社交-尊重-自我实现
• 人的需求是如何一步步提升的。
• 赫兹伯格双因素理论
• 保健因素（边际福利）、激励因素
• 将外在因素与内在因素并列
• 麦格雷戈
• X理论-人性本恶、Y理论-人性本善
• 对不同的人用不同的管理方法。
• 光环效应
• 帕金森定律VS学生综合征
• 学生综合征：到了最后时间才冲刺
• 帕金森：用完所有时间做无关的事，蔓延
• 激励理论
• 威廉·大内的Z理论
• 终生雇佣制
• 论旨在追求效率、减少对立，尽量取得行动上的统一
• 弗鲁姆期望理论
• 努力成功，报酬多多
• 好好干，达到绩效发奖金
• 麦克利兰成就动机理论
• 根据不同人更看重的成就来源（权利、亲和、成就），采取不同的激励措施。
• 赫兹伯格双因素理论
• 保健因素（良好不会激励，但不好会负激励）、激励因素（成就感、责任感、发展、自我实现）
3.2. 规划：规划资源管理
3.2.1. 资源管理计划
• 角色和职责、项目组织图、人员配备管理计划，如何获取和管理资源
• 项目组织图
• 以图形方式展示团队成员及其报告的关系
3.2.2. 责任分配矩阵，RACI矩阵
• 只能由一个A
• 把工作授权出去，只是移交了执行的责任，而不改变最终责任人。
• 需要完成的工作与团队资源之间的关系
3.2.3. 资源直方图
• 说明项目工作对具体资源的需求，包括在整个项目期间每单位时间（如每天、每周、每月）需要某人、某部门或整个项目团队的工作小时数。
3.3. 规划：估算活动资源
3.3.1. 资源分解结构RBS
• 按资源的类别、类型，对团队和实物资
源的层级列表，逐层细化，可与WBS结合，用以规划和监控项目工作
• 有助于对资源进行获取、管理和报告
3.3.2. 团队章程
• 团队成员共同讨论制定，达成一致认识。创建团队价值观、共识、工作指南
3.4. 执行：获取资源
3.4.1. 本过程旨在以正确的方式在正确的时间获取正确的资源并进行分配，以形成
相应的资源分配文件——实物资源分配单、项目团队派工单。
3.4.2. 塔可曼理论
• 形成
• 互相认识，了解项目情况和各自的角色职责，相互独立
• 震荡
• 规范
• 开始协同工作、开始互相信任
• 项目经理采用支持的领导方式，和成员一起参与项目活动。
• 成熟
• 互相依靠、组织有序、平稳高效
• 项目经理采用授权式领导风格，将大量工作授权给团队成员去完成。
• 解散
3.4.3. 资源获取困难，组织无法提供，考虑招募
3.4.4. 获取资源后，下一步进行资源日历、成员分工
• 资源日历，确定团队成员的可用性
3.4.5. 制定可行德资源管理计划，尽可能多的团队成员和相关方参与规划过程，并获得他们的批准
3.5. 执行：建设团队
3.5.1. 提升团队绩效、提升员工能力
3.5.2. 团队有冲突–冲突管理，士气低落–团队建设
• 现参考资源管理计划
3.5.3. 项目绩效考评VS团队绩效评估
• 项目绩效考评
• 注重每个团队成员如何执行项目、如何完成工作
• 团队绩效评估
• 注重团队效率评估、降低员工周转率
• 包含团队建设的信息，可以提高团队绩效、从而提高项目成功的可能性
3.5.4. 解决冲突的基本方法
• 基本方法
• 合作/解决问题
• “合作”是指取两个现有方案的优点，形成新方案；“面对”是指
选择一个现有的方案，放弃另一个现有的方案
• 面对
• 妥协/调解
针对事
• 各退一步、折中一定程度上满意、差强人意，双输
• 缓解/包容/调和
针对人际关系
• 求同存异，保持友好，双赢
• 私人矛盾，缓和解决，求同
• 撤退/回避
• 强制/命令
• 立即解决冲突
• 内部冲突，尽快并首先私下解决
3.5.5. 团队建设
• 培训共同定位、认可和奖励。提高团队绩效、改善团队氛围、提高实现项目目标的可能
• 能力提升、降低离职率、增强团队凝聚力
• 工具：集中办公=紧密矩阵
3.6. 执行：管理团队
3.6.1. 本过程旨在跟踪团队成员和整个团队的工作表现，并把跟踪到的情况反馈给
团队成员，还要预防和解决团队中出现的问题，管理团队成员的变化
3.6.2. 建设团队VS管理团队
• 共性
• 都是为了提高团队绩效和项目绩效
• 建设团队
• “推动”团队的发展，找到能导致良好团队绩效的方式。
• 管理团队
• “拉动”团队的发展，基于实际行为及效果，采取补充行动来管理团队。
3.6.3. 工具
• 项目管理信息系统
• 为指导和管理项目工作提供自动化工具，用于收集和报告绩效
3.6.4. 绩效评价
• 好言相劝不管用，祭出大旗，绩效考核强制约束
3.6.5. 基本规则
• 解决冲突，如团队成员质检的负面评价
3.7. 监控：控制资源
3.7.1. 本过程旨在监督和控制实物资源的获取、分配和使用，提出必要的变更请求，
确保在正确的时间将正确的资源用在正确的地方，确保资源使用的效率和效果，
并在使用完毕后及时释放资源
• 关注实物资源
3.7.2. 项目成员遣散计划
3.7.3. 人员变更，先评估对项目德影响，视评估结果提出相应变更
• 评估影响参考资源管理计划 - 模拟题笔记
4.1. 敏捷
4.1.1. 敏捷DoD:完成标准
• 满足什么标准才算迭代完成
• 产品负责人最终确认是否达到验收标准
4.1.2. 产品负责人
• 负责按价值排列优先级，判定哪些需求最有价值并排序
• PO代表客户的利益，工作重点是从业务角度出发调整功能需求
• 负责发布计划
• 计划更新修订由团队和PO共同确认
• 待办事项细化会议
• 相关方反馈新故事后，产品负责人待办事项列表的细化准备与会议，把整个故事的概念呈现给团队
4.1.3. 自组织的开发团队
• 自组织团队，没有领导。不需要向PO或SM汇报工作，方案和分歧也不是他们决策，由团队成员民主表决。团队自组织自我评价，自我改进
• 团队遇到问题，团队绩效低了，考虑分析“流程价值”，消除浪费
• 客户和团队对需求发生冲突？客户有决定权
• 遇到问题，先让团队处理。团队有震荡了/士气低下，敏捷项目管理经理介入，团队协作
• 遇到问题，团队协作，协作！先分析问题
• 团队成员出现问题时，先私下沟通，鼓励团队成员，并提供帮助解决问题
• 两个团队有误解？沟通
• 激励、相信、私下
• Scrum主管发现问题，应告知团队成员，有团队成员自行决定如何继续工作，透明沟通的原则
• 如有虚拟团队，完全自组织不现实
• 团队成员不愿发言，不够投入
• 使用DISC框架，寻找定义个人行为模式的方法
• MosCoW
• 需求排序的方法
• SoS
• Scrum of Scrums目标是取保团队协调工作并清除障碍，以优化所有团队的效率，可帮助多个敏捷团队的项目解决问题
• 团队决定将工作项添加到冲刺，产品负责人确定添加到待办事项列表并排列优先级
4.1.4. 产品所有者负责确定商业价值是否已经实现
4.1.5. 计划扑克
• 基于宽带德尔菲，以共识为基础的工作量估算技能。在故事点和开发用户故事中估算相对工作量。
4.1.6. 产品待办事项
• 需求/变更由客户提出，再由产品负责人调整产品待办事项，然后敏捷团队调整。不应该敏捷实践者直接与相关方合作
• 一般不接受当前冲刺中添加新任务，除非紧急或重要且优先级非常高。团队与PO合作，PO确定优先级，团队讨论决定是否本次迭代添加，必要时投票。不是SM批准。
• 产品负责人与客户确定优先级
• 如果遇到一些复杂需求，为了避免转述造成的误解，是可以让客户直接和团队沟通的。
• 收到变更请求，通知产品负责人加到待办事项中，并与已有待办事项进行优先级排序
• 识别到重大技术债务时，在产品待办事项中收集，供未来迭代处理。
• 有问题，问题改进项，列入待办事项列表，以供查看，确保实施改进的效果
• 条目应符合DEEP原则
• 详略得当的
• 经过估算的
• 涌现的
• 按优先级排序的
• 确定和吸引业务相关方，确保团队了解相关方的需求
4.1.7. SM
• 团队的导师，帮助团队提高效率
• 与PO不能是同一人
• 与团队成员指定团队规则
• 变更多，与敏捷教练合作，协作的方式，拥抱变更
• 保护团队在冲刺过程中不被干扰
• 整合
• 敏捷教练推行敏捷实践，对整合管理提供指导和支持，由开发团队执行整合管理
4.1.8. 敏捷PMO
• 多学科型，可以制定和实施标准，提供用户故事、测试案例、累计流量图等模板
4.1.9. 信息发射源
• 用户故事地图
• 从客户角度展示产品全景，提供范围
• 任务板/看板面板
• 展示当前和未来迭代的任务
• 西悉尼放射源，随时了解项目状态
• 在线协作网站
4.1.10. 燃尽图/燃起图
• 监控项目执行情况，用于团队讨论，显示团队速度与故事点之间的关系，便于团队及时进行调整和纠偏
• 燃尽图：通过将实际绩效与计划绩效进行映射来了解项目进度
• 显示过程并帮助判断项目应该什么时候完成
• 燃尽图：剩余工作，燃起图：已完成、已交付的东西
4.1.11. 演示（确认范围、验收可交付成果）–如有问题或调整，后面冲刺中调整
4.1.12. 敏捷的不确定性的三个特征
• 过程适用性、产品说明书、产品能力
4.1.13. 用户故事地图VS产品开发路线图
• 产品开发路线图
• 由产品负责人、团队一起制定
• PO所拥有，可以很好的聚焦关键利益相关者关注的价值
• 用户故事地图
• 比产品开发路线图详细，从客户角度展示产品全景
• 了解何时可以提供范围
4.1.14. 预算
• 敏捷项目预算一般不变，范围和进度具有共生关系，动态调整
• 财务部门负责预算
4.1.15. 风险
• 项目涉及重大技术风险，从第0轮冲刺就开始关注风险，并对风险制定合理的应对措施
• 不用风险登记册
4.1.16. 基于流程的敏捷
• 站立会
• 作为一个团队我们需要完成什么
• 我们需要做什么推进此工作
• 是否有人在做黑板上没有的事
• 在工作流程中是否有任何瓶颈或障碍
4.1.17. 基于迭代的敏捷
• 站会
• 昨天？今天？障碍？
4.2. 混合型
4.2.1. 项目经理（一定有）
• 全局把控项目，对项目负最终责任
• 项目经理是促进者，促进合作，帮助团队消除障碍
• 对变更负责
4.2.2. SM
• 发起人、相关方有问题来问他，别找项目团队成员
• 指导、培训，促进团队协作
• 冲突
• 分为两组：正面、负面
4.2.3. PO（不一定有）
• 负责需求优先级，负责产品待办事项列表
• 冲刺计划
• 接受变更，首选PO
4.2.4. 团队成员
• 项目经理可以适当放权，鼓励团队做决定
• 自组织团队，民主领导风格，团队集体决策
4.2.5. 衡量交付物的质量
• 时间盒
• 固定的项目节奏
• 站立会议
• 使团队理解每人每天承诺的价值所在，并兑现
4.2.6. 持续调查可交付成果的质量，以确保在执行阶段完全符合质量要求
4.2.7. 保护团队免受干扰
4.3. 冲突解决的初始责任是冲突者，然后是项目经理
4.4. 亲和图
4.4.1. 1、按照共同属性、逻辑关系将问题直接联系起来。
4.4.2. 2、分组
4.5. 冲突的来源
4.5.1. 稀缺的资源、个人工作风格、日程安排的优先级
4.6. 引导式研讨会VS焦点小组
4.6.1. 引导：达成一致意见
4.6.2. 焦点小组：收集全面的需求，同领域专家
4.7. 审计：只有发生问题或上级要求时才开启
4.8. 领导力技能：包括指导、激励和带领团队的能力，包括人际交往、领导者的品质和技能、权术权利、办好事情
4.9. 团队章程
4.9.1. 团队价值观、沟通指南、冲突处理准则和措施、团队共识、会议指南
4.10. 配置管理计划
4.10.1. 四大类内容：版本、变更、文档、过程
4.11. 项目经理
4.11.1. 能力/技能
• 技术项目管理技能
• 与项目、项目集和项目组合管理特定领域相关的知识、技能和行为
• 领导力技能
• 指导、激励和带领团队所需的知识、技能和行为，可帮助组织达成业务目标
• 战略和商务管理技能
• 关于行业和组织的知识和专业技能，有助于提高绩效产取得更好的业 务成果
4.11.2. 整合的三个层面
• 过程
• 一系列过程和活动
• 认知
• 项目经理的能力
• 背景
• 新技术等
4.12. 范围说明书VS范围管理计划
4.12.1. 范围说明书是客户与项目团队就项目的准确工作达成的协议
4.12.2. 范围管理计划、需求管理计划是指导项目团队如何管理范围和需求，是指导性纲领文件
4.13. 项目经理成本和进度问题，如何解决问题？–因果分析查找原因。挣值管理无法解决问题，只是个绩效测量工具
4.13.1. 挣值分析
• 关注偏差和绩效，确保成本不受影响
4.14. 质量管理
4.14.1. 质量量偏差超过规格上限或下限，就表明产品是不不合格的
4.14.2. 标杆对照（基准实践）
• 可以来自任何行业或组织，只要在特定方面与本项目有可比性即可
4.14.3. 客户满意度–适用性
• 客户满意就是需要把“符合要求”（确保
项⽬目产出预定的成果）和“适合使⽤用”（产品或服务必须满⾜足实际需求）结合起来.适用性
4.14.4. 管理质量-质量审计
• 确认项目是否包含了最新的变更请求
4.14.5. 流程图
• 可了解和估算一个过程的质量成本
• 帮助分析问题是如初出现的
4.14.6. 结构化问题解决7步法
• 1、先记录，后定义问题–2、分析识别根本原因，收集信息–3、出具可能的解决方案–4、选择最佳方案–5、实施解决方案–6、验证解决方案有限性
4.14.7. 帕累托图
• 大量原因中的主要原因
• 排序，最大、频率
4.14.8. 直方图
• 能用图表描绘在一个特定组内出现的观测值频率
4.14.9. 控制图
• 过程稳定？预测未来情况
• 先用控制图探明生产过程是否失控–如果失控，在用流程图探明哪个环节除了问题
• 规格上下限
• 可允许的最⼤大值和最⼩小值，硬性要求，超过规格上下限，就表明产品是不合格的。
• 控制上下限
• 过程偏差可接受的范围，超出即失控
4.14.10. 质量特征是涉及和测试产品的具体特征，可度量的，既是主观的也是客观
4.14.11. 质量核对单
• 确保任务执行一致，核实所要求的事情是否已经被正确执行
• 检查表
• 收集数据
• 对于核查表和帕累托图内容的补充：“用核查表收集的关
于缺陷数量或后果的数据，又经常使用帕累托图来显示
4.14.12. 质量功能展开
• 强调吧功能和需求联合起来考虑，确定各种功能满足用户需求的程度，并排序
4.14.13. 矩阵图
• 行列交叉的位置展示因素、原因或目标之间的关系强弱
4.14.14. 鱼骨图
• 将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因
4.14.15. 质量量管理理⽔水平有效性排列列，最有效的举措是在整个组织内建⽴优秀的质量文化
4.14.16. 审计-管理质量过程、监督风险过程、控制采购过程；
4.15. 风险
4.15.1. 风险态度
• 风险阈值和风险偏好
• 风险偏好大于风险承受力，太冒险，不成功便成仁
4.15.2. 内部报酬率
• 项目抗风险的能力大小、盈利能力大小
4.15.3. 净现值
• 净现值指未来资金（现金）流入（收入）现值与未来资金（现金）流出（支出）现值的差额，是项目评估中净现值法的基本指标
4.15.4. 制约因素/假设条件
• 制约因素可以用合理代价接触，可以获得一个机会
• 假设条件成立的可能性很小，可以写成威胁
4.15.5. 识别风险
• 风险分解结构，有利于全部识别风险，避免遗漏
4.16. 分析
4.16.1. 偏差分析
• 判断偏离进度基准的原因和程度，以及是否采用纠偏或预防措施
4.16.2. 工作绩效
• 工作绩效数据what
• 原始观察结果和测量值
• 通常记录在项目管理信息系统PMIS中，如完成百分比、质量/技术绩效测量结果
• 工作绩效信息why
• 与计划相比较的结果，各种比较值包括偏差分析、进度偏差、成本偏差、范围偏差
• 可以看到偏离进度计划的任何关键里程碑
• 工作绩效报告how
• 为制定决策、提出问题、采取行动或引起相关方关注
• 确定上一过程是否延期
4.16.3. 趋势分析
• 判断绩效改善还是恶化
• 担心项目将超出批准的预算
4.16.4. 挣值分析
• 关注偏差和绩效
4.16.5. 绩效审查
• 面向未来的，对能力的综合评价
4.17. 变更专题
4.17.1. 变更管理流程
• 提-记-评-批-更-通-干
4.17.2. 对变更的追踪
• 只有经过批准的变更，才能被追踪
4.18. 采购
4.18.1. 与多个供应商签订多个合同，注意管理多个供应商之间的界限
• 每个合同的风险单独管理
4.18.2. 卖方做了额外的工作
• 买方先支付卖方的合理索赔金额，并采购合理措施
4.18.3. 索赔管理
• 谈判是所有索赔和争议的首选方法
• 如果发现对方违约，必须第一时间书面告知对方，保留自己的索赔权利
4.18.4. 合同条款
• 招标文件中包括合同条款、预付款等，如有疑问，在提交投标文件之前，投标人会议上进行商谈。
4.18.5. 合同工作分解结构CWBS
• 合同签订后，卖方应编制合同工作分解结构，与买方就合同工作范围的细节达成一致
4.19. 相关方
4.19.1. 识别-分类-根据分类制定有值队形的沟通策略
• 凸显模型
• 权利、紧迫性、合法性
• 大型复杂项目
• 相关方立方体
• 三维分析、有助于制定沟通策略
4.19.2. 相关方参与计划
• 包括但不限于调动相关方参与的策略，也记录了可能影响相关方的因素
4.20. 资源管理
4.20.1. 资源直方图VS资源分解结构VS资源日历
• 资源日历
• 每种具体资源可用的工作日
• 资源分解结构
• 展现整个项目所需的各种资源种类和数量
• 资源直方图
• 项目每个时间需要哪些资源
• 责任分配矩阵
• 显示了分配给每个工作包的项目资源，用于说明工作包或活动与项目团队资源的关系
4.20.2. 建设团队VS管理团队
• 建设团队
• 提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程
• 集中办公、团队建设、培训、个体和团队评估、认可与奖励
• “推动”团队的发展，找到能导致良好团队绩效的方式
• 管理团队
• “拉动”团队的发展，基于实际行为及效果，采取补充行动来管理团队。
• 冲突管理、情商、影响力、领导力 - 沟通管理
5.1. 规划：规划沟通管理
5.1.1. 干什么？
• 何时何地何人何种方式沟通什么信息制定恰当的方法和计划。为及时向相关方提供相关信息，引导相关方有效参与项目，而编制书面沟通计划。
5.1.2. 沟通渠道
• N（N-1）/2
5.1.3. 沟通模型
• 编码-发送信息-确认收到-解码-反馈/响应
5.1.4. 有效沟通5C原则
• 目的清晰、明确
• 表达正确、简洁
• 逻辑连贯
• 加入引言和小结
• 思路掌握
5.1.5. 确定沟通的复杂性
• 先进行沟通需求分析，再构建沟通模型
5.1.6. 沟通方法
• 推式
• 特定的接收方，确保发送，不确保目标受众收到或理解
• 发邮件、报告、新闻稿、备忘录
• 受众非常多的情况不适合
• 书面文件发给特定对象属于推式沟通
• 拉式
• 适用受众多、信息量大
• 网站、共享盘、知识库
• 布告栏公布信息属于拉式沟通
• 互动
• 实时，最有效
5.2. 执行：管理沟通
5.2.1. 干什么？
• 是确保信息及时且恰当收集、生成、发布、存储、检索、管理、监
督和最终处置的过程。本过程的主要作用是，促成项目团队与相关方之间的有效信息流动。
5.2.2. 输入
• 工作绩效报告
• 状态报告、进度测量结果、预测结果，确定上一过程是否延期
• 相关方登记册
5.2.3. 项目状态会议
• 已完成、进行中、未开始的工作包
5.3. 监控：监督沟通
5.3.1. 干什么？
• 便发现、记录和分析沟通工作中的偏差，并提出变更请求
5.3.2. 区别
• 规划沟通管理过程是为了开展有效率和有效果的沟通而编制沟通
管理计划，管理沟通过程是实实在在开展有效率和有效果的沟通，监督
沟通过程是监督沟通的效率和效果是否达到了计划中的要求 - 敏捷50%
6.1. 敏捷开发流程
6.1.1. 产品愿景，干系人分享，目标达成共识–待办事项列表，优先级排序–迭代计划会议，选择高优先级待办事项–每日站会–迭代复审会议，演示demo–迭代回顾会议
• 干系人参与，共同制定敏捷做法
6.1.2. 四大会议
• spring迭代计划会
• 本次迭代做什么？价值排序。spring应包含什么特性、功能
• 用户故事：故事点
• 变更不纳入spring待办事项，放入下次迭代，与剩余工作排序优先级
• 每日站会
• 昨天？今天？明天？
• SM引导，只暴露问题，不解决问题
• 跟踪进度，最新进展、曝光风险
• 只有猪可以发言
• 基于流程的站会，关注团队能力和工作流程
• spring评审会议
• 演示增量，获得反馈，促进合作
• PO必须参加
• 回顾会议
• 总结反思、发现问题并计划解决、流程改进
6.2. 范围管理
6.2.1. 产品未完项
• 每个迭代中重复收集需求、定义范围和工作分解结构，选择最优先项在下一次迭代中交付
6.2.2. 有变更找PO，商量影响和应对措施
6.2.3. 看板
• 由团队负责更新自己的工作状态，进而作为一个团队对整体项目状态更新和监督
• 记录和跟踪遇到的障碍，连续冲刺，改善
6.3. 进度管理
6.3.1. 敏捷发布规划
• 基于项目路线图和产品发展愿景，确定发布的迭代或冲刺次数
• 遣散计划
• 定义了发布的迭代次数
6.3.2. 燃尽图
• 对角线，表示理想燃尽情况，再每天画出实际剩余工作，基于剩余工作计算出趋势线以预测完成情况。从过去的曲线也看出
• 本迭代剩余工作量与工作日的关系，一般每日站会更新
• 还剩余多少工作
6.3.3. 燃起图
• 燃起图可以看出项目范围的变化。除了显示已完成的工作量，燃起图还能显示项目中的实际总工作量
• 多个迭代的需求累计完成情况（y 轴）与各迭代（x 轴）的关系
• 已完成多少工作。范围的变化
6.3.4. 产品路线图、故事地图
• 跟踪现状，了解项目全貌
• 产品路线图（产品负责人所拥有）
• 关于产品发布和产品主要组件的可视化概述，快速查看主要发布点和该发布点计划功能的沟通工具
• 由产品负责人、团队一起制定
• 故事地图（团队成员）
• 客户价值优先级排序的工具
• 关于功能何时交付的产品路线图
• 可视化的展示
• 如果故事规模太大，可沿支持的数据边界分割大故事
6.3.5. 产品待办事项和每日站会
• 计划和监督相关方
• 产品待办事项
• 由产品负责人排列优先顺序
• 收集技术债务，供未来迭代处理
6.3.6. 价值流程图
• 把工作步骤展示出来，找出整体上的改进点。让浪费看得见，查看消除浪费的时间
6.3.7. 利特尔法则
• 在制品数量越少，平均每个产品完工周期就越短。改进质量。
6.3.8. 累计流量图/看板
• 看出当前缺陷的数量，目前的解决状态及循环时间和前置时间。
6.4. 成本
6.4.1. 若要求严格控制成本
• 更频繁地更改范围和进度计划，来保证项目在成本制约因素之内
6.5. 资源
6.5.1. 自组织团队
• 复合型人才
6.6. 敏捷宣言-四大价值观
6.6.1. 个体和交互
6.6.2. 工作软件
6.6.3. 客户合作
6.6.4. 相应变化
6.7. 三大支柱
6.7.1. 透明、检视、适应
6.8. 关键词
6.8.1. 协调、协商、鼓励、讨论、一起、引导 √
6.8.2. 上报、管理、要求、必须、举报、解雇、竞争 X
6.8.3. 缺乏经验、不了解技术或项目
• spike 刺探技术
6.8.4. 价值风险4纬表格
• 先做高价值、高风险的
6.8.5. 排序优先级
• Moscow莫斯科、卡农Kano、虚拟货币
6.8.6. 纪录类的文件或字眼，错误
6.8.7. 需要估算
• 带宽德尔菲、敏捷扑克、相对估算、亲和估算
6.9. 风险燃尽图
6.9.1. 干系人可快速查看随着时间项目风险管理的绩效
6.9.2. 在理想情况下， 风险严重度会随着时间降低
7. 相关方管理
7.1. 启动：识别相关方
7.1.1. 权力利益方格（二维）、相关方立方体（三维）、凸显模型（大型）
• 进行分类、团队与相关方建立关系
7.1.2. 相关方登记册
• 相关方基础信息、期望、权力利益、需要最多关注
• 确保与相关方期望保持一致
• 相关方不了解他们在项目中的参与情况？优先完善相关方登记册
• 记录：相关方的识别信息、评估信息、分类
7.1.3. 相关方分析
• （如职能经理不愿提供资源）分析相关方，了解相关方的关系、利益、期望和影响，利用关系建立联盟和合作
7.2. 规划：规划相关方参与
7.2.1. 干什么？
• 基于对相关方的分析，制定相关方参与方法
7.2.2. 区别
• 相关方参与度评估矩阵（没有策略）
• 是一种工具技术
• 相关方参与计划
• 如何调度的策略
• 是一份计划，可提供给上级
7.3. 执行：管理相关方参与
7.3.1. 干什么？
• 与相关方沟通协作，促进其参与，解决问题、满足他们的期望
7.4. 监控：监督相关方参与
7.4.1. 干什么？
• 发现有偏差，提出纠偏措施，让相关方合理参与
8. 风险管理
8.1. 规划：规划风险管理
8.1.1. 风险管理计划
• 如何对识别的风险进行分析和规划应对策略
• 包括风险管理战略、可接受的临界风险（相关方风险偏好）、职责、资金、风险类别、概率和影响定义
• 风险临界值、风险容忍度，反映在项目的风险影响级别定义中
8.2. 规划：识别风险
8.2.1. 风险登记册
• 单项风险的概率、影响评估
• 风险登记册仅供项目团队内部使用，风险报告则报送给主要相关方。
• 包含观察清单
• 内容：风险清单、潜在的风险责任人、初步应对措施
8.2.2. 风险报告
• 整体项目风险信息
• 记录最重要的单个项目风险
• 已识别风险的优先级列表及简要结论
8.2.3. 模糊性风险
• 基于复杂度制定风险管理措施
8.2.4. 工具
• 专家判断、头脑风暴、访谈、SWOT分析、核对单、假设条件和制约因素分析
• 德尔菲
• 减少分析过程中的偏见，防止任何人对事件结果施加不正确的影响
8.3. 规划：定性风险分析
8.3.1. 干什么？
• 单个项目风险发生的概率和影响以及其他特
征，对风险进行优先级排序
8.3.2. 概率影响矩阵
• 对单个风险进行概率影响评估。优先级排序
8.3.3. 对所有项目以及已识别的全部单个项目风险，都要进行定性分析，
但不是都要进行定量分析，应当依据风险管理计划的规定，来确定是否
需要进行本过程。
8.3.4. 实施定性风险分析过程的落脚点是单个项目风险，实施定量风险分
析的落脚点是整体项目风险
8.3.5. 正式确定风险责任人
• 负责规划风险应对措施，
并确保实施应对计划。
8.3.6. 气泡法
8.4. 规划：实施定量风险分析
8.4.1. 干什么？
• 量化整体项目
风险敞口，并提供额外的定量风险信息，以支持风险应对规划。
8.4.2. 决策树
• 清楚显示出项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果，后果发生的概率，以及每种方案的损益期望值
• 通过计算每条分支的预期货币价值，就可以选出最优路径
8.4.3. 敏感性分析（龙卷风图）
• 用敏感性分析计算每个风险的影响值，在用龙卷风图排序，确定最大影响的风险
• 有助于比较具有较高不确定性的变量与相对稳定的变量之间的相对重要程度。
8.4.4. 预期货币价值分析EMV
• 不确定情况下的平均值，解决选择困难症
• 收益大于成本，EMV为正值，可以考虑采用新技术
8.4.5. 影响图
• 是不确定条件下决策制定的图形辅助工具，它将一个项目或项目中的
一种情境表现为一系列实体、结果和影响，以及它们之间的关系和相互影响
8.4.6. 蒙特卡洛模拟
• 如缺陷数量多余或少于预期，变异性风险
8.4.7. 加权系统
8.5. 规划：规划风险应对
8.5.1. 为处理整体项目风险敞口，以及应对单个项目风险，而制定
可选方案、选择应对策略并商定应对行动的过程
8.5.2. 干什么？计划增加机会并降低威胁
8.5.3. 已知未知
• 应急储备
• 对于整个项目的应急储备，如果没有任何可靠的依据，就按项目总
成本的 10%计算。
• 主动接受策略，管理特定风险
8.5.4. 未知未知
• 提前加强项目的韧性，灵活应对突发性风险
• 发生了就动用管理储备，走审批
8.5.5. 应对措施
• 规避（概率高、影响大）
• 延长工期、改变策略、缩小范围、确保万无一失
• 去掉ABS中有风险的工作包、或由第三方消除
• 分享
• 多方合作
• 减轻
• 采取措施降低威胁发生的概率或影响
• 接受（概率低、影响大）
• 应急储备、定期审查
• 积极风险/消极风险都可采用策略
• 置之不理
• 增强
• 积极风险应对，如增加资源
• 转移
• 对财务风险应对最有效
• 开拓
• 积极风险，确保风险一定发生（机会）
8.6. 执行：实施风险应对
8.6.1. 应急计划（已知的风险、应急储备，走变更刘城）–弹回计划–权变措施（处理未知的风险、必须走变更流程）
8.7. 监控：监督风险
8.7.1. 输入：工作绩效信息、工作绩效报告
8.7.2. 早发现早治疗，持续评估风险管理工作有效性，避免执行过程中的不合格
8.7.3. 风险审计
• 风险评估，评估风险管理工作的有效性
• 将计划实施结果与可接受临界风险对比
8.7.4. 风险审查会（包括风险再评估）
• 在风险审查中，还可以识别出新的单个项目风险（包括已商定应对措施所引
发的次生风险），重新评估当前风险，关闭已过时风险，讨论风险发生所引发的
问题，以及总结可用于当前项目后续阶段或未来类似项目的经验教训。
8.7.5. 技术绩效分析
• 把项目执行期间所取得的技术成果与取得相关技术成果的
计划进行比较。实际结果偏离计划的程度可以代表威胁或机会的潜在影响。
9. 采购管理
9.1. 规划：规划采购管理
9.1.1. 输出
• 采购管理计划
• 描述了合同的书写规范、合同的收尾内容
• 采购工作说明书SOW
• 依据项目范围基准，为每次采购编制工作说明书（SOW），详细描述拟采购的产品、服务或成果，以便潜在卖方确定他们是否有能力提供这些产品、服务或成果。
• 供方选择标准
• 作为依据对卖方建议书进行评级和打分
• 财务能力 重要指标之一
9.1.2. 做什么
• 编制采购管理计划、编制招标文件、识别潜在卖方
9.1.3. 采购流程
• 自制外购分析-采购策略-编制SOW-编制招标文件-独立估算-识别潜在卖方-投标人会议-招标-选择卖方-合同谈判-签订合同-控制采购
9.2. 执行：实施采购
9.2.1. 发招标文件、开招标会，评审Review卖方建议书选择卖方，签订合同
9.2.2. 采购协议
• 定义了规定的产品服务或成果，双方义务及权力、验收标准及支付条款等。可交付成果的详细信息
9.3. 监控：控制采购
9.3.1. 管理合同关系，监督合同绩效，纠偏或变更，核实和移交成果，关闭合同，总结经验教训
9.3.2. 索赔管理
• 首选谈判
• 若客户停止所有沟通，无法谈判
• 考虑替代争议解决方案
• 调解、仲裁、谈判、诉讼
• 还有未决索赔，不能关闭合同
9.3.3. 绩效审查
• 面向未来，卖方执行本合同的能力评价，未来要不要让他做
• 决定项目是否进入下一阶段
• 工作包提前或落后进度计划？超出还是低于预算？是否存在资源或质量问题？
9.3.4. 采购审计
• 对合同和采购过程的完整性、正确性和有效性进行审查。
• 记录经验教训，成功与失败之处，供未来参考
9.3.5. 收集数据和管理项目记录，建立与采购相关的项目数据，以便向卖方付款
9.3.6. 合同收尾
• 合同收尾需要更新合同记录，收集资料，整理合同档案，总结采购工作经验教训
更新组织过程资产。
9.4. 几种合同
9.4.1. 固定总价
• 买方风险最小，范围确定
• 总价加经济价格调整合同
• 适用于长期合同
9.4.2. 总价加激励合同
• 设置了封顶价，超过价格上限的全部成本由卖
方承担
• 计算
• 先算总价，与最高限价比较：总价=实际成本+目标利润+（目标成本-实际成本）x卖方比例
• 实际利润=最终总价-实际成本
9.4.3. 成本补偿合同
• 适用于买方不清楚具体工作范围（范围十分不清楚），或者买方特别信任卖方的情况。买方的风险最高。
• 成本加激励合同
• 买方承担履行合同的一切可列支成本，双方按
比例承担节约或超支的部分
• 可激励卖方节约成本，降低买方成本风险
• 计算
• 先算最终费用，与最低最高费用比较：费用=目标费用+（目标成本-实际成本）x卖方比例
• 总价=最终费用+实际成本
• 成本加固定费用奖励合同
• 按买方的主观感觉给与适当奖励
• 范围不明、后期可能有大的范围变更
9.4.4. 工料合同
• 范围不十分清楚，缺乏项目管理能力、工作规模小、工期短、任务简单
• 双方都有风险
• 无法明确编制采购说明书时，兼具成本补偿和总价合同的特点
10. 成本管理
10.1. 管理储备
10.1.1. 项目经理无权控制，如要使用需要提交变更请求
10.1.2. 只能针对整个项目进行预留，而不能针对活动或阶段预留。
10.2. 规划：规划成本管理
10.3. 规划：估算成本
10.3.1. 工具技术
• 自下而上估算、三点估算（考虑风险）、专家判断
• 参数估算VS类比估算
• 参数估算可有公式计算出，有统计关系
• 成本和工期准确性十分重要，不考虑风险
• 类比估算
• 启动阶段、项目早期信息不足时，特点：快速、低成本、准确度较低
• 也叫自上而下，也是一种专家判断
• 数据分析（储备分析、质量成本、备选方案分析）
• 决策（投票）
• 项目管理信息系统
10.3.2. 输出成本估算、估算依据
10.3.3. 估算成本是对完成项⽬目⼯工作所需资源成
本进⾏行行近似估算的过程
10.4. 规划：制定预算
10.4.1. 成本基准
• 包括应急储备
10.4.2. 工具技术
• 储备分析
• 监督项目中应急储备和管理储备使用情况，是否够用，是否需要增加
• 成本汇总
• 资源限制平衡
10.4.3. 项目预算
• 成本基准+管理储备
10.4.4. 汇总所有单个活动或工作
包的估算成本，建⽴立一个经批准的成本基准的过程”
10.5. 监控：控制成本
10.5.1. 挣值分析
• SPI、CPI
• 完工尚需预算
• ETC = （BAC-EV）/CPI
• 完工预算BAC
• 完工估算
• EAC = AC+ETC
• 完工偏差
• VAC =完工预算 BAC - 完工估算EAC
• 完工尚需绩效指数
• TCPI=（BAC-EV）/（EAC-AC）
• 剩余的价值/剩余的预算，用1块钱干多少活，越小越好
• EAC=BAC ，TCPI=1，可以完成；EAC>BAC,TCPI<1,容易完成；TCPI>1,不容易完成
• 挣值管理
• 将范围、进度、成本测量值综合起来，评估项目绩效和进展
• 确保成本基准不受影响
10.5.2. 输出成本预测
11. 进度管理
11.1. 规划：规划进度管理
11.2. 规划：定义活动
11.2.1. 工具
• 滚动式规划，一种渐进明细的规划方式
• 分解
11.2.2. 输出活动清单、活动属性、里程碑清单（图）、变更请求
11.3. 规划：排列活动顺序
11.3.1. 子主题 2
11.4. 规划：估算活动持续时间
11.4.1. 三点估算PERT
• 贝塔分布（默认）
• 标准差
• （最悲观-最乐观）/6
• ±1σ:68.2%,±2σ:95.4%,±3σ:99.7% ；±4σ：99.9%
• 最可能x4+最乐观+最悲观/6
• 三角分布
• 最可能+最乐观+最悲观/3
11.4.2. 持续时间估算不包括滞后量和提前量
11.4.3. 进度安排的灵活性
• 总时差决定
11.5. 规划：制定进度计划
11.5.1. 紧前关系绘图
11.5.2. 进度网络分析
• 关键路径法
• 一般情况下，关键路径活动的浮动时差为0，也可能为负或正
• 正常情况下，关键路径上的活动，其浮动时间为零。当关键路径上的活动，
出现了负浮动时间，则表示活动被延迟了，必须立即解
• 自由时差
• 不影响紧后活动开始的可浮动时间
• 项目总时差
• 不延误项目完工日期的总浮动时差，体现进度的灵活性
• 作为评估项目进度绩效的一种途径
• 资源平衡VS资源平滑
• 资源平衡
• 当出现资源短缺时使用，很可能改变关键路径。
• 尽量减少资源负荷的变化
• 资源平滑
• 资源平滑作用于活动的浮动时间内
• 关键路径保持不变，资源制约时
• 一般先做资源平滑，再做资源平衡
• 建模技术
11.5.3. 进度压缩
• 赶工
• 投入资源
• 是否一定要变更？影响基准？
• 平衡进度和成本因素
• 快速跟进
• 并列开展，风险增加
• 关键前提条件
• 不缩减项目范围
• 活动之间是软逻辑，选择性依赖关系
11.5.4. 关键路径法VS关键链法
• 关键链法考虑资源制约
• 关键路径理想状态下
11.5.5. 蒙特卡洛模拟
• 利用风险和其他不确定资源计算项目可能的进度结果，计算概率分布，计算多种可能的持续时间。
• 可能结果分布
• 分析风险对项目结果可能产生的影响
11.5.6. 横道图/甘特图/概括进度计划图
• 活动与时间的关系，可用于追踪活动进度，或用于显示项目实际进度。
• 甘特图=横道图
• 向管理层汇报项目进展情况，高层次
• 里程碑图
• 比甘特图更高层次
• 从较高层次展示主要可交付成果的状态
11.5.7. 网络图
• 显示活动之间的逻辑关系。
• 路径汇聚、路径分支
11.5.8. 里程碑图/里程碑进度计划
• 于显示项目内外部之间的关键接口（里程碑）。
11.5.9. 进度关联横道图/详细进度计划/进度网络图
• 活动之间的依赖关系，进度关联横道图结合了里程碑图和横道图的特点，并指明了各种活动之间的关系。
• 项目团队内部进度信息
11.5.10. 输出进度数据
• 至少包括进度里程碑、计划活动、活动属性及已知的全部假设条件和制约因素
11.5.11. 输出项目进度计划
• 进度基准
• 进度计划里的高层次进度计划，管理层批准
11.6. 监控：控制进度
11.6.1. 本过程通过比较项目的进度绩效与进度计划中的要求，分析偏差并预测未来
绩效，并解决不可接受的偏差或可能发生的不利绩效
11.6.2. 偏差分析
12. 范围管理
12.1. 规划：规划范围管理
12.1.1. 需求管理计划
• 如何收集需求
12.1.2. 范围管理计划
• 如何开展定义范围、创建WBS、确认范围、控制范围
12.1.3. 项目范围VS产品范围
• 项目范围是对项目所期望的最终产品和可交付成果，以及为实现该产品和可交付成果所需各项具体工作的简明描述。
• 项目范围有时包含产品范围
• 产品范围指的是产品或服务的特征与功能
12.1.4. 项目范围的完成情况是根据项目管理计划衡量的，产品范围的完成情况是根据产品需求衡量的
12.2. 规划：收集需求
12.2.1. 需求文件VS需求跟踪矩阵VS用户故事
• 需求文件
• 描述各种单一需求如何满足业务需求
• 需求跟踪矩阵
• 从来源连接能满足需求的可交付成果，为管理产品范围变更提供了框架
• 用户故事
• 对需求的简短文字描述，描述需求相关方，要实现什么目标以及期望效果
12.2.2. 需求的分类
• 项目需求
• 如里程碑日期、合同、制约因素
• 业务需求
• 某组织的高层次需求
• 相关方需求
• 解决方案需求
• 为满足业务必须具备得特性、功能。分功能需求、非功能需求
• 过渡和就绪需求
• 从当前状态过渡到将来状态得临时能力，培训、数据转换
• 质量需求
• 测试、认证、确认
12.2.3. 重点工具与技术
• 系统交互图
• 对产品范围得可视化描述。以图形方式直观的展示该系统与其他系统之间的接口关系，从而确定该系统应该满足什么需求。显示输入、输入提供者、输出、输出接受者
• 原型法：减轻返工的风险
• 体现了渐进明细特点
• 数据收集：问卷调查（拉式沟通？）、头脑风暴（发散思维、多种创意）
• 质量功能展开
• 提供更明确的产品定义和产品特征，把功能和需求联合起来，确定各功能满足用户需求的程度，进行优先级排序。然后进行分类和排序
• 思维导图：找出各原始需求
之间的顺序关系、因果关系或隶属关系。特别适合做群体发散性思维。
• 标杆对照（识别最佳实践，产品研发项目中常用的专业定义范围方法）、亲和图（分组）、焦点小组（同领域专家）名义小组（集体投票，排序.问卷调查征求专家意见）、德尔菲（专家匿名多轮，消除个人因素的偏见）思维导图（把从头脑风暴中获得创意整合分组，反映共性与差异，”逻辑任务组”、“激发新创意”）
• 1、头脑风暴
• 发散思维收集需求，适用多个未知要素难以确认，各种创意
• 2、思维导图
• 从头脑风暴中获得创意整合
• 联合应用设计或开发
• 软件开发行业，强调用户和开发团队一起明确项目需求
• 大多数VS相对多数
• 大多数：超过50%，人数一般为奇数
• 相对多数
• 候选项多个
• 群体决策
12.2.4. 输出
• 需求跟踪矩阵
• 记录需求的来源（所有权），从来源连接能满足需求的可交付成果，为管理产品范围变更提供了框架；确保商业价值；确保批准的需求都能交付。
• 并不代表项目的真实范围。需进一步明确哪些包含在项目范围内——定义范围
• 了解项目所有需求及变更执行情况，了解是否所有可交付成果均满足业务需求以及发生的范围变更。
• 客户不同意某个产品功能
• 需求文件
12.3. 规划：定义范围
12.3.1. 输出项目范围说明书，需求跟踪矩阵更新
12.3.2. 工具
• 产品分析：定义范围过程
12.3.3. 范围说明书
• 产品范围描述、可交付成果、验收标准、除外责任
• 除外责任
• 明确说明不包括哪些内容，有助于管理相关方对项目的期望及减少范围蔓延
• 对特征进行了描述
12.4. 规划：创建工作分解结构WBS
12.4.1. WBS分解5步骤
• 识别和分析可交付成果
• 确定编排方法
• 自上而下分解
• 制定和分配编码
• 核实可交付成果分解是否恰当
12.4.2. 输出范围基准
12.4.3. 控制账户-规划包（暂时无法分解）-工作包（最小单位）
12.4.4. 范围说明书、WBS、WBS词典
• 1范围说明书
• 对范围、可交付成果、验收标准进行了描述
• 2WBS词典
• 针对 WBS 中的每个组件，详
细描述可交付成果的⽂件、验收标准、假设条件等
• 详细定义了里程碑，存在进度偏差后判断是否可以实现该里程碑
• 对项目范围的描述比范围说明书详细的多，最有利于识别项目范围蔓延
• 3WBS
• WBS 组织并定义了项⽬的总范围，没有验收标准
• 最佳的定义和组织了项⽬范围
12.5. 监控：确认范围
12.5.1. 注重可交付成果的可接受性，控制质量过程注重可交
付成果的正确性
12.5.2. 项目章程（高层级需求，成功标准）
• 收集需求（需求清单）
• 定义范围（选取需求定义，范围说明书，可交付成果与验收标准）
• 指导与管理项目工作（把交付成果做出来）
• 控制质量：是否符合质量要求，核实的可交付成果
• 确认范围：是否符合验收标准，验收的可交付成果
• 结束项目或阶段：整体项目验收
• 谁批准，谁负责澄清
12.5.3. 输出工作绩效信息
12.6. 监控：控制范围
12.6.1. 控制范围过程是把项目范围执行的实际情况与项目计划中的范围要求做比
较，以确认是否符合项目范围要求，从而发现偏差、分析偏差、提出解决建议、
预测范围绩效。
12.6.2. 工具
• 偏差分析
• 判断偏离进度基准的原因和程度，以及是否采用纠偏或预防措施
• 趋势分析
• 判断绩效是改善还是恶化
12.6.3. 输出工作绩效信息
• 与进度基准相比较的工作执行情况，包括偏差分析
• 可以看到偏离进度计划的任何关键里程碑
12.6.4. 控制质量
• 检查技术正确性
12.6.5. 控制范围
• 检查工作完成情况
12.6.6. 确认范围
• 检查是否符合验收标准
13. 项目整合管理
13.1. 启动：制定项目章程
13.1.1. 商业文件（项目经理只能提建议，无权修改）、协议、事业环境因素（如监管要求）、组织过程资产
• 商业论证不包含效益实现方式、时间责任人等，需要效益管理计划
• 商业论证内容：项目所需能力和组织现有能力的差距、识别已知风险、潜在方案的制约因素、假设、风险和依赖关系
13.1.2. 输出项目章程
• 高层级需求
• 里程碑进度计划
• 可测量的项目目标和成功标准
• 区分范围说明中的具体验收标准
• 项⽬执⾏组织与需求组织之间建⽴
起伙伴关系
13.1.3. 假设日志
• 如合同中的要求、制约因素
13.1.4. 项目发起人走了，换了新领导
• 分析事业环境因素，审查项目章程，与新领导沟通，确认项目目标，可行性
13.1.5. 发起人不在，可由指导委员会授权，开始项目
13.2. 规划：制定项目管理计划
13.2.1. 项目启动大会(Initial Meeting)：启动结束，规划之前。师出有名
13.2.2. 其他规划过程输出的管理计划作为输入
13.2.3. 焦点小组（同职能领域）
• 区别引导式研讨会（跨职能，多部门）
13.2.4. 输出项目管理计划
• 包含10子计划：需范进成质险源沟采相关方+2配置、变更管理计划+3基准：范围、进度、成本+3组件：项目生命周期、绩效测量基准、开发方法
• 配置管理计划
• 定义配置项，定义需要正式变更控制的内容，并为这些配置项和内容规定变更控制过程，用来明确如何开展配置管理
• 哪些项目工件受控于配置管理程序
• 描述如何记录和更新项目的特定信息，保持产品、服务或成果的一致性和有效性
• 变更管理计划
• 定义管理项目变更的过程，用来明确如何对变更进行监控。
• 需求管理计划、范围管理计划……
• 项目管理计划修改，需要走变更，相关方审批同意
• 项目文件项目团队自行维护：活动属性、假设日志、估算依据、成本估算、变更日志、项目范围说明书、经验教训登记册、项目日历、进度计划、质量报告、需求跟踪矩阵、资源分解结构、风险登记册等
13.3. 执行：指导与管理项目工作
13.3.1. 项目开工会议（kick Off Meeting）：规划完成，实施之前。获得相关方承诺、期望，正面影响最大化
• 规划阶段结束后，阶段收尾：审查项目可交付成果、继续项目
13.3.2. 输出：可交付成果、变更请求、问题日志、工作绩效数据
• 工作绩效数据、信息、报告的区别
• 首次创建问题日志
• 发现问题-记录-分析-解决
• 根本原因：鱼骨图、因果图
• 澄清问题、解决担忧
• 帕雷托主要原因排序
13.3.3. 项目管理系统
• 项目管理信息系统
• 为指导和管理项目提供工具
• 为了项目的目标控制
• 用于支持项目的所有方面
• 授权系统
• 保障正确，防止镀金
• 配置管理系统
13.3.4. 纠正、预防措施、缺陷补救、更新
• 维护某些基准
• 纠偏差，事后
• 预防风险，事前
• 补质量，针对质量缺陷
• 更新通常改计划，修改计划或基准
13.4. 执行：管理项目知识
13.4.1. 显性知识、隐性知识
• 信息管理有助于分享显性知识
• 具体方法：工作跟随和跟随指导
13.5. 监控：监控项目
13.5.1. 监督包括收集、测量和分析测量结果，以及预测趋势，以便推动过程改进；控制包括制定纠正或预防措施或重新规划，并跟踪行动计划的实施过程，以确保他们能有效解决问题。
13.5.2. 输出工作绩效报告
13.6. 监控：实施整体变更控制
13.6.1. 先记录-再评估-提交：涉及基准，需CCB批准-更新：必须更新变更日志，通过时更新管理计划-通知
13.6.2. 设计基准的变更
• 建立新的基准，体现从现在起发生的变更。不能修改以前的变更和绩效，保护基准和历史绩效数据的完整性。
13.6.3. 输出批准的变更
13.6.4. 变更可以以任何方式提出，但记录必须书面
13.6.5. 输入变更请求、工作绩效报告
13.7. 结束项目或阶段
13.7.1. 输入项目管理计划、验收的可交付成果
• 可交付成果在项目的全过程都会输出
13.7.2. 整体项目验收，书面
• 注意客户验收可交付成果是在确认范围过程
13.7.3. 审核成败（满意度、成败原因）
• 测量相关方满意度
• 为了确保未来项目的成功，而不是为了未来与该客户合作
• 获取客户满意度，记入组织过程资产作为经验教训知识库
主要相关方的满意度
13.7.4. 总结经验教训，组织过程资产更新
• 审查和更新风险核对单，供以后项目使用
13.7.5. 归档项目文件：合同、经验教训等，项目收尾报告
13.7.6. 工具
• 数据分析：回归分析
• 分析项目结果的不同项目变量之间的相互关系。如项目收尾阶段发现一个技术问题
• 会议：项目评审会议
• 确认可交付成果已通过验收，确定达到推出标准、评估满意度、收集经验教训，为下一个项目提供初始风险登记册
• 移交成果，移交会议