导图社区 PMP-第七版-终极版

PMP-第七版-终极版

PMP-第七版-终极版八大绩效域，其中项目工绩效域涉及与建立项目过程、管理实物资源和营造学习环境相关的活动和功能

编辑于2023-09-04 23:53:04 上海

蛮吉

他的近期作品查看更多>>

PMP-第七版-终极版

社区模板帮助中心，点此进入>>

蛮吉

他的近期作品查看更多>>

相似推荐
大纲

项目时间管理6大步骤
- 17.5k
- 356
- 896
- 127
MindMaster
项目管理的五个步骤
- 52.4k
- 2.1k
- 2.6k
- 528
MindMaster
安全教育的重要性
- 6.7k
- 892
- 98
- 18
issen
电商部人员工作结构
- 7.7k
- 175
- 247
- 14
issen
个人日常活动安排思维导图
- 7.3k
- 0
- 80
- 1
少儿栏目外景策划波波老师
暮尚正常运转导图
- 7.7k
- 703
- 43
- 0
宋林鉴
产品经理如何做好项目管理
- 7.0k
- 48
- 209
- 10
issen
西游记主要人物性格分析
- 15.4k
- 1.4k
- 639
- 105
issen
车队管理
- 3.5k
- 12
- 78
- 4
嘻嘻哈哈
17种头脑风暴法
- 200.4k
- 4.0k
- 11.7k
- 4.0k
MindMaster

PMP

项目管理知识体系指南

项目绩效域

干系人绩效域

概要

干系人绩效域涉及与干系人相关的活动和功能

有效执行此绩效域将产生以下预期成果：

在整个项目期间与干系人建立富有成效的工作关系

干系人对项目目标表示同意

作为项目受益人的干系人表示支持并感到满意，而对项目或其可交付物可能表示反对的干系人不会对项目成果产生负面影响

核心概念

干系人：能影响项目、项目集或项目组合的决策、活动或成果的个人、群体或组织，以及会受或自认为会受它们的决策、活动或成果影响的个人、群体或组织

干系人分析：通过系统收集和分析各种定量与定性信息，来确定在整个项目中应该考虑哪些人的利益的一种方法

驾驭干系人参与的一般步骤：识别-理解-分析-优先级排序-参与-监督

具体环节

简述

识别干系人，分析期望和影响，制定策略，调度参与决策与执行

需要把干系人满意度作为也给关键项目目标进行管理

识别干系人

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

作用：帮助项目经理建立对各个干系人或干系人群体的适度关注

发生时间:需要根据需要在整个项目期间定期开展

审查是否合理：执行期间定期审查，防止干系人遗漏或变动

识别干系人：审查若不合理需要调整，项目早期就要开始

规范参与：

ITO-输入输出工具

数据收集：

问卷调查

头脑风暴/头脑写作

数据分析

干系人分析：产生干系人清单和干系人信息（兴趣/权力/所有权/知识/贡献/文件分析）

数据表现-干系人映射分析/表现

三类方格

权力/利益方格-职权/对项目结果的关注程度

权力/影响方格-职权/主动参与项目的程度

影响/作用方格-主动参与项目的程度/改变项目计划或执行的能力

适用于小型项目和干系人关系简单的项目

干系人立方体

把上述方格中的要素组合成三维模型，有助于沟通策略的制定

凸显模型

权力-施加自己意愿的的能力，紧急程度-需要立即关注、合法性-有权参与

用于复杂关系网络，确定相对重要性

影响方向分类

上下内外

优先级排序

大量干系人、频繁变化、内部关系复杂

干系人登记册

身份信息：姓名、在组织中的职位、地点、在项目中的角色、联系方式

评估信息：主要需求、主要期望、对项目的潜在影响、与生命周期的哪个阶段最密切相关

干系人分类-内部/外部，支持者/中立者/反对者等

规划干系人参与

定义与作用

定义：分析干系人需求，制定项目干系人参与项目的方法

作用：提供与干系人进行有效互动的可行计划

发生时间：根据需要在整个项目期间定期开展

为满足项目干系人的多样性信息需求，应该在项目生命周期的早期制定一份有效的计划，并在后期更新

规范干系人参与-ITO

干系人参与度评估矩阵

比较干系人计划参与程度与实际参与程度

C代表干系人的当前参与水平

D是项目评估出来的、为确保项目成功所必不可少的参与水平-期望的

发现不一致可开展必要的沟通，有效引导干系人参与项目

干系人参与计划

确定用于促进干系人有效参与决策和执行的策略和行动

可包括调动个人或干系人参与的特定策略或方法

干系人参与计划还可包括：

关键干系人的当前和计划参与程度

干系人变更的范围和影响

干系人之间的关系和潜在交叉

管理干系人参与

定义：与关系人互动，满足需求，处理问题，促动参与

作用：降低风险，减少混乱，提高支持，降低抵制

发生时间：在整个项目期间开展

项目团队成员识别干系人，项目经理管理干系人期望和参与

干系人的影响力在项目启动阶段最大，随后降低

有助于确保干系人明确了解项目目的、目标、收益和风险，以及他们的贡献将如何促进项目成功

ITO-输入输出工具

变更日志

变更日志用来记录在项目过程中发生的各种变更

必须让有关干系人了解这些变更及其对项目时间、成本和风险的影响

变更日志不等于变更请求，变更请求批准后，需要将变更的结果登记到变更日志中

问题日志

可用来记录和监督问题的解决情况

需要根据问题的紧急性和潜在影响，明确地对问题进行描述和分类

三要素：问题、负责人、解决期限

为解决的问题往往是导致冲突和项目延误的主要原因

监督干系人参与

定于：全面监督，调整策略，调动参与，引导合作

作用：随着项目进展和环境变化，维持/提升干系人参与活动的效率和效果

发生时间：在整个项目期间开展

干系人满意度通常可以通过与干系人的对话来确定，以衡量他们对项目可交付物和项目总体管理的满意状况。也可以通过迭代审查会、产品评审会、阶段关口和其他方法获得定期反馈。如果有大量的干系人，还可以使用问卷调查来评估满意度。必要时，甚至可以通过更新干系人参与方法来提高干系人满意度

敏捷项目，可能需要让干系人查阅信息发射源来了解信息，提高满意度

ITO-输入输出工具

项目管理数据和信息

数据分析

工作绩效数据->工作绩效信息

工作绩效数据/项目管理计划-->数据分析-->偏差大-->纠正或预防/变更请求

工作绩效数据/项目管理计划-->数据分析-->偏差小或无-->继续监控

其他经验

要采用多种沟通方式与干系人沟通，可以通过书面或口头方式进行，可以是正式的、非正式的、推式、拉式

参与比推式或拉式沟通更深入。参与是交互式沟通，它包括与一个或多个干系人交换信息，例如：对话、电话、会议、头脑风暴、产品演示

整个项目周期中需要监督干系人的变化，在整个项目期间对干系人的数量和有效性要进行监督

合理授权与有效培训可以增加干系人满意度

团队绩效域

概要

涉及与负责生成项目可交付物以实现商业成果的相关人员互动和功能

预期成果

共享责任

高绩效团队

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

核心概念

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

项目管理团队：直接参与项目管理活动的项目团队成员

项目团队：执行项目工作，以实现项目目标的一组人员

管理活动：聚焦于实现项目目标的手段，例如制定有效的程序、规划、协调、测量和监督工作等

领导力活动关注于人。领导力活动包括影响、激励、倾听、促使、引导，以及与项目团队相关的其他活动。这两个方面对交付预期成果非常重要

高绩效团队：项目团队彼此信任、相互协作。项目团队适应不断变化的情况，并在面对挑战时有韧性，项目团队感到被赋能

服务型（仆从型）领导者：使项目团队在可能的情况下进行自组织，并通过项目团队成员提供适当的决策机会来提高自主性，服务型领导力行为包括：

消除障碍：由于是项目团队创造了大部分商业价值，服务型领导者的关键角色是通过消除进展中的障碍因素来最大化的交付商业价值。这包括解决问题和消除可能妨碍项目团队工作的障碍。

避免分心：服务型领导者会使项目团队免受内部和外部分心之事影响，时间碎片会降低生产率，因此使项目团队免受非关键外部需求影响有助于项目团队保持专注。

鼓励和发展机会：提供相关工具和奖励，让项目团队保持满意度且工作富有成效。

具体环节

简述

识别、获取和管理所需资源以成果完成项目的各个过程

包括成立团队、组织团队、建设团队活动、处理冲突等事宜

规划资源管理

定义：规定如何估算、获取、管理和利用团队资源的过程

作用：根据项目类型和复杂程度确定适用于项目资源的管理方法和管理程度

时间：仅开展一次或仅在项目的预定义点开展

需要考虑稀缺资源的可得性或对稀缺资源的竞争，编制相应计划，保证人力资源规划的有效性

资源可以从组织内部资产获得，或从外包/采购从组织外部获取

ITO-输入输出工具

职责分配矩阵-RACI

资源管理计划

资源管理计划提供了如何分类、分配、管理和释放项目资源的指南

资源管理计划可以根据项目的具体情况分为团队管理计划和实物资源管理计划

包括

角色和职责-角色、职权、职责、能力的具体说明

项目组织图-展示项目团队成员及其报告关系

如何识别、获取、控制资源

如何进行团队建设

如何进行团队资源管理-人员招募、人员配备、人员管理、人员遣散、培训需要、认可计划

团队章程

团队章程对项目团队成员的可接受行为确定了明确的期望

要塑造团队文件-透明、诚信、尊重、勇气、庆祝成功等

可定期审查和更新团队章程，确保团队始终了解团队基本规则，并指导新成员融入团队

为团队建设团队价值观、共识和工作指南的文件

可能包括

团队价值观

沟通指南

决策标准和过程

冲突处理过程

会议指南

团队共识

估算活动资源

定义：估算执行项目所需的团队资源的过程

作用：明确完成项目所需的资源种类、数量和特性

发生时间：应根据需要在整个项目期间定期开展

ITO-输入输出工具

常见估算类型

资源需求

资源需求识别了各个工作包或工作包中每个活动所需的资源类型和数量

汇总这些需求，以估算每个工作包、每个WBS分支以及整个项目所需的资源

资源需求描述的细节数量与具体程度因应用领域而异

资源需求文件也包含为确定所用资源的类型、可用性和所需数量而做的假设

资源分解结构

资源分解结构是资源依类别和类型的层级展现

资源类别包括：人力、材料、设备和用品

资源类型包括：技能水平、要求证书、等级水平或适用于项目的其他类型

在规划资源管理过程中，资源分解结构用于指导项目的分类活动

在这一过程中，资源分解结构是一份完整的文件，用于获取和监督资源

获取资源

定义：获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程

作用：概述和指导文件的选择，并将其分配给相应的活动

发生时间：根据需要在整个项目期间定期开展

内部资源由职能经理或资源经理负责获取/分配

外部资源通过采购获得

项目团队可能不对资源选择有直接控制权，但要注意下面三点

有效谈判

资源不能获取时的风险预判

有时不得不使用能力不同的替代资源-注意职业道德

ITO-输入输出工具

多标准决策分析

技能/知识/能力/经验/成本/可用性

实物资源分配单

记录项目将使用的材料、设备、用品、地点和其他实物资源

项目团队派工单

记录了团队成员及其在项目中的角色和职责

包括项目团队名录

需要把人员姓名插入项目管理计划的其他部分，如项目组织图和进度计划

资源日历

表明每种具体资源的可用工作日或工作班次的日历-资源的客观提供

需要在整个项目过程中渐进明细和更新

项目日历

表明进度活动的可用工作日和工作班次的日历

资源直方图

按一系列时间段显示某种资源的计划工作时间的条形图-按时段计列的资源主观需求

建设团队

定义:提高工作能力，促进团队互动和改善团队氛围，以提高团队/项目绩效的过程

作用：改进团队协作、增强人际关系技能、激励员工、减少摩擦以提升整体项目绩效

发生时间：整个项目期间开展

PM是个纽带，让团队更和谐

项目管理团队应该利用文化差异，营造充满信任的氛围

建设团队四个目标

提高团队成员的知识和技能

提高团队成员之间的信任和认同感

创建富有生气和凝聚力的团队文化

提高团队参与决策的能力

ITO-输入输出工具

团队一般成长规律-塔克曼模型

形成阶段-相互认识，了解角色。相互独立，不怎么开诚布公

震荡阶段-开始从事工作并讨论，可能有冲突，团队环境可能恶化成破坏性的

规范阶段-开始协同工作，开始相互信任

成熟阶段-相互依靠，平稳高效解决问题

解散阶段-完成所有工作，团队成员离开项目

阶段持续时间的长短，取决于团队活力、团队规模、团队领导力

集中办公

许多或全部最活跃的项目团队成员安排在同一个物理地点工作，可以是临时的也可以是永久的

集中办公又称为紧密矩阵

是一种有效的团队建设活动

尽管集中办公是一种良好的团队建设策略，但是虚拟团队的使用有时也不可避免

虚拟团队

可以使用更多技术熟练的资源、降低成本、减少出差及搬迁费用

注意沟通规划

认可与奖励

只要能满足被奖励者的某个重要需求的奖励，才是有效的奖励

在决定认可与奖励时，应考虑文化差异

客观多赢的态度

输/赢-零和奖励会破环团队凝聚力

大多数项目团队成员会因得到成长机会、获得成就感以及用专业技能迎接新挑战，而受到激励

在整个项目生命周期中尽可能地予以表扬，而不是最后

培训

可以是正式的-课堂培训/在线培训或非正式的-辅导及指导

应该按资源管理计划中的安排来实施预定的培训

培养成本包含在项目预算中

培训按照70-20-10原则

个人和团队评估

能让项目经理和项目团队洞察成员的优势和劣势

评估团队成员的偏好和愿望、了解团队成员如何处理信息、如何制定决策、如何与他人打交道

有利于增进团队成员间的理解、信任、承诺和沟通，从而提高团队绩效

常用工具：态度调查、转向评估、结构化访谈、能力测试、焦点小组

马斯洛需求层次理论

麦克雷戈XY理论

Z理论

第一种：在工作中，个人的动机是自我实现、价值观和更强的使命感。在这种情况下，最佳的管理风格是一种可培养洞察力，具有意义的管理风格

第二种：侧重于通过创造关注员工及其家人福利的终身工作来激励员工

旨在提高生产率、士气和满意度

赫茨伯格的双因素理论又称激励保健理论，引起人们工作的因素主要有两个：

激励因素-给人们带来满意感。指那些与人们满意情绪有关的因素：工作表现机会、工作带来的愉快、工作上的成就感、由于好的成绩得到奖励、未来发展的期望、职务上的责任感，缺少他们人们不会满意

保健因素-消除人们的不满，但不会带来满意感。是指那些与人们的不满情绪有关的因素：企业政策、工资水平、工作环境、劳动保护、人际关系等，缺少他们人们会不满意

驱动力模型

自主：我做什么我决定-人们需要在做什么，什么时候做、和谁做以及如何做上实现自主

专精：能够运用并改进所擅长的技能，把想做的事做的越来越好

目的：创造不同-认可自己工作的价值，让生活更有意义

团队绩效评价

项目团队的有效性，进行正式或非正式的评价

评价标准：项目的技术成功度-达到预定的项目目标、项目进度绩效-按时完成和成本绩效-在财务约束条件内完成，来评价团队绩效

评价团队绩效有效性指标包括：

个人技能的改进，从而使成员更有效的完成工作任务

团队能力的改进，从而使团队整体工作的更好

团队成员离职率的降低

团队凝聚力的加强，从而使团队成员开放的分享信息和经验，并互相帮助，来提高项目绩效

管理团队

定义：跟踪团队成员的表现、提供反馈、解决问题并管理变更，以优化项目绩效的过程

作用：影响团队行为、管理冲突以及解决问题

发生时间：在整个项目期间开展

ITO-输入输出工具

人际关系与团队技能

冲突管理

大体情况

冲突是正常的，它迫使人们寻求解决方案

冲突因团队而存在

开诚布公有利于解决冲突

解决冲突应对事不对人

解决冲突应着眼于现在而非过去

冲突不可避免，遇到冲突需要考虑怎样处理

早期冲突的原因是优先级和资源，中后期是进度

解决方法

合作：当参与者之间已建立信任并且有时间达成共识时，这是一种有效的方法。项目经理可以引导项目团队成员之间采用这种解决冲突的方法

强迫/命令：一输一赢，利用权力，暂时解决---1.没有足够时间合作、解决问题，2.需要立刻解决健康和安全方面的冲突

妥协/调解：双输，各让一步，一定程度上满意---双方不会完全满意，冲突双方拥有平等的权力

缓和/包容/迁就：为维持和谐关系而退让一步，考虑其他方的需要---希望与权力高的一方保持良好关系

撤退/回避：退出、推迟、推脱，没有解决冲突---降温无法取胜时

面对/解决问题：可以把这个单独当作一种方法，当冲突双方之间的关系很重要，并且每一方都对另一方解决问题的能力有信心时，就会采用这种解决冲突的方法

冲突五个阶段

阶段一：潜在对立-原因：沟通、结构和个人因素

阶段二：认识和情感投入-当个体有了感情上的投入，双方都体验到焦虑和紧张、挫折和敌对时，潜在冲突方才可能成为现实

阶段三：行为意向-介于一个人的认识和外显行为之间，指采取某种特定的策略。行为意向之所以作为独立阶段划分出来，是因为行为意向导致行为。

阶段四：行为-当一个人采取行动去阻止他人达到目标或损害他人的利益时

阶段五：结果-冲突双方之间相互作用导致最后的结果，可能是正向也可能是负向

制定决策

着眼于所要达成的目标

遵循决策流程

研究环境因素

分析可用信息

激发团队创造力

理解风险

高效制定决策

情商

情商指识别、评估和管理个人情绪、他人情绪及团体情绪的能力

了解、评估及控制项目团队成员的情绪，预测团队成员的行为，确定团队成员的关注点及跟踪团队成员的问题，来减轻压力、加强合作的

组成部分

影响力

矩阵环境中，项目经理对团队成员通常没有或仅有很小的命令职权，所以他们适时影响干系人的能力，对保证项目成果非常关键

影响力主要体现

说服他人

清晰表达观点和立场

积极且有效的倾听

了解并综合考虑各种观点

收集相关信息，在维护相互信任的关系下，解决问题并达成一致意见

领导力

建立和维护愿景、批判性思维、激励、情商、决策

情景领导力II

Ken Blanchard的情景领导力II通过将胜任力和承诺作为两大主要变量来测量项目团队成员的发展情况

胜任力：能力、知识、技能的组合

承诺：涉及个人具有的信心和动机

随着个人的胜任力-能力和承诺-意愿不断演变，领导风格会经历从指导到教练到支持再到授权的变化，以满足个人的需要

判断员工的发展阶段可以通过两个组合要素：能力和意愿。

D1阶段的员工能力弱，但是工作意愿强--->热情高涨的初学者--->适合用指令型的领导形态：S1-高指导，低支持

D2阶段的员工能力弱或能力平平，但工作意愿低--->憧憬幻灭的学习者--->教练型的领导形态：S2-高指导，高支持

D3阶段的员工能力中等或强，但工作意愿不足--->有能力的但谨慎的执行者--->支持型的领导形态：S3-高支持、低指导

D4阶段的员工能力强且工作意愿高--->独立自主的完成者--->授权型的领导形态：S4-低指导、低支持

五种权力类型

正式权力：来自组织的正职位，也叫法定权力

奖励权力：PM可以在其职位使用的奖励权

惩罚权力：很有力，但会对团队造成很坏的气氛

专家权力：具有专门的知识，拥有很高的威望

暗示权力：与一些有权利的人有关系，狐假虎威

PMI推崇奖励权力/专家权力，避免使用惩罚权力

开发方法与生命周期绩效域

概要

涉及与项目的开发方法、节奏和生命周期阶段相关的活动和功能

预期成果

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

由从项目开始到结束各个阶段组成的项目生命周期，这些阶段将项目交付与干系人价值联系起来

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

核心概念

开发方法：在项目生命周期内用于创建并改进产品、服务、或结果的方法，例如预测型、迭代型、增量型、敏捷性或混合型方法

节奏：在整个项目期间所开展活动的节奏

项目阶段：一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付物的完成为结束

项目生命周期：项目从开始到结束所经历的一系列阶段

不同生命周期的比较

预测型生命周期：一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程

采用迭代型方法的生命周期：允许对未完成的工作进行反馈，从而改进和修改该工作

采用增量型方法的生命周期：向客户提供各个已完成的，可能立即使用的可交付物

采用敏捷性方法的生命周期：既有迭代，又有增量，便于完善工作，频繁交付价值

敏捷相关知识

敏捷的灵魂

敏捷宣言

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

尽管右项有其价值，我们更重视左项的价值

敏捷原则

细则

优先做通过尽早的、持续的交付有价值的软件来使客户满意

即使到了开发后期，也欢迎改变需求

经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的间隔越短越好

整个项目开发期间，业务人员和开发人员必须天天都在一起工作

围绕被鼓励起来的个人来构建项目

工作的软件是首要的进度度量的标准

敏捷过程提倡平稳的开发节奏，发起人、开发者和用于应该能够保持一个长期、恒定的开发速度

团队内部，最具有效果并富有效率的传递信息的方法就是面对面的交谈

不断的关注优秀的技能和好的设计会增强敏捷能力

简单化是根本，不做过度设计和预测

最好的架构、需求和设计出于自组织的团队

每隔一定时间，团队会在如何才能有效的工作方面进行反思，并对自己行为做出调整

简化

持续交付，小步快跑

拥抱变化，提高优势

尽早反馈，价值排序

成果达成，衡量进度

持续更新，强化敏捷

精简产品，杜绝浪费

团队合作，每日互动

信任成员，给予支援

当面沟通，高效明了

各方成员，稳定节奏

同心协力，自我组织

团队自省，自我改进

敏捷的灵魂是思维模式的改变，而不是工具方法的堆砌

敏捷的角色

三种常见角色

跨职能团队成员-team

一般情况下人数在3-9人

团队成员跨职能-开发人员、测试人员、用户界面设计师等，鼓励成为T型人才，最好是全栈工程师

敏捷团队成员需要全职，不能随意发生变化（至少迭代内），否则影响团队速度

在团队章程内由权力做任何工作形式的决策来确保达到迭代、冲刺的目标

高度的自组织能力-重点强调尊重、承诺和责任，而不是肆无忌惮的自由散漫

需要向Product Owner演示产品功能

团队需要定义DoD-针对所有任务的

DoD/AC/DoR的区别和联系

在敏捷项目中，常用Definition of Done“完成的定义”来表示工作是否已完成，不同的活动有不同的完成定义-迭代DoD、发布DoD、每日DoD、用户故事DoD等

用户故事DoD实例

用户故事最终的描述符合INVEST

用户故事得到测试用例的对应覆盖

DoD是针对所有需求、任务、迭代、交付定义的-整体性

验收标准AC(Accopt criteria)是针对每个需求定义的-局部性

DoR（Definition of Ready）是某一阶段正常开启的先决条件。而DoD则是某阶段产物完成的标准和原则

产品负责人-Product Owner

确定产品功能

决定发布日期和发布内容

根据市场价值等因素确定需求/用户故事优先级

为产品的POI（profitability of the product）负责

每个冲刺/迭代(Sprint)前，根据需要调整功能和优先级

接受或拒绝接受开发团队的工作成果

作为客户代言人，接受不同的需求和反馈，并不断梳理待办事项清单，但不能在迭代中影响团队现有的工作

团队促进者-Team FaciliTator、Scrum Master、Team Leader、Project Manager

在不同的敏捷模型中可能被称为项目经理、Scrum Master、Team FaciliTator等

促动者倡导仆人式领导-servant leadership

仆人式/服务型领导为团队赋权

仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效

以下仆人式领导的特征让项目领导变得更加敏捷，促进团队成功

提升自我意识-不强行决策与干预

倾听-了解根因与现状、了解团队情绪

为团队服务-解决团队现有的障碍，而不是制造麻烦

帮助他人成长-培训与辅导

引导与控制-让团队说话，在流程上控制好，而不是制造麻烦

促进安全、尊重与信任-先私下沟通，鼓励团队自组织

促进他人精力和才智提升-减少其他人对团队的影响

促动者更像是守望者，不是做决策，而是提供支持，对流程负责，对内容不负责

和PO及团队紧密地工作在一起，可以及时为团队成员提供帮助

确保团队资源完全可被利用并且全部都是高产出的，否则应提供相应的培训和指导

确保各个角色及职责的良好协作，让大家了解敏捷的真正作用与相关要求

解决团队开发中的障碍，沟通障碍，流程障碍等

做为团队和外部的接口，处理外界对团队成员的干扰-信息发射源、看板解决信息不对成的问题；新的需求转移给PO解决新需求影响团队的问题

保证开发过程按计划进行，组织各种会议-如：站立会、冲刺回顾会、迭代规划会等

辅助性角色

治理团队

PMO

设立PMO的目的是引导组织实现商业价值。敏捷PMO为价值驱动型、面向创新型、多学科型

职责

制定和实施标准：提供用户故事、测试案例、累积流图等模板，提供敏捷工具并培训支持小组了解迭代开发概念

通过培训和指导发展人才：协调敏捷培训教程、教练和导师以帮助员工过渡到敏捷思维模式并升级其技能。鼓励和支持员工参与本地敏捷活动

多项目管理：通过不同项目交流协调敏捷团队。考虑分享进度、问题、回顾性发现和改进实验等内容。借助适当的框架，项目项目管理层的主要客户发布和项目组合层的投资主题

促进组织学习：搜集项目进度信息并获取、存储和记录回顾性发现成果

管理干系人：提供产品负责人培训、指导验收测试以及评估方法、并提供系统反馈。宣扬主题专家-SME对项目的重要性

招聘、筛选和评估项目领导：制定敏捷实践者访谈指南

执行专业化项目任务：培训和提供回顾促进者，与敏捷项目问题解决者订立协议，并提供导师和教练

敏捷的方法

敏捷方法实在敏捷宣言、敏捷原则的指导下，根据不同场景总结出的良好实践

看板

看板一次字面翻译为“视觉符号”或“卡片”。带有卡片的物理看板面板能够推送和实现整个系统中工作流的可视化，让每个人都可以看到

信息发射源包括许多列，表述需要完成的工作流的状态。最简单的面板可能包含三列-要完成的工作、进行中的工作、已完成的工作，但可以调整为使用团队所需要的任何状态

看板方法应用并适用于多种场合，可以确保工作流和价值交付的持续性

完成工作比开始新工作更重要。从未完成的工作中无法获得任何价值，因此团队将协作实施和遵从在制品-WIP限制，让整个系统中的每份工作得以完成

考试中，看板通常用来展示项目情况、透明各方信息的作用

极限编程-XP-eXtreme Programming

轻量级的开发流程

主要精神：在客户有系统需求时，给予及时满意的可执行程序，适合需求快速变动的项目

强调客户所要的是workable的执行代码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以side-by-side的方式一起工作

XP的实践包括

完整团队、计划游戏、客户测试

不同层面测试：

对端对端信息使用系统级测试，对构建块使用单元测试。在两者之间，了解是否需要进行集成测试，以及在何处进行测试。

团队发现冒烟测试有助于测试工作产品是否良好

团队发现，决定何时以及对那些产品进行回归测试，也可以帮助他们在维护产品质量的同时，良好的构建性能。

敏捷团队非常偏爱自动化测试，因此他们可以借此构建和保持交付的势头

简单设计、结对编程、测试驱动开发

验收测试驱动开发-ATDD

在ATDD中，整个团队聚集在一起讨论工作产品的验收标准。然后团队创建测试，这让团队能够编写足够的代码，进行自动化测试，满足标准要求。对于非软件项目，要考虑怎样在团队完成大量价值时对工作进行测试

测试驱动开发-TDD和行为驱动开发-BDD:在编写/创建产品之前编写自动化测试，实际上可以帮助人员设计产品，防范产品错误。对于非软件项目，要考虑如何通过“测试驱动”团队的设计。硬件和机械类项目经常使用模拟进行设计的中间测试

改进设计、持续集成、集体代码所有权

持续集成：无论产品如何，都要频繁的将工作集成到整体中，然后进行重新测试，以确定整个产品依然按照预期工作

编码标准、隐喻、可持续的速度

刺探-时间盒研究或实验：刺探对学习有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助

Scrum

Scrum概述：Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员

Sprints-冲刺

Scrum的项目过程由一系列的Sprint组成

Sprint的长度一般控制在2-4周

通过固定的周期保持良好的节奏

产品的设计、开发、测试都在Sprint期间完成

Sprint结束时交付可以工作的软件

Sprint过程中不允许发生变更

Scrum of Scrums

SoS也成为“meta Scrum”,是由两个或多个Scrum团队而不是一个大型Scrum团队所使用的一种技术

其中一个团队包含3到9名成员来协调其工作。每个团队的代表会与其他团队定期召开会议，可能是每日例会，但同通常是一周两次或三次

每日例会的执行方式类似于Scrum的每日站会，其中代表将报告已完成的工作、下一步工作设置、任何当前障碍以及可能会阻碍其他团队的潜在未来障碍。其目标是确保团队协调工作并清除障碍，以优化所有团队的效率

具有多个团队的大型团队可能要求执行Scrum of Scrum of Scrums,其遵循的模式与SoS相同，每个SoS的代表向更大组织的代表报告

时间盒-Time Box

时间盒的价值

帕金森定律的一剂良药

人们往往记住的是失误的日期，而不是失误的特征

尽早促成难度大的决策和权衡

更好的控制

防止镀金，因为时间很短，没有时间镀金

运作规则

在每个时间盒的过程中，不要增加人员。Brook定律：在一个滞后的项目中加人只能使其滞后

时间盒不用来做绩效考核

时间盒内不允许有变更

每日同步

追逐太阳模式：

追逐太阳的开发过程实一种每天结束时将工作交给下一个工作地点-可能相差很多时区的方法，旨在加快产品的开发

浴缸窗口模式：

各地点之间建立长期视频会议链接，创建一个鱼缸窗口。每天工作开始时，打开链接，工作结束时，关闭链接

远程结对模式：

由两名团队成员结对，同时从事同一工作项目的技术。而远程结对是通过使用虚拟会议工作来共享屏幕，包括语音和视频链接，建立远程对接

敏捷的过渡

不同生命周期的比较

混合型生命周期

意义和价值

项目管理的目标是在当前环境下尽可能以最好的方式创造商业价值

项目采用何种生命周期的元问题：我们怎样做才能最成功的交付价值

解决价值交付过程中组织不能完全敏捷的场景、敏捷过渡期的场景、加速预测生命周期交付速度的场景以及改变团队成员思维模式的场景。目的是为了增加价值交付的效率和效果

当团队创造价值时，是否需要快速阶段性反馈？如果需要，增量方法将会有所帮助

在探讨各种想法时，是否需要随时管理风险？如果需要，迭代方法或敏捷方法将会有所帮助

当组织无法交付中间价值时，完全敏捷的方法可能不是很有用。可能会选择部分使用敏捷，部分使用预测型生命周期的方式来做项目

不同类型

敏捷的工具和预测的计划模式在整个生命周期同步存在：比如：同一项目中结合使用了预测计划法和敏捷工具及思想。如短迭代、每日站会和回顾会等。虽然它显然没充分体现敏捷思维模式、价值观和关注，不过这是一种典型的混合方法

与预测法为主，敏捷方法为辅的方法：如：某工程公司正在使用也给新的组件建筑一个设施，虽然大部分项目是常规的，可预测的，就像组织实施的许多其他设施项目一样，但这个项目包含了一种新的屋顶材料。承包商可能计划首先在地面进行一些小规模的安装迭代实验，以确定最佳安装方法，并在由足够时间解决问题时尽早发现问题

以敏捷方法为主，预测法为辅的方法：当某个特定要素不可协商，或者使用敏捷方法不可执行时，可能会使用该方法。如：集成由不同供应商开发的外部组件，这些外部组件不能或不会以协作或增量方法合作，在组件交付后，需要单独集成

答题思路

重点考察敏捷的灵魂-敏捷宣言和原则，偶尔会考察敏捷的具体工具-看板/燃尽图等

会对项目经理/SM的角色定位考察比较深入，全面了解考生是否对VUCA环境下项目经理的角色由深刻的洞见和理解

对沟通和协同的考察比较多，项目经理/SM需要有充分的仆人式领导力来为团队扫清障碍，并学会选择优秀的试点推广敏捷思想，并通过结果证明敏捷方法的好处与劣势

部分题目会关注项目质量问题，需要对DoD/AC/DoR有清楚的理解和认知

是稳定和灵活的一种平衡，需要注意通过治理团队的决策作用、产品目标和冲刺/迭代目标的清晰共识、PMO的多项目协同让项目更稳定

敏捷转型成果的策略和方法

一：渐进的过渡涉及到增加更多的迭代技术，以便改进学习，加强团队和干系人的一致性

二：考虑增加更多的增量技术，以加快对发起人的价值和投资回报

三：可以先在一个风险不大、具有中等程度不确定性的项目中尝试这些技术

四：通过组织成功的使用混合方法后，在尝试更复杂的敏捷项目，这些项目需要增加更多的敏捷技术。这是一种根据组织的情况、特定的风险、团队适应并接受改革的就绪情况而调整的渐进混合的良好过渡

交付绩效域

概要

涉及与交付项目要实现的范围和质量相关的活动和功能

预期成果

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

项目实现了启动它们要交付的成果

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

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

干系人接受项目可交付物，并对其感到满意

核心概念

需求：满足需要，某个产品、服务或结果必须达到的条件或具备的能力

工作分解结构-WBS:对项目团队实现项目目标、创建所需可交付物，而需要实施的全部工作范围的层级分解

完成的定义-DoD：为了考虑可交付物能供客户使用，而需达到的所有准则的检查清单

质量：一系列内在特征满足要求的程度

质量成本-COQ：在整个产品生命周期所产生的以下所有成本，即：为预防产品或服务不符合要求而进行的投资，为评估产品或服务是否符合要求而产生的成本，以及因产品或服务未达到要求而带来的损失

范围管理强调：不镀金、预防范围蔓延

产品范围：某项产品、服务或成果所具有的特性和功能。根据产品需求来衡量产品范围是否完成

项目范围：为交付具有规定特性与功能的产品

服务或成果而必须完成的工作。根据项目管理计划来衡量项目范围是否完成

具体环节

概述：

确保项目做且只做所需的全部工作，且实现战略和价值

定义和控制哪些工作包含在项目内，哪些不包含在项目内

规划质量管理动作，制定质量测量指标

制定项目章程

概念：编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程

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

发生时间：仅开展一次或仅在项目的预定义点开展

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

项目章程可由发起人编制，或者由项目经理与发起机构合作编制

项目章程不等于合同，无报酬、金钱、交换条件

最好在项目章程时任命项目经理，最晚也必须在规划开始之前由项目以外的机构来批准-如项目绩或项目管理办公室PMO,项目组合治理委员会主席

ITO-输入输出工具

引导

通过流程引领人们达成公共目标的艺术

引导时关注的焦点是流程-如何去做一件事，而不是内容-做些什么

注意事项

严禁使用反问句

不参杂自己的主观想法

善于确认和总结

巧妙处理冲突

项目章程

确保干系人在总体上就主要交付物、里程碑以及每个项目参与的角色和职责达成共识

包括

项目目的

可测量的项目目标和相关的成功标准

高层级需求

高层级项目描述、边界定义以及主要可交付物

整体项目风险

总体里程碑进度计划

预先批准的财务资源

关键干系人名单

项目审批需求

项目退出标准

委派的项目经理及其职责和职权

发起人或其他批准项目章程的人员的姓名和职权

假设日志

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

在项目启动之前编制项目论证时，识别高层级的战略和运营假设条件与制约因素

高层级假设条件与制约因素应纳入项目章程

详细的假设条件在项目期间伴随相关活动而生成

规划范围管理

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

作用：在整个项目期间对如何管理范围提供指南和方向

发生时间：本过程仅开展一次或在项目的预定义点开展

ITO-输入输出工具

范围管理计划

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

有助于降低项目范围蔓延的风险

定义如何完成如下过程：

制定详细项目范围说明书

根据详细项目范围说明书创建WBS

确定如何审批和维护范围基准

正式验收完成的项目可交付物

需求管理计划

记录如何分析、记录和管理需求

有些组织称之为-商业分析计划

定义如何完成如下过程

如何规划、跟踪和报告各种需求活动

配置管理活动的要求

需求优先级排序

产品测量指标

列入跟踪矩阵的项

收集需求

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

作用：为定义和管理范围奠定基础

发生时间：仅开展一次或仅在项目的预定义点开展

让干系人积极参与需求的探索和分解工作，能直接促进项目成功

需求包括发起人、客户和其他关系人的已量化并记录下来的需求和期望

收集需求从项目一开始就开始进行-分析项目章程/干系人登记册/干系人参与计划中的信息

需求是工作分解结构，成本/进度/质量规范的基础

收集需求-需求分类

ITO-输入输出工具

数据收集

头脑风暴

自由发言，面对面交流

速度快，但容易受影响

常用技巧：不批评，不表扬/以量求质/尽量扩散/最后总结

焦点小组

一定要有一个受过专业训练的主持人

引导,讨论

强调碰撞,比访谈更热烈

可分成不同小组和主题

问卷调查

设计书面问题,向众多受访者快速收集信息

适合于:受众多样化,快速完成,地理位置分散,开展统计分析

标杆对照

概念:实际项目实践与可比项目实践对比-两个项目

使用范围:组织内部或外部,同一或不同领域

两个目的:识别最佳实践,为绩效考核提供基础;规范质量管理过程也用到了标杆对照

数据分析

问卷分析

分析文档,挖掘需求

文件分析技巧:头脑风暴+焦点小组会议

可用于分析的商业文件包括:

商业计划

市场文献

协议

建议邀请书

程序和法规文件

用例

数据表现

亲和图

准备

头脑风暴法会议

制作卡片

分成小组

并成中组

归成大组

编排卡片

确定方案

思维导图

将放射性思考图形化的方法

反映创意之间的共性和差异,激发新创意

以主题为中心开始,沿着不同分支进行思考

应用于记忆\学习\思考等的思维地图,利于人脑的扩散思维的展开

常用软件:FreeMind/MindManager

人际关系与团队技能

名义小组技术：是一种结构化的头脑风暴形式,分成四个步骤

1.向集体提出一个问题或难题,每个人在沉思后写出自己的想法

2.主持人在活动挂图上记录所有人的想法

3.集体探讨各个想法,直到全体成员达成一个明确的共识

4.个人私下投票决出各种想法的优先级排序,可进行数论投票。每轮投票后，都将清点选票，得分最高者被选出

观察和交流

难以说或不愿说

又被称为工作跟随

旁观式观察，体验式观察

原型法

符合渐进明细性

原型是有型的实物，它使得干系人可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述

故事板：通过一系列图像或图示展示顺序或导航路径

广告、电影行业中，利用显示效果的视觉草图

软件开发中，通过实体模型显示网页、屏幕或者GUI

需求文件

描述各种单一的需求将如何满足于项目相关的业务需求，包括：

可跟踪的业务目标和实施项目的原因-业务需求

干系人对沟通和报告的需求-干系人需求

功能需求、非功能需求-解决方案需求

数据转换和培训需求等-过度和就绪需求

验收标准-项目需求

质量需求

一开始概括性的需求，然后逐步细化

只有明确的-可测量和可测试的、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准

需求跟踪矩阵RTM

需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值

为在整个项目生命周期中跟踪需求提供了一种方法

为管理产品范围变更提供了框架

包括：

从需求到业务需要、机会、目的和目标

从需求到项目目标

从需求到项目范围/WBS中的可交付物

从需求到产品设计

从需求到产品开发

从需求到测试策略和测试场景、脚本

从高层次需求到详细需求

定义范围

定义：指定项目和产品详细描述的过程

作用：描述产品、服务、或成果的边界和验收标准

发生时间：仅开展一次或仅在项目的预定义点开展

收集需求过程识别的所有需求未必都在本项目中完成，定义范围过程会从中选出最终的项目需求，制定出关于项目边界的具体描述

应根据项目启动过程中记载的主要可交付物、假设条件和制约因素来编制详细的项目范围说明书

在敏捷型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围-多次重复

ITO-输入输出工具

项目范围说明书

是对项目范围、主要可交付物、假设条件和控制因素的描述。包括

产品范围描述

可交付物

验收标准

项目的排外责任

制定项目范围说明书的时候，会生成更详细的假设条件和制约因素

表明项目干系人之间就项目范围所达成的共识

描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度

注意项目章程与项目范围说明书内容上的差别

创建WBS-工作分解结构

定义：把项目可交付物和项目工作分解成较小、更易于管理的组件

作用：为所要交付的内容提供架构

发生时间：仅开展一次或在项目的预定义点开展

WBS(Work Breakdown Structure):是对项目团队为实现项目目标、创建所需可交付物而需要实施的全部工作范围的层级分解

工作分解结构组织并定义项目的总范围，代表着现行项目范围说明书所规定的工作

WBS最底层的组成部分叫工作包，可针对工作安排进度、估算成本和实施监控

“工作”是指作为活动结果的工作产品或可交付物，而不是工作本身

WBS不表示逻辑关系和历时，只表示范围

ITO-输入输出工具

创建WBS

WBS具有分层结构，由团队成员共同完成制作

账户编码COA-Code Of Account:每个组成部分分配唯一的编码，识别所在的层次和位置

控制账户-Control Account:是一种管理控制点，用于挣值分析-高低决定控制粗细---每个控制账户都可以包括一个或多个工作包，但是每个工作包只能属于一个控制账户

规划包-Planning Package:在CA之下，工作包之上。知道工作内容，但暂时不确定详细工作分解

工作包-Work Package:位于工作分解结构每条分支最底层的可交付物或项目组成部分

WBS分解原则

100%包含原则：WBS分支的上下包含关系，WBS整体包含了项目所需的所有工作

MECE-Mutually Exclusive Collectively Exhaustice,互斥，完全穷尽

如果采用敏捷方法，可以将长篇故事分解成用户故事

WBS可以采用提纲式、组织结构图或能说明层级结构的其他形式

不同的可交付物可以分解到不同的层次

分解到可控层面即可

滚动式规划：远期工作或信息暂时不足的可交付物，可暂时不分解，等信息充分后继续分解

分解

目的：便于控制

程度：能够可靠的估算工作费用和持续时间

创建WBS常用方法：自上而下、使用组织特定的指南、使用WBS模板、自下而上-用于归并较低层次的组件

可作为分解第二层：项目生命周期各阶段，主要的可交付物，子项目

不能分解：很远的将来要完成的成果-WBS也是渐进明细的定义

范围基准包括：

项目范围说明书

WBS

工作包

规划包

WBS词典

对工作分解结构组成部分-包括工作包和控制账户，进行更详细的描述

内容：

账户编码标识

工作描述

假设条件制约因素

负责的组织

进度里程碑清单