新考纲
考试知识点占比
五大过程组
启动过程–规划过程–执行过程–监控过程–收尾过程
第四章 项目整合管理
商业论证
项目章程
项目章程的意义
看清方向：项目章程可以帮助项目经理领会发起人意图、明确项目目标、识别项目成功标准。
认清形势：通过盘点可获得的有限资源和支持来制定客观可行的计划。
分清责任：项目章程明确了对项目经理的授权，也分清了项目经理也发起人及其他相关各方的责任。
假设日志:用于记录整个项目生命周期的所有假设条件和制约因素
假设日志关键词：假设、制约、风险输入
整体变更控制
变更答题思路：
相关方提出变更–>项目经理和项目团队分析影响–>项目经理提出审批
实施整体变更控制（大概率会选）
范围蔓延–首先进行变更
会议
1、项目启动会议（initiating meeting）：概念阶段—规划阶段
发布项目章程
任命项目经理
宣布项目正式启动
2、项目开工会议（kick-off meeting）：规划阶段–执行阶段
宣布项目计划编制完成
确认资源已按计划到位
宣布项目进入执行阶段
项目文件 项目管理文件
项目管理计划中的基准变更必须走整体变更控制程序，有CCB批准。
项目文件中实施计划更新也需要走整体变更控制程序，由项目经理批准。
结束项目或阶段-收尾流程
核实（内部验收）
第五章 项目管理范围
范围管理=产品范围+项目范围
不同生命周期的范围管理对比
范围与需求
范围来自于需求
需求–客户想要的
范围–最终要做的
收集需求常用的方法和工具
-
头脑风暴
-
访谈（一对一）
-
焦点小组（针对某个主题、某个问题）
-
问卷调查（量大、面广，需要快速收集多人的需求）
-
标杆对照
-
联合应用设计或开发（JAD）：与客户一起解决问题
-
亲和图
将相关的放在同一组 -
质量功能展开（QFD）
-
思维导图
-
名义小组
小组成员独立思考（区别于头脑风暴） -
观察法
-
引导式研讨会
跨部门、跨专业（主持人鼓励大家发言） -
系统交互图
-
原型法
-
故事版
导演分镜手稿–可视化剧本
需求跟踪矩阵
敏捷场景下的需求管理
卡诺模型
卡诺模型–分析产品属性
卡诺模型：当时间、资源有限时，判读预先满足的属性（优先级）
属性具备程度–满意度
精益画布
精益画布–商业论证
MMR最小可发布版本
MVP：最小可行性产品（不一定是真是产品）
MMR：最小可发布版本（真实可用，可付钱购买的产品）
莫斯科法则（MoSCoW LAWS）
莫斯科法则：所有必须有的功能构成–最小可发布版本MMR
must have必须有
should have 应该有
could have 可用有
wonont have不该有
产品代办事项列表
- WSJF原则（最短作业有限原则）–优先级
每个功能开发所需要的时间
每耽误带来的延迟代价
WSJF=单位延迟代价/开发所需时长（WSJF越大，优先级越高）
用户故事
作为一个<角色>，我想要<活动>，以便于<商业价值>
用户故事卡片
用户故事地图
项目章程 项目范围说明书
项目章程–>项目范围说明书 ：渐进明细
范围基准
范围基准=wbs+wbs词典+范围工作说明书
WBS 工作分解结构
子项目
控制账户
工作包（WBS最小单元）
规划包（与工作包同层级，目前不确定工期、成本）
活动
任务
WBS分解原则：百分百原则（包含所有需要完成的工作）
- WBS价值：
基准的来源（范围基准、进度基准、成本基准）
计划的基础
工作的表现
控制的依据（范围）
团队的指南
WBS词典
针对每个WBS组件，详细描述可交付成果活动和进度信息的文件。
RAM责任分配矩阵
每个工作包的负责人–唯一
确认范围
每个阶段结束时都需要向客户确认范围，不能等到最后
先进行内部质量控制检查–在向客户确认
范围蔓延
- 范围镀金：主动增加的
- 范围爬行：客户要求增加的
范围蔓延（范围镀金和范围爬行）没有经过整体变更控制流程
敏捷开发中产品需求来源
将需求加到–产品代办事项列表（PO负责收集、排列优先级）
1、团队内部想法、创意
2、用户反馈
第六章 项目进度管理
看板
WIP（在制品）：堆积的半成品
看板系统的精髓是：拉动式生产
看板六大核心实践
1、可视化工作流程
2、限制在制品（WIP）
每个环节设置上限
3、管理和度量流动
即使发现问题、解决问题
4、显式化流程规则
对即将落实的规则展开讨论，并达成一致意见
5、建立反馈环路
例如：每日站会（鼓励成员主动参与、持续改进）
6、协作式改进
洋葱圈规划
敏捷
具有未完项的迭代进度计划–产品代办事项列表
敏捷每个冲刺都从产品代办事项列表中挑选出本次冲刺需要完成的用户故事，完成后进行评审，合格则上线，如果不合格则重新放回产品代办事项列表中。
滚动式开发
滚动式开发：渐进明细
紧前关系绘图法（PDM）
活动的关系
FS（finish-start）
SS（start-start）
FF（finish-finish）
SF（start-finish）
提前量、滞后量
提前量–压缩工期
PDM 前导图
估算资源
学习曲线
成本效益分析
当投入的成本高达一定程度时，还可能存在边际效益递减
资源日历
资源可能同时肩负几个项目
资源直方图
资源随着时间，需要的数量变化
资源过载：具备的可用资源小于需要的资源
活动历时估算
专家判断
专家判断：可能存在偏差
类比估算
参考相似的项目
优点：经济高效
缺点：可能不准
参数估算
知道关键参数就可以进行估算。如果模型成熟，参数准确，参数估算价值大。
三点估算（考试重点）
期望值计算（期望值：概率50%）
标准差
三角分布（简化评估）
正态分布
自下而上的估算
自下而上的估算：可以用于估算项目工期、项目成本
优点：估算精确度高
缺点：周期长成本高
五种估算方法对比
敏捷场景下工期估算
敏捷估算扑克
储备分析
进度储备
项目风险
- 已知风险
- 已知-未知风险（概率、影响中有一个不确定）
预防：备选方案 - 未知-未知风险（未能识别到的风险、发起人不认可的）
应急储备和管理储备
项目进度计划
里程碑计划（关键时间节点）
- 里程碑计划重要用途：
计划：分解为阶段性目标
控制：强制约束，控制各阶段目标实现
沟通：与管理层、干系人良好沟通
横道图（甘特图）
开始时间、结束时间
黑色横道（摘要任务–工作包：包含所有活动）
可以清晰看到当前正在进行的工作，以及当前工作应该完成的工作进度。
缺点：不能体现关键路径、浮动时间
网络图
PMP考试中–单代号网络图比双代号网络图重要
相同项目- 双代号网络图比单代号网络图更简洁
虚工作： 双代号网络图中的虚线
时标网络图
时标网格图=双代号网络图+时间
波浪线代表浮动时间
进度前锋线图
进度前锋线图 与双代号网络图相似
蓝线：当前计划进度
红线：实际完成工作进度
关键路径法（重点）
关键路径决定项目总工期
关键路径所需要的时间最长
关键路径上的浮动时间最少
一个项目可以有多个关键路径
关键路径与技术难易无关
活动延误可能导致关键路径变化
关键路径上的活动工期可以压缩
建议最早开始时间写0
多个紧前关系时，最早开始时间选最大的
多个紧后活动时，最晚结束时间选最小的
总浮动时间最小的为关键路径（关键路径上的浮动时间可能>0、=0、<0）
项目3种浮动时间
- 自由浮动时间：不影响后续工作最早可以开始时间的前提下（不影响其他活动时间），这项工作可以拖延的时间。
- 总浮动时间：不影响项目总工期的前提下，活动可以拖延的总时间。
- 项目浮动时间：项目发起人或高层级领导在总工期上多给出的时间
关键链法（CCM）
路径汇聚前增加接驳缓冲
其他名词（非重点）
帕金森定律： 工作会自动膨胀，占满所有可用时间
学生综合征：作业总会拖到最后完成
墨菲定律：工作全都比你估计的时间要长；越担心的事情越可能发生。
关键路径法 关键链法
关键路径法：把应急储备分配到各个工作包、活动上
关键链法：工作包按照三点估算方法估算工期，有特殊情况再单独分配
资源优化
- 资源平衡：解决某时间段资源过载问题
某类资源在某个时间段紧缺–资源平衡可能会导致工期延长 - 资源平滑：解决资源数量波动问题
利用浮动时间调整，尽量保持资源数量随着时间不会发生巨大变动。一般不会影响项目工期
进度压缩技术
进度压缩技术用在关键路径上才能压缩项目工期
- 快速跟进
成本、质量理论上不会发生变化
缺点：增加后续工作返工风险 - 赶工–增加资源
缺点：会增加成本
燃尽图
第七章 项目成本管理
成本管理重点
成本管理计划（不包含具体成本信息）规定管理成本的方法、规则、单位等
成本的分类
直接成本&间接成本
间接成本：房租、水电、工资、税
直接成本：项目耗材
固定成本&可变成本
固定成本：产线固定设备
可变成本：材料、人工（随着生产数量会增加的成本）
机会成本&沉没成本
机会成本：当有多个可选项目时，放弃方案中最大的潜在收益就是机会成本（前提是具备项目所需要的能力）
沉没成本：项目已投入的成本
全生命周期成本
在规划阶段就要考虑全生命周期（包括运营维护、报废拆除）的所有成本
敏捷场景下的成本管理
最小可用产品（MVP）
确认是否有市场、验证用户真实需求，明确客户最想要的
1、产品介绍视频（例如：dropbox）
2、仿真（例如：网上鞋店zappos、AI开发builder）
3、众筹
4、原型法
5、预售（例如：攒课）
6、访谈
成本估算与预算
- 资金限制平衡
阶段支付
项目预算组成
成本基准（项目完工预算）=工作包成本估算+应急储备
项目预算=成本基准+管理储备
挣值分析（重点）
PV（planned value计划值）=计划单价×计划工作量
AC（actual cost 实际成本）=实际单价×实际工作量
EV（earned value 挣得值）=计划单价×实际工作量
CV（成本偏差）=EV-AC （CV>0成本节约）
SV（进度偏差）=EV-PV （SV>0进度超前）
PV AC EV都是累计值
EV
挣值曲线
挣值曲线（香蕉曲线）：曲线瘦长，最终形成交点是最好的情况
挣值分析–两个指数
成本绩效指数CPI=EV/AC
进度绩效指数SPI=EV/PV
绩效指数：用于比较不同规模项目的绩效；值越接近1越好，大于1比小于1好
挣值分析-完工估算EAC
-
PB（project budget 项目预算）=BAC+管理储备
-
BAC（budget at completion 完工预算）=PMB绩效测量基准=成本基准
-
EAC（estimate at completion 完工估算）：估算时刻 去估计完成整个项目的费用
-
ETC（estimate to completion 完工尚需估算）：从估算时刻开始到最终完成整个项目需要的费用
ETC=EAC-AC
EAC完工估算
EAC=BAC/CPI（成本不纠正：按照当前实际单价一直到完成项目）
EAC=AC+（BAC-EV）（成本纠正：剩余工作按照计划单价完成）
EAC=AC+[（BAC-EV）/（CPI×SPI）] （成本进度都不纠正：成本和进度都按当前状态继续直到完成项目）
TCPI完工尚需指数
TCPI=(BAC-EV)/(BAC-AC)
或
TCPI=(BAC-EV)/(EAC-AC)
VAC(完工偏差)=BAC-EAC
挣值分析的应用难点
获得EV方式
1、计算每个工作包当前完成的百分比
2、50% 50% 法则
3、20% 80%法则
4、0 100% 法则
5、里程碑法
6、容器法、主材消耗法（适用部分行业）
挣得进度
成本估算工具
项目预算
第八章 项目质量管理
本章重点
易混淆概念
- 等级 质量
等级不等于质量 - 精确度 准确度
精确度：样本之间互相距离小
准确度：样本与目标的距离小
质量管理水平 质量管理发展
质量管理水平
质量管理趋势一：客户满意
代表人物：朱兰
质量管理趋势二 ：持续改进–戴明环
代表人物：爱德华戴明
- 6σ–6个标准差
概率>=99.99966%
缺陷率<百万分之3.4
质量管理趋势三：管理层的责任
质量管理趋势四：与供应商持续合作，互利共赢
质量成本 COQ
质量成本：包括为预防质量不合格或纠正不合格（返工等）而发生的成本
质量成本：一致性成本、不一致性成本
一致性成本：预防成本、评估成本–预防质量出现问题的成本
不一致性成本：失败成本（内部、外部）–已经出现质量不合格，为了弥补而产生的成本
克劳斯比（质量应该在设计时就被考虑，而不是靠测试提高质量）
质量矩阵图
流程图
由戴明提出
QA&QC(质量保证&质量控制)
质量保证-过程合规（审计–过程）
质量控制-结果合格
面向X的设计（DFX）
根本原因分析
石川馨
QCC（质量圈子）：跨部门人员讨论质量问题
质量管理7大工具
鱼骨追原因 （出现问题的根本原因）
检查集数据（记录统计缺陷数量）
直方显分布（偏态分布、陡壁分布等可能是某种原因导致）
控制找异常（7点法则、位于控制线以外等异常情况）
帕累托重点（二八法则）
散点看相关（是否与质量存在关系）
层别做解析（人机料法环角度解析缺陷产生的原因）
因果图（鱼骨图、石川图）
鱼骨图–找原因
直方图（柱状图）
存在问题的直方图
散点图
检查表
帕累托图（二八原理）
统计抽样
控制图（重点）
直方图规格线：位于均值左右两侧4倍标准差
控制图控制线：位于均值上下两边3倍标准差
控制图需要停工找原因的三种情况
1、连续7点出现在均值一侧
2、连续7点呈单调上升\下降趋势
3、数据出现在控制线以外（即便在规格线以内也需要停工找原因）
层别法
人、机、料、法、环
例子
控制质量
过程决策程序图
质量管理观念的改变
提升质量成本会减小
质量管理工具
帕累托图：28原则（主要原因）
第九章 项目资源管理
《敏捷宣言》：最好的架构、需求、设计出自 自组织团队
本章学习重点
权利矩阵
项目资源管理
项目资源管理：请、用、育、还（从职能部门邀请技术人员，还需要考虑什么时候释放资源）
项目团队人员专业技术培训–职能经理负责
项目团队人员项目管理相关知识培训–项目经理负责
项目团队人员企业流程、制度–人力资源经理负责
团队章程
团队价值观
沟通指南
决策标准和过程
冲突处理过程
会议指南
团队共识
资源分解结构（RBS）
RACI矩阵
预分派
预分派资源：资源具备无法代替的能力
虚拟团队
由跨地区、跨组织的成员通过通讯和信息技术联结和协同工作的团队
在线协作（微信、腾讯视频等等）
谈判
与职能经理谈判：保障能获得想要的资源且资源能按时到位
与分包商谈判：保障项目保质保量完成
资源获取
能力可以培养，但是人品很难改变（野狗、狗、兔子队友都不能要）
兔子不爱学习
野狗难易控制
塔克曼阶梯理论（重点）
1、塔克曼阶梯各个阶段可能在一个项目中多次出现（例如：进入规范阶段后因为矛盾又回到震荡阶段）
2、塔克曼阶梯各个阶段也不是一定会按顺序发生（已经合作过的团队，再次合作可能不需要形成、震荡阶段直接进入规范阶段）
项目经理管理风格
敏捷中的项目团队
-
有效项目团队
具有共同目标
分工明确，优势互补
喜欢一起工作，互相帮助
凝聚力强，彼此信任
顺畅的沟通，主动分享
顺利达成目标
1+1>2 -
无效项目团队
每个人对目标的理解不一致
职责不清，专业重复或缺位
彼此排斥，单打独斗
冲突和不良竞争
挫折、无谓的返工
沟通障碍，没有效率的会议
1+1<2
团队绩效评价 项目绩效评价
团队绩效评价方法–回顾会议：针对人（团队协作是否高效、沟通是否顺畅、哪些可以改进）
项目绩效评价方法–挣值分析
团队绩效评价–执行过程组
项目绩效评价–监控过程组
团队工作时长与生产力
短期、临时加班有助于提高生产力，但长期加班会导致生产力下降
即便是每天8小时工作时间也不应该全部安排满工作，应该给成员留出思考、改进的时间
团队规模与生产力
敏捷最好的团队规模是5-9人
冲突管理
冲突常常是有益的（良性冲突：对事不对人；恶性冲突：存在人身攻击、侮辱等）
1、促进磨合，增进了解
2、灵感源泉，创新动力
3、暴露问题，降低风险（如果冲突不可调和，则越早暴露越好）
4、加速决策，改进管理（认识到管理中的问题）
war room（作战室、集中办公、紧密矩阵）
冲突解决办法
1、强迫/命令–一赢一输（冲突双发是上下级关系、强弱两方）
2、撤退/回避–双输（问题未解决，先搁置以后再解决）
3、缓和/包容–一赢一输（冲突一方包容、迁就对方）
4、合作/解决–双赢（寻找双方都同意的解决方案）–最好的解决冲突办法
5、妥协/调解–双输（双方各让一步。两方诉求都未完全满足）
情况紧急、事情重要–强迫/命令
情况紧急、事情一般–妥协/协调
情况不紧急、事情重要–合作解决
情况不紧急、事情不重要–撤退/回避、缓和/包容
人员遣散计划
人员遣散计划有助于：
1、控制项目成本
2、提升士气（团队成员明白完成项目后的安排，有安全感、有清晰目标）
3、降低风险（安排工作量合理、紧凑）
常见的人力资源管理理论
X-Y理论
X理论：假设人都是好逸恶劳、不负责任，有利益就抢，有责任就推
Y理论：假设人都是积极上进的、用于承担责任、愿意接受更大的挑战
环境造就人
X理论–适合流水线
Y理论–适合创造性、研发型人才
需求层次理论
双因素理论
保健因素（卫生因素）–必要条件，必须满足（如果不满足就会导致不满意）
激励因素–获得认可、赏识
期望理论
绩效–通过努力可以达到
兑现–完成绩效就要兑现
吸引–满足期望
定性分析：单个风险发生概率及影响
定量分析：对整个项目的影响
塔克曼阶梯理论
团队建设：快速压缩塔克曼理论的时间（成立、震荡）
第十章 项目沟通管理
本章重点
沟通效果
项目沟通效果取决于沟通载体
最好的沟通载体–war room（作战室）
有效沟通：以正确的形式、在正确的时间把信息提供给正确的受众，并且式信息产生正确的影响
项目经理通常70%-95%时间放在沟通上
规划沟通管理
沟通方式
垂直沟通–上下级
水平沟通–平级
乔哈里窗
乔哈里窗–改善沟通
适当开放隐秘区，开放区就会变大，未知区会越来越小
书面沟通的5C原则
1、正确的语法和拼写
2、简洁的表述和无多余字（通俗、直观、形象）
3、清楚的目的和表达（适合读者需要）
4、连贯的思维逻辑
5、受控的语句和想法承接
规划沟通管理需要考虑的要素、沟通模型
- 规划沟通要考虑的因素
- 沟通模型
- 沟通漏斗
解决沟通漏斗问题–反馈（双向沟通）
沟通路径
两个人直接就有一条沟通路径
过滤
过滤：指大量信息在自上而下或自下而上的沟通过程中损失掉的现象
扁平化模式可以减少过滤情况
影响沟通的9大障碍
1、信息过载
2、缺少知识
3、文化差异（国家文化差异）
4、分散注意力的环境因素
5、有害的态度
6、情绪
7、不懂专业或技术术语
8、沟通渠道过多
9、选择性认知（表扬、批评；沟通中多说鼓励的话）
沟通障碍的原因
沟通技术
1、简化运用语言（考虑对方感受，书面沟通与口头沟通差异，言简意赅）
2、视觉辅助手段
3、积极倾听（不要轻易打断对方讲话）
4、有效的反馈
5、情绪控制
沟通方式
交互式沟通
推式沟通（群发邮件、群发短信）
拉式沟通（下载、订阅）
会议管理的学问
需要参加会议的人：必须在会议上发言的、做决策的人、承担责任的人
会议决议形成闭环（明确负责人）
第十一章 项目风险管理
项目风险管理重点
风险属性：概率、影响（有利影响、不利影响）
变异性风险（黑天鹅事件）：异于常理，罕见新事物–剧情反转、屌丝逆袭等等
模糊性风险：不了解需求、趋势不知道、规律不清楚、未来不清楚
提高项目韧性以应对风险。项目韧性：项目遭遇风险或受到扰动时 维持状态的能力、迅速恢复的能力，通过适应来更好地应对未来不确定性的能力。
整合式风险管理
具体项目风险–项目经理负责
项目集风险–项目集经理负责 （项目集：多个相关项目）
项目组合风险–项目组合经理负责 （项目组合：一类的项目）
项目风险分类
已知风险
未知风险：已知-未知风险、未知-未知风险
内部风险
外部风险（例如：通货膨胀、国家政策法律）
商业风险（做生意可能挣钱可能亏。保险公司不会承担的风险）
可保险风险（通过买保险转移要承担的风险。例如：地震等自然灾害保险）
风险分解结构（RBS）
风险–人--活动（工作包）
相关方对风险的态度
风险临界值–相关方对风险的态度取决于：风险承受力、偏好（有人喜欢冒险）
识别风险的工具、技术
头脑风暴
头脑风暴：包容；鼓励所有人积极参与（记录所有的想法）
德尔菲技术
多次收集、修改专家单独填写的意见
根本原因分析
核对单分析
整理所有可能的风险清单
假设分析
造成结果可能存在多种原因，两两比较，最终选出最可能的原因
鱼骨图
系统流程图
专家判断
注意专家的偏见（–利用德尔菲技术消除偏见的影响）
重视专家的直觉
假设条件、制约因素
制约因素：已经确定，客观存在（放宽制约因素，就能带来机会）
假设条件：（收紧假设条件就会暴露风险）
SWOT分析
优势、劣势、机会、威胁
提示风险–单个风险
RBS风险分解
战略框架–整体项目
PESTLF
政治、政策
经济
社会
技术
法律
环境
TECOP
技术
环境
贸易
运营
政策
VUCA
多变的
不确定的
复杂的
模棱两可
层级图（气泡图）
风险间的关系
风险概率和影响定义
影响间距不是等间距
下图：影响较小的区域–细分；影响大的区域–不用细分
深灰色部分应该重点关注，放在风险短名单中，需要有详细的应对措施
其他的放在风险观察清单，每次例会要重新评估、核对，必须有详细应对方案
风险定量分析
风险定量分析：针对某个风向，分析其对项目的影响
模拟
蒙特卡洛技术
计算机产生随机数产生风险组合，进而计算出成本–完成概率关系（工期–完成概率）
敏感性分析（龙卷风技术）
NPV排序
决策树
EMV（预期货币价值）
影响图
线条连接–风险间联系，线条粗细–影响关系强弱
形状–不同类型风险
应对风险工具
应急计划（plan B）
弹回计划（保底计划）
权变措施–随机应变、临时
风险与资源
自动权变：不需要汇报（先斩后奏）
自动权变适用情况：
1、人命关天
2、有充足的理由证明来不及请示回报
应急计划、弹回计划、权变措施–整体变更控制流程
没有其他办法才会启动弹回计划
风险应对策略
规避–负面风险
选择其他方式
转移
保险、外包
减轻
1、降低风险发生可能性
2、降低影响程度
例子：流感–流感疫苗、口罩
分享 --正面风险
能力、资源有限，与其他人合作
开拓
提高
接受–正面、负面
上报
超出项目经理能力范围（项目经理只负责能力范围内的）
风险应对策略选择
与上图内容相同
风险相关概念
蒙特卡洛分析
权变措施：应对未知风险发生（权变措施–变更），紧急变更可以先解决再提交CCB
第十二章 项目采购管理
采购管理重点
- 国际标准采购合同范本
1、FIDIC：国际咨询工程师联合会
2、AIA：美国建筑师协会
3、world bank：世界银行
敏捷场景下的采购管理
通过**主要服务协议(MSA)**来管辖整体协作关系，用附录或补充文件记录适应型的工作内容。
采购合同类型
总价类
1、固定总价合同（FFP）或称 总价包死合同
项目不会有大的变化
2、总价加激励费合同（FPIF）
成本按预算控制另加约定费用，如果成本超支或节约，按约定的比例分担或共享，并设置天花板价格。
高于天花板价格，就只支付天花板价格
3、总价加经济价格调整（FP-EPA）
适用于：项目时间较长的
合同总价可以根据物价变动等因素调整。
成本类
1、成本+固定费（CPFF）
成本实报实销，按约定的固定数额支付费用
2、成本+激励费（CPIF）
成本按预算控制另加约定费用，如成本超支或节约，按约定的比例分担或共享。
没有天花板限制
3、成本+奖励费
成本实报实销，甲方根据乙方表现给予奖励。
–激励费用可以以成本、时间、质量等作为激励依据
工料合同
适用于：项目范围不会太大，项目范围不会有大变动。但是当前无法预测需要使用的工料情况
合同类型与风险分担
招标文件
信息邀请书（RFI）
信息邀请书：买方需要卖方提供拟采购货物和服务等信息。
报价邀请书（RFQ）
报价邀请书：买方需要卖方提供关于满足需求需要多少成本
建议邀请书（RFP）
建议邀请书：买方需要卖方提供完整的解决方案。
（采购）工作说明书（SOW）
工作说明书：根据项目范围基准，详细描述拟采购的产品、服务或成果。说明需要干什么、工作范围、工作性质
工作大纲（TOR）
工作大纲包括：
承包商要执行的任务，以及需要协调的工作。
承包商必须达到的适应标准。
需要提交批准报告和数据等。
采购交付方法
DDB-设计 招标 建造
甲方需要承担大量协调工作
总承包模式（EPC）–设计 采购 建造
特许经营–甲方是政府
- BOT（建设-运营-移交）
运营权–建设方具备一段时间的运营权 - BT（建设-移交）
运营权–政府 - PPP（public-private-partnership）
政府与合作单位均投入资金，共同承担风险
自制-外购分析
供方选择分析
独立估算
标底价（保密）
拦标价（公开）：在标底价基础上增加一定比例
招标会议
- 投标人会议
声明甲方招标的合规、合法、有效，免除不必要责任 - 采购人谈判
（仅甲方与中标方参与）在合同签署前，对合同内容加以澄清，以取得一致意见。包括责任、变更权限、使用的条款和法律、技术和商务要求、所有权、合同融资、技术解决方案、总体进度计划、付款及价格等。
不在采购人谈判会议内容的：中标价格、交付期限、质量验收标准、工作范围
索赔管理
有助于甲乙双方慎重、严谨对待合同的每个条款，
争议管理
采购管理责任
项目收尾
租赁 购买分析
沟通与相关方分析
第十三章 项目相关方管理
谁是你的相关方？
他们有什么期望？
他们的影响有多大？
怎么调动他们的积极性？
如何与他们沟通？
怎么解决利益冲突？
相关方分析
相关方类型
参与项目的人
收项目影响的人（正面影响、负面影响）
权利利益矩阵
- 相关方影响力
0（无） 1（弱） 2（中） 3（强） 4（极强） - 相关方态度
-2（坚决抵制） -1（反对） 0（中立） 1（支持） 2（积极推动）
相关方立方体
权利–态度–利益
凸显模型
权力、紧迫性、合法性
凸显：需要及时
蓝色：代表以满足条件
灰色：如果被授予相应的权限则满足条件
整合资源（利用支持者影响反对者）
相关方登记册
相关方参与程度评估矩阵（当前相关方状态、期望相关方状态）
管理相关方
相关方登记册–的输入是–协议
敏捷
PMP考试中敏捷特点
1、题目场景50%是预测型，50%是由混合型和纯敏捷型组成
2、题目首先需要判断出题目场景，需要了解不同场景的特点和关键词
3、混合型场景下不同角色的职责和定位（PM、PO、SM、开发团队）
4、混合型和敏捷场景下团队特点和PM领导风格
5、敏捷里的名词概念需要理解
Stacey矩阵
敏捷洋葱圈
敏捷软件开发宣言
我们一直在实践中探寻更好地软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
使用敏捷 不等于 快
敏捷–适应型
敏捷原则
1、我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。
（业务人员、开发人员、客户对需求理解一致）
5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
（团队：协调、矩阵、项目制）
6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7、可工作的软件是进度的首要度量标准。
（只区分完成、未完成，不论完成多少只要没有全部完成就视为未完成）
（百分比方式–很可能会影响进度）
8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
–（工作时间增加不会增加产出）通过提高效率提高产出，敏捷不鼓励加班。
9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10、以简洁为本，它是极力减少不必要工作量的艺术。
11、最好的架构、需求和设计出自自组织团队。
–自组织团队：拥有共同价值观、工作习惯。没有领导，彼此间不一定在一起工作。
12、团队定期地反思如何能提高成效，并依此调整自身的行为表现。
–回顾行为（短反馈）
敏捷生态：敏捷采购…
scrum体系
敏捷实践：精益管理、看板…
scrum体系：产品代办事项列表、迭代代办事项列表、迭代、交付物
3355
3个角色
一、PO（Product Owner）–产品负责人、产品所有者
客户代表
定义所有产品功能
决定产品发布的内容及日期
对产品的投入产出负责
根据市场变化对需要开发的功能排列优先顺序
合理的调整产品功能和迭代顺序
认同或者拒绝迭代的交付
确保开发团队制定产品待办事项列表
二、SM（Scrum Master，Scrum教练或者Scrum大师）
SM与项目经理比较：
项目早期SM和PM相对统一（制定规则、管理期望、管理相关方、制定沟通策略、管理承诺等）
项目执行起来则SM 和 PM进行切割（SM不做决策，相信团队做的决策）
鼓励言论自由（实现方案、需求等提出自己的想法）
保证仪式（5种仪式活动）
团队有问题，优先内部解决讨论
保护团队一个整体
三、Dev team（开发团队–所有参与到项目工作中的人）
自主选择（自己选择要做的事情）
全职能（开发人员具备测试能力）
跨团队本身不进行解决（发现团队外部问题时，把团队外人员邀请到团队内进行解决）
决策在团队内
平级
典型团队通常为5-9个人
跨职能团队，囊括了开发人员、测试人员、业务分析师等开发最终软件所必需的角色
团队成员应该是全职的。也可能有特殊情况 (例如, 数据库管理员DBA等兼职)
保持纪律，遵守承诺，按时交付软件成果
自组织、自管理的团队
3种工件
一、产品待办事项列表（product backlog）–排好序的需求池
产品需求列表
包括业务需求、技术需求、NFR（非功能性需求）等（还包括培训、学习等）
理想情况下，每一个待完成的工作都将对客户产生价值
PO对该列表进行优先级排序
每个迭代开始前，优先级排序还需要再度修正
待办事项列表中的条目以用户故事形式呈现
产品Blacklog是Scrum中的核心工件，它是对整个产品的功能描述，所有功能描述都是有顺序的排列，团队依照优先排列顺序进行工作。
它是产品需求的唯一来源，开发团队所有工作都来自产品Backlog。
产品Blacklog由产品负责人创建和维护。
产品Blacklog贯穿于整个项目的生命周期。
产品Blacklog是一个有顺序的列表。
产品待办事项列表特点
适当的详细程度
被估算的--由PO、SM进行估算当前迭代需要放入多少需求。做多少由团队决定
涌现的--会有新的变化出现
排了优先级的
二、迭代待办事项列表（sprint backlog）–迭代完成的需求列表
一个迭代中团队只做迭代待办事项列表中的内容，新增加的需求需要添加到产品待办事项列表中
产品待办事项列表的子集，只记录当前迭代的工作
将用户故事拆分成任务，团队成员主动领取任务
团队成员有共同的迭代目标，为可交付工作的成果而努力
团队成员可以添加、删减或者更改迭代中的任务
迭代列表中的任务进行估算，剩余工作量的估计 每天更新----燃尽图
三、产品增量（product increment）–交付物
团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付
每次交付的用户故事必须符合验收条件
每次交付的增量成果必须处于可用状态，而不管PO是否发布这个用户故事（交付和上线）
5种仪式（5种活动）
一、待办事项梳理会（产品梳理会）–不包含在5种活动中
PO、Dev team必须参与
识别依赖
识别风险
识别架构
相对估算：没有相对固定的时间，与基线相比较
绝对估算：使用三点估算等方法确定时间
敏捷中优先级以价值划分
优先级-MoSCow技术（60% must have、20% should have、20% could have）
优先级–kano（基于用户兴奋点、满意度排列优先级）
优先级–权重分析
敏捷中的计划
发布燃尽图、 条形燃尽图、累计流量图用于敏捷发布计划
发布燃尽图–针对项目（横坐标是迭代）
燃尽图（横坐标是日期）
条形燃尽图–（0点以下的工作代表初始未识别到后来增加的）
累计流量图
累计流量图可以看到当天甬道内的任务数
前置时间（Avg.Lead Time）：任务从制造到完成的时间
利特尔法则-PMP中不考
MVP-三个最小（最小可交付价值、最小可售单元、最小可行性产品）
产品愿景–电梯演讲（elevator pitch）
电梯演讲–用户画像–用户故事–用户故事地图（离发布越近的故事越详细，越远的越粗糙）
二、迭代计划会（规划会议）
1、确认做什么–做承诺
2、确认怎么做–拆任务
两周的迭代，2个小时选择故事，2小时估算分配（任务级估算）
1个月的迭代，4小时选择故事，4小时估算分配
输入：梳理会–>迭代计划会–>输出：燃尽图
团队速率
固定时间内团队完成任务的规模
通常是单次迭代
团队速率不是越大越好，而是越稳定越好
跨团队比较不成立，但可以跨迭代比较，前提是统一基准
DOD（完成的定义）
核心就是做到什么样就是完成了
可以通过流程或者本身交付物进行限定
探测（刺探 spike）
敏捷中使用的一种技术，一般情况下只用来判断可行性的，所有不确定的地方：风险、技术、商业模式等
三、每日站会
每日站会是用来做每日承诺的，而不是讨论会。（说明已完成、计划完成、遇到的问题）
必须参与人员：Dev team、SM、PO；
其他人员可以参与，但是不具备发言权
每日站会–>输出：燃尽图、燃气图
四、迭代评审会
和外部交互的会议
原则上是计划会议时间的一半
这个活动输出的是一份修订的产品待办事项列表、可交付的软件
这个活动在迭代的倒数第二位执行
这是为了和利益相关方的步调一致（让利益方尽早参与到项目中）
五、产品回顾会
除站会外时间最短的活动（15min-30min）
产品回顾会在迭代最后执行
活动书上写的参与人员：PO、SM、Dev team、企业利益相关者整个团队。但是建议只有Dev team和SM参与
产品回顾会：代码评审、整个过程评审（问题等）、制定行动项
六、迭代
5种价值观
勇气
开放（信息尽可能公开）
专注
承诺
尊重
适应型项目–敏捷
预测型项目
精益与kanban体系
看板
区分看板和kanban系统
看板是用来展示透明的，对于管理干系人的希望有促进
燃尽图、燃起图、看板或任务板、风险看板等
kanban系统（起源于丰田）
kanban系统是体系化的
1、工作流程可视化
2、限制在制品数量（WIP）（优化瓶颈，不进行全局优化）
3、度量和管理流动
4、显示化规则
5、建立反馈环路（按需开评审会、回顾会）
6、在协助及实验中改进
kanban没有时间箱概念
极限编程
极限编程重点实践：持续集成、TDD（测试驱动开发）、结对编程（空间上、物理上（使用同台设备）两个人干同一件事）
结对编程 适用场景：老带新、技能复制（团队多个人具备同一技能）、攻艰
代码集体所有权、小型发布
持续集成
- CI的工作流程
提交代码到代码库
CI server 监听代码库的变更
CI server处罚自动化构建
CI server处罚自动化测试
通知相关方
好处：1、减少代码冲突 2、对交付有基本把控
团队管理
敏捷变更： 迭代内部不做变更，迭代完成进入下一个迭代前可以变更人员、需求、环境、计划等
体系总结
其他
项目目标SMART原则
四种生命周期
固定搭配
通知–相关方
变更请求–评估影响
书面报告–CCB
敏捷
敏捷项目章程
敏捷特征
小步快跑（冲刺周期短）
高效反馈
保持节奏
价值交付
敏捷3355
SM敏捷教练:引导（相当于项目经理）核心工作是消除障碍（仆人式领导）
PO（必不可少）：创建代办列表并排序、确定工作优先顺序、提供反馈、指导开发方向（排优先级、面对客户）
敏捷112原则
仆人式领导：培养和发展团队成员，帮助他们超越当前的角色，即使团队将失去他们也在所不惜； 帮助团队
项目愿景
敏捷发布规划过程
传统与敏捷（合同技术）
错题知识点总结
发现问题 如果避免/将来避免
发现问题–>分析影响–>采取解决措施
德尔菲技术
德尔菲技术：专家匿名参与
2056
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
