首页  思维导图  详情

PMP笔记

2024-03-27 11:17:17   0  举报





AI智能生成

为你推荐

查看更多



为了考pmp，上培训课做的笔记

作者其他创作

大纲/内容

只针对单个项目，不针对项目集/组合

大多数时候适用

裁剪：过程、输入、工具、技术、输出、生命周期阶段的恰当组合

业界定义的最重要价值观：责任、尊重、公正、诚实

PMBOK指南：

项目定义：是为创造独特的产品、服务或成果而进行的临时性工作

不确定性

(有型、无形)可交付成果：可核实

独特性

明确的起点和终点

交付成果是持久的

达成目标

无法达成目标

缺资金

缺资源（人、物）

需求不存在（需求终止）

法律或便利原因终止

终止原因：

临时性

驱动变革

资产、工具

有形效益

商誉

品牌利益

标杆项目

战略需要

无形效益

创造商业价值

特点

1.1.1项目基础

项目管理是将知识、技能、工具和技术应用于项目活动，以满足项目的要求

完成效益管理计划

达到商业论证中记录的财务指标

完成组织从当前状态转到将来状态

履行合同条款和条件

使干系人满意

达到组织战略、目的、目标

需要与干系人(stakeholder)达成共识

1.1.2成功标准

关联关系

协调

方式正确

项目集

竞争关系

优先级

选择正确

项目组合

重复的

持续的

项目开始，资源从运营转移到项目中；项目结束后，资源从项目转到运营

运营

确保组织开展正确的项目并合理分配资源

组织级项目管理OPM

1.1.3项目集&项目组合

定义：从启动到完成所经历的一切阶段，可以顺序、迭代、交叠进行

开始项目

组织与准备

执行项目工作

结束项目

通用生命周期：

审查

进入下个阶段

整改后进下阶段

停留在当前阶段

重复阶段或某个要素

决策

阶段关口13;(阶段审查、阶段门、关键决策点、阶段入口、阶段出口)

成本投入在项目开始时缓慢增加，在执行工作时达到最高，项目结束快速回落

干系人影响力、风险与不确定性、变更数量在开始时最大，后续逐步降低

变更的代价、风险的影响在开始时较小，后续显著增高

项目生命周期内与开发相关的一个或多个阶段

定义

瀑布型

计划驱动，按计划执行，一次交付

充分了解产品，有厚实的行业基础，范围进度成本在早期阶段就确定

预测型

从模糊到清晰

重复的循环活动来开发产品

迭代型

从部分到整体

逐渐增加产品功能，最后一次增量后才视为完整的

增量型

敏捷、变更驱动型

较小的增量，每次交付最有价值的功能

快速迭代

频繁交付，干系人频繁参与

适用于创新项目，需快速应对变化

适应型

混合型

类型

开发生命周期

通用生命周期

启动、规划、执行、监控、收尾

五大过程组

为完成预定的产品、成果或服务而执行的一系列相关行动和活动

每个过程都有各自的输入、工具与技术、输出

项目管理过程

每个阶段可以多次执行五大过程组

阶段和过程组的关系

整合

范围

进度

成本

质量

资源

沟通

风险

采购

干系人

项目管理十大知识领域

输出过程组：执行

工作绩效数据

输出过程组：监控

工作绩效信息

工作绩效报告

文档化的经济可行性研究报告（是否值得投资）

由发起人负责制定和维护

项目经理负责提出建议

项目商业论证

描述项目实现效益的方法和时间

效益管理计划

商业文件

1、在项目之前制定，需要定期审核；2、不是项目文件，项目经理不能修改，只能提出建议

1.1.4项目管理的关键要素

基于数据分析出信息，汇编信息形成文件

1.1项目基本要素

不可控，需遵守

市场条件、社会和文化影响与问题

法律限制、政府或行业标准、物理环境要素

商业数据库、学术研究、财务考虑因素

外部

组织文化、结构、治理

基础设施、设施和资源的地理分布、资源可用性

信息技术软件

员工能力

内部

包括

事业环境因素

可裁剪，多积累

工作、实践、知识

经验教训和历史信息

完成的进度计划、风险数据、挣值数据

组织过程资产

1.2.1事业环境因素和组织过程资产

兼职项目经理，权利很小或没有

职业路径清晰，横向联系薄弱

职能型

兼职项目经理，权利小

弱矩阵

兼职项目经理，权利小到中

平衡矩阵

全职项目经理，权利中到大

强矩阵

矩阵型

资源利用率高，有利于跨部门协调；多头领导，管理难度大，资源争夺

全职项目经理，权利大甚至全部

控制度高，重复配置，项目解散后成员无家可归

项目型

有机或简单型组织

多部门组织

虚拟组织

其他一些类型

组织结构

对项目相关的治理过程进行标准化，并促进资源、方法论、工具、技术共享的一个组织结构。

支持团队，控制度很低

支持型

支持+要求服从，控制程度中等

控制型

直接管理和控，控制程度很高

指令型

管理共享资源，识别和制定最佳实践标准

管理

通过项目审计，监督对标准的遵守程度

监督

制定和管理政策、程序、模板，提供指导和培训

指导培训

协调跨项目的沟通

PMO对项目经理支持的方式

PMO项目管理办公室

1.2.2组织系统

1.2项目外部运行环境

由执行组织委派，领导团队实现项目目标的个人

项目经理：专注项目目标的达成

职能经理：专注某个职能领域或业务单元的管理和监督

与职能经理的区别

1.3.1项目经理的定义

项目、组织、行业、专业学科、跨领域

1.3.2影响力范围

技术项目管理能力

战略和商务管理技能

领导力技能

1.3.3PMI人才三角

专家权利

个人吸引他人并简历起的忠诚度能力

参照权利（潜示权利）

职位所拥有的权利

正式权利（法定权利）

奖励权利

惩罚权利

1.3.4项目经理的权利

由正式权利而获得

有利于创新

放任型

奖惩

交易性

服务优先于领导，关注成长发展和团体合作

服务型

通过促进创新提高追随者能力

变革型

魅力型

结合了交易型、变革型、魅力型

交互型

1.3.5项目经理的领导力风格

1.3项目经理

1.概论

编写正式批准项目并授权项目经理的文件

明确项目与组织战略目标之间的直接关系，确立项目的正式地位，展示组织对项目的承诺

作用

由项目以外的实体（发起人、PMO）来启动

尽早确认并任命项目经理，最晚规划开始前

项目经理应当参与项目章程的制定

批准项目章程意味着项目正式启动

在做外部项目时，不能把章程看做合同

注意点

论证项目是否值得投资

商业需求分析

成本效益分析

商业论证（经济可行性研究报告）

招投标文件、意向书、合同、服务品质协议、谅解备忘录

协议

输入

专家判断

头脑风暴

同领域的干系人和主题专家讨论相关议题

焦点小组

与干系人直接交谈

访谈

数据收集

引导团队达成共识

引导

不要把各种类型的会议混一起开

会议管理

人际关系与团队技能

会议

工具与技术

由项目发起人发布，正式批准项目成立，并授权项目经理的文件

项目目的、目标、成功标准、退出标准

主要可交付成果，高层级的需求、项目描述、战略、运营假设条件、制约因素

总体里程碑进度计划、预算、项目风险

委派的项目经理及其权责

项目审批要求、关键干系人名单

内容

项目章程

用于记录整个项目生命周期中所有假设条件和制约因素

不需要验证即可视为正确、真实、确定的因素

还要描述假设不成立时，可能造成的潜在影响

假设条件

对项目或过程执行有影响的限制性因素

制约因素

假设日志

输出

2.1.1制定项目章程

定期识别干系人（相关方），分析记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程

建立对每个干系人或干系人群体的适度关注

里面有关键干系人名单，还可能包含与干系人职责相关的信息

商业论证

头脑风暴（获取身份信息）

头脑协作

干系人分析（评估信息）

数据分析

权利/利益、权利/影响、影响/作用

权利/利益方格（二维方格）适用于小型项目，干系人之间、干系人与项目的关系简单

多维度

干系人立方体

子主题

根据干系人权利、紧迫性、合法性（邻近性），对干系人进行分类

适用于复杂的干系人大型社区、干系人内部存在复杂网络关系

凸显模型

干系人映射分析（干系人分类）

数据表现

身份信息

需求、期望、影响、与生命周期哪个阶段关系密切

干系人分类

干系人登记册

首次开展识别干系人过程，不会提出任何变更请求

后续持续识别，出现新干系人或现有干系人的新信息可能会导致对产品、项目管理计划、项目文件提出变更请求

变更请求

2.1.2识别干系人

2.1启动

为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程

对如何管理范围提供指南和方向

描述如何定义、指定、监督、控制、确认项目的范围

没有项目范围，范围在范围基准中

范围管理计划

描述将如何分析、记录和管理项目产品需求

没有项目需求，需求在需求文件中

需求管理计划

2.2.1规划范围管理

定义：为实现目标而确定、记录并管理干系人需求的过程

作用：为定义产品范围和项目规范围奠定基础

需求：包括发起人、客户、干系人已量化且书面记录的需要和期望

畅所欲言

可以获取机密信息

同职能、同领域的专家讨论

受众多样、地理分散、快速完成，无法保证可靠度

问卷调查

参考榜样，识别最佳实践，形成改进意见

标杆对照

文件分析

德尔菲

一致同意

决策小组人数奇数，超过半数

大多数同意

项目章程（里面有宏观的需求）

相对多数同意

投票

独裁型决策制定

每个标准评分，权重，算总分

多标准决策分析

分组、分类

亲和图

反应共性与差异，激发新创意

思维导图

投票、排序

名义小组（民意小组）

难以说清需求、挖掘隐藏需求

观察(工作跟随)和交谈

联合应用设计或开发（JAD）

质量功能展开（QFD）

用户故事

跨职能，协调干系人差异

引导（引导式研讨会）

系统交互图

模型（原型图、样板房、效果图……）

能减轻返工风险

原型法

描述各种单一、具体的需求将如何满足相关的业务需求

需求文件

把需求从来源连接到对应的可交付成果

把需求与目标联系起来，确保每个需求都具有商业价值

确保每个需求都最终得以交付

需求跟踪矩阵

2.2.2收集需求

从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务、成果的详细描述

与干系人就交付成果打成共识

备选方案分析

通过适用引导技能来打成跨职能的共识

包括各种产品分解、系统分析、需求分析……

产品分析

描述项目和产品范围，详细描述了可交付成果，代表项目干系人质检就项目范围所达成的共识

产品范围描述

可交付成果

是针对可交付成果而言，对项目而言是成功标准、退出标准

验收标准

除外责任

项目范围说明书

需求和可交付成果的对应关系

2.2.3定义范围

把项目可交付成果和工作分解成较小的、更利于管理的组件的过程

对交付的内容提供架构

组织并定义了项目的总范围

最底层的组成部分称为工作包

工作是个名词，不是指活动本身

要点

范围说明书

项目章程、需求说明书……

层级

WBS词典

敏捷：分解成用户故事

不同交付成果可以分解到不同层级

并不是分得越细越好

当前无法分解的规划包，需要滚动式规划

四个注意

100%原则（做且只做的总范围）

责任明确原则

建议80小时原则

建议分解4到6层（不分解过细）

四个原则

分解

工作包

规划包

控制账户

WBS

账户编码标志号

工作描述

负责的组织

里程碑清单

相关采购工作说明书SOW

所需的合同条款

招标文件

自制或外购决策

作为评价卖方报价的对照基准

如果跟卖方报价差异较大，说明SOW存在缺陷或模糊，或潜在卖方误解或不能完全响应SOW

独立成本估算

选择供应商的评分标准

供方选择标准

2.2.23规划采购管理

定义、准备、协调项目计划所有组成部分，并把他们整合成一份总和项目管理计划的过程

生成一份综合文件，用于确定所有项目工作的基础和执行方式

足够强大

基准化

渐进明细

项目管理计划应该

其他规划过程输出的子计划和基准

冲突管理

所属过程组：规划过程组

召开时间：规划过程组即将结束，执行过程组没开始前（对于多阶段项目，每个阶段开始时都要举行）

主要任务：获得主要干系人对项目管理计划的一致认可；传达项目目标、获得团队对项目的承诺

开工会议（以前叫启动会议）kick-off meeting

九大知识领域的10个管理计划

配置管理计划

2个子管理计划

3个基准

绩效测量基准（是3个基准的统称）

项目生命周期描述

开发方法

3个组件

除了项目管理计划外的文件，都属于项目文件

项目管理计划需要干系人批准，修改需要走变更

项目文件是团队自己使用，可自行修改

项目管理计划和项目文件的区别

2.2.24制定项目管理计划

2.2规划

获取所需的成员、设施、材料、用品、其他资源

从职能经理或资源经理处获得

内部资源

通过采购、租赁等途径获得

外部资源

1、集体劳资协议

2、矩阵型项目环境

3、分包商人员使用

4、外部报告关系

项目经理对资源没有直接控制权的情况

资源或人员能力不足会降低项目成功的概率，甚至是取消项目

项目经理应进行有效谈判，获取所需资源

无法获取所需时，不得不使用替代资源（也许能力较低）

竞标过程中承诺

特定人员的专有技能

项目章程中指定

预分派

1、定标准

2、设权重

3、评级或打分

4、计算

5、排序

（找普通人）职能经理：确保项目在要求时间内获得最佳资源

（找牛人）组织中其他项目管理团队：稀缺或特殊资源

（找牛人）外部组织：合适的、稀缺的、特殊的人力资源

谈判对象

谈判（协商）

很少没时间面对面，异地，通过远程协作形成虚拟团队

沟通可能存在问题

虚拟团队

实物资源分配单

项目团队派工单

资源日历

事业环境因素更新

规划资源管理→获取资源

2.3.1获取资源

通过提高工作能力、人员互动、改善分为，以提高项目绩效的过程

1、形成阶段

2、震荡状态

3、规范阶段

4、成熟阶段

5、解散阶段

通常按顺序排列，但是可以停滞、跳过或回退到某个阶段

考试时，回退到某个阶段要选形成阶段

塔克曼阶梯理论

集中办公（紧密矩阵）

影响力

激励

谈判

团队建设（协同工作）

奖励计划是在规划人力资源管理过程中编制的

认可与奖励

了解团队成员优势和劣势，评估偏好和愿望

360度反馈

个人和团队评估

个人能力

团队能力

离职率

凝聚力

团队绩效评价

更新员工发展计划、技能评估

2.3.2建设团队

跟踪团队工作表现，解决问题并管理团队变更，以优化项目绩效的过程

管理冲突、解决问题（不好→好）

团队章程

资源稀缺

进度优先级

个人工作风格差异

性格差异

冲突来源

1、冲突人先私下解决

2、冲突升级，项目经理提供协助（不公开）

3、冲突还存在，则使用正式程序，包括采取惩戒措施

冲突解决步骤

双赢，打成共识，既解决又缓和氛围

合作解决

支持一方，紧急解决问题，没有缓和氛围

强迫/命令

各退一步，解决部分问题，缓和一定的氛围

妥协/调解

没有解决问题，缓和氛围

缓和/包容

没有解决问题，也没缓和氛围

撤退/回避

冲突解决方法

领导力

人关系与团队技能

2.3.3管理团队

获取卖方应答、选择卖方授予合同（招投评授）

采购工作说明书SOW

采购文档

价格建议书

技术建议书

卖方建议书（投标文件）

（招）广告

目的是保证所有潜在卖方对采购要求都有清楚且一致的理解

（投）投标人会议

评估委员会

建议书评估

加权系统

筛选系统

（评）建议书评估

通知中标、未中标人，公式

谈判采购细节

（授）采购谈判

选定的卖方

规划采购管理→实施采购

2.3.4实施采购

为实现目标而领导和执行项目管理计划中确定的工作（分内的），并实施已批准变更的过程（分外的）

实施已计划好的项目活动

管理项目内各种技术接口和组织结构

回顾所有变更的影响，并实施已批准的变更

收集工作绩效数据，并传达给合适的控制过程

需要实施的活动

项目管理信息系统PMIS

工作授权系统

可核实的产品成果、服务

项目管理计划成果

问题日志

事前：预防措施-防风险

事后：纠正措施-纠偏差

用来维护某些基准

更新-通常改计划

缺陷不就-补质量（针对质量缺陷）

会修改计划或基准

2.3.5指导与管理项目工作

把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程

提高实现质量目标的可能性

识别无效过程

识别导致质量低劣的原因

质量控制测量结果：来自质量控制QC

质量测量指标：来自规划质量QP

经验教训登记册

核对单与范围基准中定义的验收标准保持一致

用来确定项目活动是否遵循了组织和项目的政策、过程、程序

质量审计通常由项目外部的团队开展（组织审计部门，项目管理办公室PMO、外部审计师）

识别好与不好的地方

分享良好实践

协助改进

积累经验教训

确认已批准的变更请求的实施情况

目标

质量审计

审计（审过程）

找到根本原因，杜绝问题再次发生

根本原因分析RCA

识别过程改进机会

过程分析

有助于识别根本原因

因果图（鱼骨图、石川图、why-why分析图）

集中趋势、分散程度，特定变量发生频率

直方图

直方图排序

累计，识别主要原因

帕累托图

展示两个变量之间的关系

散点图

面向X的设计

1、定义问题

2、识别根本原因

3、方案

4、选择最佳方案

5、执行

6、验证有效性

问题解决

PDCA

6西格玛，百分之三点四的缺陷率

质量改进方法

质量问题

改善建议

纠正措施

质量报告

测试用例

测试与评估文件

规划质量管理→管理质量

2.3.6管理质量

确保项目信息及时且恰当的收集、生成、发布、存储、检索、管理、监督、最终处置的过程

状态报告

进展报告

未来计划

项目报告发布

项目沟通记录

规划沟通管理→管理沟通

2.3.7管理沟通

与干系人沟通和协作，以满足其需求与期望，处理问题，并促进干系人合理参与

提高干系人的支持，降低干系人的抵制

充分识别干系人，做好干系人分析

制定干系人参与计划

发生问题事前管理：

1、了解或分析原因

2、审查干系人参与计划

引导参与，获得支持

谈判沟通，管理期望

处理风险，预测问题

澄清和解决问题

3、管理

发生问题事后管理：

沟通技能

观察和交谈

文化意识

政治意识

基本规则

启动：识别干系人→规划：规划干系人参与→执行：管理干系人参与

2.3.8管理干系人参与

由风险责任人执行商定的风险应对计划

规划风险管理→识别风险→定性→定量→规划风险应对→实施

2.3.9实施风险应对

使用现有知识（组织过程资产）并生成新知识，以实现目标并帮助组织学习的过程

文字、图片、数字

易分享、易保存

缺乏情景，每个人解读不同

显性知识

个体难以表达的知识，信念、经验、洞察力、诀窍

蕴含情景

难以编撰

隐性知识

营造信任氛围

一起分享，不要单独分享

最重要的环节

需要拥有的知识

可能拥有的知识

资源分解结构

针对隐性知识进行管理

交互式培训、研讨会、专题讲座、论坛、工作跟随和指导

知识管理

针对显性知识

经验教训登记册、图书馆、网络搜索、项目管理信息系统PMIS

信息管理

倾听

人际交往

项目结束时归入知识库

2.3.20管理项目知识（整合）

2.3执行

监督范围状态，管理范围基准变更的过程

维护范围基准

确保变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理

将基准与实际结果进行比较，以确定偏差是否处于临界值区间

偏差分析

看在变好还是变坏

趋势分析

没有对时间、成本、资源做调整，未经控制的范围的扩大

团队内部原因造成的范围蔓延

镀金

团队外部原因造成的范围蔓延

范围潜变

停止不良变更，补变更流程（变更如果没获得批准，取消不良变更）

范围蔓延

2.4.1控制范围

直接成本

间接成本

固定成本

可变成本

全生命周期成本

任何已经发生的成本，跟是否合理无关

在决定是否继续某个出问题的项目时，不应该考虑沉默成本

沉没成本

因为选择一个项目而放弃另一个项目，另个一项目带来的利益就是积灰成本

机会成本

成本的类型

BAC完工预算（成本基准，不考虑管理储备）budget at completion

PV计划价值（到目前为止计划做多少）planned value

EV挣值（到目前为止，已经做了多少）earned value

AC实际成本（到目前为止实际花了多少）actual cost

EV不可能大于BAC

挣值四个基本数据

计划做6天每天做100元包子。假如现在是第二天下班，按计划应该完成200元的包子（PV=200元）。向团队了解，因为一些原因团队实际只做了100的包子（EV=100），为了做100的包子实际花了150元（AV=150元）

挣值分析

= EV - PV

< 0：进度延期

> 0：进度提前

进度偏差SVschedule variance

= EV / PV

适用在项目之间做比较

进度绩效指数SPIschedule performance index

= EV - AC

< 0：成本超支

> 0：成本节约

成本绩效CVcost variance

= EV / AC

成本绩效指数CPIcost performance index

PV与AC质检没有可比性，必须要知道EV挣值

SV、SPI在项目完成是分别为0、1

SPI仅反映工作量，还需要对关键路径进行分析

根据当前绩效估算总预算

剩余工作重新估算需要多少预算

= (BAC - EV) / 绩效

完工尚需估算ETCestimate to complete

= AC + ETC = AC + (BAC - EV) / 绩效

按当前绩效继续（典型）（默认） = AC + (BAC - EV) / CPI = BAC / CPI

按原计划继续（非典型）= AC + BAC - EV

按某个特殊绩效继续 = AC + (BAC - EV) / (CPI * SPI)

完工估算EACestimate at completion

剩余工作的预算价值/剩余预算

= (BAC - EV) / (BAC - AC)

< 1 ：难度小

> 1 ：难度大

如果BAC不可行(BAC = AC)，分母BAC要用EAC替代

完工偏差VAC = BAC - EAC

完工尚需绩效指数TCPIto complete performance index

预测

挣值管理

监督应急储备和管理储备的使用情况

如果已识别的风险没有发生，就可能要从项目预算中扣除未使用的应急储备

未来的钱折算到现在值多少钱

= 将来的钱价值 / （1+折现率）年的次幂

现值PVpresent value

折现率DRdiscount rate

将来的钱折算到现在减去投资成本（越大越好）

= PV - 当前成本值

NPV > 0：接受该项目

NPV < 0：放弃该项目

净现值NPVnet present value

净现值等于0时的折现率DR，表示项目抗风险能力，越大越好

内部收益率IRR

从项目投建之日起，净收益偿还原始投资所需要的年限（越短越好）

不考虑通货膨胀，不考虑折现率

投资回收期PP

投资回报率ROI

效益成本比BCR

一些财务概念

2.4.2控制进度2.4.3控制成本

确保按计划分配实物资源，监控使用情况和纠正

工具和技术

2.4.4控制资源

优化沟通

搞定人

规划干系人参与计划

观察

交谈

修正干系人的沟通要求

简历消除瓶颈的新程序

2.4.5监督沟通

提升干系人参与的效率和效果

干系人参与度评估矩阵

反馈

演示

人际关系技能

改善干系人当前参与水平的纠正及预防措施

2.4.6监督干系人参与

监督商定的风险应对计划的实施，跟踪已识别风险，分析识别新风险

评估风险管理有效性

技术绩效分析

用于评估风险管理过程的有效性

风险审计

识别新风险

重新评估当前风险

关闭已过时风险

风险审查会议

识别风险→定性→定量→规划风险应对→实施风险应对→监督

2.4.7监督风险

管理采购关系、监督合同绩效，变更和纠正

确保买卖双方履行法律协议，满足项目需求

批注的变更请求

1、谈判协商

2、替代争议解决方法ADR

3、起诉

索赔管理

甲方对乙方过程的审查

绩效审查

挣值分析EVA

对可交付成果的检查

对采购过程的结构化审查

甲方对自己整个采购过程的审计

采购审计

审计

采购关闭

2.4.8控制采购

跟踪、审查、报告整体项目进展，为了输出工作绩效报告

控制和监控的工作绩效信息

进度预测

成本预测

便于干系人决策、行动、引起关注

2.4.9监控项目工作

QC，针对可交付成果，核实是否达到质量要求，可供最终验收，确保输出完整正确

内部团队人员做

显示每种项目缺陷的数量

又经常使用帕累托图来显示

核查表

统计抽样

查结果

测试/产品评估

用来确定一个过程是否稳定，或者是否具有可预测的绩效

= 标准差 * 3

控制上/下限

公差，人为规定的最大最小限度，超出就有可能受罚

规格上/下限

某个数据点超出控制界限

连续7个点落在均值上方

连续7个点落在均值下方

失控的判断，需要查原因

控制图

质量控制测量结果

1、查原因

2、走变更，缺陷补救

如果少量可交付成果有问题

要查过程

如果大量可交付成功有问题

核实的可交付成果

变更请求和项目文件更新

规划质量管理→管理质量→控制质量

2.4.11控制质量

客户或发起人正式验收可交付成果的过程

由发起人、客户、主要干系人做

通过验收每个可交付成果，提高最终可交付成果验收的可能性

保证收尾

判断工作和可交付成果是否符合需求和产品验收标准

复核标准的成果，应该由客户或发起人正式签字批准

验收的可交付成果

validate scope验证/验收范围

2.4.12确认范围

2.4监控

验收整个项目的成功标准、退出标准

偏形式验收

终结项目、阶段、合同的所有活动

存档信息，释放组织资源

1、获得项目整体验收

2、移交成果

3、总结和记录经验教训

4、组织过程资产更新

5、文件归档

6、释放资源

干系人满意度调查

庆功会

成功

1、收尾文件中说明终止原因

2、把已完成、未完成的可交付成果移交他人

提前终止

结束项目/阶段的注意事项6+2

乙方的验收申请

从一个团队转交到另一个团队或组织，让他们进行运营、维护、支持

最终产品、服务、成果的移交

最终报告

收尾文件

组织过程资产更新

释放资源（解散团队）

项目完成收尾的标志

发现缺陷，走变更流程

提出新需求，走变更或新开项目

项目经理又被分配新项目，应当优先保证当前项目收尾

收尾期间

还发现缺陷，由运营解决

提出新需求，建议开新项目

收尾完成

收尾题，下一步做什么？

2.5.1结束项目或阶段

2.5收尾

2.项目管理过程

需求必须明确

如果经常改变需求，需要通过变更流程修改计划

一开始就要写大量文档

客户参与度不高

需要花大量时间汇报当前项目状态

项目结束才显现价值（大爆炸式交互）

无法灵活应对市场变化

问题

3.1.1预测性的特点和问题

提供最小可行产品（只有基本功能），并在此产品上持续快速迭代，直到产品到达一个相对稳定的阶段

对创业团队来说很重要，可以快速验证团队目标，快速试错

时间不多，无法做大且全的功能

市场反馈不明，快速试错获得反馈

竞品

适用

3.1.2MVP最小可行产品

需求明确、技术成熟，就是简单的项目，用预测型生命周期

需求不明确、技术成熟 or 需求明确、技术复杂，用适应型生命周期

需求不明确、技术有些复杂，用敏捷

需求完全不清晰、技术没接触过，混乱的，不做

需求是否明确、技术是否成熟

3.1.3STACEY矩阵

项目中一部分用预测型，一部分用敏捷

难以从预测一步切换到敏捷

可以在风险不大，具有中低程度不确定性的项目中尝试

在成功使用混合方法后，再尝试更复杂的项目实现渐进过度

3.1.4混合型生命周期

3.1敏捷概述

是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力

个体互动胜过流程和工具

获得反馈

可用的软件胜过详尽的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

宣言

及早和持续不断地交付有价值的软件，价值驱动

欣然面对需求变化，即使在开发后期也一样

较短的周期

业务和开发必须相互合作（业务：了解业务的人员，客户、ProductOwner）

辅以信任，项目经理是仆人式/服务型

面对面交谈

可工作的软件是进度的首要度量标准（没完成的功能就是没有工作成果）

倡导可持续开发，责任人、开发、用户要能共同维持其步调稳定延续

坚持追求技术卓越和良好设计

简洁为本

最好的架构、需求和设计出自自组织团队（自组织团队属于敏捷的输出）

定期反思如何提高成效并调整（PDCA）

十二原则（思想、价值观）

3.2敏捷宣言和原则

管理产品待办事项列表PB的唯一责任人（可以亲自完成，也可以让团队人员完成）

非常懂需求：商业分析师、需求工程师……

清晰表达需求、优先级排序、列表对所有人透明、确保团队理解

决定接受或拒绝每次sprint完成的产品增量，决定是否上线

产品负责人Product Owner

也称为项目经理、团队促进者

确保Scrum团队遵循Scrum理论、实践、规则

服务式领导，服务产品负责人、开发团队、组织

敏捷教练Scrum Master

负责每次Sprint结尾交付产品增量

自主选择任务、如何实现、自己估算，主动学习

自组织

团队技能全面

跨职能

无论承担那种工作都是开发者

不认可成员头衔

有专注领域，其他方面也略懂

T型人才

一般3~9人，比较稳定

相对稳定

开发团队

3个角色

作为一个角色，我想要什么功能，以便于实现什么价值

谁要使用

角色

功能的相关描述

功能

为什么需要，会带来什么价值

价值

需求明确

一个Sprint可以完成

验收标准清晰

就绪的定义DORdefinition of ready

产品待办事项是一个排序列表，产品负责人负责内容、可用性、优先级

由PO负责维护澄清需求、优先级

列出了所有特性、功能、需求、改进方法、缺陷修复

如果团队觉得需求不明确，可要求PO澄清需求

高比低的需求更清晰具体（低的可以以后再补充），符合就绪的定义DOR

PO和团队协作，梳理增添细节、估算和排序，是个持续不断的过程

魅力型：越具备越满意

期望型：具备与满意呈线性

无差异：是否具备不影响满意度

必备：没有就不满意

反向需求：越具备越不满意

KANO模型

MoSCoW法must or should，could or won't

优先级从高到低排序

梳理PB的时间不超过10%

最后的估算由执行工作的人来决定

产品待办事项列表PBProduct Backlog

是一组为当前Sprint选出的PB中的条目

在敏捷中，应当认为团队是Y理论的

每日站会，透明

鼓励挑战，T型人才

开发团队将用Sprint中的用户故事拆分成任务，团队成员主动领取任务

确保团队Sprint目标清晰可见

足够具体的计划

步调稳定

短周期

Sprint内不做变更

开发团队专注于打成Sprint的目标

冲刺待办事项列表Sprint Backlog

是一个Sprint完成的所有产品待办列表的总合

验收标准针对外部干系人

DOD包括文档

在Sprint最后，新的增量必须是可用并且达到Scrum团队对完成的定义DOD（Definition of Done）

增量是在Sprint结束时可检视可完成的产品组成部分

无论PO是否决定发布，增量必须是可用的

为了加速开发，在应该采用最佳方案的时候进行了妥协，后续会要进行处理（优化或重构）

技术负债technical debt

产品增量Product Increment

3个工件

是Scrum的核心，以持续时间很短，以构建一个完成的、可用的、潜在可发布的产品增量

长度通常保持一致（固定的“时间盒”）

构成：计划会议、每日站会、开发工作、Sprint评审会议、回顾会议

期间不能做出有害于Sprint目标的改变

一个Sprint未完成的待办事项，放回到PB中，重新估算（因为优先级、价值会变化）

如果某个Sprint失去了价值和意义，可以在结束之前取消，只有PO有取消的权利。但由于Sprint时间短，取消的意义不大

sprint定义

两周Sprint最多开4小时

PO介绍待完成优先级高的功能

如果团队有信心完成一个功能，就把功能从PB移到Sprint Backlog中

如果团队发现增加的工作量已经超量了，团队立即建议PO停止

通常由团队决定一个Sprint完成多少

团队和PO一起确定目标，在Sprint结束时的评审会议中，审视是否打成目标

好处是更容易打成共识

宽带德尔菲/计划扑克

相对估算

一种快速而简陋的实验

探针Spike

可以先做几个Sprint，就能大概得出一个团队稳定的速率

团队不同，选择的基准用户故事不同，速率不同

速率Velocity

故事点和团队的速率

Sprint计划会议

15分钟为限

Scrum Master确保如期举行

只有开发团队成员参加（干系人也可以参加，但不能发言干扰会议）

昨天做了什么

今天准备做什么

是否有障碍、问题、风险

只记录问题，不讨论问题

开发团队在站会后，立即聚到一起详细讨论

增进交流沟通，减少其他会议，发现开发过程中问题，促进快速决策，提高认知程度

Scrum每日站会

看已完成的工作

看板

时间/剩余故事点二维图，看剩余工作

燃尽图

燃起图、累计流量图、停车场图……

信息发射源（信息扩散器）

在Sprint快结束时举行，两周的一般开2小时

Scrum团队、干系人都要参加

开发团队演示完成的工作，获取反馈

就下一步工作进行探讨，为下次Sprint计划会议提供有价值的输入信息

评审会议结果是一份修订后的产品待办列表PB（维护PB）

Sprint评审会议

在评审会议结束后，下个Sprint计划会议开始前，进行，2周不超过2小时

用来总结经验教训

明确下一次Sprint中需要落实的改进

Sprint回顾会议

5个事件

承诺

专注

开放

尊重

勇气

5个价值观

3.3.1Scrum

0库存，just in time

看板：可视化管控，消除瓶颈

测试驱动开发TDD

重构（技术负债）

结对编程

集体所有权

持续集成

极限编程

3.3.2其他

3.3敏捷实践

3.敏捷

4.1价值驱动的项目管理只是体系

简历富有成效的工作关系

干系人认同项目目标

支持的干系人满意并受益，反对的干系人没有收到负面影响

预期目标

识别干系人，高层级到低层级

理解和分析干系人的感受、情绪、信念、价值观……

优先级排序

管理干系人参与

监督干系人变化，更新干系人参与方法

绩效要点

干系人参与的连续性

变更的频率

干系人行为、满意度、相关问题和风险

执行效果检查

4.2.1干系人绩效域

共享责任

建立高效绩效团队

所有团队成员都展现出相关领导力和其他人际关系技能

团队文化：透明、诚信、尊重、积极、支持（同理心、共情）、勇气

高绩效团队：沟通、共识、共享责任、新人、协作、适应性、韧性、授权、认可

领导力技能：建立和维护愿景、批判思维、吉利、人际关系技能（情商、决策、冲突管理）

目标和责任心

信任与协作程度、适应变化能力、彼此赋能

管理和领导力风格事宜

4.2.2团队绩效域

开发方法与项目可交付物相符

将项目交付与干系人价值紧密相连

项目生命周期由促进交付节奏和交付物所需的开发方法组成

交付节奏：一次性、多次、定期交付

开发方法：预测型、混合型、适应型

开发方法的选择：受到产品、服务或成果、项目、组织的影响

协调交付节奏和开发方法：交付节奏、开发方法应该匹配

产品质量和变更成本相对较小

价值导向型项目阶段

多个可交付物可将生命周期阶段重叠或重复

4.2.3开发方法和生命周期

项目以有条理、协调一致和经过周密考虑的方式推进

对不断演变的信息有详细说明

规划投入时间和成本恰当

规划内容足以管理干系人期望

根据出现的和不断变化的需求

规划的影响因素：开发方法、可交付物、组织需求、市场条件、法律法规

影响项目估算的四个方面：区间、准确度、精确度、信心

进度估算和成本估算

团队和结构规划：技能、熟练度、工作地点

沟通规划

实物资源规划

采购规划

变更规划

度量指标和一致性

绩效审查，绩效偏差处于临界值范围内

整体性

详尽程度

适宜性

充分性

可适应变化

4.2.4规划绩效域（规划过程组）

有效率、效果

适合项目环境

干系人适当的参与和沟通

有效管理实物资源

有效管理采购

有效处理变更

持续学习改进提高管对能力

建立并定期审查项目过程

平衡竞争性质的因素

使团队保持专注

项目沟通管理并关联干系人绩效域

管理实物资源

处理采购事宜

监督新工作和变更

做好知识管理工作

过程审计、质量保证

沟通有效性

自愿利用率

采购过程事宜

变更处理情况

团队绩效

4.2.5项目工作绩效域（执行过程组）

有助于实现业务目标和推进战略

实现预期成果

在规划时间内、框架内实现了项目收益

项目团队对需求有清晰的理解

干系人接受项目可交付物并满意

价值交付

可交付物

目标一致性

项目完成度

项目收益

需求稳定性

干系人满意度和质量问题

4.2.6交付绩效域（确认范围、验收）

对项目状况产生可靠的理解

数据充分，可支持决策

及时采取适当行动，确保项目绩效处于正规

根据可靠的预测和评估，做出明智及时的决策，来实现目标并产生商业价值

制定有效的测量指标：spi进度、cpi成本、提前指标、滞后指标，符合SMART原则

测量内容及相应指标

展示度量信息和结果

测量陷阱

对绩效问题进行判断

测量结果，工作绩效数据

执行结果

4.2.7测量绩效域（监控过程组）

了解运行环境

积极探索和应对不确定性

能够预测威胁和机会并了解问题的后果

减少受不可预见时间的负面影响

利用机会改变

有效利用成本和进度储备

模糊性

复杂性

易变性

增强项目韧性

考虑环境因素

风险应对措施

应对措施适宜

风险管理系统或机制

利用机会的机制

储备使用

4.2.8不确定性绩效域（风险）

4.2项目绩效域

4.3项目管理原则

4.项目绩效域和项目管理原则

投票注重决策结果；名义小组注重投票过程

point

 收藏

立即使用

PMP笔记

弹弹弹

职业：暂无

去主页





0 条评论

回复删除



取消

下一页