首页 思维导图 详情

PMP-项目管理核心内容汇总

2023-10-30 18:16:23 0 举报
AI智能生成
项目管理PMP-核心内容整理汇总（基于光环PMP课程）。包括对课程内容的提炼，总结，以及重点的标记。
项目管理
作者其他创作
大纲/内容
图例
考试重点 & 工作重点
工作重点
概述
项目组合
(Portfolio)
概念：为了实现同一个战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作
强调价值判断：根据战略目标判断什么事情价值最高
波士顿矩阵
- 横轴：市占率
- 纵轴：销售增长率
明星
最重要的：高占有高增长
金牛
传统优势项目，能够带来稳定的现金流，但已经进入瓶颈期
瘦狗
保持团队的稳定，人员的稳定（虽然无法带来价值）
问题
销售增长呈现爆发，虽然现在无足轻重，但未来可能会成为爆款
项目集
(Program)
成果交付
项目集 vs 项目组合
项目集管理
把互相之间有内部逻辑关系的项目进行统筹管理
互相依赖，互相共享资源
蚂蚁金服旗下的各种APP打包一起管理：支付宝、余额宝（存钱）、蚂蚁小贷（借钱）
项目组合
一个项目组合：包含项目和项目集，他们之间不一定有逻辑关系，但战略目标一致
不同项目组合：服务不同的战略目标，会指定不同的优先级
例：腾讯同时开发多个吃鸡游戏项目，但都是为同一个战略目标：抢占吃鸡游戏市场
       但项目之间可能有竞争关系，且项目是由不同的部门开发的
运营
商业价值的实现
项目 vs 运营
项目与运营不是完全独立，而是相辅相成的
运营阶段收集反馈，会转变为项目新需求，来推动项目
环境
组织运行环境
事业环境因素EEFs
（客观存在）
来源
政府、行业协会、管理层
用途
遵守
方式
被动接受
组织过程资产OPA
（主动产生）
来源
历史项目团队及项目相关部门
用途
使用
方式
主动参与，更新维护
组织结构类型
职能型
特点
各个部门各司其职
不为项目绩效负责，项目难以推动（只有总经理可以做决策）
影响
客户有需求无法及时相应和满足。例如：医院
项目型
特点
优点
以项目为单位，每个项目里包含各个职能的人：开发，测试、做预算
沟通高效，有明确的责任人
缺点
人力成本高：因为每个项目都需要配齐所有人，在某些时间里造成人力资源浪费
驱动力弱：大家都不愿意项目结束，团队成员没有安全感，没有有归属感
不利于个人成长：一个项目内相同职能的只有一个人，缺乏同类型人员的沟通
适用领域
大型长期项目：房地产开发，工程行业
矩阵型
架构
职能型*项目型
从每个职能部门抽调人手组成项目团队，并任命项目经理
优点
有负责人
能够快速处理客户需求
较高的沟通效率
不会造成人力资源浪费：项目结束后可以回到原职能部门等待安排新的工作
缺点
员工没有明确的领导，不知道听谁的
主要类型
强矩阵：项目经理>职能经理
职能经理：维护培养资源池，支持各个项目。负责派哪个人去哪个项目
场景：公司以项目为导向的业务为主
弱矩阵：项目经理<职能经理
职能经理：掌握预算、资源
项目经理：协调资源
场景：运营为导向的业务模式。持续运营为主，只有一些临时的项目
治理 vs 管理
治理
定规矩，指定总的规章制度
项目治理框架是为项目相关方提供管理项目的结构、过程、角色、职责、终责和决策模型。
管理
针对具体的事情
项目治理 vs 项目管理
治理：提前确定项目汇报机制、沟通原则、决策方式
管理：进度管理、成本管理
项目的复杂性
复杂性≠不确定性
如何驾驭？
拥抱变化
项目韧性：当遭遇风险时
维持状态的能力
迅速恢复的能力
通过适应来更好地应对不确定性的能力
管理项目知识
显性知识
易于总结、易于表达、易于归纳
i.e. 文字、数据、表格
隐形知识
无法编撰、难于表达
i.e. 经验、洞察力
认知升级
持续不断的PSCA循环以达到认知升级的效果
产生（Produce）
积累（Stockpile）
交流（Communication）
应用（Application）
如何有效得到认知升级 - 学习金字塔
听：5%（留存率）
阅读：10%
视听：20%
主动演示：30%
讨论互动：50%
实践：75%
教授给他人：90%
持续学习
风险
含义
中性词：好事->机遇；坏事->威胁
风险敞口
未经保护的风险
干系人的风险态度
风险临界值
取决于干系人的偏好和承受力
项目经理职责：识别各个干系人（发起人，老板）的风险临界值，再做进一步的项目计划
主动管理风险
1. 提前启动并持续进行风险识别
2. 评估风险阈值，确定管理策略
3. 风险定性分析，确定优先级
概率
影响
4. 风险定量分析，设计止损机制和储备
应对风险所要预备的时间、成本、资源
5. 研究风险触发机理，设置预警机制
6. 平衡威胁和机遇，积极配置风险组合
买保险
7. 规划风险应对方法，控制风险
plan B
8. 跟踪风险，动态调整应对方案
9. 评估应对措施的有效性，防范次生风险
分类1
变异性风险
突发的风险，黑天鹅事件
模糊性风险
未知领域带来的风险
例如对于最前沿技术不了解而带来的风险
整合式风险管理
原则：各司其职
项目风险：项目经理管理；一个战略下面的项目（项目组合）：由项目组合经理去管
分类2
已知 vs 未知风险
（认知角度）
未知风险
已知-未知风险
风险可识别，但概率、影响无法评估
未知-未知风险
风险本身无法识别，或未达成共识的风险（我认为是，其他人不认同）
内部 vs 外部风险
内部
项目管理团队可以产生影响：例如工期估不准可以请专家指导
外部
无法施加干预（但可以在事前规避/预防）：通货膨胀风险，采用美元结算以进行规避
商业 vs 可保险风险
可保险
保险覆盖的风险
商业风险
保险不能覆盖的风险
识别方法
头脑风暴
互相平等，互相启发，集思广益
收集整理idea，从中识别风险
德尔菲法
咨询专家，并投票（多数专家服从少数专家）
1. 单独访问，单独整理汇总。
2. 对于大多数人都认可的风险，那么进行记录确定。
3. 对于意见不一的风险，进行第二轮访谈
避免专家之间互相影响
根本原因分析
向上追溯，直到找到根本原因
核对单分析
钱、人、技术各个方面进行检查
假设分析
列出所有假设原因，两两比较，保留可能性最大的，直到找到最主要原因
系统流程图
盘点项目流程，判断风险
专家判断
注意专家的偏见：可以使用德尔菲法解决
注重专家的直觉
假设条件&制约因素分析
制约因素
已确定，客观存在
i.e. 只给6个人，预算只有50万，数据保密
先枚举，再一层一层放宽来增加机会
假设条件
不确定，经验推断
i.e. 已有可行的技术方案，有成熟的产品组件
     ，不会有其他突发工作，客户不会该需求
先假设，再一层一层收紧来暴露风险
SWOT分析
基础版
S&W：内部因素
O&T：外部因素

S&O：优势
W&T：劣势
进阶版：战略管理 - 应对策略判断
风险的管理&记录
对于单个项目风险
提示清单（Prompt List）
- RBS（风险分解结构）
例题：项目经理识别到可能影响项目进度计划的风险后：
第一步：更新风险登记册
第二步：风险评估->制定风险应对计划等
对于整体项目风险
战略框架（分析框架）
PESTLE (Political, Economic, Social, Technological, legal, Environmental)
TECOP (Technological, Environmental, Commercial, Operational, Political)
VUCA (Volatility, Uncertainty, Complexity, Ambiguity)：多变、不确定、复杂、模棱两可
对于风险间的逻辑关系
层级图（气泡图）- 三个维度分析
可选维度：
紧迫性、邻近性、潜伏期、可管理性、可控性、可监测性、连通性、战略影响力、密切度
举例：
邻近性*可监测性*冲击值
合规
Step1: 确认合规要求（要熟悉行业法规）
行业规范：行业监管部门的政策规范
质量：国家/行业/企业标准
安全/健康：对安全、健康的要求
环境：对环境保护的要求
Step2: 分析不合规后果，潜在威胁
Step3: 确定必要方法和行动保障不会出现不合规的情况
Step4: 持续衡量项目合规程度/合规与否：审计、回顾、改进
审计：过程合规性的审查（该走的流程没走，该签字的没签）
管理计划和项目文件
商业文件
商业论证、效益管理计划：项目前期收集制定
项目章程
(总则）
包括：业务需要、假设条件、制约因素、对客户需要和高层级需求、需要交付的新产品、服务或成果
- 在90个工作日完成
项目管理计划
（规则&目标）
规则程序
定义规则，不包含项目的具体信息和数据
包括：范围/进度/成本管理计划... ...
举例：进度管理计划
- 包括：用什么工具编制进度计划，用什么方法优化进度，进度单位
- 不包括：进度的具体信息和数据
项目基准
(baseline)
范围
进度
i.e. 不能超过3个月，否则延期
成本
i.e 不能超过3M预算
质量
按严格程度排序：企业>行业>国家
项目文件
(执行过程产生)
实施计划
实施的具体信息和数据
包括：范围说明书、进度计划、成本估算
举例：项目进度计划，包含项目工期
资料文件
假设日志、问题日志、项目沟通记录、经验教训登记册
里程碑计划
含义
非常重要的事件或者节点
i.e. 软件开发项目中：原型评审、单元测试、集成测试、验收评审、版本发布
特征
时间节点稳定，不会轻易变动
意义
分解计划，制定阶段性目标
控制：保证每个里程碑如期完成
责任：容易明确每个里程碑对应的责任人
沟通：方便客户/高层管理者的沟通
报告：体现对整个项目进度的把控
两个重要会议
项目启动（Initiating）
时间：制定完章程后
召集人：项目发起人
目标
发布章程（明确目标，达成共识）
确认项目经理
承接
下一步是项目规划（编制项目计划）、方案评审
-- 包含：识别项目风险，创建工作分解结构（WBS）
项目开工（Kick-off）
时间：计划编制完成后（项目规划结束后/完成审批后），实施计划前
召集人：项目经理
参与方
项目负责人
各个相关方
内容
明确项目目标
明确分工（获得团队对项目的承诺）
明确责任（阐明相关方角色和责任）
承接
下一步是项目规划
项目价值
评估
识别：创造什么价值（What）
做项目前，识别项目可能产生的利益和价值
计划：如何创造价值（How）
制定效益管理计划
确保效益目标和战略的一致性
确定效益管理责任
项目经理、团队、发起人的责任分别是什么
规划实现效益目标的时间
时间表
确定效益的评估指标
测量指标&测量方法
例如商业论证中的常用财务测量指标
- 投资回报率 ROI
- 投资回收期 PBP
- 净现值 NPV
- 内部收益率 IRR
- 效益成本比率 BCR
识别风险和应对方案
跟踪&评价
持续跟踪和评价项目价值
效益目标
维度（经济&社会&环境）*存在形式（有形&无形）
无形：比如通过这个项目，可以提升企业知名度（本身不挣钱），增加企业未来赚钱的能力
项目环境的持续评估
(环境变化对项目的影响)
调查环境的变化
政策有没有改变，竞对对我们的竞争态势有无变化？
评估影响和优先级
持续审视和评估影响
提出变更建议
项目评价
卓越项目管理模型
领域
3个主领域&9个子领域
A. 人员（团队）和目标
A1. 领导力和价值观
A2. 目标和战略
A3. 项目团队与合作伙伴的合作关系
B. 过程及资源
B1. 项目过程管理和资源管理
B2. 其他关键流程和资源管理
C. 成果
C1. 客户满意度
C2. 项目团队满意度
C3. 其他干系人满意度
C4. 项目结果及对环境的影响
标准
20个评估标准&107个要素标准
案例
大量的案例，过程记录，证明文件
不同阶段的评价
前期
重点评估项目价值
中期
重点评估项目是否合规、项目预期的验收成果是否合格，是否能交付
后期
是否能实现最初设定的期望
- 6个方面
目标
目标的视线程度
实施过程
过程的合理性和规范性
效益
财务指标和经济性
影响
经济、社会、环境
持续性
可持续性&可重复性
可持续性：项目不仅在验收时，而且要在验收后均保证质量
项目收尾&组织过程资产
（2-31 & 4-31节）
合同收尾
对外：与外部买方/卖方交接
对外产生冲突的基本都产生在合同收尾阶段
例如客户临时增加需求，付款出现问题
行政收尾
对内：与公司内部交接（贯穿项目始终）
责任人
项目经理
归档并上报项目文档记录、经验教训、知识等，交给PMO
PMO
Step1：整理、甄别、归纳、提炼
Step2：形成组织过程资产：PMO提炼后，有共性 & 对未来项目有价值的内容
组织过程资产是提炼后的内容，包含部分项目文件。
- 例如项目文件中的经验教训登记册，并不都属于组织过程资产，只有共性、再次发生概率大的部分参会放进去
Step3：及时分享给所有人，学习、观摩、交流
容易出现的问题
例如没有按照公司流程制度提交经验教训，文档记录，或没有及时提交
人
项目经理
角色和职责
角色
资源整合者（Integrator）
整合各个方面的人才
信息沟通者（Communicator）
建立一套合理的沟通机制（针对不同部门的人）
氛围创造者（Climate Builder）
决策制定者（Decision Maker）
团队领导者（Team Leader）
管理 vs 领导
只有领导没有管理：只剩下鼓励和激发，没有秩序，状态不易保持
只有管理没有领导：紧张的上下关系，缺乏内动力（没有远期目标和方向）
领导力
风格
服务型
服务一线员工，提供支持，员工才能全心全意为客户服务（星巴克，海底捞）
变革型
强调集体，强调组织。通过变革不断提升组织整体的能力
其他：放任型，交易性（赏罚分明），魅力型，交互性（交易+变革+魅力的均衡型）
创建协作的环境
信任
激发
多指导，多表扬
影响
卓越领导者的行为习惯
以身作则
共启愿景
挑战现状
主动从外部获取创新方法，寻求改进机会的尝试和冒险，从实践中学习
使众人行
建立信任和增进关系来促进合作，增强自主意识和发展他人的能力
激励人心
表彰他人的卓越表现来认可贡献，创造集体主义精神，庆祝胜利
品质
诚实>有胜任力的>能激发人的>有前瞻性的>聪明的>心胸宽广
有胜任力的：持续学习
前瞻性：扎实的知识积累，关注细节，相信专家的建议
情境领导力
有能力的下属
信任，授权
针对下属的态度，采取不同的措施来领导
能力*意愿
D1：没能力*没意愿
指导型：指示/教授 + 监督
D2：没能力*有意愿
教练型：传授 + 督促
D3：有能力*没意愿
支持型：鼓励 + 支持
D4：有能力*有意愿
授权型：信任 + 授权 + 观察
领导力评估
（3-33）
团队成员心目中领导力的8个指标
建立信任、积极聆听、共启愿景、激发动力、表达欣赏、管理进步、促进行动、启发创造
谈判
对象：职能经理
目标：要技术开发人员，确保人数够，按时到位，技术合格
对象：分包商/供应商
目标：让对方的精锐人员支持项目
团队
类型划分
项目团队 vs 项目管理团队
项目管理团队
（项目团队子集）
工作性质和项目经理类似，帮助项目经理编制计划、控制偏差、协调管理等工作
项目管理团队人员并不一定专职做项目管理，可能是一些兼职人员：开发帮项目经理计算工期
项目团队
项目管理团队 + 做具体业务的人（开发、产品）
好的团队成员
永远选择优秀的人
- 业绩好，价值观正确
自组织团队
权利矩阵
Level 1：定调子（整体方向的设定）
发展方向
Level 2：搭台子（团队及组织环境的规划）
如何搭建公司的组织管理框架，管理的制度流程
Level 3：写谱子（工作过程和进度的监控和管理）
任务怎么安排
Level 4：唱曲子（团队任务的执行）
具体干的活
团队规则
团队章程
(章程的内容)
价值观
沟通指南
开会的纪律：哪些需要开会，多长时间开
决策标准和过程
举手表决还是项目经理一个人拍板
风险描述
团队建设
&
项目经理的管理风格
形成
描述：召集团队. 项目初期团队士气较高
管理风格：指导型
指导为主：直接了当，明确指令
震荡
(磨合)
描述：分配工作后，会出现不满的意见，此时士气最低
管理风格：教练型
支持+指导：(引导、斡旋、调解、计划、督导)
规范
描述：逐渐开始配合
管理风格：支持型
支持为主（帮助、参与、促进）
表现
描述：非常默契的阶段。士气最高
管理风格：授权型
支持、指导力度低（进一步放权：信任、授权）
遣散
领导团队
- 促进团队成长
创建公平环境
持续学习
带领团队持续学习
挑战现状
锐意进取，设置更有挑战、更新的目标
文化与价值观
阳光、积极心态
尊重与信任
有效的激励
鼓舞和表扬每一个进步，和对团队的每一个贡献
冲突管理
冲突的好处
促进团队磨合，增进了解
灵感源泉、创新动力
暴露问题，降低风险
加速决策，改进管理
及时认识问题，及时优化决策
解决方法
强迫命令
特点
强决策（决策效率高），体验差
- 上下级关系，通过命令加以统一
- 一赢一输
场景
紧急&重要情况下使用，此时以大局为重
合作/解决
特点
强决策，体验好
- 双赢的解决方法。解决的很彻底
- 影响最持久，效果最好
- 双赢
场景
不紧急&重要
- 寻找双方诉求并不矛盾的点，是否可以皆大欢喜
妥协/调解
特点
两个维度均适中
- 双方讨价还价，各让一步
- 双输
场景
紧急&不重要
撤退/回避
特点
弱决策，体验差
- 搁置争议，后面再解决
-  双输
场景
不紧急&不重要
缓和/包容
特点
弱决策，体验好
- 冲突一方主动让步
- 一赢一输
场景
不紧急&不重要
凝聚共识
分析产生误解的原因
引导各方达成都能接受的目标
创造必要的仪式感
方式
制定精致的任务书，大家进行签名
达成阶段性的目标，一起吃饭
及时表扬团队成员
建立war room
集中办公（项目团队成员能够处于同一物理环境）
时机
项目启动会与开工会
里程碑（项目阶段目标达成时）、项目例会
任命和授权
各种庆祝活动
定期团建和表彰
虚拟团队
(临工经济)
vs 实体团队
优势
办公成本低，人才来源广泛，灵活性与自由度高
劣势
信任度差，沟通低效，工作氛围差，激励与约束弱
参与方案
(如何做好虚拟团队)
清晰的规则
成员参与项目的方式，交付时间，交付标准
标准的流程
特别是开发，要把交接的流程定的非常清晰
具体的任务
任务要分的更细
合适的工具
合适的写作平台
民主的机制
线上投票等决策机制
积极的互动
加强沟通
充足的储备
时间、资源储备都要留足
（资源方面要有backup，以免团队成员掉链子）
及时的复盘
团队绩效的提升
高情商的特征
照顾别人的感受
解读对方的情感和意图
正能量
善于维护亲近的关系，也能保持独立自我
深刻理解“意图与结果”的差异，根据对方反馈调整自己
朋友圈广，接纳度高
习惯鼓励和赞美
评估情商
感知他人情感的能力
关注他人情感的意愿
影响他人情感的能力
掌控自我情感的能力
如何提升情商
尊重差异
面向体验
给大家有意义的愿景和有挑战的目标
平等民主的氛围
充分的尊重和信任
团队归属感和有效指引
不断认可和有效激励
支持团队绩效
基本关注点：进度、成本、质量
进阶关注点
支持团队成员的成长
了解他们的需求和目标
参与和反馈
经常复盘，给成员建议
解决和消除影响发展的障碍
参与决策，不能一言堂
RACI矩阵
作用
每个人都能知道自己和哪些工作，有什么样的关系
- 类似RAM：责任分配矩阵
角色
R：负责
A：问责
如果有问题，谁来拍板负责
C：咨询
有谁来提供解决方案和建议
I：通知
告知
提供适当的培训
团队成员
领导、客户、供应商
多采用领域专家进行培训
团队绩效评价
团队绩效评价
Method
改善&提升团队绩效&有效性（回顾/复盘会（Sprint））
When
完成一个阶段/一个迭代
Target
针对人，而不是项目（事情）本身
How
团队协作是否高效？沟通是否顺畅？哪些需要提高？
项目绩效评价
Method
挣值分析：执行的绩效与项目计划是否吻合
Target
针对事（项目），例如进度是否延误，成果在质量上是否合格
团队成长评估
是否满足以下4个方面
1. 互相尊重，彼此欣赏
2. 开诚布公，荣辱与共
3. 持续学习，挑战现状
4. 优势互补，成就对方
干系人
(Stakeholders)
干系人分析维度
（识别干系人）
维度1：直接/间接
参与者
直接支持项目：供应商、分包商、公司各个职能部门
不参与
（影响者/受影响者）
维度2：利益
受益者
受损者
维度3：关系远近
内部（和项目经理最近）
PMO、项目管理办公室、职能经理、团队成员
本地
供应商、外包商、政府、媒体
国内
供应链、物流、仓储、协会、组织
国际
国际客户、合作伙伴
维度4：职能
投资人、客户
供应商、分包商
职能部门（职能经理）
项目团队成员
干系人评估（打分）
影响力
无(0)，弱(1)，中(2)，强(3)，极强(4)
影响阶段
I-启动，P-规划，E-执行，C-收尾
态度
抵制(-2)，反对(-1)，中立(0)，支持(1)，推动(2)
-2: 会极力破坏这个项目，无论是否征求意见
-1: 会反对，但如果强推也没有办法强制阻止
干系人管理
策略
态度
支持者：直接谈行动
反对者：直接谈后果
中立者：谈利弊（不做会有哪些坏处，做了有什么好处）
未做决定者：主要谈好处
未获信息者：主动谈信息（主动说明项目情况）
影响力 X 态度
深-支持
Tiger：充分合作
深-不支持
Snake：积极争取
浅-支持
Monkey：密切观察
浅-不支持
Ant：保持关注
权力利益矩阵
（分析工具）
第一象限：权力大、利益密切
密切管理，了解他们的体验、态度和意见
第二象限：权力大、利益不密切
尽量满足他们的需求
- 由于对于他们利益相关度低，需求较少，尽量避免受到他们的阻挠
第三象限：权力小、利益不密切
定期监督，保持关注，不要忽视他们的存在
第四象限：权力小、利益密切
及时知会，积极主动保持沟通，争取理解和支持
行动
Step1：干系人分类，哪些反对，哪些支持
Step2：整合资源，让支持者帮助项目经理说服反对者
共创模式
维基百科的创建
小米系统的迭代更新：粉丝提出系统改进建议
京东 + 天猫
互相竞争，互相提升
与干系人协作
创建干系人登记册
例：IT信息化管理系统的开发项目
- 客户总经理：关心项目初期和交付阶段，但对于中间的细节不关心
- 财务职能经理：可能会额外增加他的工作量
控制干系人的参与程度
（参与程度评估矩阵）
目标/用途
1. 盘点各个干系人目前的态度和期望态度
2. 决定该采取何种的措施已达到期望的目标态度
维度
信息1：对项目的态度分级
不知晓：对项目和潜在影响不知晓
抵制：知晓项目和潜在影响，抵制变革
中立：知晓项目，既不支持，也不反对
支持：知晓项目和潜在影响，支持变革
领导：知晓项目和潜在影响，积极致力于保证项目成功
信息2：每个干系人目前的态度是什么，期望的态度是什么
C：当前状态
D：期望状态
干系人满意度评估（3-33节）
干系人关心的6大维度
交付成果、需求相应、工作效率、专业程度、冲突处理、沟通协调
干系人的影响方向
干系人的参与度
（4-18节）
凸显模型 - 干系人的评价
（权力*紧迫性*合法性）
绿色：凸显性低
蓝色：凸显性中
红色：凸显性高
干系人管理
(根据干系人评价分级)
含义
蓝色：这一类干系人具备的特点
灰色：触发条件。若干系人得到灰色条件，则会变为蓝色，此时干系人评级发生改变
管理目标
尽量避免干系人向更高的凸显层级触发，避免节外生枝
敏捷场景
"项目经理"
敏捷场景强调“自组织”，即去中心化（没有领导），鼓励是人人都是项目经理
- 共同讨论，表决决策
没有明确的项目经理岗位
类似的角色：敏捷专家
不负责
不是团队领导
不做决策
不负责工作结果
负责
警察：维护团队规则和秩序
保安：保护开发团队，不受外界干扰
不允许额外需求出现
如果有新需求，需要对接PO进行评估
保姆：为团队提供支持和服务
教练：带领大家认识敏捷场景的规则和方法
警察：维持团队规则和秩序
团队管理
控制团队工作时长
例如：8小时工作时间，应该只安排6小时工作量
控制团队规模
最合适的规模：7±2
过程
阶段 vs 过程
阶段
组成
阶段1：概念
需求识别、可行性研究、商业分析
阶段2：规划
解决方案、规划设计、预算编制
阶段3：实施
开发/施工、需求实现、执行与控制
阶段4：收尾
交付验收、合同支付、总结经验
- 总结经验教训，所有变更控制的文档和记录，形成组织过程资产
阶段划分&阶段关口
目的
化整为零，拆分大的目标位小的阶段目标，方便控制，项目成本，质量，目标更容易实现
示例：工程行业
结束项目和阶段
（项目收尾，4-31节）
流程
Step1：最终验收
客户对交付物进行验收和确认
Step2：关闭合同
关闭和客户合同，和供应商合同
Step3：财务收尾
完成财务结算（和甲方完成收款，和分包商、供应商完成付款）和决算（公司内部对项目的投资，收益率报，回报率的计算）
Step4：相关方满意度
调查相关方满意度，有何建议，以后的合作如何改进
Step5：归档工作
文档、数据、登记册、日志进行归档。包括项目开发的每一种计划，以及项目中的模板
Step6：经验教训
总结经验教训，更新组织过程资产
Step7：庆祝会
Step8：解散团队
释放项目资源，解散团队
合同收尾 vs 行政收尾
见“环境”-“项目收尾&组织过程资产”，2-31节
过程组
&
过程
组成
5个过程组：启动、规划、执行、监控、收尾
49个过程
含义
定义了项目的每个阶段都要执行的步骤（标准套路）
特点
没有严格的承接关系。存在明显的相互作用，在时间方面有overlap
- i.e. 执行过程组贯穿始终
- 规划过程可能影响执行过程，反之亦然
区别
阶段
一个完整的生命周期（时间维度上的划分）、不管每个项目都要经历
过程
项目执行的方式，在每个阶段都需要执行一遍
裁剪
裁剪的对象 (What)
49个过程
过程的输入、工具技术、输出
阶段（生命周期）的划分，不一定要保留每个阶段
开发模式的选择：敏捷、增量、迭代
考虑的因素
项目的进度，范围，成本，资源
质量和风险之间的相互制约
项目环境
公司的制度、考核
组织文化
严格还是包容？前者不能茅台大的风险
干系人的需求
质量管理
- 金字塔分级
Level 1：用户发现缺陷
代价最大，商誉和口碑受损
Level 2：QC (质量控制)
- 结果检查和纠正
结果合格
i.e. 普通球迷只关心结果（谁赢了）
自己有质量检查和纠正的办法
归因分析，找到质量差的原因，并加以改进
Level 3：QA (质量保证)
-过程保证
过程合规
i.e. 专业教练关心球员是否把教练的战术部署，战略规划执行到位
通过控制生产过程，来控制质量
例如：通过制定标准，来从根源上避免误差
Level 4：DfX-设计优化
（Design for X）
在规划设计阶段就融入质量管理
例如，在设计时充分考虑：好加工，好装配，好搬运，好修理等
宜家：遵循模数化设计
家具规格统一，例如不同的柜门以45cm的倍数设计，方便运输
融入用户参与：模块化设计，用户使用简单工具可以完成组装，避免高昂的组装成本
Level 5：TQM-全面质量管理
聚焦客户
持续改进
全员参与
有效沟通
任何质量问题都应该有渠道，有方法被及时发现，及时被报告，及时被解决
过程为中心
只有保证过程合规，结果才有望实现质量合格
基于事实的决策
集成系统
各专业各部门不能各自为战，应该互相进行有效的沟通配合
战略性与系统方法
企业应该建立一套系统的质量管理方法，来指导项目管理的实践
聚焦于价值
&
驱动变革
段到段
各个部门，各自为营，有各自的流程。用户需求很难及时高效被解决
端到端
客户需求端 - 客户价值端
所有的工作都是从客户需求出发
所有的努力都是为了给客户创造价值
核心流程
客户需求->客户价值
市场管理 - 理解客户需求
集成产品开发 - 实现客户需要的功能/产品
客户关系管理 - 对客户做出承诺
集成供应链 - 交付最终的产品/服务
客户服务管理 - 保护和客户的关系
最终实现客户价值
支撑流程
为核心流程提供支撑服务（中台）
PMO
职责
支持类
模板支持
为项目经理提供类似项目的资源：进度计划，预算计划模板
流程优化
发起优化流程的动作
- 当一个流程对公司很多项目都造成了阻碍
例如，对于研发中的小批量采购的零部件，可以直接采购，而不用走招标流程
资源协调
PMO负责界定各个项目的优先级，进而合理地分配资源
决策机制
PMO事先定义好项目的决策机制：决策层级，决策步骤等
监督类
跟踪预警
跟踪每个项目的偏差：成本是否超支等
绩效评价
负责建立项目的评价机制
例如，不能简单以利润作为评价指标
- 有些金牛项目天然利润很高，还有些是不以赚钱为目标，为了公司战略发展的项目
负责对多个项目的评价
类型
支持型
模板、工具的支持，培训、顾问的服务
控制型
不仅支持服务，还提管控要求
指令型
完全控制，直接领导
生命周期划分
(4-15至17&92)
项目的
生命周期
预测型
场景1
传统行业：工程建设行业
场景2
IT行业：瀑布模型
特点
每个阶段按顺序排列，无法改变顺序
每个阶段都需要签字确认，确认后无法更改，才能进入下个阶段
迭代型
按照版本迭代的方式进行开发，每个版本经历一个完整的项目循环
-- 需求->设计->开发->测试
反复求精，从模糊到清晰，从简陋到精细
增量型
逐块构建，逐块交付
- 每次交付一部分完整的功能
适应型
(敏捷开发)
优势
对未来不确定性有更好的适应能力
对项目中的各种变更，新的需求态度友好
劣势
成本优势不明显
一个需求的变更可能会导致大量的返工
不适用的行业：硬件开发，工程项目
混合型
主要思路
不同的项目阶段，采用不同的开发方法
例1：不同的开发阶段
产品预研阶段：敏捷开发，根据客户反馈快速更新方案
产品开发阶段：瀑布开发
例2：不同的产品模块
软件（操作系统）子项目：敏捷开发
硬件子项目：瀑布开发
对比&总结
1. 彼此是连续的，可以随时进行相互转化。
2. 每个项目都可以在连续区间内找到一个点，根据项目背景实现最佳平衡
3. 无论哪种生命周期，都需要计划，计划贯穿其中
项目 vs 产品
传统
1. 项目生命周期只是产品生命周期的一小部分，只参与产品开发
2. 开发和运营独立
敏捷
开发和运营同时存在
首先开发MVP，接受客户反馈/市场验证，通过运营不断迭代更新产品
产品需要有快速转型升级等能力
产品需要持续运营
沟通
有效的沟通
乔哈里窗
（4-19节）
适当开放隐秘区，以获得更多盲目区的信息，扩大开放区
及时反馈
（4-20节）
闭环的沟通模型：接收方（听众）及时给与反馈，能明显提升沟通效率，提高沟通漏斗的转化率
沟通完成后，最好需要让接收方再反馈一遍沟通内容或者需求内容
e.g. 我不知道刚才有没有讲清楚，你是怎么理解的？
影响沟通的障碍
（4-22节）
因素
信息过载
单位时间里，沟通的核心信息不能太密集
缺少知识
对沟通内容有足够的知识储备
不懂专业/技术术语
文化差异
分散注意力的环境因素
寻找适合交流的环境
有害的态度
避免成见，客观沟通
情绪
沟通渠道过多
选择性的认知
多表扬，少指责
本质原因
不同干系人对项目目标的理解不同
人力、设备、材料等资源的竞争
人员之间的冲突
对变化的抵制（新技术，新流程）
提升沟通技巧
（4-23）
简化语言（简化表达）
视觉辅助手段
积极倾听，不要轻易打断对方
有效的反馈：双向沟通，实现闭环的沟通漏斗
情绪控制
沟通方式
交互式
双向闭环。i.e. 面对面沟通
效率高，但规模受限
推式（Push）
单向（被动接收信息）。i.e. 邮件信息方式推送信息
批量发送，范围广，但效果不佳
拉式（Pull）
单向（主动获取信息）。i.e. 文章订阅，在线视频，需要主动浏览
适合信息多，受众广的情况，但效果不佳
沟通管理（规划）
- 需要考虑的因素
Who&What
谁需要（哪些干系人/相关方）什么信息
- 是否有权限？
项目经理在信息传递的过程中：
- 需要检查确认接收人有相应权限
- 若接收人没有权限，可能要对信息做加密处理
When
什么时候需要这些信息
e.g. 每天发还是每周周例会之前发即可
Where
信息应该储存在什么地方
How
应该以什么形式储存
如何检索这些信息
Other
是否需要考虑时差、语言、跨文化等因素
书面沟通的5C原则
Correct Grammer & Spelling
正确的语法和拼写
Concise Expression & Elimination of Excess Words
简洁的表述和无多余字
Clear Purpose & Expression
Directed to the needs of the Readers
清楚的目的和表述（基于表达对象的需求）
Coherent Logitcal Flow of Ideas
连贯的思维逻辑
Controlling Flow of Words & Ideas
受控的语句和想法承接
整片文字中，段落之间应该由承前启后的衔接关系，头尾要呼应
沟通路径
（4-21节）
沟通路径个数： 其中，n代表人数
会议管理
准备并发布会议议程，包括会议目标
会议要切题
严格控制时间：按照计划时间开始，计划时间结束
确保适当参与者受邀并出席
汇报者，或需要发表意见的人
决策者
责任人：对会议决定承担责任
记录所有的行动（或决议）
明确完成指标
明确完成时间限制
明确负责人
整合管理
发展趋势
使用自动化的工具
项目管理信息系统（PMIS）
配置管理软件
可视化管理工具
横道图、网络图、看板、燃尽图
项目知识管理
知识的收集、整理、传达和分享
增加项目经理的职责
工作向两端延伸
前期商业论证 + 后期运营（获取用户反馈，持续改进）
混合型的方法
Scrum（敏捷）、精益、看板混合使用
例如在不同阶段采取敏捷和瀑布的方法管理项目
整合什么？
资源
搭团队，分工
平衡竞争性需求
（需求整合）
摆平冲突、矛盾、各方妥协以达成都接受的方案
研究各种备选方法
（项目的方法和路径）
收益、风险的整合
过程裁剪
49个过程取舍，如何裁剪与搭配？
知识领域之间的关系
进度、成本、质量之间的平衡和取舍
整体变更控制
谁会提出变更？
客户
供应商
己方团队
例如，有更好的技术方案
谁能决策变更？
变更控制委员会-CCB
(Change Control Board)
由项目发起人组成的一个常设，但未固定的正式团体
常设：项目整个生命周期都有
未固定：各方组成，均参与决策
团队成员可能会变
CCB是变更的最高决策机构
负责影响基准的变更
拒绝后不能再提出同样的变更请求
项目经理
变更流程 & 变更原因
见1-2流程图
准则
对基准的变更，仅对今后的情况有效，不影响以往的绩效
有助于保护历史绩效的严肃性
偏差的监控与修正
(4-94节)
团队成员发现项目偏差：工期不够，质量不符合要求等
项目经理负责纠偏决策：是否要进行变更
变更的应对措施
防范，纠正，缺陷补救（亡羊补牢）
范围 & 需求管理
（4-32至43节）
不同类型项目的范围管理区别
收集需求
需求 vs 范围
需求管理计划：用户想要的
范围管理计划：为了实现需要，项目要做的工作
- 范围来源于需求，但不等于需求，因为有些需求并不能满足
需求的识别
头脑风暴
访谈
焦点小组 (Focus Group)
针对某一个主题进行讨论：例如信息安全主题
问卷调查 (Questionnaire)
标杆对照 (benchmarking)
通过学习标杆产品来提升自己的产品
联合应用设计或开发（JAD）
和客户一起解决问题
需求收集的工具
亲和图
需求的整理归类
例如：屏幕相关（全面屏、曲面屏），摄像（美颜，超广角）
质量功能展开（QFD）
(Quality Function Deployment)
作用
进一步的专业分析。需求描述翻译（质量展开）为专业的技术指标
维度
维度1：原始的用户需求表达
维度2：转换后的工程性能指标
维度3：竞品对比
维度4：需求优先级
维度5：冲突标记（标记冲突的需求）
创建
步骤
Step1：产品规划矩阵
用户原始需求 -> 设计语言
Step2：零件规划矩阵
设计语言 -> 零件特性
转化为技术工程师理解的语言
- 例如超广角->16毫米镜头
Step3：工艺规划矩阵
零件特性-> 工艺要求
转化为生产部门理解的语言
- 例如16毫米镜头->厚度不超过3mm
Step4：质量规划矩阵
工艺要求-> 生产要求
转化为工人、技术员理解的语言
- 例如厚度不超过3mm->控制误差在0.1%以内
需求决策
方式
投票
一致同意、大多数同意、相对多数同意
独裁
工具
多标准决策 - MCDA
(Multi-Criteria Decision Analysis)
方案层
准则层
目标层
需求文件与
需求跟踪矩阵
要素
分类
详细说明
完成情况跟踪
- 需求被确认、更改、实现都需要进行标记
责任人
需求的转化
敏捷开发
确认的需求都应该翻译为用户故事写在backlog里
经典瀑布式开发
确认的需求应该写在配置文件里。例如最终版本包含哪些功能点，都应该是该产品的配置
需求的呈现和表达
用户故事
需求描述
目的：收集用户需求
As a <Role>, I want <Activity>, so that <Business Value>
- 《角色、期望（需求），目的（价值）》
- i.e. 作为一个微信深度用户，我希望有一个不限人数的版本，以便我只带一个手机
收集完成后，可以使用亲和图对用户故事进行归类
验收标准
Given（在什么样的情境或条件下）
What（做了什么操作，采取了什么行动）
Then（得到了什么结果）
用户故事地图
目的：确定用户故事开发的优先级
第一个版本（最小可发布版本MMR）要实现哪些功能？
后续各个版本要补充哪些功能？
维度
业务流程（时间线）
商业价值
系统交互图
原型法
先做一个产品或功能的原型，以此和客户进行需求的确认
故事版
例如：可视化剧本和演员沟通
范围基准
(Baseline of Scope)
项目范围说明书
项目章程 --> 项目范围说明书
关系:渐进明细的过程
i.e. 章程：高层级项目描述、边界定义以及主要可交付成果
项目范围说明书：项目可交付成果（与章程的这一条相对应）
工作分解结构WBS
(work breakdown structure)
组成部分
可交付成果
Deliverables
子项目
Subproject
控制账户
Control Account
财务口径的最细粒度，用户统计和分析项目成本，管理预算
一般和团队对应，例如开发团队的工作对应一个控制账户
工作包
Work Package
WBS的最低层次单元，也是项目经理管理到的最低层次单元
- 例如：支付系统的开发
到项目经理
拆解
活动
Activity
到团队
- 例如支付系统开发中的系统设计、产品开发、测试
任务
Task
到人（由活动继续拆分得到）
- 例如支付系统代码开发 -> 接口开发 -> 微信支付接口、支付宝接口
规划包
Planning Package
与工作包的区别：同一层级，但不是立即要去做，处于规划中（还不确定要多少人天等）
等到合适的时候，才能去准确的评估
WBS的价值
基准的来源
WBS是三大基准的来源：项目范围（三大基准之首）、进度、成本
进度基准、成本基准依据于范围基准
计划的基础
项目子计划（进度、成本、质量、沟通）都依赖于WBS来制定
工作的展现
结构化层次化展现了项目全貌
控制的依据
WBS里面没有的工作，就不在项目范围，新增需求需要进行项目范围变更
团队的指南
团队成员对工作由清晰和统一的认识
WBS词典
1. 针对每个工作包，呈现详细的要求和信息
2. 一个工作包有这样的一个表
关键信息
隶属于哪个控制账户
控制包的编码
控制报的负责人
工作包的交付成果、质量要求、成本
交付日期
RAM责任分配矩阵
RAM - Responsibility Assignment Marix
-和WBS配合使用，将工作包落实到人的工具(每个工作谁来负责，每个相关人的角色是什么）
责任定义
负责：每个工作包必须要有负责人，且唯一
辅助：参与者
通知：知会工作进展和结果
审批：工作是不是能够通过验收，需要做验收拍板
承包：有谁负责把它外包给外包商或协作团队
确认范围
vs
质量控制
每完成一部分工作，需要及时进行质量控制检查/及时和客户确认（是否合格，是否满足客户要求）
- 只有每一项工作均能完成范围确认，才能最终完成项目验收（不要统一堆到项目验收再全部确认）
范围蔓延
镀金 (主动)
乙方主动增加的需求
为什么会出现镀金？
维护和客户的关系
主动进行的升级（为了保证各个功能的配置一致，在同一个水平线上）
爬行 (被动)
甲方要求增加的需求
如何避免
要有规范的项目变更流程
进度管理
紧前关系绘图法
(PDM)
PDM: Precedence Diagramming Method
逻辑关系
FS: Finish-Start
前面工作结束，后面才能开始
示例：淘宝购物
SS: Start-Start
示例：摊煎饼
AB顺序不能颠倒，但A开始后，B就可以开始做
FF: Finish-Finish
示例：拍电影
A结束后，B才能结束
SF: Start-Finish
示例1：系统升级
新系统上线工作后，老系统才能关闭
示例2：交接班。下一位同事来之前（开始之前），上个人不能走
这里的start指的是B任务
依赖关系
内部依赖
外部依赖
例如政策性的限制
选择性依赖
强制性依赖
工作B必须依赖于工作A完成后才能开始
滞后量 (Lag)
&
提前量 (Lead)
滞后量
下一个工作往后推N天
意义：给项目带来弹性
提前量
压缩工期
关键路径法-CPM
(Critical Path Method)
活动表格
活动历时（固定不变） = 结束 - 开始
总浮动时间 = 最晚 - 最早
示例
Step1: 向前推导 - 基于最早开始、结束时间
1. A的起始时间（刻度0）
2. B的开始时间就是A的结束时间
3. 多个紧前关系选最大（max(5,6)）
前项推导完成后：项目最大工期已经推断完成，为10天
Step2: 向后推导 - 最晚开始、结束；关键路径
4. G工作没有浮动时间，因此最晚时间 = 最早时间
5. G工作最晚在8开始，因此，它的紧前工作E、F在最晚8结束即可
6. 最晚 - 最早 = 1，因此浮动时间是1
7. 多个紧后工作选最小。即C不能晚于6结束，否则会影响F工作
关键路径：总浮动时间最小的工作所组成的路径（红色路径）
关键路径特征
总浮动时间最小的工作所组成的路径
浮动时间<0的情况
此时需要优化工期（增加人力等方式）
浮动时间>0的情况，总工期宽松，有比较多的浮动时间
1.关键路径决定了项目的总工期
2.关键路径所需要的时间最长
3.关键路径上的浮动时间最少
4.一个项目关键路径只能有一条
5.活动延误可能导致关键路径变化
6.关键路径上活动的工期可以压缩
第4点：假如D工作需要4天，那么C、D都在关键路径上
第5点：假如D工作延误（所需时长增加），那么会导致关键路径转至D工作上
关键链法-CCM
(Critical Chain Method)
主要思想
规划工期时，每项工作均采用三点法（50%概率）估算工作工期和总工期
对于计划总工期和估算工期的时间差，作为项目缓冲，供项目经理进行支配
路径汇聚风险
原因
多个紧前工作汇聚时，会造成汇聚后的今后工作能够按计划开始的概率大大降低
以三点法估算时，每项工作按时完成概率为50%，但紧后工作D能够按计划开始的概率仅为15%
解决
主动增加缓冲 - 接驳缓冲
给非关键路径上的工作给缓冲时间
剩余缓冲统一放在最后，作为项目缓冲池
进度计划
（4-47节）
里程碑计划
(粗粒度)
计划性：分解为阶段性目标
控制性：强制约束，控制各阶段目标实现
沟通工具：与管理层、干系人良好/高效沟通
分清责任：明确规定项目各方的责任义务
横道图（甘特图）
(细粒度)
信息
细粒度的任务安排
帮助项目经理判断任务风险（延误风险）
缺点
无法帮助识别关键路径和关键路径上的活动
- 非关键路径上的活动都有浮动时间
网络图
单代号网络图-AON
(Activity on Node)
特点
活动在节点上
优势
能够反映4种逻辑关系
缺点
比较复杂
双代号网络图-AOA
(Activity on Array)
特点
任务表示在路径上
- 例如可以用"3-4"表示C任务
虚线：虚工作，不代表实际工作，仅表示逻辑关系
- 例如C工作实际要在A、H完成后才能开始。
优势
清晰
缺点
仅可以表示FS逻辑关系
时标网络图
双代号网络图 X 时序
兼具网络图和横道图的优点
- 网络图：逻辑关系清晰
- 横道图：时间关系清晰
用于优化工期、成本、资源
波浪线：浮动时间，例如E工作在9天的范围内，任意2天完成即可
进度前锋线图
蓝线：当前日期
红线：实际进度
进度压缩
快速跟进
Fast Tracking
提前开始下一个工期
- FS 改为 FS-N
代价
增加风险
- 增加了后续工作返工的风险（如果前项工作出现问题）
赶工
Crashing
增加资源，直接缩短工期
代价
成本的增加
资源优化
（4-59）
资源平衡
解决的问题
处理某时间段人员overload（资源过载）的问题
代价
延长工期
资源平滑
解决的问题
解决资源数量波动的问题，避免资源浪费（拆东墙补西墙）
- 不会影响工期
做法
如果关键路径面临无法按时完成的风险，那么可以适当分配非关键路径上的资源到关键路径
例1
例2：A、B均处于非关键路径，且分别需要3个人。
由于C工期长于A、B，因此AB的人员可以缩减为一共3个人
将B工作向后挪动，先干A工作，再干B工作
成本管理
(4-55至4-58)
成本的分类
直接vs间接
直接：材料成本，人力成本（项目推进就要花钱）
间接：房租，水电等一直会支出的成本
固定vs可变
(盈亏平衡分析)
固定成本：投入的固定资产 (i.e. 设备)的成本
可变成本：材料费用，人工费用
机会成本
vs 沉默成本
机会成本
放弃的所有可选方案带来的最大潜在收益（最大收益的方案产生的收益）
- 范围是所有方案里面合理的可选方案
- 例如：项目A为200万收益，B为150万，C为250万。若最终选择B，则机会成本=max(A, C)=250万
沉默成本
项目已经投入的成本
全生命周期成本
（理念）
在项目设计阶段，就要考虑整个项目过程中所涉及的成本
- 有时候项目材料的节省，很可能会导致项目后期成本的增加
- 例如：鸟巢取消了顶盖涉及，虽然节约了施工成本，但造成后期运营维护成本增加（无法全天候使用），可能无法收回投资
成本的估算和预算
精确度等级
资金限制平衡
目的：避免项目资金链断裂
用法：项目资金支出计划（花的钱）与资金到位承诺（收的钱）做对比，调整工期和资源投入
项目预算的组成
工作包成本 = 活动成本 + 活动应急储备成本
控制账户成本 = 工作包成本 + 工作包应急储备成本
成本基准（=项目成本=完工预算) + 管理储备 = 项目预算
- 项目成本 ≠ 项目预算
- 项目结束时，累计的成本基准就是完工预算
管理储备是高层为了应对项目经理无法识别的风险所做的储备
- 只用于应对“未知-未知风险”
应急储备：项目经理负责，应对“已知-未知风险”
质量管理
等级与质量
精确度与准确度
等级vs质量
等级高不一定质量高
精确度vs准确度
精确度高 -> 方差小（多次射击，命中在一个很小的范围）
准确度高 -> 偏差小（多次射击，都能命中，但各个命中距离比较大）
发展趋势
(4-61至63)
质量管理的观念
- 质量是设计出来的
质量成本（COQ）
一致性成本
场景：预防性质
主动预防
为了防止最后的产品质量不合格，提前做一些工作
预防成本：打造高质量产品付出的成本
- 员工培训、设备维护
评估成本：评估质量付出的成本
- 测试、检查
非一致性成本
场景：纠正性质
被动修改
预防失败，最终还是出现了质量问题
内部失败成本：项目中己方发现的质量问题
- 返工，报废
外部失败成本：客户发现的质量问题
- 返修，召回
管理&分析
方法与工具
鱼骨图
(因果图)
适用场景：根本原因分析
先拆分大的类别，每个大的类别下再细拆
直方图
适用场景：质量检查结果分布分析，并满足以下要求
1. 基本符合正态分布
2. 数据全部在规格以内（全部在上&下规则线内）
3. 均值和上下规格先均值一致（处于正中间）
4. 上下规则线的设置，应位于均值的4倍标准差的位置
类型分析
偏态分布：技术、习惯原因造成，为异常生产情况
锯齿分布：分组不当，或测试方法和读数有问题
孤岛分布：工人不熟练或交接班失误造成
陡壁分布：由剔除不合格品、外品或超差返修后造成
双峰分布：由两种不同的分布混合在一起检查的结果
平峰分布：由缓慢变化的因素起主导作用的结果
不好的直方图
双侧无余量型：实际样本的质量数据接近上下限，如果工序稍有变化，则很容易出现质量问题
余量过富裕型：质量要求太严格，应适当放宽工序能力指数，以降低成本
平均值偏离型：平均值过于偏左。为了降低不良率，应该调整工序中心使之接近规格中心
散点图
帕累托图
散点图
适用场景：质量问题相关性分析
变量相关性分析发现质量问题
帕累托图
(2-8原理)
适用场景：重点（主要）原因识别
Step1：汇总计数表 (检查表) 
对质量问题进行记录和统计数量
Step2：按照出现次数进行倒序排序，判断从主要质量因素
控制图
(7点法则)
适用场景：寻找异常情况
问题判断准则
1. 当产品的质量数据连续7点位于均值一侧
2. 连续7点呈单调上升或下降的趋势
3. 当数据出现在控制线之外（虽然在规格线之内）
层别法
适用场景：解析产生缺陷的原因，进一步找到改进方法
问题分析维度
(数据分层法：4M1E)
MAN(人)
Machine (机器设备)
Material (材料)
Method (方法/工艺)
Environment (环境)
质量控制
作用
识别过程低效或质量低劣的原因
建议或采取相应措施解决这些原因
确认项目可交付成果及工作满足主要相关方的既定需求，满足验收要求
工具
核对单（check list）
把可能出现质量问题的点，总结成清单，一个一个核对
统计抽样
过程决策程序图-PDPC
(Process Decision Program Chart)
采购管理
(4-69至77)
自制外购分析
概念
对于某个工作包，自己干还是找供应商干
决策的因素
交付方式
设计-招标-建造模式（DBB）
Design-Bid-Build
流程
甲方先找设计方做设计方案
根据设计方案招标施工方
施工方在进行具体的施工建造
特点
传统模式
甲方承担了大部分工作，需要做大量的协调工作
总承包-EPC
设计、采购、建造 (Engineer-Procurement-Construction) 打包在一起，交给一个总承包方
- 总承包方进行统一协调，减小成本，减小沟通成本
甲方只需对接总承包方即可
特许经营
甲方一定是政府
类型
BOT- 建设&运营&移交
(Build Operation Transfer)
案例：北京机场高速建设
- 投资款、建设、50年的运营权都由乙方负责，政府不出钱，50年后收回运营权
BT- Build Transfer
投资、建设由乙方负责，建设完成后政府付款，交付给政府
PPP
Public Private Partnership
政府和企业合资建设，成立合资公司，由甲乙方关系变为合伙人方式
采购合同
总价类合同
固定总价合同 (FFP)
Firm Fixed Price
总包合同（总价包死）
总价 + 激励费 (FPIF)
Fixed Price + Incentive Fee
1. 成本按预算控制
2. 另加约定费用作为利润
- 激励费是事先约定好，可以明确算出来的
3. 如成本超支或节约，按约定比例分担（一般甲方大头）
4. 设定甲方额外支付的上限（天花板价格）
总价 + 经济价格调整 (FP-EPA)
Fixed Price-Economic Price Adjustment
若原材料由于物价波动产生变化，甲方承担物价变动带来的费用
- 物价上涨，甲方额外多支出
- 物价下降，甲方额外收回一部分费用
适用场景
卖方履约期跨越几年时间
以不同货币支付货款
成本补偿类
基本特征
乙方实报实销，花多少甲方都得认
成本+固定费 (CPFF)
Cost Plus Fixed Fee
成本实报实销 + 额外给固定的费用（作为乙方利润）
成本+激励费 (CPIF)
Cost Plus Incentive Fee
与FPIF的区别：没有天花板价格限制
上例中：如果是CPIF合同，则支付480
成本+奖励费 (CPAF)
Cost Plus Award Fee
成本实报实销 + 甲方根据乙方表现给与奖励
（甲方给多少乙方拿多少，乙方无法申诉）
工料合同
按照人工、材料参加报价，乙方用多少，甲方付多少
采购文件
工作说明书-SOW
甲方出具，关于需要乙方具体做什么的说明
- 比较细、比较实
工作大纲-TOR
Terms of Reference
工作的范围、性质
- 比较虚
招标文件
用途
选择合格的分包商
信息邀请书-RFI
Request for Information
目的：让对方提供一些能做这件事的基本信息
报价邀请书-RFQ
Request for Quotation
对方提供信息 + 报价
建议邀请书-RFP
Request for Proposal
对方提供信息 + 报价 + 计划方案
供方选择分析
采购过程中，实现确定依据
维度：
成本、资质、技术/质量、来源
采购流程
Step 1：准备SOW或TOR
描述清楚外部的这部分工具，具体想要做什么
- 顾问类，咨询类的，准备好TOR
Step 2：独立估算，确定标底价
独立估算
请第三方造价咨询公司进行估价：标底价
拦标价：在标底价的基础上加上一定的比例。任何投标方报价高于这个价格则默认废弃
Step 3：确定选择供方的方案
包括供方选择分析，编制招标文件
Step 4：发布招标公告
Step 5：卖方资格预审
筛选合格的卖方，确定卖方清单
Step 6：召开投标人会议
主要作用只是声明甲方招标过程的合法、合规和有效（澄清招标文件）
- 确认甲方给各方的招标文件和资料都是一致的，清楚的
- 对于文件和资料问题，负责给投标人答疑
- 投标人已经是合格的卖方
Step 7：组织专家评标，确定哪一方中标
投标人准备标书，完成后，组织专家评标：
- 建议书技术评估
- 建议书成本评估
Step 8：与中标方采购谈判
目的
澄清合同内容，对合同的条款一一梳理确认，确保双方对合同的理解保持一致，避免理解歧义
- 条款包括：责任、变更的权限、使用的条款和法律、技术和商务要求、所有权、合同融资、技术解决方案、总体进度计划、付款以及价格等
不涉及的内容
中标价格，交付期限，质量验收标准，工作范围
Step 9：签订采购合同
争议解决
(4-76)
谈判
甲乙双方谈判解决
替代争议解决方法-ADR
(Alternative Dispute Resolution)
请第三方评判
仲裁
诉讼
采购审计
合规性检查
检查在采购执行的过程中，和采购管理计划中定义的规则流程是否一致
- 先有采购管理计划
- 不关心采购结果
采购的
结束方式
维度
关系维护 * 完成度
分类
成功完成
变更补偿
完成度高，关系差
- 甲乙双方经常有分歧，互相博弈，合作的不愉快
仲裁诉讼
完成度低，关系差
协商终止
完成度低，关系好
- i.e. 乙方能力不足以完成整个项目。在某一阶段协商终止
责任
项目经理
定义清晰完整的项目需求
技术经理
对技术规范负责：是不是符合技术标准和规范
采购经理
采购文件：采购合同是否合法合规
风险管理
(4-78至87)
定性分析
目的
给风险排序：哪些是重要的，哪些是次要的。并不会真正计算风险带来的损失
Step1：统一标准
定义风险的概率和影响
Step2：评估风险影响
1. 创建风险概率和影响矩阵
（程度 X 概率）
2. 归类
风险高的部分（深灰色区域），单独归入风险短名单
- 要做出详细的应对计划：谁负责，怎么解决？
其他部分，归入风险观察清单
持续监控
定量分析
目的
针对特别重要的特定风险，准确评估影响
成本高，无法对所有风险都进行定量分析
方法
蒙特卡罗法
(Simulation)
完成项目目标的概率 vs 项目预算(成本) 或 风险程度
敏感性分析
风险 (影响)因素 vs 最终结果的改变程度
（因素每变化1%，会对结果产生N%的变化）
案例：各影响因素 vs 净现值
- 首先列出各个影响因素每变化N%，目标值是多少
其次，画图观察斜率，斜率越大则敏感性越高，最后整理成金字塔图
决策树
思路：分开分析不同的决策，以及每个决策在未来不同机会条件下产生的期望价值
组成
决策节点
不同的方案以及对应的成本
机会节点
不同概率的机会下，产生的收益
影响图
思路：通过相同的符号对风险/机会归类，并画出逻辑关系（线条的粗细表示逻辑关系的强弱）
应对措施&流程
（4-82&83节）
措施分类
应急计划
Plan B：基本可以保持和原计划相同的效果
权变措施
根据当时环境，临时做出的解决方法，不一定会对最终指标效果产生影响
弹回计划
保底方案：应急计划、权变措施失效，为了避免项目完全失败而采取的计划
- 对原计划能达成的效果有较大损失，只能保留基本功能
措施的使用流程
主流程：原计划->应急计划->权变措施->弹回计划
- 权变措施优先级大于弹回计划
都需要走整体变更控制程序
应急计划 & 权变措施 & 弹回计划
自动权变：紧急情况下，无需请示汇报，直接做出决策
- 未知-未知的紧急风险才可以使用
风险 vs 资源
已知风险：能够识别出来，并且也知道发生的概率，项目原计划已经考虑到了
- 团队成员负责，因为通过WBS已经分为了不同的工作包和活动，已经明确了每部分工作的负责人
已知-未知风险：可识别（在风险清单里），但不知道什么时候，多大概率会发生
未知-未知风险
应对策略
负面风险
（威胁）
规避
i.e. 快捷连锁酒店，砍掉健身房、餐厅等成本高的部分，规避这几个部分产生的亏损风险
减轻
降低风险发生的概率，或者减轻风险的影响
- i.e 预防流感，打流感疫苗
转移
买保险、找外包
正面风险
（机会）
开拓
提高
分享
个人搞不定，和他人进行合作，找投资人
影响策略选择的因素
风险承受力 * 管理程序 (灵活、僵化)
风险（影响概率 & 损失量）
vs 项目生命周期
同一个风险，发生在项目的不同阶段所带来的损失完全不同
管理问题
(4-87节)
问题 vs 风险
风险：可能发生，但还没有发生
问题：已发生
此时必须要面对和解决
针对问题的准备工作
定义/确认问题上报路径和上报门槛
什么样的问题应该在什么层级解决
- 哪些问题团队自己解决，哪些问题需要上报给领导
- 严重到什么程度就应该要上报
配置管理
定义
交付物应该包含哪些功能，哪些组件
包含的内容
产品的功能、组件、文档
项目的基准、计划、文件
组织过程资产：知识、经验、教训
管理目标
完整性
包含的内容事先定义清楚，不能有缺失
一致性
产出和既定的配置一致
可控性
交付完整的内容，并且每个功能和组件满足配置计划中的质量要求
追溯性
每个版本有独立完整的存档，方便出现问题时回滚至上个版本
案例：软件开发项目的配置管理
配置管理
版本管理
各个历史版本完整，可用，可追溯
变更管理
改变原来的配置，包括
- 标识、控制、报告变更
过程管理
过程标准、合规：什么时候上线，什么时候做review
文档管理
文档完整、一致、及时更新
开发状态
汇流管理
代码管理：代码怎么写，怎么上传，避免多人工作不会互相冲突，覆盖
常用管理软件
入门级-版本控制
SVN，CVS，VSS，Microsoft Visual Software Safe, 
项目级
支持：软件版本管理+Bug追踪+重构等
- ClearCase, ClearQuest, PVCS
企业级
Harvest
数据&信息&报告管理
(项目经理应该管什么)
工作绩效数据
成果是什么
上周开发完成了5个功能点
成本是什么
上周使用了6个人*天
工作绩效信息
在执行阶段客观产生的数据，经加工处理后，对管理、绩效产生指导作用的信息
i.e. 上周完成的工作，和原计划相比，偏差是多少
受众：团队内部人员
分析方法
备选方案分析
(Plan B)
结合成本、功能等多方面因素，在多种方案中选最优：例如在APP、小程序等
趋势分析
按照目前项目进度，最终我们会delay多少？
偏差分析
现状与原计划的偏差：进度、成本等
工作绩效报告
绩效信息进行进一步分析、统计，提炼出逻辑性更强、具有明确解决方案的报告
受众：外部（客户，高层管理者，CCB-变更控制委员会）
包含
普通：周报、月报
专项：变更控制报告、采购报告、挣值分析报告
选取合适的开发方式
(4-91节)
STACEY矩阵
作用
帮助判断，用哪种开发方式来应对当前的项目
维度
技术（确定性） * 需求（明确性）
分类
1. 简单项目
预测型开发方式：按既定计划行事即可
2. 复杂烧脑项目
技术成熟但需求不明确
混合型开发方式
- 例如：预研阶段-敏捷；正式阶段-瀑布
3. 复杂棘手项目
需求清晰但技术不确定
- 案例：无人驾驶（技术不成熟）
混合型开发方式
4. 混乱
不要接手
5. 混沌
敏捷型开发方式
敏捷适用性评估
作用
帮助判断一个项目是否适合使用敏捷开发
维度
3个大维度 -> 9个小维度， 分别打分
知识转移
Knowledge Transfer：教会客户怎么用
显性知识
产品说明书
隐性知识
培训、演示
资源估算
专家判断
类比估算
参数估算
三点估算
自下而上
敏捷
敏捷生态圈
(敏捷实施框架)
宣言
(第一层)
个体和互动 > 流程和工具
- 更注重人与人的交流
工作的软件 > 详尽的文档
客户合作 > 合同谈判
响应变化 > 遵循变化
12原则
(第二层)
目的
(成就客户)
有价值的交付
持续不断 & 及早进行有价值的交付使客户满意
拥抱变化
善于掌控变化：即使在开发后期也能欣然面对需求变化
- 和客户更多地进行合作而不是谈判
- 当发现新情况或需要改变现状时，可以及时变更敏捷计划
合作
相互合作
业务与开发相互合作：客户<->业务<->开发
-业务应该起到沟通桥梁的作用：及时澄清需求，及时传达客户反馈
激发和信任
激发个体斗志；提供所需的环境和支持，信任团队，信任队友
面对面
一起办公，尽量以面对面形式进行沟通
过程
简洁
极力减少不必要的工作量
- 例如很多文档都是不必要的
自组织团队
协商、表决来解决问题
最好的架构、需求和设计出自组织团队
自发性根据项目需要来工作：我需要，或者有人依赖我，那我就来工作
不是一开始就出现，而是一个团队不断发展，渐渐达成自组织
回顾总结
及时规范的以会议形式回顾总结：前期的不足和下一个冲刺中需要的改进
- 从错误中吸取教训，不重蹈覆辙
短的，频率高的复盘
开发
短周期
在较短的周期，经常性的进行交付：及时确认交付物是否满足客户需求
可工作的交付物
交付物是进度的首要度量标准
- 交付物必须可以直接使用、好用
- 使用“完成” 或 “未完成”来判断任务状态。已完成的要及时提交交付物
- 百分比形式交付意义不大，都是未完成
可持续开发
持续开发、持续集成、持续发布
自动化测试、自动化部署
技术卓越
良好设计
有新的不用旧的：鼓励采用新技术、新方法
敏捷实践
(第三层)
产品视角
实践：产品管理的角度应该有精益思想
实践方法：强调精益创业、设计思维
研发视角
实践：
掌握Scrum框架、看板
敏捷管理实践
实践方法：推动Scrum冲刺和极限编程
- 冲刺（Sprint）：短而快
规模化视角
实践：
版本火车
DevOps
实践方法：尝试SAFe、LeSS等规模化敏捷方法
子主题
其他
敏捷领导力、敏捷中台... ...
实施敏捷
(创建敏捷环境)
评估敏捷变革可行性
- 敏捷变革友好型特征
- 指南6.1.2 变革就绪情况 P73
管理层的变革意愿
最重要
公司对员工认知、审核、评估上是否愿意做出变革
项目、项目集、项目组合管理职能是集中还是分散的
敏捷强调个体和互动，管理职能要分散在每个团队中
- 如果是集中的，则不好推动敏捷变革
专注于短期预算和指标而不是长期目标
敏捷对于控制短期的目标非常有效
- 长期目标还是要使用瀑布型
人才管理成熟度和能力
不具备，则需要敏捷培训
组织结构对敏捷环境的影响
- 指南6.7 组织结构 P83
地理
分散的项目组织可能会有很多阻碍工作进展的挑战
- 敏捷12原则中：面对面交谈是最好的沟通方式
职能结构
高度职能型组织，不容易实施敏捷（各部门之间壁垒严重）
项目可交付成果的大小
是否可以缩小项目可交付成果来激励部门之间更频繁的交流
- 频繁的交流，可以带来组织内更快速的价值流动
项目人员的分配
是否可以保证从各个部门抽调的人员，可以完全分配到项目上
重采购型组织
涉及到很多供应商，当供应商退出合约后：
- 带走项目知识
- 限制持续灵活性和迭代速度
如何与供应商共赢？
- 指南 6.3 采购与合同 P77
原则
客户合作高于合同协商
- 强调如何合作共赢，而不是合同条款
要点
多层结构
- 简化合同
变化因素隔离到单独的文档中，集中进行修改，简化修改工作量
强调价值交付
以价值驱动可交付成果来设置里程碑
- 每个里程碑，分别可以交付哪些价值
传统项目根据重要节点来交付，但这些节点不一定具备价值
总价增量
尽量拆小项目的可交付成果，更加有利于和客户合作
固定时间和材料
整体预算限定在一个固定的数额，但允许客户纳入新的观点和创新，但此时需要替换掉原来的一些计划项
动态范围方案
预算固定，项目范围可以动态调整
累进的时间和材料
共担财务风险，早交付给奖励，晚交付交罚金
提前取消方案
如果在某个阶段，已经交付了足够的价值，如果客户不再需要剩余范围/价值，那么不必支付这部分费用
团队扩充
供应商将人员派驻到项目团队中（融合成一个新的自组织团队）：资助团队而不是资助项目范围
敏捷PMO
- 指南 6.6 敏捷和项目管理办公室 P81
特点
价值驱动型
所有的项目都应该在合适的时间，为合适的客户提供合适的价值
面相创新型
为了实现价值，PMO可能需要强制执行某些解决方案或方法
多学科型
除项目管理外，要熟悉其他的技能
职责
制定和实施标准
模板
提供敏捷场景的模板：用户故事、测试案例、累计流图
工具
提供敏捷工具
培训
帮助小组了解敏捷开发概念
通过培训和指导发展人才
协调敏捷培训、教练和导师。帮助员工尽快过渡到敏捷思维模式
多项目管理
通过不同项目交流协调敏捷团队
促进组织学习
通过收集项目进度信息，获取、存储、回顾成果
管理相关方
提供产品负责人培训、指导验收测试、评估方法，提供系统反馈
宣扬主题专家（SME）对项目的重要性
招聘、筛选和评估项目领导
负责招聘、评估敏捷实践者（例如敏捷教练）
执行专业化项目任务
培训敏捷实践者（提供导师和教练）
项目经理的角色
- 指南 4.2
总原则
仆人式领导
特点
由团队中心转变为给团队和管理人员提供服务
- 因为敏捷是去中心化的
促进团队合作，保持与相关方的需求一致
鼓励将责任分配给团队成员
- 要求团队成员承担更多地责任
职责
促进
促进团队成员成长
实践：提供指导、鼓励、帮助，为团队提供支持
实践：通过项目管理技术来帮助团队
消除组织障碍
实践：教育相关方，使其了解为何以及如何实施敏捷
实践：组织架构对团队产生障碍，就要项目经理出面沟通解决
实践：为团队与外部团队合作提供支持，起到桥梁作用
为他人贡献铺路
帮助他人成功
成功的敏捷团队
- 指南 4.3.1 敏捷团队 P39
专门人员
全职工作
小于10人团队
跨职能团队成员
拥有全职能能力，可以独立完成项目，应对频繁的开发和交付
通才+专家组成
通才：提升灵活性，胜任多个岗位
专家：提供专门技能
集中办公 或
能够解决不同办公地点带来的挑战
高效沟通，致力于相互合作
知识共享，降低学习成本
稳定的工作环境
成员彼此依赖、互相认同，有利于实现交付
简化团队成本
方便知识资本的保留和发展
常见角色
- 指南 4.3.2 敏捷中的角色 P40
跨职能团队成员
产品负责人-PO
团队促进者
Scrum Master、项目团队领导、团队教练等
敏捷团队章程
- 指南 5.1 项目章程和团队章程 P49
团队价值观
例如：可持续的开发速度
工作协议
定义“工作就绪”- DOR
定义“工作完成”- DOD
基本规则
约束团队成员的行为：例如会议上每个人都需要发言，不能超过5分钟
团队规范
例如：会议不能迟到
Scrum框架
（4-3节）
3种角色
产品负责人-PO
 (Product Owner)
客户代表
在团队内部，代表着客户方（甲方）
工作内容
定义所有产品功能
产品负责人是所有需求的收口
决定发布内容和日期
vs. 传统项目
- 日期和内容是和技术团队讨论决定的，更多基于技术团队的能力，而非市场需求，可能会导致发布不合理
决策
对开发功能排定优先级
- 合理调整产品功能和迭代顺序
vs. 传统项目
- 传统项目中由项目经理决定
认同或拒绝迭代的交付
责任
对产品的ROI (投入产出)负责
vs. 传统项目
- 传统项目很难找到一个明确的负责人
讲清楚、弄明白需求的内容
确保开发团队知道产品待办事项列表、回答业务需求方面的问题
服务式领导-SM
 (Scrum Master)
支持和保障工作
（仆人式领导）
帮助团队排除障碍
&
保护团队不受外界影响，保持专注
关注冗长的过程，识别阻碍因素，并联系相关部门解决这些阻碍
确保团队胜任工作，保持高效率
保证仪式，组织日常会议
鼓励言论自由；团队有问题，优先内部讨论解决
更新冲刺并发布燃尽图或燃起图
不衡量团队成员个人表现：敏捷团队是自我管理团队
提高生产力
生产关系
当团队表示有意见，不合适的时候，会导致生产力出现问题
生产工具
对生产工具进行补充维护和推广
- SM 主动涉猎、认知一些先进的实践 (行业应用)，并理解这些实践对团队的帮助，引入这些先进的实践
vs 项目经理
早期，与项目经理相对一致：制定规则、管理期望、管理相关方、制定沟通策略等
项目执行后：SM不做决策（信任团队自己做决策，去中心化决策 - 自组织）
开发团队
(Dev Team / Developer)
组成
开发+ 测试 + support人员组成
特点
自主选择（自组织）：自己选择自己愿意做的事情（自领状态）
- 传统项目中，一般是WBS工作拆解下来后，分派工作
全职能
成员是通才/多面手：每个成员都能够做每个方面的工作（例如开发人员应该具备测试的能力）
全职
团队成员在一个迭代内尽量稳定
100%专职成员，一个萝卜一个坑。没有结对编程的情况
- 冲刺计划开始前，团队就应该和职能经理确认好资源，以免冲刺中资源变化
外部团队问题
（考试用到）
识别出来问题来源于外部团队，需要拉着外部团队一起解决，而不是自己团队内部抱怨
决策在团队内
去中心化决策
平级
职能水平上没有划分：技术经理的角色不存在（即不会出现一个人指派任务让另一个人做）
3种工件
(工具)
产品待办事项列表
（Product Backlog）
含义
排了优先级的需求池
所有需求：业务需求，技术需求，NFR (非功能性需求，例如安全性，性能)等
不允许有任何的需求不进入产品待办事项列表
每个Sprint开始前，都需要修正优先级排序
在某个Sprint结束时，所有未完成的需求，都要重新返回到产品待办事项列表，PO重新评估优先级，而不能直接安排在下一个冲刺中
每一项需求 (待完成的工作)都将对客户产生价值
负责人
Product Owner
负责创建&维护：需求、优先级
内容
条目以用户故事的形式呈现
用户故事（user story）：表述需求的工具
- 作为一个用户角色（XXX），我想要XXX，以便获得XXX
- 详见“过程”-> “需求的呈现与表达”
产品愿景（电梯演讲-Elevator Pitch）：出现在用户故事之前
- 为了满足（目标客户）的需求（XXX）
- 这个（产品名称）是一个（产品类别）类型的产品
- 他可以（关键优点和使用理由）
- 而不像（同类竞品），我们的产品具有（差异化的特点）
满足DEEP
原则
Detailed：适当的详细程度
只有进入迭代的需求需要尽量详细
- 产品待办事项列表中每个需求不是都要非常详细
Estimated：估算的资源使用量
PO只负责估算（大体估算），产品待办事项列表中具体要做多少，是开发团队决定的
- 放多少-PO负责；做多少-团队决定
Emergent：涌现的
需求是涌现的。例如完成了一个版本交给客户后，客户会根据实际情况涌现出很多新的需求
Prioritized：排了优先级的
Action
Scrum团队进行产品待办事项列表梳理活动：向PO讲清楚每个需求和各需求之间的关系
迭代代办事项列表
（Sprint Backlog）
含义
某个Sprint开始前，从Product Backlog中选取优先级最高的放入Sprint Backlog, 作为该Sprint过程中的代办事项
- 仅对当前的Sprint有用
- 一个Sprint中只做在迭代待办事项列表中的任务
结构
用户故事 + 具体任务
用户故事：PO创建，来源于产品待办事项列表
任务：团队协商、共创出来的
- 团队成员主动领取任务（不是用户故事）
- 团队成员可以添加、删除、更改Sprint Backlog中的任务（不是故事）
- 具体做多少，由团队自己决定（基于PO讲清楚需求的价值、内容和必要性），因此，敏捷中工作不是项目经理安排的，而是团队自己承诺的
- 任务需要估计工作量，并每天更新剩余工作量（燃尽图）
产品增量
（Product Increment）
概念
某个Sprint的交付物 (可以发布的产品组成部分)
- 集成至以往的迭代成果中，形成增量式交付
要求
交付的用户故事必须符合验收条件（必须达到Scrum团队定义的质量标准）
增量成果必须可用（随时上线使用）
- 不是一定会发布，PO决定是否发布（交付和上线）这个故事
5种活动
5个会议
Sprint
冲刺(迭代)，是Scrum的核心
时间箱
1-4周
标准：在这个时间内，可以构建出一组可用/可发布的产品增量
长度应保持一致
双周版本
固定时间、固定活动，有明确的预期
优势：
- 专注、增加创造力
- 固定时间内可以实现可预期的价值（时间价值、效率高）
- 可用时间多（只有4个固定会）
规则
一个迭代中，不推荐做变化：每个人的职能尽量不变。要变也要再下个迭代中
产品梳理会
(待办事项梳理会)
内容
重新梳理用户故事和优先级
PO拿着Product Backlog和团队讨论
目的
为Sprint计划会做准备，梳理需求
参与者
整个Scrum团队：PO，SM，Dev团队
邀请利益相关者来参与和评审
Action
增、删、改、查、拆解用户故事
明确验收标准（对于每个用户故事）
估算规模（需要的时间）
使用相对估算：通过一个benchmark (例如一个轻量级的用户故事)，工作量大概是几倍
- 即使用目标故事与基准故事进行对比
排序故事的优先级
原则：基于价值来分析优先级（交付成本、延迟成本、ROI）
工具
莫斯科法则
Must、Should、Could、Won't
- 详见“需求管理”
Kano模型
基于客户兴奋点/满意度来排序（客户满意度*客户需求实现度）
- 详见“需求管理”
权重分析模型
给需求打分，根据得分判断优先级
- 罗列需求对应的收获和制约因素
- 分析影响范围和大小
- 关注：做了带来的收益、风险、问题，不做的损失
- 打分综合判断优先级
识别风险、依赖和技术架构
可以包括技术相关的讨论
产出
Initial版本的Sprint Backlog
多个迭代待办事项列表组成了发布计划（敏捷中的计划）
- 敏捷中的计划是以故事为单位的（故事层），体现要发布哪些故事，每个故事在哪个迭代中出现
发布计划完成情况
发布燃尽图
针对整个项目的燃尽图：横轴是每个Sprint，纵轴工作量是跨迭代的，例如：特性维度
- 普通燃尽图的横轴是天：第1、2、3天，纵轴是一个迭代内的剩余工作量
条形燃尽图
累计流量图
1. 纵轴：总任务量
2. 不同颜色代表不同泳道，不同类型的任务（随着时间的推移，原始任务会不断地分配到不同的泳道中）
    - 最左侧蓝色泳道: 待完成的任务池；最右侧深紫色泳道：已完成的任务
3. WIP：某一天正在进行的任务
    Avg. Lead Time: 前置时间，代表完成"WIP"这部分任务所需要的时间
    Avg. Delivery Rate: 斜率代表完成速率
4. 利特尔法则（Little's Law & Cumulative Flow）
    Delivery Rate = WIP / Lead Time
Sprint计划会
（Plan）
目标
制定迭代计划
选故事 (确认做什么 - 做承诺)
选取用户故事，确定迭代目标
PO与团队一起从产品待办事项列表中选取用户故事
明确完成的定义-DOD
- 做到什么样就是完成了
验收标准：具体的指标
完成的定义：必须要完成哪些测试，必须部署到什么样的环境
探测/刺探技术（Spike）
可行性判断 - 用于任何不确定的地方（风险，技术、商业模式）
- 对于高度不确定/从未做过的工作，需要短暂停止项目工作，先探明可行方案，不能贸然开始冲刺
拆任务（确认怎么做）
创建迭代待办事项列表
团队拆分和确认任务，给出工作量估算
依据之一：团队速率（固定时间内团队完成任务的规模）
- 团队速率不是越快越好，而是越稳定越好
- 使用相对估算：不能跨团队比较，但是可以跨迭代比较（使用统一的benchmark）
范围
(Who)
整个Scrum团队共同完成
主持：Sprint Master
时长
限时会议。2周的迭代：2小时选择故事，2小时估算分配（每个任务大概花多长时间）
产出
这个Sprint的燃尽图
由SM负责完成
每日Sprint站立会
（Do - 执行）
目标：回答三个问题
昨天做了什么
今天准备做什么
存在什么样的困难
范围 (Who)
整个Scrum团队都必须参加
团队成员自组织，互相承诺
- 如果时间紧张，SM可以不参加
时长
每天开，15分钟
产出
燃起图
Sprint评审会 (验收会)
（Check - 检查）
目标
产品验收评审
检视交付的产品增量
和外部交互的会议
开发团队通过Demo演示进行 - To PO或客户
产品负责人选择接受或拒绝，决定是否发布产品增量
按需调整产品代办事项列表（Product Backlog）
不需要汇报进度。目的是获取反馈促进合作
范围
(Who)
Scrum团队 + 客户
时长
Sprint临近尾声
产出
可交付的产品软件（产品增量）
修订后的产品待办事项列表
业务方根据实际产品增量，可能会提出新的想法和需求
Sprint回顾（复盘）会
（Action - 改进）
目标
回顾总结，识别改进项，在下个Sprint实施
相当于传统项目中的审计（针对过程的审计）
参与者
整个Scrum团队（没有客户）-闭门会
回顾范围
技术细节：例如代码review
执行过程中的所有活动：活动有没有意义
产出
制定出next action list
5种价值观
(团队遵循的核心理念)
勇气
用于做很多过去不敢做，不管承诺的事情
开放
不鼓励一对一交流的形式。信息应及时传递给全团队
专注
短周期内，团队专注于一件事情上
承诺
尊重
相信个人都是积极向上的，有职业操守，尊重想法和决定
敏捷的产品管理
项目边界
（敏捷 vs 传统）
1. 敏捷 = 
传统 + 需求理解 + 产品运营

2. 金字塔结构（由宏观到微观）：
第一层：公司愿景 -> 商业战略
第二层 (产品管理)：产品愿景 -> 产品战略 -> 发布计划
第三层：迭代计划 -> 每日计划
产品待办事项列表的产生
流程
产品愿景
(电梯演讲)
总思路
描述对产品的目标，希望达到的效果
结构
目标
为了（目标客户）
他们的（需求和机会）
产品简介
这个（产品名称）
是一个（产品类型）
它可以（关键有点和使用理由）
差异化
(对比优势)
而不像（同类竞争者）
我们的产品（差异说明）
使用场景
张贴在显眼的位置
项目过程中不断声明产品愿景：团队成员实时知道为什么要做这个产品
用户画像
目的
收集用户信息
了解用户需求
结构
基本信心
喜欢/不喜欢
对产品的期待
对产品的痛点
用户故事
目的
促进开发人员对用户需求的理解
结构
正面：用户故事
作为XXX（用户角色）
我想要XXX（结果）
以便XXX（原因/价值）
示例：作为一个网络购物者，我想要支持小额免密码支付功能
以便在我点击支付时能够快速完成订单的支付
反面：验收标准DoD
(用户故事的实现效果)
在（场景或条件）下
做了（操作/行动）
得到了（结果）
用户故事地图
创建步骤
确定关键用户
描述用户活动
活动分解为史诗
基于史诗编写用户故事
确定产品发布的版本
产品待办事项列表
创建
从用户地图中，拉取优先级较高的用户故事（例如某一个MVP下面的用户故事）
更新时间点
每个迭代都要更新
原则：DEEP
Detail.适当的详细适度
用户故事不能太大，也不能太小。
Estimate.被估算的
用户故事的规模需要估算
Emergent.涌现的
完成顶层的用户故事后，下面的需要完成的用户故事内容自然涌现出来
Prioritize.排了优先级的
用户故事的优先级需要满足排序标准。
估算工具
(用户故事的规模)
宽带德尔菲
流程
用途：收集估算
关键词
收集
例题
SM与团队和PO开会澄清用户故事，会后团队收集并提供个人用户故事估算。采用的是什么方法?
A.计划扑克
B. 宽带德尔菲法 --> √ (关键词：收集）
计划扑克
流程
用途
故事点相对估算：基于一个benchmark故事点，估算其他用户故事的故事点倍数
应用
数字代表故事点数量
1. 0 - 不需要任何工作量
2. ？- 需求不理解，无法评估
3. 100 - 工作量太大，需要细化
亲和估算
流程
关键词
规模大
T恤尺码估算
量级估算：S、M,、L、XL等，将不同的用户故事放入对应的量级
优先级排序工具
MoSCoW法则
卡诺模型
相对量级
优先级 = （商业价值+风险）/成本
- 成本：指成本或规模
一个软件开发项目潜在的利益大于风险。在选择每次迭代的内容时，应该优先开发哪些功能?
A.高价值和低风险功能
C.高价值和高风险功能--> √
敏捷价值路线图
(价值流是什么？)
流程
敏捷项目章程
定义愿景：项目愿景/产品愿景， 介绍高层级目标
概要的需求，进度计划
使命，为达到敏捷的目标需要做的事
项目成功标准
产品路线图
敏捷发布规划
例题：你正在创建在公司部署一个新的ERP软件的时间表。公司决定选代开发新的ERP。ERP的第一个版本应该在四个月内推出，你知道另一个全公司范围操作系统升级的项目计划在三个月内推出。随着升级项目影响你的进度，你应该评估以下哪一项以确定在推出前的迭代次数?
A.敏捷发布规划--> √
B.产品路线图--> ×
C.迭代待办事项列表
KanBan体系
原则
完成工作比开始工作更重要
未完成工作不会产生任何价值
因此才会有WIP的规定：专注于当前的少量工作
概述
单团队敏捷实践
拉动（Pulled）式生产
i.e. 后接工人完成工作后，发出信号，前序工人再继续工作
避免高在制品（WIP）数量累积的恶性循环
基于流程的思路
- Scrum是基于迭代的思路
任务放置在看板上进行跟踪管理
特点
(核心实践)
工作流程可视化 -> 决策可视化
例如：设计、开发、测试、部署阶段的可视化
看板直观反映出问题/状态，团队成员更容易理解团队的决策
限制在制品(WIP)数量
目的：更加聚焦（局部优化/瓶颈处优化）
做法：每个泳道限制任务数量
度量和管理流动
和Scrum不同，KanBan系统对数据和度量有要求
常用工具：累计流量图，包含WIP数量、Lead time、吞吐率
显示化流程规则
公开透明：清晰展示任务的流动和每个工序的流程规则
建立反馈环路
KanBan没有时间箱概念
- 任然要开回顾会、评审会、计划会，但按需召开，不严格规定召开时间
每日展会的形式，从右至左检查看板工作项
在协作及实验中改进
（持续改进）
保证从用户需求到创造用户价值的顺畅流动
不需要增加额外的角色
现有团队成员就可以完成
衡量指标
交付周期
总时间：任务卡片从贴上到完成
周期时间
处理时间：处理一个任务所需的时间，不包含开始前的等待时间
响应时间
等待时间：一个任务等待开始的时间
KanBan面板
vs
任务版
任务板
一共包含三个主要泳道：To Do, Ongoing, Done
流动的是任务（从故事拆分下来）
KanBan面板
更加健全的泳道
每个泳道都有限制WIP的数量
定位瓶颈：很容易发现瓶颈在哪个环节
- 距离如果任务F开发完成，此时Test里仍然有2个任务，则无法移动，此时无法从ToDo中拿新的任务。此时需要协助Test，使其流动起来
学习成本低：不用知道每个具体任务是什么，只关注整个流动是否健康
看板面板
创建流程
Step1：梳理工作流程
Step2：画出看板面板&放置工作任务
Step3：设置WIP限制
Step4：定义完成规则
Step5：召开每日展会
当面移动标签
Step6：度量和管理流动
累计流浪图（见“5种活动”-“产品梳理会”），斜率就是吞吐率
精益画布
MVP&MMR
精益画布
背景
产品构想->商业计划->商业计划书（过于冗长）
适用场景
进行商业论证
核心模块
（部分）
市场渠道（获客通道）
收入来源：营收是从哪里来的
关键指标：如何衡量产品的成功与否？
竞争壁垒：产品护城河是什么？
MVP
MVP - 最小可行性产品
(Minimum Viable Product)
背景：互联网背景下，需求快速变化，无法支持企业花很长时间来开发一个产品
思路
不断验证用户需求、市场需求
尽早给出一个初始可用版本让客户先用起来，通过一步步迭代优化最终满足客户要求
- 例如：客户要求开发一个汽车。那么可以从滑板车->自行车->摩托车->汽车
优点/特点
充分理解客户需求：促使客户不断提供更加有效的反馈和意见，快速迭代，保证最终交付物符合业务需求
化解项目风险（避免客户对最终做出来的产品不满意）
始终/及早有产出交付给客户
不一定是一个真实的产品，试验品性质，不包含所有的功能
效率高：用最小代价（最小精力，最小投入）
实现途径
产品介绍视频
介绍开发想法：理想的功能有哪些？可以怎样使用？适用场景？
仿真
众筹
获得宝贵的早期用户，同时验证市场需求
原型法
通过原型图来确认需求
预售
i.e. 课程预售，满XX人报名开班，否则退款
访谈
MMR
MMR（Minimum Marketable Release）：最小可发布版本
用途
验证真实产品是否满足用户需求（用户是否愿意买单）
特点
真实可用的产品，用户可以真实付钱购买的版本
必须要有的功能
工具：莫斯科法则 (MoSCoW Laws)
敏捷实践
(查遗补漏)
组织内部变革
变革就绪：
1.管理层的变革意愿
2.员工认知的转变
3.集中或分散项目管理职能
4.专注于短期目标而非长期
5.人才管理成熟度和能力
例题：一家沉浸于瀑布式项目管理中的PMO聘请了你，作为敏捷实践者，来指导组织向敏捷的转变。你意识到许多干系人都抵制变革。最佳行动方案是什么?
A.提供培训来确保员工更加专业化
C.寻求愿意支持这一事业的高层高管 --> √
D.确保工作分解成孤岛
敏捷合同管理
原则
多层结构
固定内容（法律、法规等） + 灵活内容
强调价值交付
增加增量
一个个故事进行交付
固定的时间和材料
管理给定能力：如果要加进来一个故事，必然要踢出去一个故事
允许动态范围
允许特定点的更改
累进的时间和材料
类似激励合同：按时完成给奖励，否则给处罚
提前取消方案
若已完成的部分能够满足需求，那么可以取消项目，不用支付剩余费用
团队扩充
支持把供应商团队的人拉到自己团队来
支持全方位供应商
支持全能型的供应商，由一个供应商处理所有工作
多团队协作与PMO
多团队合作
SAFe
(Scaled-Agile Framework)
LeSS
(Large-Scaled Scrum)
每1到3个团队配备1名SM
PO最多可以负责8个团队
SOS
(Scrum of Scrum)
丽日
敏捷PMO
价值驱动
培训发展人才
促进组织学习
招聘项目领导
例题：PMO想要结合敏捷的最佳实践。项目经理担心团队不具备在混合环境中工作的能力。最佳行动方案是什么?
A.授权团队自我组织和学习敏捷最佳实践
B向项目管理办公室(PMO) 申请培训 --> √
D审查敏捷最佳实践的经验教训知识库
领导
(管理型->仆人式)
责任
消除组织障碍
审计、财务、CCB、过程文档
促进团队合作
仆人式领导促进合作
教育干系人
敏捷的干系人管理
培训与发展团队
超越角色，即使失去成员也在所不惜
例题
1. 一个组织正在从预测性项目管理过渡到敏捷。作为项目经理，合规报告需要提交给内部审计师。如何在混合环境中满足法规遵循报告的需要?
A.与审计师合作来简化过程--> √ （消除组织障碍）
B.任命一位团队成员完成合规性报告
2. 你是敏捷项目的经理。一个关键干系人是团队的主要干扰人，频繁地从团队中获取项目状况信息，提供建议、变更需求。对此，你应该做什么?
B. 邀请利益相关者参与适当的规划或审查会议，要求他提供自已的观点--> √
D. 直接告诉利益相关者在迭代周期中不要打扰团队
3. 敏捷教练一直在通过或超越他们当前的角色来培养和发展团队成员。帮助一些团队成员发展了他们的个人和专业技能，使他们觉得他们已经超越了自己的角色。最终，他们中的一些人离开了团队寻找新的机会。敏捷教练的方法正确吗?
B.正确，敏捷领导者应该培养团队成员，即使这意味着失去他们--> √
C.不正确，敏捷领导者可能会培养团队成员，但不会超越他们当前的角色
团队
(孤岛式->自组织)
3-9人的专职团队
切换任务时，效率损失20%-40%
克服组织孤岛
孤岛：职能部门的分组
通才型专家、T型
自组织团队
团队主动领取，估算，分配任务
团队工作场所
集中办公、分布式团队
敏捷工具
信息发射源
- 在不干扰团队的情况下即时实现知识共享
- 包含：看板、燃尽图、燃起图、障碍日志
燃尽图
(Burn-down Chart)
作用：监控项目进度
体现当前迭代的进度
燃尽图 = 燃起图
剩余工作 * 时间
注：蓝线如果一直在黑线下方，则表示进度计划安排不合理，有造成资源浪费（不饱和）的风险
迭代速度
本次迭代种完成的故事点总和
判断工作完成速度，帮助规划下阶段的能力
看板
(KanBan)
详见看板体系
发布燃尽图、条形燃尽图、累计流量图
见“5种活动”-“产品梳理会”
敏捷团队管理
变更
Sprint内部的需求相对不变，变更尽量安排在后续的Sprint
- 如果变更频繁（例如一周一次），那么Sprint可以改为1周
团队
团队阶段划分 & 管理，详见“团队”->“团队规则”
服务型领导
帮助团队>命令团队
移除障碍>创建障碍
保护团队>干扰团队
管理基于团队而不是任务（敏捷创建的是自组织团队）
冲突
&
迭代与回顾
冲突
解决方法：投票
大拇指投票法
同意，反对，弃权
五指拳投票法
5：完全有信心... ... 1：不可能实现
迭代与回顾
（每个冲刺）
回顾方法
（SSCC）
Start
新做法
下一个冲刺当中，应该开始哪些新的做法
Stop
被禁止做法
之前做法不合适，不应该做
Change
改进做法
哪些做法需要改进
Continue
优秀做法
好的做法继续做
变更管理遵循的规则
（4-29节）
小步快跑
冲刺周期（Sprint）较短，优先级高的新需求可以很快被满足
高效反馈
任何用户需求和团队创意，都会被及时记录下来并及时评估优先级
保持节奏
定下来2周一个冲刺，那么未来也是以该周期为一个周期
价值交付
以创造用户价值为目标。以创造用户价值的变更都是欢迎的
需求管理
Kano (卡诺)模型
指导需求的优先级管理，基于用户兴奋点、满意度设计
维度
满意度
用户满意度
具备程度
产品是否有这个功能 或 该功能的完善程度
属性
(优先级从高到低)
必备属性（Must have）
i.e. 手机通话、上网、拍照功能
期望属性（Should have）
i.e. 待机时间长
魅力属性（Nice to have）
i.e. 折叠屏、无线充电
无差异属性（Does not matter）
i.e. 手机电路板层数
反向属性（Should not have）
i.e. 预装第三方软件
莫斯科法则
(MoSCoW Laws)
Must have
必须做
Should have
迟早得做，但优先级不是最高
Could have
可以做，也可以不做
Won't have
无论是否有能力做，都不应该做
进度管理
(4-51节)
分解和细化产品待办事项列表
- 规模*详尽程度
按照箭头所示路径，逐步分解细化带边事项列表
发布规划
洋葱圈规划
(Onion Plan)
每日站会
Sprint计划/评审/回归
版本计划/评审/回归
产品路线图计划/评审/回归
投资组合计划/评审/回归
其他敏捷实践
极限编程
核心目的
尽早拿到反馈，快速迭代
实践
持续集成
CI（Continuous Integration）
减少代码冲突
流程化、规范化代码提交，对整个交付有一定把握
工作流程
提交代码到代码库
CI server监听代码库的变更
CI server触发自动化构建
CI server触发自动化测试
通知相关方
TDD
Test Driven Development (测试驱动开发)
测试行为驱动开发行为
- 先写测试用例，再写开发代码
测试用例通过是开发的一个关键路径
- 开发的真正目标是完成测试用例覆盖的内容，而不是完成需求文档
结对编程
概念：2个人在空间上、物理上（同一台电脑）同时做一个任务
适用场景
老带新
技能的复制
为了满足开发团队成员全职能的要求
攻坚
代码集体所有权
小型发布
水晶
一种方法论家族
根据项目规模和关键性来选择合适的方法
Scrumban
Scrum到看板的过渡方法
把Scrum的Task放在看板上，监控Task的开展状态（类似任务板）
功能驱动开发-FDD
目的是满足大型软件开发项目的特定需求
动态系统开发方法-DSDM
强调制约因素驱动交付
敏捷统一过程-AgileUP
软件项目中，统一过程（UP）的分支。目的在于在7个主要因素之间执行更多的迭代周期，在正式交付前纳入相关反馈
Scrum of Scrums
(多团队敏捷实践)
SOS, 也称meta Scrum
两个或多个Scrum团队使用的技术
不是一个大型的Scrum团队
每个团队包含3-9人
团队间协调：每个团队代表与其他团队定期召开会议，通常一周2-3次
每日例会
类似每日站会
SAFe
大规模敏捷框架
专注于项目组合、项目集、团队层
LeSS
大规模敏捷开发
扩展Scrum方法为共同目标，来组织多个开发团队。
仍然要求多个团队使用同一个产品待办事项列表
- 仍保留更多的传统Scrum元素
企业Scrum
团队级扩充至整体性组织层面，延展Scrum方法和理念
规范敏捷-DA
整合多种敏捷最佳实践的过程决策框架
考试要点
重要角色
高级管理层
项目经理的顶头上司
管理的是项目储备
CCB
变更控制委员会（Change Control Board）
只有项目经理和CCB能够决策变更
项目管理的基准
baseline
包含范围、进度、成本三个部分
区别
影响基准的变更只能由CCB来决策（提供书面报告）
各方代表组成的一个小组：甲方、乙方项目经理、外包商
PMO
职能经理
财务、法务、采购、行政、人事等
发起人
出钱的人
甲方或内部项目中的老板
团队
项目团队制定项目计划
项目经理负责制定粗粒度计划，最细到工作包
执行团队会细化工作包，细到活动：每个活动都需要评估成本（人*天）
项目计划是自上而下分解，再自下而上汇总（成本汇总等）得到
项目干系人
项目管理
价值观和方法论
未雨绸缪
计划
事先识别出每一步怎么做
风险管理
识别出可能遇到的风险
做出风险的应对计划
指定明确的负责人
防微杜渐
监控
持续实时监控项目
及时纠正
监控过程中出现的偏差进行及时纠正
资源集成
整合管理
最专业的资源整合在一起
项目经理最重要的职责是把专业的事情交给专业的人干，而不是自己
采购管理
恰到好处
范围
只做范围内的事情。可做可不做的，原则上不做
质量
达到合同规定的验收标准即可
达不到和超出都不行。超出可能意味着多花资源和时间，意味着成本可能会超出
循规蹈矩
过程
遵循项目的49个过程
制度
项目变化优先考虑走整体变更控制程序：增加/变更需求，项目突发意外
锲而不舍
目标
目标不变
积微成著
组织过程资产
变更 - 变更日志
需求 - 需求登记册
变更后 - 经验教训登记册
公开透明
沟通
参与
同舟共济
诚信
共赢
各司其职
授权
项目经理的权利：团队成员的工作分配
即使是发起人，也无权对项目人员安排私自做调整
平等
固定搭配
章程->发起人
发起人是章程的发布者和责任人
基准->CCB
基准的变更，只能是CCB表决变更
优先级->PMO
各个项目的优先级是PMO决定的
通知->干系人
如果有变更，在执行新计划前，必须通知相关干系人
管理储备->高级管理层
高级管理层掌握管理储备
变更->评估影响
变更发起后，下一步一定是评估影响
更新->计划/文件
更新项目计划和项目文件
记录->问题/经验教训
经验教训登记册，问题日志
审计->过程合规（管理计划）
审计过程是否合规。规则存在于管理计划，包括流程和做法
偏差->监控过程
监控过程组：寻找和及时发现偏差
评论
0 条评论
下一页
为你推荐
查看更多
PMP-监控项目工作
PMP-监控项目工作
项目招标工作核心内容beta版
项目招标工作核心内容beta版
如何高效学习- 核心内容
如何高效学习- 核心内容
PMP-项目整合管理基本信息
PMP-项目整合管理基本信息
产品经理三大文档核心内容解析：BRD、MRD、PRD
产品经理三大文档核心内容解析：BRD、MRD、PRD
PMP-敏捷方法知识点汇总
PMP-敏捷方法知识点汇总
PMP-项目整合管理概述
PMP-项目整合管理概述
项目管理十大知识域核心内容大纲
项目管理十大知识域核心内容大纲
项目招投标工作核心内容
项目招投标工作核心内容
PMP-项目整合管理详细内容
PMP-项目整合管理详细内容