五大过程组
五大过程组：启动 规划 执行 监控 收尾（启规执监收）
十大知识领域：整合管理 范围管理 进度管理 成本管理 质量管理 资源管理 沟通管理 风险管理 采购管理 干系人管理（整范进成质 资沟风采干）
三大基准：范围 进度 成本
项目
项目：单个项目 具有独特性（项目有不确定性和风险） 临时性（明确的起止时间）渐进明细（滚动式规划）
项目集：统一协调管理 相互关联有
依赖关系项目 获得额外的收益
项目组合管理：基于战略选择项目 给项目集排列优先级 再根据项目的优先级来分配资源
项目开发生命周期/开发方法
预测型：瀑布型生命周期 需要在项目早期花费大量时间来计划 按计划驱动项目
迭代型：原型确认或者是概念验证
增量型：渐进地增加产品功能
适应型：敏捷方法、变更驱动型生命周期 每个迭代都能够完成一定的产品增量 通过每次发布来交付价值
混合型：包含迭代型和增量型 开发过程使用敏捷 但是最后一次性交付
（如果组织要转型 从预测 型向敏捷转型过程中 使用混合型作为过渡）
项目商业文件
在项目启动之前产生 并不是项目经理或项目团队编写 由发起人提供 后续如果需要更新商业论证 一定是由发起人来完成 项目经理可 以针对商业论证的内容提供建议
事业环境因素和组织过程资产
事业环境因素：（组织内、组织外 有限制性） 如政府、行业协会、公司的管理层 是用来遵守的 被动接受
组织过程资产：（组织内）历史项目团队及项目相关部门 是用来使用和借鉴的 主动参与更新维护
项目管理办公室
PMO（项目管理办公室）：是一个组织级的常设部门
提供组织内的项目管理流程和制度 编制项目中使用的各种模板和表格 也可以对项目进行 审计 还可以称为项目的发起人
PMO＞PM
分类：支持型、控制型、指令型
组织结构
- 职能型：无全职 PM 兼职 几乎没有权力 团队成员唯一的领导 FM（PM充当联络员 ）
- 矩阵型：双重领导/汇报 团队成员有俩领导——FM 和 PM
- 弱矩阵：PM＜FM 无全职 PM 兼职（PM充当协调员）
- 均衡矩阵：PM=FM PM 的直属领导还是 FM
- 强矩阵：PM＞FM 全职 PM 和团队成员 PM 可以掌控资源和预算 默认都是采用强矩阵型组织
- 项目型：无 FM 团队成员唯一的领导 PM
项目经理 领导力风格
- 放任型：一般成熟的团队使用
- 交易型：为了让团队成员更好的完成工作
- 服务型：仆人式 适用于敏捷团队
（如果通过题干的描述确定没有明确指向性的 一般也可以考虑选择交易型）
PMI人才三角
旧版：技术项目管理、领导力、战略和商务管理
新版：工作方式、商业敏锐度、影响力技能
项目干系人
能影响项目、受项目影响、自认为受项目影响
项目发起人
乙方的高层领导
1、给项目提供资金和资源
2、批准项目的开始和结束
3、验收项目的可交付成果
4、帮助项目经理解决超出项目经理权力范围的事情
5、商业论证提供和更新、项目章程的更新 项目 目标的澄清
制定项目章程
正常情况下 制定项目章程工作应该由发起人来做 需要发起人编写并发布项目章程 （发起人也可以授权项目经理代为编写）
（如果发起人不提供项目章程 要求项目经理开始项目工作 项目经理应与发起人沟通 强调项目章 程的重要性）
项目章程作用：
- 标志着项目的正式开始/启动
- 任命项目经理
- 授权项目经理使 用组织内的资源
项目章程内容
项目章程是一份正式文件，它定义了项目的目标，范围，时间，成本，风险等关键因素
1.项目目的：明确项目的背景、目标和理由，使相关方对项目有一个基本的了解。
2.项目范围：定义项目的边界和范围，以及需要实现的工作内容和交付成果，帮助团队明确任务的范围和方向，核心工作内容。
3.项目时间：明确项目的开始和结束时间，各项重要活动的时间节点和进度计划，为团队及管理层监控项目进展提供依据。
4.项目预算：定义项目的开支预算，包括人力资源、物资采购、运输和设备等费用支出的详细预算计划。
5.关键风险：识别和分析项目的关键风险，以及应对措施计划，帮助团队了解潜在的关键风险和挑战，并提前做好应对计划。
商业论证：是否值得投资
项目章程：项目目标
项目管理计划：计划怎么做
项目文件：记录做了什么
项目启动会和项目开工会议的区别
项目启动会和项目开工会议（也叫开踢会）召开时间不同 目的和任务也不同
启动会：召开时间为启动阶段结束 规划阶段开始前
目的和任务
1、发布批准的项目章程
2、任命项目经理
3、授权项目经理动用组织资源的权利
开工会：召开时间为规划阶段结束 执行阶段开始前
1、项目团队成员互相认识
2、介绍项目背景及计划
3、发布批准的项目管理计划
4、上下级互相承诺、达成共识
如果有关键干系人无法出席某个会议，PM 应该怎么做？
1、 启动会/开踢会 在会前沟通 获得支持和承诺
2、 某个特殊的会议 在会前沟通 获得该干系人的想法
3、 其他状态会议 在会后发布会议纪要
制定项目管理计划
项目经理带领项目团队编写项目管理计划
关键干系人审批项目管理计划
项目管理计划：
10 个子计划：范围、进度、成本、质量、资源、沟通、风险、采购、干系人
3 个基准：范围、进度、成本
其他组件：项目生命周期（阶段是如何划分的）、开发方法（采用预测型、适应型还是 混合型）、变更管理计划
管理项目知识
显性知识：使用文字、图片和数字进行编撰知识隐性知识：个体知识以及难以明确表达的知识 如信念、洞察力、经验和诀窍
两个误解：
知识只是记录下来用于分享→使用
经验教训只是在项目收尾时做→在整个项目过程中持续去做
(
经验教训总结或知识管理的工作需要所有干系人参与)
经验教训登记册：实际上项目开始之后该文档即可存在 并在产生经验教训后马上更新
在项目或阶段收尾时 将相关内容存储到 OPA 中的经验教训知识库
知识转移→OPA 更新 （知识分享相互培训）
实施整体变更控制
只有经批准的变更请求才可以实施
变更控制委员会（CCB）：项目干系人组成 PM 也是 CCB 成员
PM→基准内 紧急变更
CCB→改基准 重大变更
一种是干系人有新需求，先提变更后分析
一种是团队管理绩效的偏差，先分析后提变更
将变更请求提交给 CCB，通常应该在项目团队分析变更造成的影响之后去做。
也可以简单理解为，存在两个提交，一个是由变更申请人将变更请求提交项目经理/项目团 队，另外一个就是项目团队将变更请求和影响提交给 CCB
提交给团队→团队分析影响→提交给 CCB
变更管理流程步骤
- 了解变更（获取书面变更请求）
- 评估影响
- 准备处理方案
- 通知干系人
- 批准或拒绝
- 更新计划/基准/项目文件
- 通知受影响的干系人
- 跟踪变更实施情况
需求跟踪矩阵
考试：在确认范围正式验收时 项目团队确认已经按范围 进度和成本交付 可是客户不满意
这时 可以审查需求跟踪矩阵
范围蔓延和镀金
既成事实，发现时工 作已完成
范围蔓延包含镀金
范围蔓延：团队外的干系人主动
1、 如何解决？补变更
2、 如何避免？严格执行变更管理计划/变更控制系统
镀金：团队成员主动
如何解决？
1、 确认镀金是否存在
2、 确认镀金的影响
3、 补变更
镀金
往往是项目人员为了"讨好"客户而做的不解决实际问题、没有应用价值的项目活动
范围蔓延
是指未得到控制的变更，常表现为在未分析对进度、成本、质量和资源等的影响下或未得到关键干系人批准的情况下添加产品的功能和特性
“范围蔓延”指项目范围没有很好的控制 项目工作范围超出了项目立项时的范围
项目应该是“满足要求”与“适合使用” 不论镀金还是蔓延 都应该在项目过程中严格禁止
结束项目或阶段
根据项目管理计划，来确定项目工作是否按计划完成
提前终止的流程：
1、 记录提前终止的原因（通常是基于发起人的正式决策进行的）；
2、 验收并移交已完成的可交付成果；
3、 经验教训总结并存档；
4、 解散团队释放资源
正常收尾流程
1.制定收尾程序
2.完成采购合同收尾
3.确认项目工作完成 符合要求
4.确认已获得产品的验收并移交
5.最终绩效报告
6.更新项目记录
7.更新经验教训存档
8.庆功会
9.解散团队
收集需求
所有干系人参与，收集到全部的需求
工具：
头脑风暴：大量创意
焦点小组：期望和态度，干系人是同一立场
访谈：更深入
标杆对照：最佳实践
引导：跨职能，有助于达成一致；联合应用开发、质量功能部署（展开）、用户故事
亲和图：分组分类
名义小组：投票排序
多标准决策分析：排序
问卷调查：人多、地理位置分散
原型法：
系统交互图
投票：
一致同意
大多数原则：2 选 1，选择超过 50%
相对多数原则：3/多选 1，选择相对最多，但是可能不足 50%
(
在正式验收时，项目符合要求，但是客户仍然不满意，需要查看需求跟踪矩阵)
创建 WBS
项目可交付成果和项目工作→更小的更易于管理的组件→工作包
WBS 定义了项目的全部范围
工作包是最底层
滚动式规划：规划包→暂时不需要做的工作，暂时也不需要详细的分解
输出：
范围基准=WBS+WBS 词典+项目范围说明书，需要关键干系人的审批批准
1.WBS定义：
WBS，即工作分解结构(work break-downstructure)是以项目的可交付结果为导向而对项目任务进行的分组，它把项目整体任务分解成较小的、易于管理和控制的工作单元
一个完整的WBS包括四个部分：WBS元素、工作包、结构化编码以及WBS词典。
WBS可以用多种方式来表示，包括：图表、文本、表格形式。
工作包 (Work package) ：WBS是有层次的，一般分为4~6层。最底层的项目单元，是工作包。每个工作包的工作量应介于一个人工作8小时至80小时之间，也就是每个工作包，工作量可对应1到10个人日不等。
估算活动持续时间
工具：
类比估算
：早期/启动/开始使用 需要使用历史信息 好处就是快 缺点就是可能不准 "过去类似”
参数估算
：需要使用历史信息 单位数据值 统计方法
三点估算
：来源于计划评审技术（pert 分析），考虑了风险的影响最悲观、最可能、最乐观
三角分布：(P+M+O)/3
贝塔分布：（P+4M+O）/6
标准差=(P-O)/6
±1→68.26%
±2→95.46%
±3→99.73%
自下而上估算：
最准确的 需要有详细的信息
储备分析：
- 应急储备：基准内，已知-未知风险
- 管理储备：基准外，未知-未知风险
什么是应急储备和管理储备?
1、应急储备是包含在成本基准内的一部分预算，用来应对已经接受的已识别风险，以及已经制订应急或减轻措施的已识别风险。应急储备通常是预算的一部分。
2、管理储备用来应对项目范围中不可预见的工作、“未知一未知”风险。管理储备不包括在成本基准中，但属于项目总预算和资金需求的一部分，使用前需得到高层审批。
专家判断：适用于发起人不相信、不懂的领域的场景
制定进度计划
- 关键路径法
- 关键路径是在进度网络图中最长的一条或几条路径
- 决定了项目的最短工期
- 关键路径法不考虑资源限制 默认资源无限供应
- 通常关键路径上的活动总浮动时间和自由浮动时间都是 0
- 关键路径上的活动总浮动时间也可以是正或者是负
- 关键路径越多，风险越大
（在考试中，如果某路径 TF=0，就可以直接判断，该路径是关键路径）
正推/逆推
TF：在不延误项目工期的情况下 活动可以推迟的时间量
FF：在不延误紧后活动的最早开始时间的情况下 活动可以推迟的时间量
非关键路径 非关键路径汇聚到关键路径前的那一个活动
资源优化：
- 资源平衡：改变关键路劲 通常是导致变长
- 资源平滑：不改变关键路径 在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、总价加经济价格调控合同：适用于履约期较长（数年），对通货膨胀，材料价格等外部条件无法准确预测的情况。
成本类合同
4、成本加固定费用合同：成本实报实销，项目的不确定性由甲方承担。适用于前期无法判断项目是否成功，更无法估算项目成本的项目，如创新研发类项目。
5、成本加激励费用合同：成本按预算控制另加约定费用。例如，成本超支或节约，按约定的比例分担或分享。
6、成本加奖励费用合同：成本实报实销，奖励数额完全由甲方主管判断决定，一般不允许申诉。
工料类
7、工料合同：按实际消耗的工时和材料支付费用，适用于工作内容明确，但工作量不容易准确评估的项目。
项目干系人管理
干系人：影响、受影响，自认为受影响
发起人：给项目提供资金/资源；批准项目开始和结束；验收项目可交付成果；帮助项目经
理解决超出项目经理权力范围的事
敏捷方法
3个角色：
- 产品负责人PO（Product Onwer）
- 开发团队DT （Develop Team）
- 敏捷教练SM（Scrum Master）
3个工件：
- 产品待办列表（Product Backlog）
- 迭代冲刺列表（SprintBacklog）
- 产品增量（Increment）
5个事件：
- Sprint（Sprint本身是一个事件，包括了如下4个事件）
- Sprint计划会议（Sprint Planning Meeting）
- 每日站会（Daily Scrum Meeting）
- Sprint评审会议（Sprint Review Meeting）
- Sprint回顾会议（Sprint Retrospective Meeting）
4大价值观：
- 个体和互动 高于流程和工具
- 工作的软件 高于详尽的文档
- 客户合作 高于合同谈判
- 响应变化 高于遵循计划
自组织团队：服务型领导/仆人式领导
响应变化：自适应性
敏捷项目，进度和成本固定（工作量固定），范围/功能可调
敏捷团队：100%全职，集中办公
PO：产品负责人，产品拥有者，确定产品开发方向，编制和维护产品待办事项列表，确定 发布目标/发布计划/迭代目标，创建产品路线图，审批新需求的变更，在迭代评审会议上对 于产品增量给出通过验收/拒绝通过验收的决策
PM/SM：项目经理/敏捷教练/scrum 主管/团队促进者/团队领导/团队负责人/项目负责人/团 队教练，通常情况下，项目经理和敏捷教练是一个人。但是在混合型生命周期下有可能出现 项目经理和敏捷教练是俩人。
服务型领导：引导、指导和辅导，创建环境，解决障碍，帮助团队成长（允许团队成员在迭 代过程中学习与本项目无关的知识或技能） 在项目工作中一定不会直接给决策也不会直接给建议
DT：跨职能团队，自组织团队，3~9 人/5~9 人，不超过 10 人。通才型专家/T 型人才，也 可以通过项目工作成长为通才型专家，编写和维护迭代待办事项列表，确定在当前迭代完成 哪些用户故事以及如何完成这些用户故事 团队成员想自由切换团队，这是不被允许的
敏捷工作区：公共区域/私密区域
分布式团队最佳实践：追逐太阳式的开发、鱼缸窗口、远程结对
看板：使工作过程可视化、限制在制品、管理工作流动（发现瓶颈并解决，蜂拥模式/而上）
XP：重构、结对编程、计划扑克、持续集成
技术债务
史诗故事→特性/功能→用户故事
- MoSCoW 模型：
- Must do→必须有→发布 1
- Should do→应该有→发布 2
- Could do→可以有→发布 3
- Won’t do→没有
相对估算：估算故事点数/理想天
以项目中最小的故事的故事点数设为 1，然后用其他故事与该故事对比，确定具体数字
所以不同的团队，不能去比较故事点数/速度
亲和估计：T 恤估算 亲和估算是预测工作量的一个方法
计划扑克：具体步骤要记住，斐波那切数列，宽带/频德尔菲技术
（计划扑克是基于宽带德尔菲估算技能 是以共识为基础的工作量估算技能
有时候也称为敏捷扑克 往往在故事点和开发用户故事中用来估算相对工作量）
1) PO 叙述故事
2) DT 提问
3) DT 思考之后选定一张牌
4) 同时举牌
5) 如不一致，最大和最小的人分享
6) 再重复 3-5，直到达成一致
所有的敏捷项目都使用 测试驱动开发模式敏捷就是一个不断试错的过程敏捷是靠经验开发产品待办事项→用户故事产品待办事项列表→记录故事的那个工件敏捷项目中信息传递都是采用信息发射源（大型图表，张贴在墙上），低科技高触感常见的信息发射源：迭代燃尽图、迭代燃起图、风险燃尽图、累积流量图（看板）预测型的沟通靠汇报（不公开不透明），敏捷的沟通靠信息发射源（公开透明）敏捷项目中，问题记录在停车场区，风险记录在风险板，障碍记录在障碍板敏捷项目的风险管理：把风险看成是负价值。从第一次迭代计划会议开始，每一个会议都会做风险的识别和管理的工作风险应对措施记录在风险调整待办事项列表中
风险解决的顺序：
- 风险大，价值大→首先做
- 风险小，价值大→其次做
- 风险小，价值小→最后做
- 风险大，价值小→不予处理
Scrum 会议(5 个仪式)
① 冲刺计划会议：Scrum 团队的所有成员出席，在此次会议中,
开发团队识别当前冲刺开发交付的产品待办事项中的故事。
时间箱为：一个月的冲刺，会议时间 8 小时，4 个小时用于选择故事和 4 个小时估算分配。
② 每日站立会议：
由 Scrum Master 和开发团队参加,产品负责人可以自行选择是否参加。用来分享迭代或迭代进展。
“昨天做什么?” “今天将做什么?”“遇到了什么问题?“
时间箱 15 分钟,每天发生在同一时间和地点。
③ 冲刺评审会议：（review）
由 Scrum 团队的所有成员参加。开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人。
Sprint 评审会议的结果是
一份修订的产品待办列表，确定很可能进入下个 Sprint 的产品待办列表项。
时间箱为一个月的迭代，4 个小时，比冲刺计划会议的持续时间更短。
④ 冲刺回顾会议：（retrospective）
由 Scrum 团队的所有成员参加。是对整个迭代进行回顾。细节包括：什么进行顺利，缺少什么，需要改变什么等等。团队就未来的迭代改进计划达成一致。这个会议时间框为一个月的迭代，3 个小时，比迭代评审时间短。
⑤ 待办事项梳理(Grooming)
Scrum 团队在冲刺中经常会面进行待办事项的梳理。
梳理或细分是一种逐步完善待办事项的方法，所以它会保留现有信息同时反映利益相关者的需要。
该会议有助于：
增加新用户故事；
丢弃不相关的用户故事；
估算新增加的用户故事；
重新估算用户故事；
对用户故事进行优先级重排序；
史诗分解成更小的用户故事。
敏捷项目的绩效评估：
敏捷项目的评估方式与预测型不一样
速度：在迭代周期内，已完成的用户故事的故事点的和
在敏捷项目中，挣值管理也适用，SPI=完成的价值/计划的价值
燃尽图
项目的燃尽图是一个常用来展示迭代进度的信息发射源。它记录两项序列，横轴是时间，纵轴是剩余的实际工作和剩余的理想/预估的工作
燃起图
与燃尽图相反，它的横轴是时间，纵轴是已完成的实际工作和剩余的理想/预估的工作。
在迭代期间，有成员离职，暂时无法补充，一种与 PO 沟通确定任务优先级，优先交付价值 更高的故事；
第二种，开发团队自行加班来完成
下一个迭代计划会议期间，依然未能加人，一定需要按照当前的实际工作能力做计划
扫一扫
1205
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
