文章目录
- 一、业务环境
- 1、项目合规管理（[email protected],P27&考纲）
- 考纲-规划和管理项目的合规性包括：
- 2、项目商业论证（[email protected],P30）
- 3、项目效益管理计划（[email protected],P33）
- 4、事业环境因素（[email protected],P38）
- 组织内部的事业环境因素包括：
- 组织外部的事业环境因素包括：
- 5、组织过程资产（[email protected],P39）
- 过程、政策和程序：组织用于执行项目工作的流程与程序，包括（但不限于）:
- 启动和规划
- 执行、监控
- 收尾项目收尾指南或要求（如项目终期审计、项目评价、可交付成果验收、 合同收尾、资源分配，以及向生产和（或）运营部门转移知识）。 组织知识库：组织用来存取信息的知识库，包括（但不限于）:
- 6、组织变革管理（[email protected],P161）
- 二、人员
- 1、团队章程（[email protected],P319）
- 2、塔克曼阶梯理论（[email protected],P338）
- 3、仆人式领导（敏捷实践指南-4.2,P33）
- 仆人式领导的职责主要包括：
- 4、冲突管理（[email protected],P348&[email protected],P29）
- 五种常用的冲突解决方法：
- 应在冲突已超出有益辩论的范畴而升级之前加以解决，这可带来更好的成 果。以下方法可能会有所帮助：
- 5、自组织团队
- 6、责任分配矩阵（[email protected],P316）
- 7、建设团队的工具
- 为了最小化分布式项目团队面临的困境，可以通过技术手段增加和改善沟 通。范例包括：
- 集中办公（[email protected],P340）
- 认可与奖励（[email protected],P342）
- 培训（[email protected],P342）
- 8、干系人分析（[email protected],P512）
- 9、权力利益方格（[email protected],P512）
- 10、干系人登记册（[email protected],P514）
- 11、干系人参与度评估矩阵（[email protected],P521）
- 12、干系人参与计划（[email protected],P522）
- 13、指导干系人（考纲）
- 14、谈判（[email protected],P488）
- 三、过程
- 1、项目章程（[email protected],P77）
- 2、项目管理计划（[email protected],P83）
- 3、最小可行产品-MVP（PMBOK@7,P243）
- 4、项目生命周期（[email protected],P19）
- 5、沟通方法（[email protected],P374）
- 应该采用不同方法来实现沟通管理计划所规定的主要沟通需求：
- 6、沟通技术（[email protected],P370）
- 可能影响沟通技术选择的因素包括：
- 7、文化意识（[email protected],P375）
- 8、沟通管理计划（[email protected],P377）
- 9、变更流程（[email protected],P113）
- 10、收尾流程
- 11、收集需求的工具（[email protected],P142）
- 专家判断：
- 头脑风暴：
- 访谈：
- 焦点小组：
- 问卷调查：
- 标杆对照：
- 12、需求跟踪矩阵（[email protected],P148）
- 13、范围基准（[email protected],P¹61）
- 14、范围蔓延（PMBOK@6,P715&PMP备考宝典（第2版）,P199）
- 15、关键路径法（[email protected],P210）
- 16、进度压缩（[email protected],P215）
- 17、在制品-WIP（[email protected],P99）
- 18、进度估算工具（[email protected],P200）
- 类比估算：
- 参数估算：
- 三点估算：
- 自下而上估算：
- 19、资源优化（[email protected],P211）
- 20、资源日历（[email protected],P323）
- 21、储备分析
- 应急储备（[email protected],P245）:
- 管理储备（[email protected],P252）:
- 22、控制成本的技术（[email protected],P261）
- 挣值分析（EVA）:
- 进度绩效指数：
- 成本绩效指数：
- 23、质量成本（[email protected],P282）
- 一致性成本（项目花费资金规避失败）:
- 24、审计（[email protected],P294）
- 25、采购工作说明书（[email protected],P477）
- 26、合同类型（[email protected],P471）
- 27、协议（[email protected],P489）
- 28、绩效审查（PMBOK@6,P708）
- 29、采购审计（PMBOK@6,P709）
- 30、自制或外购分析（[email protected],P473）
- 31、风险管理流程（PMBOK@6-11,P395）
- 32、风险登记册（[email protected],P417）
- 33、蒙特卡洛分析（[email protected],P433）
- 34、风险应对策略（[email protected],P442）
- 针对机会，可以考虑下列五种备选策略：
- 35、风险与问题的区别
- 36、残余风险与次生风险的区别
- 37、问题日志（[email protected],P96）
- 38、经验教训登记册（[email protected],P104）
- 39、监控项目工作的技术（[email protected],P111）
- 40、显性知识和隐性知识（PMBOK@6-术语表，P704、P716）
- 四、敏捷相关知识
- 1、敏捷宣言（敏捷实践指南-2.2,P8）
- 2、敏捷12原则（敏捷实践指南-2.2,P9）
- 3、敏捷核心实践和原则
- 包括但不限于以下：
- 敏捷不包含什么:
- 敏捷益处：
- 4、敏捷“3355”
- 三大角色：
- ①产品负责人（Product Owner）:
- ②敏捷教练（Scrum Master）:
- ③开发团队（Dev Team）:
- 三个工件：
- ①产品待办列表（Product Backlog）:
- ②冲刺/迭代待办列表（SprintBacklog）:
- ③产品增量（ProductIncrement）:
- 5种仪式：
- ①冲刺/迭代（Sprint）:
- ②迭代计划会（Sprint Planning）:
- ③每日站会（Daily Serum）:
- ④冲刺评审会（Sprint Review）:
- ⑤冲刺回顾会（Sprint Retrospective）:
- 4、优先级技术
- MoSCoW
- 计划扑克
- 5、Kanban看板
- 看板是一个跟精益和及时制生产相关的概念：
- kanban卡片：
- 6、完成的定义-DoD
- 7、准备就绪的定义-DoR
- 8、MVP
- 9、用户故事
- 10、刺探
- 11、故事点
- 12、结对编程
- 13、测试驱动开发-TDD
- 14、利特尔法则
- 15、敏捷合同管理
- 五、高频考点分析
- 1、组织变革
- 2、商业文件
- 3、需求排序
- 4、干系人与沟通
- 5、培训
- 6、虚拟团队
- 7、情商
- 8、团队章程
- 9、变更管理
- 瀑布型变更：
- 敏捷型变更：
- 10、监督风险流程
- 11、决策流程
- 问题处理流程
- 日志更新问题
- 12、常见场景
- 4.2.1 一个新人加入
- 4.2.2 重要会议
- 4.2.3 干系人直接找团队成员
- 4.2.4 团队有分歧
- 六、考试技巧总结
- 1、提升做题速度
- 2、如何精准答题
- 3、如何避免干扰
一、业务环境
1、项目合规管理（[email protected],P27&考纲）
项目需遵守其组织内外得到适当授权的法律、规则、法规和要求。但高绩效 项目会寻求通过各种方法将合规性更充分地融入项目文化，从而与可能相互冲突 的各种准则更好地保持一致性。项目经理需努力遵守旨在保护他们及其组织、干 系人和广大公众的准则。如果项目经理在行动或计划是否符合既定准则方面遇到 了相互冲突的准则或问题，他们需要寻求适当的建议和指导。
考纲-规划和管理项目的合规性包括：
● 确认项目合规要求（例如保护措施、健康和安全、监管合规）
● 对合规类别进行分类 确定合规面临的潜在威胁
● 采用干系人法为合规提供支持
● 分析不合规的后果
● 确定必要的方法和行动来满足合规需要（例如风险、法律方面的）
● 衡量项目的合规程度
2、项目商业论证（[email protected],P30）
项目商业论证指文档化的经济可行性研究报告，用来对尚缺乏充分定义的所 选方案的收益进行有效性论证，是启动后续项目管理活动的依据。商业论证列出 了项目启动的目标和理由。它有助于在项目结束时根据项目目标衡量项目是否成 功。商业论证是一种项目商业文件，可在整个项目生命周期中使用。在项目启动 之前通过商业论证，可能会做出继续/终止项目的决策。
需求评估通常是在商业论证之前进行，包括了解业务目的和目标、问题及机 会，并提出处理建议。需求评估结果可能会在商业论证文件中进行总结。
定义业务需要、分析形势、提出建议和定义评估标准的过程，适用于任何组织的项目。 （题干关键词“是否值得投资、决策、商业需求、成本效益分析”。）
3、项目效益管理计划（[email protected],P33）
项目效益管理计划描述了项目实现效益的方式和时间，以及应制定的效益衡 量机制。项目效益指为发起组织和项目预期受益方创造价值的行动、行为、产品、 服务或成果的结果。项目生命周期早期应确定目标效益，并据此制定效益管理计 划。它描述了效益的关键要素，可能包括（但不限于）记录以下内容：
● 目标效益（例如预计通过项目实施可以创造的有形价值和无形价值；财务价值体现为净现值）；
● 战略一致性（例如项目效益与组织业务战略的一致程度）；
● 实现效益的时限（例如阶段效益、短期效益、长期效益和持续效益）；
● 效益责任人（例如在计划确定的整个时限内负责监督、记录和报告已实现效 益的负责人）；
● 测量指标（例如用于显示已实现效益的直接测量值和间接测量值）； 假设（例如预计存在或显而易见的因素）；
● 风险（例如实现效益的风险）。
制定效益管理计划需要使用商业论证和需求评估中的数据和信息，例如，成本效益分析数据。
在成本效益分析中已经把成本估算与项目拟实现的效益进行了比较。效益管理计划和项目管理计划描述了项目创造的商业价值如何能够成为组织持续运营 的一部分，包括使用的测量指标。测量指标可核实商业价值并确认项目成功与否。
项目效益管理计划的制定和维护是一项迭代活动。它是商业论证、项目章程 和项目管理计划的补充性文件。项目经理与发起人共同确保项目章程、项目管理 计划和效益管理计划在整个项目生命周期内始终保持一致。
4、事业环境因素（[email protected],P38）
事业环境因素（EEFs）是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。这些条件可能来自于组织的内部和（或）外部。事业 环境因素是很多项目管理过程，尤其是大多数规划过程的输入。这些因素可能会提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极的影响。从性质或类型上讲，事业环境因素是多种多样的。有效开展项目，就必须考虑这些因 素。
组织内部的事业环境因素包括：
● 组织文化、结构和治理。例如包括愿景、使命、价值观、信念、文化规范、 领导风格、等级制度和职权关系、组织风格、道德和行为规范。
● 设施和资源的地理分布。例如包括工厂位置、虚拟团队、共享系统和云计算。 基础设施。例如包括现有设施、设备、组织通讯渠道、信息技术硬件、可用 性和功能。
● 信息技术软件。例如包括进度计划软件工具、配置管理系统、进入其他在线自动化系统的网络界面和工作授权系统。
● 资源可用性。例如包括合同和采购制约因素、获得批准的供应商和分包商以及合作协议。 员工能力。例如包括现有人力资源的专业知识、技能、能力和特定知识。
组织外部的事业环境因素包括：
● 市场条件。例如包括竞争对手、市场份额、品牌认知度和商标。
● 社会和文化影响与问题。例如包括政治氛围、行为规范、道德和观念。
● 法律限制。例如包括与安全、数据保护、商业行为、雇佣和采购有关的国家或地方法律法规。
● 商业数据库。例如包括标杆对照成果、标准化的成本估算数据、行业风险研 究资料和风险数据库。
● 学术研究。例如包括行业研究、出版物和标杆对照成果。
● 政府或行业标准。例如包括与产品、生产、环境、质量和工艺有关的监管机 构条例和标准。
● 财务考虑因素。例如包括货币汇率、利率、通货膨胀率、关税和地理位置。
● 物理环境要素。例如包括工作环境、天气和制约因素。
5、组织过程资产（[email protected],P39）
组织过程资产是执行组织所特有并使用的计划、过程、政策、程序和知识库， 会影响对具体项目的管理。
组织过程资产包括来自任何（或所有）项目执行组织的，可用于执行或治理 项目的任何工件、实践或知识，还包括来自组织以往项目的经验教训和历史信息。 组织过程资产可能还包括完成的进度计划、风险数据和挣值数据。组织过程资产 是许多项目管理过程的输入。由于组织过程资产存在于组织内部，在整个项目期 间，项目团队成员可对组织过程资产进行必要的更新和增补。组织过程资产可分 成以下两大类：
过程、政策和程序：组织用于执行项目工作的流程与程序，包括（但不限于）:
启动和规划
● 指南和标准，用于裁剪组织标准流程和程序以满足项目的特定要求；
● 特定的组织标准，例如政策（如人力资源政策、健康与安全政策、安保与保 密政策、质量政策、采购政策和环境政策）；
● 产品和项目生命周期，以及方法和程序（如项目管理方法、评估指标、过程 审计、改进目标、核对单、组织内使用的标准化的过程定义）；
● 模板（如项目管理计划、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵，以及干系人 登记册模板）；
预先批准的供应商清单和各种合同协议类型（如总价合同、成本补偿合同和 工料合同）。
执行、监控
● 变更控制程序，包括修改组织标准、政策、计划和程序（或任何项目文件） 所须遵循的步骤，以及如何批准和确认变更；
● 跟踪矩阵；
● 财务控制程序（如定期报告、必需的费用与支付审查、会计编码及标准合同 条款等）；
● 问题与缺陷管理程序（如定义问题和缺陷控制、识别与解决问题和缺陷，以 及跟踪行动方案）；
● 资源的可用性控制和分配管理；
● 组织对沟通的要求（如可用的沟通技术、许可的沟通媒介、记录保存政策、 视频会议、协同工具和安全要求）；
● 确定工作优先顺序、批准工作与签发工作授权的程序； >模板（如风险登记册、问题日志和变更日志）；
● 标准化的指南、工作指示、建议书评价准则和绩效测量准则； 产品、服务或成果的核实和确认程序。
收尾项目收尾指南或要求（如项目终期审计、项目评价、可交付成果验收、 合同收尾、资源分配，以及向生产和（或）运营部门转移知识）。 组织知识库：组织用来存取信息的知识库，包括（但不限于）:
● 配置管理知识库，包括软件和硬件组件版本以及所有执行组织的标准、政策、 程序和任何项目文件的基准；
● 财务数据库，包括人工时、实际成本、预算和成本超支等方面的信息； 历史信息与经验教训知识库（如项目记录与文件、完整的项目收尾信息与文 件、关于以往项目选择决策的结果及以往项目绩效的信息，以及从风险管理 活动中获取的信息）；
● 问题与缺陷管理数据库，包括问题与缺陷的状态、控制信息、解决方案以及 相关行动的结果；
● 测量指标数据库，用来收集与提供过程和产品的测量数据；
● 以往项目的项目档案（如范围、成本、进度与绩效测量基准，项目日历，项 目进度网络图，风险登记册，风险报告以及干系人登记册）。
6、组织变革管理（[email protected],P161）
《组织变革管理：实践指南》是一个迭代模型，它基于一系列变革管理模型
中的常见要素。该框架有通过一系列反馈闭环相互关联的五个要素：
● 启动变革。该要素侧重于确定理由，以帮助人们了解为什么需要变革以及如 何使未来状态变得更好。
● 规划变革。确定活动有助于人们为从当前状态过渡到未来状态做好准备。 实施变革。该迭代要素侧重于表明未来状态的能力，进行检查以确保这些能 力能够产生预期影响，并作为应对措施进行必要的改进或调整。
● 管理过渡。该要素会考虑如何应对与未来状态实现后可能出现的变革相关的 需要。
● 维持变革。该要素旨在确保新的能力能够得以保持，而以前的过程或行为得 以停止。
二、人员
1、团队章程（[email protected],P319）
团队章程是为团队创建团队价值观、共识和工作指南的文件。团队章程可能 包括（但不限于）:
● 团队价值观；
● 沟通指南；
● 决策标准和过程；
● 冲突处理过程；
● 会议指南；
● 团队共识。
团队章程对项目团队成员的可接受行为确定了明确的期望。尽早认可并遵守 明确的规则，有助于减少误解，提高生产力；讨论诸如行为规范、沟通、决策、 会议礼仪等领域，团队成员可以了解彼此重要的价值观。由团队制定或参与制定 的团队章程可发挥最佳效果。所有项目团队成员都分担责任，确保遵守团队章程 中规定的规则。可定期审查和更新团队章程，确保团队始终了解团队基本规则， 并指导新成员融入团队。
（题干关键词“纪律问题、不认真开会、团队的最佳实践”。）
2、塔克曼阶梯理论（[email protected],P338）
塔克曼阶梯理论，其中包括团队建设通常要经过的五个阶段。尽管这些阶段 通常按顺序进行，然而，团队停滞在某个阶段或退回到较早阶段的情况也并非罕 见；而如果团队成员曾经共事过，项目团队建设也可跳过某个阶段。
● 形成阶段。在本阶段，团队成员相互认识，并了解项目情况及他们在项目中 的正式角色与职责。在这一阶段，团队成员倾向于相互独立，不一定开诚布公。（题干关键词“独立、自我、不开放、组建”；适合指令型领导风格）
● 震荡阶段。在本阶段，团队开始从事项目工作、制定技术决策和讨论项目管理方法。如果团队成员不能用合作和开放的态度对待不同观点和意见，团队环境可能变得事与愿违。（题干关键词“冲突、反对、争执”；适合影响型 /教练型领导风格）
● 规范阶段。在规范阶段，团队成员开始协同工作，并调整各自的工作习惯和 行为来支持团队，团队成员会学习相互信任。（题干关键词“开始建立信任、 喜欢互动”；适合参与型/支持型领导风格）
成熟阶段。进入这一阶段后，团队就像一个组织有序的单位那样工作，团队 成员之间相互依靠，平稳高效地解决问题。（题干关键词“组织有序、相互协助”；适合授权型领导风格）
● 解散阶段。在解散阶段，团队完成所有工作，团队成员离开项目。通常在项 目可交付成果完成之后，或者，在结束项目或阶段过程中，释放人员，解散团队。
某个阶段持续时间的长短，取决于团队活力、团队规模和团队领导力。项目 经理应该对团队活力有较好的理解，以便有效地带领团队经历所有阶段。
3、仆人式领导（敏捷实践指南-4.2,P33）
仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成 员的需要和发展，旨在使团队尽可能达到最高绩效。仆人式领导的作用是促进团 队发现和定义敏捷。仆人式领导实践并传播敏捷。
仆人式领导按照以下顺序从事项目工作：
● 目的。与团队一起定义“为什么”或目的，以便他们能围绕项目目标进行合 作互动。整个团队在项目层面而不是在人员层面优化。
● 人员。目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队 成员在项目工作中做出贡献。
● 过程。不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团 队能够常常交付完成的价值并反思产品和过程，团队就是敏捷的。团队将其 过程称作什么并不重要。
以下仆人式领导的特征让项目领导变得更加敏捷，促进团队的成功：
● 提升自我意识；
● 倾听；
● 为团队服务；
● 帮助他人成长；
● 引导与控制；
● 促进安全、尊重与信任；
● 促进他人精力和才智提升。
仆人式领导的职责主要包括：
● 项目经理成为仆人式领导时，工作重点就会从“管理协调”转向“促进合作”。
● 消除组织障碍。
● 注重为团队铺路，让团队尽其所能。
● 教育干系人，使其了解为什么要敏捷以及如何敏捷。
● 通过指导、鼓励和帮助为团队提供支持。倡导团队成员的培训和职业发展。
● 通过技术项目管理活动，如量化风险分析来帮助团队。比如通过提供培训或 开展某些活动来为不具备某些经验或知识的团队提供支持。
● 庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用。创造 相互欣赏的积极氛围，建立加强合作的良好意愿。
4、冲突管理（[email protected],P348&[email protected],P29）
成功的冲突管理可提高生产力，改进工作关系。同时，如果管理得当，意见 分歧有利于提高创造力和改进决策。假如意见分歧成为负面因素，应该首先由项 目团队成员负责解决；如果冲突升级，项目经理应提供协助，促成满意的解决方 案，采用直接和合作的方式，尽早并且通常在私下处理冲突。如果破坏性冲突继 续存在，则可使用正式程序，包括采取惩戒措施。
五种常用的冲突解决方法：
● 撤退/回避。从实际或潜在冲突中退出，将问题推迟到准备充分的时候，或者将问题推给其他人员解决。（未解决问题；题干关键词“退出、推迟到准备 充分、推给其他人解决”。）
● 缓和/包容。强调一致而非差异；为维持和谐关系而退让一步，考虑其他方的 需要。（冲突依然存在；题干关键词“强调一致性”。）
● 妥协/调解。为了暂时或部分解决冲突，寻找能让各方都在一定程度上满意的 方案，但这种方法有时会导致“双输”局面。（双赢或双输；题干关键词“一 定程度满意”。）
● 强迫/命令。以牺牲其他方为代价，推行某一方的观点；只提供赢一输方案。 通常是利用权力来强行解决紧急问题，这种方法通常会导致“赢输”局面。 （输赢二选一；题干关键词“解决紧急问题”。）
● 合作/解决问题。综合考虑不同的观点和意见，采用合作的态度和开放式对话 引导各方达成共识和承诺，这种方法可以带来双赢局面。（双赢；题干关键 词“公开对话、达成共识”。）
应在冲突已超出有益辩论的范畴而升级之前加以解决，这可带来更好的成 果。以下方法可能会有所帮助：
● 沟通时要开诚布公且对人要表现出尊重。由于冲突可能会引起焦虑，因此必 须保持安全的环境来探索冲突的根源。没有安全的环境，人们就会停止沟通。 确保言语、语调和肢体语言不具有威胁性。
● 聚焦于问题，而不是针对人。之所以会发生冲突，是因为人们对情况有不同 看法。应做到对事不对人。重点是解决问题，而不是指责。
● 聚焦于当前和未来，而不是过去。保持聚焦于当前的情况，而不是过去的情 况。如果以前发生过类似的事情，那么旧事重提不会解决当前的问题。事实 上，它会进一步加剧当前的冲突情况。
● 一起寻找备选方案。冲突造成的损害可以通过寻找解决办法和替代方案来加
以修复。这样还可以建立更具建设性的关系。这种做法会使冲突进入更有利 于解决问题的空间，人们可以共同努力，形成创造性的替代方案。
5、自组织团队
对于拥有自组织团队的项目，“项目经理”（可能不称为“项目经理”）的 角色主要是为团队创造环境、提供支持并信任团队可以完成工作。成功的自组织 团队通常由通用的专才而不是主题专家组成，他们能够不断适应变化的环境并采 纳建设性反馈。
6、责任分配矩阵（[email protected],P316）
责任分配矩阵展示项目资源在各个工作包中的任务分配。矩阵型图表的一个 例子是职责分配矩阵（RAM）,它显示了分配给每个工作包的项目资源，用于 说明工作包或活动与项目团队成员之间的关系。在大型项目中，可以制定多个层 次的RAM。例如，高层次的RAM可定义项目团队、小组或部门负责WBS中的 哪部分工作，而低层次的RAM则可在各小组内为具体活动分配角色、职责和职 权。矩阵图能反映与每个人相关的所有活动，以及与每项活动相关的所有人员， 它也可确保任何一项任务都只有一个人负责，从而避免职权不清。
RAM的一个例子是RACI（执行、负责、咨询和知情）矩阵。分配给每项 工作的资源可以是个人或小组，项目经理也可根据项目需要，选择“领导”或“资 源”等适用词汇，来分配项目责任。如果团队是由内部和外部人员组成，RACI 矩阵对明确划分角色和职责特别有用。
（题干关键词“角色与职责、成员不知道如何完成工作、每项工作由谁来做、 不清楚职责”。）
7、建设团队的工具
虚拟团队/分布式团队（[email protected],P333&[email protected],P30）
虚拟团队的使用为招募项目团队成员提供了新的可能性。虚拟团队可定义为 具有共同目标、在完成角色任务的过程中很少或没有时间面对面工作的一群人。 现代沟通技术（如电子邮件、电话会议、社交媒体、网络会议和视频会议等）使 虚拟团队成为可行。虚拟团队模式使人们有可能：
● 在组织内部地处不同地理位置的员工之间组建团队；
● 为项目团队增加特殊技能，即使相应的专家不在同一地理区域；
● 将在家办公的员工纳入团队；
● 在工作班次、工作小时或工作日不同的员工之间组建团队；
● 将行动不便者或残疾人纳入团队；
● 执行那些原本会因差旅费用过高而被搁置或取消的项目；
● 节省员工所需的办公室和所有实物设备的开支。
● 在虚拟团队的环境中，沟通规划变得日益重要。可能需要花更多时间，来设定明确的期望、促进沟通、制定冲突解决方法、召集人员参与决策、理解文化差 异，以及共享成功喜悦。
为了最小化分布式项目团队面临的困境，可以通过技术手段增加和改善沟 通。范例包括：
● 确保建立方便人们协同工作的协作网站。
● 建立一个项目团队网站，以便提供与项目和项目团队相关的所有相关信息。 使用音频和视频功能来举行会议。
● 通过即时消息和短信等技术一直保持联系。 及时了解远程项目团队成员。
● 至少举行一次面对面会议，以建立关系。 （题干关键词“远程办公、分布式团队、沟通技术”。）
集中办公（[email protected],P340）
集中办公是指把许多或全部最活跃的项目团队成员安排在同一个物理地点 工作，以增强团队工作能力。集中办公既可以是临时的（如仅在项目特别重要的 时期）,也可以贯穿整个项目。实施集中办公策略，可借助团队会议室、张贴进 度计划的场所，以及其他能增进沟通和集体感的设施。
（题干关键词“同一地点工作、有效沟通”。）
认可与奖励（[email protected],P342）
在建设项目团队过程中，需要对成员的优良行为给予认可与奖励。最初的奖励计划是在规划资源管理过程中编制的，只有能满足被奖励者的某个重要需求的 奖励，才是有效的奖励。在管理项目团队过程中，可以正式或非正式的方式做出奖励决定，但在决定认可与奖励时，应考虑文化差异。
当人们感受到自己在组织中的价值，并且可以通过获得奖励来体现这种价值， 他们就会受到激励。通常，金钱是奖励制度中的有形奖励，然而也存在各种同样 有效、甚至更加有效的无形奖励。
大多数项目团队成员会因得到成长机会、获得成就感、得到赞赏以及用专业 技能迎接新挑战，而受到激励。项目经理应该在整个项目生命周期中尽可能地给 予表彰，而不是等到项目完成时。
（题干关键词“激励”。）
培训（[email protected],P342）
培训包括旨在提高项目团队成员能力的全部活动，可以是正式或非正式的， 方式包括课堂培训、在线培训、计算机辅助培训、在岗培训（由其他项目团队成 员提供）、辅导及训练。如果项目团队成员缺乏必要的管理或技术技能，可以把 对这种技能的培养作为项目工作的一部分。项目经理应该按资源管理计划中的安 排来实施预定的培训，也应该根据管理项目团队过程中的观察、交谈和项目绩效 评估的结果，来开展必要的计划外培训，培训成本通常应该包括在项目预算中， 或者如果增加的技能有利于未来的项目，则由执行组织承担。培训可以由内部或 外部培训师来执行。
（题干关键词“技能不足”。）
8、干系人分析（[email protected],P512）
干系人分析会产生干系人清单和关于干系人的各种信息，例如，在组织内的 位置、在项目中的角色、与项目的利害关系、期望、态度（对项目的支持程度）, 以及对项目信息的兴趣。干系人的利害关系可包括（但不限于）以下各条的组合：
● 兴趣。个人或群体会受与项目有关的决策或成果的影响。
● 权利（合法权利或道德权利）。国家的法律框架可能已就干系人的合法权利做出规定，如职业健康和安全。道德权利可能涉及保护历史遗迹或环境的可 持续性。
● 所有权。
● 知识。
● 人员或群体对资产或财产拥有的法定所有权。
● 专业知识有助于更有效地达成项目目标和组织成果，或有助于了解组织的权 力结构，从而有益于项目。
● 贡献。提供资金或其他资源，包括人力资源，或者以无形方式为项目提供支 持，例如，宣传项目目标，或在项目与组织权力结构及政治之间扮演缓冲角色。
（题干关键词“干系人信息（权力、角色、利益、关系、态度、影响……）、 识别完干系人、某干系人抵制项目”。）
9、权力利益方格（[email protected],P512）
基于干系人的职权级别（权力）、对项目成果的关心程度（利益）、对项目 成果的影响能力（影响）,或改变项目计划或执行的能力，每一种方格都可用于 对干系人进行分类。对于小型项目、干系人与项目的关系很简单的项目，或干系 人之间的关系很简单的项目，这些分类模型非常实用。
（题干关键词“职权级别、关心程度”。）
10、干系人登记册（[email protected],P514）
干系人登记册是识别干系人过程的主要输出。它记录关于已识别干系人的信 息，包括（但不限于）:
● 身份信息。姓名、组织职位、地点、联系方式，以及在项目中扮演的角色。
● 评估信息。主要需求、期望、影响项目成果的潜力，以及干系人最能影响或 冲击的项目生命周期阶段。
● 干系人分类。用内部或外部，作用、影响、权力或利益，上级、下级、外围或横向，或者项目经理选择的其他分类模型，进行分类的结果。
11、干系人参与度评估矩阵（[email protected],P521）
干系人参与度评估矩阵用于将干系人当前参与水平与期望参与水平进行比 较。干系人参与水平可分为如下：
● 不了解型。不知道项目及其潜在影响。
● 抵制型。知道项目及其潜在影响，但抵制项目工作或成果可能引发的任何变更。此类干系人不会支持项目工作或项目成果。
● 中立型。了解项目，但既不支持，也不反对。
● 支持型。了解项目及其潜在影响，并且会支持项目工作及其成果。
● 领导型。了解项目及其潜在影响，而且积极参与以确保项目取得成功。
12、干系人参与计划（[email protected],P522）
干系人参与计划是项目管理计划的组成部分。它确定用于促进干系人有效参 与决策和执行的策略和行动。基于项目的需要和干系人的期望，干系人参与计划 可以是正式或非正式的，非常详细或高度概括的。
干系人参与计划可包括（但不限于）调动个人或干系人参与的特定策略或方 法。
（干系人参与计划与干系人登记册区分：前者包括干系人的应对策略，后者 记录了干系人的基本信息。）
13、指导干系人（考纲）
● 安排时间进行指导。
● 识别并利用指导机会。
14、谈判（[email protected],P488）
谈判是为达成协议而进行的讨论。采购谈判是指在合同签署之前，对合同的结构、各方的权利和义务，以及其他条款加以澄清，以便双方达成共识。最终的 文件措辞应该反映双方达成的全部一致意见。谈判以签署买方和卖方均可执行的 合同文件或其他正式协议而结束。
谈判应由采购团队中拥有合同签署职权的成员主导。项目经理和项目管理团 队的其他成员可以参加谈判并提供必要的协助。
（题干关键词“确认资源可用性、获取资源、资源被人调走、需要人员完成 任务”。）
三、过程
1、项目章程（[email protected],P77）
项目章程在项目执行组织与需求组织之间建立起伙伴关系。在执行外部项目 时，通常需要用正式的合同来达成合作协议。这种情况下，可能仍要用项目章程 来建立组织内部的合作关系，以确保正确交付合同内容。项目章程一旦被批准， 就标志着项目的正式启动。在项目中，应尽早确认并任命项目经理，最好在制定 项目章程时就任命，且总应在规划开始之前任命。项目章程可由发起人编制，或 者由项目经理与发起机构合作编制。通过这种合作，项目经理可以更好地了解项 目目的、目标和预期效益，以便更有效地向项目活动分配资源。项目章程授权项 目经理规划、执行和控制项目。
项目由项目以外的机构来启动，如发起人、项目集或项目管理办公室（PMO）、 项目组合治理委员会主席或其授权代表。项目启动者或发起人应该具有一定的职 权，能为项目获取资金并提供资源。项目可能因内部经营需要或外部影响而启动， 故通常需要编制需求分析、可行性研究、商业论证或有待项目处理的情况的描述。 通过编制项目章程，来确认项目符合组织战略和日常运营的需要。不要把项目章 程看作合同，因为其中未承诺报酬或金钱或用于交换的对价。
（题干关键词“初始阶段、项目经理加入新项目、发起人要求立即开始项目、 高层次、整体、高层次/级、整体、项目目标、项目经理权力责任”。）
2、项目管理计划（[email protected],P83）
项目管理计划确定项目的执行、监控和收尾方式，其内容会因项目所在的应 用领域和复杂程度而异。
项目管理计划可以是概括或详细的，而每个组成部分的详细程度取决于具体 项目的要求。项目管理计划应足够强大，可以应对不断变化的项目环境。这种敏 捷性有利于随项目进展产出更准确的信息。
项目管理计划应基准化，即，至少应规定项目的范围、时间和成本方面的基准，以便据此考核项目执行情况和管理项目绩效。在确定基准之前，可能要对项 目管理计划进行多次更新，且这些更新无需遵循正式流程。但是，一旦确定了基 准，就只能通过实施整体变更控制过程进行更新。在这种情况下，如果需要进行变更，应提出变更请求以待决定。这一过程将形成一份项目管理计划。在项目收 尾之前，该计划需要通过不断更新来渐进明细，并且这些更新需要得到控制和批准。
项目管理计划与项目文件的区别：前者是规则文件，一般不轻易改变，如成本管理计划就是如何做预算的规则，包括单位是元还是万元等；后者是记录项目 具体的数据和信息，如需求文件、成本估算、问题日志等。
3、最小可行产品-MVP（PMBOK@7,P243）
一个概念，通过识别可交付价值的最少数量的特性或需求，用来定义向客户 首次发布解决方案的范围。
4、项目生命周期（[email protected],P19）
项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关，这 些阶段称为开发生命周期。开发生命周期可以是预测型、迭代型、增量型、适应 型或混合型的模式：
● 预测型生命周期，在生命周期的早期阶段确定项目范围、时间和成本。对任 何范围的变更都要进行仔细管理。预测型生命周期也称为瀑布型生命周期。
● 迭代型生命周期，项目范围通常于项目生命周期的早期确定，但时间及成本 估算将随着项目团队对产品理解的不断深入而定期修改。迭代方法是通过一 系列重复的循环活动来开发产品，而增量方法是渐进地增加产品的功能。
● 增量型生命周期是通过在预定的时间区间内渐进增加产品功能的一系列迭 代来产出可交付成果。只有在最后一次迭代之后，可交付成果具有了必要和 足够的能力，才能被视为完整的。
● 适应型生命周期属于敏捷型、迭代型或增量型。详细范围在迭代开始之前就得到了定义和批准。适应型生命周期也称为敏捷或变更驱动型生命周期。
● 混合型生命周期是预测型生命周期和适应型生命周期的组合。充分了解或有 确定需求的项目要素遵循预测型开发生命周期，而仍在发展中的要素遵循适 应型开发生命周期。
由项目管理团队确定各个项目最适合的生命周期。项目生命周期需要足够灵 活，能够应对项目包含的各种因素。可以通过以下方法实现生命周期的灵活性：
● 确定需要在各个阶段实施的一个或多个过程；
● 在合适的阶段实施确定的一个或多个过程；
● 调整阶段的各种属性（例如名称、持续时间、退出标准和准入标准）。
项目生命周期与产品生命周期相互独立，后者可能由项目产生。产品生命周 期指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。
5、沟通方法（[email protected],P374）
项目干系人之间用于分享信息的沟通方法有几种。这些方法可以大致分为：
● 互动沟通。在两方或多方之间进行的实时多向信息交换。它使用诸如会议、 电话、即时信息、社交媒体和视频会议等沟通工件。（题干关键词“会议、 电话、及时通信、视频、实时、面对面”。）
● 推式沟通。向需要接收信息的特定接收方发送或发布信息。这种方法可以确 保信息的发送，但不能确保信息送达目标受众或被目标受众理解。在推式沟 通中，可以采用的沟通工件包括信件、备忘录、报告、电子邮件、传真、语 音邮件、博客、新闻稿。（题干关键词“特定群体、邮件”。）
● 拉式沟通。适用于大量复杂信息或大量信息受众的情况。它要求接收方在遵 守有关安全规定的前提之下自行访问相关内容。这种方法包括门户网站、企 业内网、电子在线课程、经验教训数据库或知识库。（题干关键词“大量信 息、受众广泛”。）
应该采用不同方法来实现沟通管理计划所规定的主要沟通需求：
● 人际沟通。个人之间交换信息，通常以面对面的方式进行。
●小组沟通。在三到六名人员的小组内部开展。
● 公众沟通。单个演讲者面向一群人。
● 大众传播。信息发送人员或小组与大量目标受众（有时为匿名）之间只有最低程度的联系。
● 网络和社交工具沟通。借助社交工具和媒体，开展多对多的沟通。
6、沟通技术（[email protected],P370）
用于在项目干系人之间传递信息的方法很多。信息交换和协作的常见方法包 括对话、会议、书面文件、数据库、社交媒体和网站。
可能影响沟通技术选择的因素包括：
● 信息需求的紧迫性。信息传递的紧迫性、频率和形式可能因项目而异，也可 能因项目阶段而异。
● 技术的可用性与可靠性。用于发布项目沟通工件的技术，应该在整个项目期 间都具备兼容性和可得性，且对所有干系人都可用。
● 易用性。沟通技术的选择应适合项目参与者，而且应在合适的时候安排适当 的培训活动。
● 项目环境。团队会议与工作是面对面还是在虚拟环境中开展，成员处于一个 还是多个时区，他们是否使用多语种沟通，是否还有能影响沟通效率的其他 环境因素（如与文化有关的各个方面）
● 信息的敏感性和保密性。需要考虑的一些方面有：
拟传递的信息是否属于敏感或机密信息?如果是，可能需要采取合理的安全 措施。
为员工制定社交媒体政策，以确保行为适当、信息安全和知识产权保护。
7、文化意识（[email protected],P375）
文化意识指理解个人、群体和组织之间的差异，并据此调整项目的沟通策略。 具有文化意识并采取后续行动，能够最小化因项目干系人社区内的文化差异而导致的理解错误和沟通错误。文化意识和文化敏感性有助于项目经理依据干系人和 团队成员的文化差异和文化需求对沟通进行规划。
（题干关键词“两拨人的背景不同、文化差异、风格差异”。）
8、沟通管理计划（[email protected],P377）
沟通管理计划是项目管理计划的组成部分，描述将如何规划，结构化、执行 与监督项目沟通，以提高沟通的有效性。该计划包括如下信息：
● 干系人的沟通需求；
● 需沟通的信息，包括语言、形式、内容和详细程度；
● 上报步骤； 发布信息的原因；
● 发布所需信息、确认已收到，或作出回应（若适用）的时限和频率；
● 负责沟通相关信息的人员； 负责授权保密信息发布的人员；
● 接收信息的人员或群体，包括他们的需要、需求和期望；
● 用于传递信息的方法或技术，如备忘录、电子邮件、新闻稿，或社交媒体； 为沟通活动分配的资源，包括时间和预算；
● 随着项目进展，如项目不同阶段干系人社区的变化，而更新与优化沟通管理 计划的方法； 通用术语表；
● 项目信息流向图、工作流程（可能包含审批程序）、报告清单和会议计划等； 来自法律法规、技术、组织政策等的制约因素。
● 沟通管理计划中还包括关于项目状态会议、项目团队会议、网络会议和电子 邮件等的指南和模板。如果项目要使用项目网站和项目管理软件，那就要把它们 写进沟通管理计划。
（题干关键词“信息、报告、项目状态、误解、通知、开会、上报步骤、术语表”。）
9、变更流程（[email protected],P113）
实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项 目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查 对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的 处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如 果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风 险。
实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任。在整个 项目生命周期的任何时间，参与项目的任何干系人都可以提出变更请求。
在基准确定之前，变更无需正式受控于实施整体变更控制过程。一旦确定了 项目基准，就必须通过本过程来处理变更请求。
尽管也可以口头提出，但所有变更请求都必须以书面形式记录，并纳入变更 管理和（或）配置管理系统中。
做题方法：
● 审批前，三步骤：提出变更→提出影响→提交审批；
● 凡变更，必流程；
●动基准，先变更：基准包括范围基准、进度基准、成本基准；
● 遇蔓延，找变更；
● 有变更，要沟通；
● 有权变，找变更；
● 外部变更先沟通，内部变更先分析：外部指团队成员以外的外部干系人，内部指项目团队成员。
10、收尾流程
在结束项目时，项目经理需要回顾项目管理计划，确保所有项目工作都已完 成以及项目目标均已实现。项目或阶段行政收尾所需的必要活动包括（但不限于）:
◆为达到阶段或项目的完工或退出标准所必须的行动和活动，例如：
● 确保所有文件和可交付成果都已是最新版本，且所有问题都已得到解决；
● 确认可交付成果已交付给客户并已获得客户的正式验收；
● 确保所有成本都已记入项目成本账；
● 关闭项目账户；
● 重新分配人员；
● 处理多余的项目材料；
● 重新分配项目设施、设备和其他资源；
● 根据组织政策编制详尽的最终项目报告。
◆为关闭项目合同协议或项目阶段合同协议所必须开展的活动，例如：
● 确认卖方的工作已通过正式验收；
● 最终处置未决索赔；
● 更新记录以反映最后的结果； 存档相关信息供未来使用。
◆为完成下列工作所必须开展的活动： 收集项目或阶段记录；
● 审计项目成败；
● 管理知识分享和传递；
● 总结经验教训；
存档项目信息以供组织未来使用。
◆为向下一个阶段，或者向生产和（或）运营部门移交项目的产品、服务或成 果所必须开展的行动和活动。
◆收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部 门。
◆测量干系人的满意程度。
如果项目在完工前就提前终止，结束项目或阶段过程还需要制定程序，来调查和记录提前终止的原因。为了实现上述目的，项目经理应该引导所有合适的干 系人参与本过程。
做题方法：
● 有收尾，先验收；
● 遇终止，要收尾。
11、收集需求的工具（[email protected],P142）
专家判断：
应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的 意见：商业分析；需求获取；需求分析；需求文件；以往类似项目的项目需求； 图解技术；引导；冲突管理。
（题干关键词“行业、法律、某领域、干系人不相信项目经理”。）
头脑风暴：
头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术。
访谈：
访谈是通过与干系人直接交谈，来获取信息的正式或非正式的方法。访谈有 经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需 产品可交付成果的特征和功能。访谈也可用于获取机密信息。
焦点小组：
焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务 或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点 小组往往比“一对一”的访谈更热烈。
问卷调查：
问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查 方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分 散，并且适合开展统计分析。
标杆对照：
标杆对照将实际或计划的产品、过程和实践，与其他可比组织的实践进行比 较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
12、需求跟踪矩阵（[email protected],P148）
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一 种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助 于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟 踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候 都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。
跟踪需求包括（但不限于）：
● 业务需要、机会、目的和目标；
● 项目目标；
● 项目范围和WBS可交付成果；
● 产品设计；
● 产品开发；
● 测试策略和测试场景；
● 高层级需求到详细需求。
应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需 求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、 收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已 取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。为确保干系人 满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。
（题干关键词“干系人对可交付物的所有权有争议、如何跟踪需求、可交付 物的变更过程、与业务目标的联系”。）
13、范围基准（[email protected],P¹61）
范围基准是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正 式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括：
● 项目范围说明书。项目范围说明书包括对项目范围、主要可交付成果、假设 条件和制约因素的描述。（题干关键词“可交付物、不知道如何满足需求、 验收标准、项目除外责任”。）
●WBS。WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实 施的全部工作范围的层级分解。工作分解结构每向下分解一层，代表对项目 工作更详细的定义。
● 工作包。WBS的最低层级是带有独特标识号的工作包。这些标识号为进行 成本、进度和资源信息的逐层汇总提供了层级结构，构成账户编码。每个工 作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点 上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。控制账 户拥有两个或更多工作包，但每个工作包只与一个控制账户关联。
● 规划包。一个控制账户可以包含一个或多个规划包，其是一种低于控制账户 而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
● WBS词典。WBS词典是针对WBS中的每个组件，详细描述可交付成果、 活动和进度信息的文件。WBS词典对WBS提供支持，其中大部分信息由其 他过程创建，然后在后期添加到词典中。WBS词典中的内容可能包括（但 不限于）:账户编码标识；工作描述；假设条件和制约因素；负责的组织； 进度里程碑；相关的进度活动；所需资源；成本估算；质量要求；验收标准； 技术参考文献；协议信息。
14、范围蔓延（PMBOK@6,P715&PMP备考宝典（第2版）,P199）
未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。
范围蔓延一般有两种：一种是范围爬行，即在客户要求下未经正常的范围变 更控制程序；另一种是范围镀金，指项目团队没有经过范围变更控制程序，在定 义的工作范围以外主动增加的额外工作。
（题干关键词“团队包含了、项目经理增加了、主动增加了、成员按照客户要求做了”。）
15、关键路径法（[email protected],P210）
关键路径法用于在进度模型中估算项目最短工期，确定逻辑网络路径的进度 灵活性大小。这种进度网络分析技术在不考虑任何资源限制的情况下，沿进度网 络路径使用顺推与逆推法，计算出所有活动的最早开始、最早结束、最晚开始和 最晚完成日期。
在任一网络路径上，进度活动可以从最早开始日期推迟或拖延的时间，而不 至于延误项目完成日期或违反进度制约因素，就是总浮动时间或进度灵活性。正 常情况下，关键路径的总浮动时间为零。
（题干关键词“进度灵活性”。）
16、进度压缩（[email protected],P215）
进度压缩技术是指在不缩减项目范围的前提下，缩短或加快进度工期，以满 足进度制约因素、强制日期或其他进度目标。负值浮动时间分析是一种有用的技 术。关键路径是浮动时间最少的方法。在违反制约因素或强制日期时，总浮动时 间可能变成负值。进度压缩技术包括：
● 赶工。通过增加资源，以最小的成本代价来压缩进度工期的一种技术。赶工 的例子包括：批准加班、增加额外资源或支付加急费用，来加快关键路径上 的活动。赶工只适用于那些通过增加资源就能缩短持续时间的，且位于关键 路径上的活动。但赶工并非总是切实可行的，因它可能导致风险和/或成本的 增加。（题干关键词“加班、增加额外资源、最小的成本增加”等，即SPI <1且CPI>1的情况下选择赶工。）
● 快速跟进。一种进度压缩技术，将正常情况下按顺序进行的活动或阶段改为 至少是部分并行开展。例如，在大楼的建筑图纸尚未全部完成前就开始建地 基。快速跟进可能造成返工和风险增加，所以它只适用于能够通过并行活动 来缩短关键路径上的项目工期的情况。以防进度加快而使用提前量通常增加相关活动之间的协调工作，并增加质量风险。快速跟进还有可能增加项目成 本。（题干关键词“无额外资源可用、并行开展”等，即SPI<1且CPI<1 的情况下选择快速跟进。）
17、在制品-WIP（[email protected],P99）
此测量指标可表明任何特定时间正在处理的工作事项的数量。它用于帮助项 目团队将正在进行的工作事项的数量限制到可管理的规模。
18、进度估算工具（[email protected],P200）
类比估算：
类比估算是一种使用相似活动或项目的历史数据，来估算当前活动或项目的 持续时间或成本的技术。类比估算以过去类似项目的参数值（如持续时间、预算、 规模、重量和复杂性等）为基础，来估算未来项目的同类参数或指标。在估算持 续时间时，类比估算技术以过去类似项目的实际持续时间为依据，来估算当前项 目的持续时间。这是一种粗略的估算方法，有时需要根据项目复杂性方面的已知 差异进行调整，在项目详细信息不足时，就经常使用类比估算来估算项目持续时 间。
相对于其他估算技术，类比估算通常成本较低、耗时较少，但准确性也较低。 类比估算可以针对整个项目或项目中的某个部分进行，或可以与其他估算方法联 合使用。如果以往活动是本质上而不是表面上类似，并且从事估算的项目团队成 员具备必要的专业知识，那么类比估算就最为可靠。
（题干关键词“粗略、快速、类似”。）
参数估算：
参数估算是一种基于历史数据和项目参数，使用某种算法来计算成本或持续 时间的估算技术。它是指利用历史数据之间的统计关系和其他变量（如建筑施工 中的平方英尺）,来估算诸如成本、预算和持续时间等活动参数。
参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。且参数进度估算可以针对整个项目或项目中的某个部分，并可以与其他估算方法联合使用。 （题干关键词“参数、定量、统计关系”。）
三点估算：
通过考虑估算中的不确定性和风险，可以提高持续时间估算的准确性。使用 三点估算有助于界定活动持续时间的近似区间：
● 最可能时间（tM）。基于最可能获得的资源、最可能取得的资源生产率、对资 源可用时间的现实预计、资源对其他参与者的可能依赖关系及可能发生的各 种干扰等，所估算的活动持续时间。
● 最乐观时间（tO）。基于活动的最好情况所估算的活动持续时间。
● 最悲观时间（tP）。基于活动的最差情况所估算的持续时间。
一个常用公式为三角分布：基于持续时间在三种估算值区间内的假定分布情 况，可计算期望持续时间tE。
tE=（tO+tM+tP）/3.
历史数据不充分或使用判断数据时，使用三角分布，基于三点的假定分布估 算出期望持续时间，并说明期望持续时间的不确定区间。
β分布：TE=（tO+4tM+tP）/6
（题干关键词“不确定性、风险、提高准确度”）
自下而上估算：
自下而上估算是一种估算项目持续时间或成本的方法，通过从下到上逐层汇 总WBS组成部分的估算而得到项目估算。如果无法以合理的可信度对活动持续 时间进行估算，则应将活动中的工作进一步细化，然后估算具体的持续时间，接 着再汇总这些资源需求估算，得到每个活动的持续时间。活动之间可能存在或不 存在会影响资源利用的依赖关系；如果存在，就应该对相应的资源使用方式加以 说明，并记录在活动资源需求中。
（题干关键词“没有合理可信度、提供准确估算”。）
19、资源优化（[email protected],P211）
资源优化用于调整活动的开始和完成日期，以调整计划使用的资源，使其等 于或少于可用的资源。资源优化技术是根据资源供需情况，来调整进度模型的技 术，包括（但不限于）:
● 资源平衡。为了在资源需求与资源供给之间取得平衡，根据资源制约因素对 开始日期和完成日期进行调整的一种技术。如果共享资源或关键资源只在特 定时间可用，数量有限，或被过度分配，如一个资源在同一时段内被分配至 两个或多个活动，就需要进行资源平衡。也可以为保持资源使用量处于均衡 水平而进行资源平衡。资源平衡往往导致关键路径改变。而可以用浮动时间 平衡资源。因此，在项目进度计划期间，关键路径可能发生变化。（题干关 键词“资源有限、过度分配、关键路径改变”。）
● 资源平滑。对进度模型中的活动进行调整，从而使项目资源需求不超过预定 的资源限制的一种技术。相对于资源平衡而言，资源平滑不会改变项目关键 路径，完工日期也不会延迟。也就是说，活动只在其自由和总浮动时间内延 迟，但资源平滑技术可能无法实现所有资源的优化。（题干关键词“无法实 现资源优化、不改变关键路径”。）
20、资源日历（[email protected],P323）
资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时 间、周末和公共假期。在规划活动期间，潜在的可用资源信息（如团队资源、设 备和材料）用于估算资源可用性。资源日历还规定了在项目期间确定的团队和实 物资源何时可用、可用多久。这些信息可以在活动或项目层面建立，这考虑了诸 如资源经验和/或技能水平以及不同地理位置等属性。
21、储备分析
（考察储备分析时，题干关键词“剩余资金应对风险、风险变化、剩余储备 时间”。）
应急储备（[email protected],P245）:
为应对成本的不确定性，成本估算中可以包括应急储备（有时称为“应急费 用”）。应急储备是包含在成本基准内的一部分预算，用来应对已识别的风险； 应急储备还通常是预算的一部分，用来应对那些会影响项目的“已知一未知”风 险。例如，可以预知有些项目可交付成果需要返工，却不知道返工的工作量是多 少。可以预留应急储备来应对这些未知数量的返工工作。小至某个具体活动，大 到整个项目，任何层级都可有其应急储备。应急储备可取成本估算值的某一百分 比、某个固定值，或者通过定量分析来确定；
而随着项目信息越来越明确，可以动用、减少或取消应急储备。应该在成本 文件中清楚地列出应急储备。应急储备是成本基准的一部分，也是项目整体资金 需求的一部分。（题干关键词“已知的未知风险”。）
管理储备（[email protected],P252）:
管理储备是为了管理控制的目的而特别留出的项目预算，用来应对项目范围 中不可预见的工作，目的是用来应对会影响项目的“未知一未知”风险。管理储 备不包括在成本基准中，但属于项目总预算和资金需求的一部分。当动用管理储 备资助不可预见的工作时，就要把动用的管理储备增加到成本基准中，从而导致 成本基准变更。（题干关键词“未知的未知风险、额外”。）
22、控制成本的技术（[email protected],P261）
挣值分析（EVA）:
挣值分析将实际进度和成本绩效与绩效测量基准进行比较。EVM把范围基 准、成本基准和进度基准整合起来，形成绩效测量基准。它针对每个工作包和控 制账户，计算并监测以下三个关键指标：
● 计划价值。计划价值（PV）是为计划工作分配的经批准的预算，它是为完成 某活动或工作分解结构（WBS）组成部分而准备的一份经批准的预算，不包 括管理储备。应该把该预算分配至项目生命周期的各个阶段；在某个给定的 时间点，计划价值代表着应该已经完成的工作。PV的总和有时被称为绩效测量基准（PMB）,项目的总计划价值又被称为完工预算（BAC）。
● 挣值。挣值（EV）是对已完成工作的测量值，用该工作的批准预算来表示， 是已完成工作的经批准的预算。EV的计算应该与PMB相对应，且所得的 EV值不得大于相应组件的PV总预算。EV常用于计算项目的完成百分比， 应该为每个WBS组件规定进展测量准则，用于考核正在实施的工作。项目 经理既要监测EV的增量，以判断当前的状态，又要监测EV的累计值，以 判断长期的绩效趋势。
● 实际成本。实际成本（AC）是在给定时段内，执行某活动而实际发生的成 本，是为完成与EV相对应的工作而发生的总成本。AC的计算方法必须PV 和EV的计算方法保持一致（例如，都只计算直接小时数，都只计算直接成 本，或都计算包含间接成本在内的全部成本）。AC没有上限，为实现EV 所花费的任何成本都要计算进去。
进度绩效指数：
进度绩效指数（SPI）是测量进度效率的一种指标，表示为挣值与计划价值 之比，反映了项目团队完成工作的效率。有时与成本绩效指数（CPI）一起使用， 以预测项目的最终完工估算。当SPI小于1.0时，说明已完成的工作量未达到计 划要求；当SPI大于1.0时，则说明已完成的工作量超过计划。由于SPI测量的 是项目的总工作量，所以还需要对关键路径上的绩效进行单独分析，以确认项目 是否将比计划完成日期提前或推迟完工。SPI等于EV与PV的比值。公式：SPI =EV/PV。
成本绩效指数：
成本绩效指数（CPI）是测量预算资源的成本效率的一种指标，表示为挣值 与实际成本之比。它是最关键的EVA指标，用来测量已完成工作的成本效率。
当CPI小于1.0时，说明已完成工作的成本超支；当CPI大于1.0时，则说明到 目前为止成本有结余。CPI等于EV与AC的比值。公式：CPI=EV/AC。
23、质量成本（[email protected],P282）
一致性成本（项目花费资金规避失败）:
● 预防成本。预防特定项目的产品、可交付成果或服务质量低劣所带来的相关 成本。如培训、文件过程、设备、完成时间等。
● 评估成本。评估、测量、审计和测试特定项目的产品、可交付成果或服务所 带来的相关成本。如测试、破坏性试验损失、检查等。 不一致成本（项目前后花费的资金一由于失败）:
● 失败成本（内部/外部）。因产品、可交付成果或服务与干系人需求或期望不
一致而导致的相关成本。内部失败成本指项目中发现失败，如返工、报废； 外部失败成本是客户发现的失败，如债务、保修工作、失去业务。
24、审计（[email protected],P294）
审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种 结构化且独立的过程。质量审计通常由项目外部的团队开展，如组织内部审计部 门、项目管理办公室（PMO）或组织外部的审计师。质量审计目标可能包括（但 不限于）:
● 识别全部正在实施的良好及最佳实践； 识别所有违规做法、差距及不足；
● 分享所在组织和/或行业中类似项目的良好实践；
● 积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率；
● 强调每次审计都应对组织经验教训知识库的积累做出贡献。
采取后续措施纠正问题，可以降低质量成本，并提高发起人或客户对项目产 品的接受度。质量审计可事先安排，也可随机进行；可由内部或外部审计师进行。
质量审计还可确认已批准的变更请求（包括更新、纠正措施、缺陷补救和预 防措施）的实施情况。
审计和审查的区别：审计相当于在有结果时，对过程进行系统化的审查。 （题干关键词“过程有效性、降低质量成本、纠正措施、合规性”。）
25、采购工作说明书（[email protected],P477）
依据项目范围基准，为每次采购编制工作说明书（SOW）,仅对将要包含 在相关合同中的那一部分项目范围进行定义。工作说明书会充分详细地描述拟采 购的产品、服务或成果，以便潜在卖方确定是否有能力提供此类产品、服务或成 果。根据采购品的性质、买方的需求，或拟采用的合同形式，工作说明书的详细 程度会有较大不同。工作说明书的内容包括：规格、所需数量、质量水平、绩效 数据、履约期间、工作地点和其他要求。
采购工作说明书应力求清晰、完整和简练。它需要说明所需的附加服务，例 如，报告绩效，或对采购品的后续运营支持。在采购过程中，应根据需要对工作 说明书进行修订，直到它成为所签协议的一部分。
（题干关键词“对可交付物的描述、规格”。）
26、合同类型（[email protected],P471）
所有法律合同关系通常可分为总价和成本补偿两大类。此外，还有第三种常 用的混合类型，即工料合同。下文将分别讨论上述几类较常用的合同类型。但在 实践中，单次采购合并使用两种或更多合同类型的情况也并不罕见。
◆总价合同。此类合同为既定产品、服务或成果的采购设定一个总价。这种合 同应在已明确定义需求，且不会出现重大范围变更的情况下使用。总价合同 的类型包括：
● 固定总价（FFP）。FFP是最常用的合同类型。大多数买方都喜欢这种合同， 因为货物采购的价格在一开始就已确定，并且不允许改变（除非工作范围发 生变更）。（题干关键词“范围明确、范围不变”。）
● 总价加激励费用（FPIF）。这种总价合同为买方和卖方提供了一定的灵活性， 允许一定的绩效偏离，并对实现既定目标给予相关的财务奖励（通常取决于 卖方的成本、进度或技术绩效）。FPIF合同中会设置价格上限，高于此价格 上限的全部成本将由卖方承担。（题干关键词“设定上限、同步目标”。）
● 总价加经济价格调整（FPEPA）。这种合同适用于两种情况：卖方履约期将跨越几年时间，或将以不同货币支付价款。它是总价合同的一种类型，但合 同中包含了特殊条款，允许根据条件变化，如通货膨胀、某些特殊商品的成 本增加（或降低）,以事先确定的方式对合同价格进行最终调整。（题干关 键词“时间很长、不同货币”。）
◆成本补偿合同。此类合同向卖方支付为完成工作而发生的全部合法实际成本 （可报销成本）,外加一笔费用作为卖方的利润。这种合同适用于：工作范 围预计会在合同执行期间发生重大变更。成本补偿合同又可分为：
● 成本加固定费用（CPFF）。为卖方报销履行合同工作所发生的一切可列支成 本，并向卖方支付一笔固定费用。该费用以项目初始估算成本的某一百分比 计列。除非项目范围发生变更，否则费用金额维持不变。（题干关键词“实 报实销、范围有较大变更”。）
● 成本加激励费用（CPIF）。为卖方报销履行合同工作所发生的一切可列支成 本，并在卖方达到合同规定的绩效目标时，向卖方支付预先确定的激励费用。 在CPIF合同中，如果最终成本低于或高于原始估算成本，则买方和卖方需 要根据事先商定的成本分摊比例来分享节约部分或分担超支部分。例如，基 于卖方的实际成本，按照80/20的比例分担（分享）超过（低于）目标成本 的部分。（题干关键词“同步目标”。）
● 成本加奖励费用（CPAF）。为卖方报销一切合法成本，但只有在卖方满足 合同规定的、某些笼统主观的绩效标准的情况下，才向卖方支付大部分费用。 奖励费用完全由买方根据自己对卖方绩效的主观判断来决定，并且通常不允 许申诉。（题干关键词“主观奖励、无权申诉”。）
◆工料合同（T&M）。工料合同（又称时间和手段合同）,是兼具成本补偿 合同和总价合同特点的混合型合同。这种合同往往适用于：在无法快速编制 出准确的工作说明书的情况下扩充人员、聘用专家或寻求外部支持。（题干 关键词“范围不明确，聘请专家”。）
27、协议（[email protected],P489）
合同是对双方都有约束力的协议。它强制卖方提供规定的产品、服务或成果， 强制买方向卖方支付相应的报酬。合同建立了受法律保护的买卖双方的关系。协 议文本的主要内容会有所不同，可包括（但不限于）:
● 采购工作说明书或主要的可交付成果；
● 进度计划、里程碑，或进度计划中规定的日期；
● 绩效报告；
● 定价和支付条款；
● 检查、质量和验收标准；
● 担保和后续产品支持；
● 激励和惩罚；
● 保险和履约保函；
● 下属分包商批准；
● 一般条款和条件；
● 变更请求处理；
● 终止条款和替代争议解决方法。
（题干关键词“与供应商有争议，审查供应商绩效、不可抗力条款”。）
28、绩效审查（PMBOK@6,P708）
对照基准，对项目正在开展的工作的实际绩效进行测量、比较和分析的一种 技术。
（题干关键词“供应商绩效、结果”。）
29、采购审计（PMBOK@6,P709）
对合同和采购过程的完整性、正确性和有效性进行的审查。（PMBOK@7, P79说法：采购审计表明，所采用的适当流程足以开展采购工作，而且承包商正 在按计划开展工作。）
30、自制或外购分析（[email protected],P473）
自制或外购分析用于确定某项工作或可交付成果最好由项目团队自行完成， 还是应该从外部采购。制定自制或外购决策时应考虑的因素包括；组织当前的资 源配置及其技能和能力，对专业技术的需求，不愿承担永久雇用的义务，以及对 独特技术专长的需求；还要评估与每个自制或外购决策相关的风险。
在自制或外购分析中，可以使用回收期、投资回报率（ROI）、内部报酬率 （IRR）、现金流贴现、净现值（NPV）、收益成本（BCA）或其他分析技术， 来确定某种货物或服务是应该在项目内部自制，还是从外部购买。
（题干关键词“自己制作还是从外部购买”。）
31、风险管理流程（PMBOK@6-11,P395）
项目风险管理的过程是：
● 规划风险管理一定义如何实施项目风险管理活动的过程。
● 识别风险一识别单个项目风险，以及整体项目风险的来源，并记录风险特征 的过程。
● 实施定性风险分析一通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程。 实施定量风险分析一就已识别的单个项目风险和其他不确定性的来源对整 体项目目标的综合影响进行定量分析的过程。
● 规划风险应对一为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。
● 实施风险应对一执行商定的风险应对计划的过程。
32、风险登记册（[email protected],P417）
风险登记册记录已识别单个项目风险的详细信息。随着实施定性风险分析、 规划风险应对、实施风险应对和监督风险等过程的开展，这些过程的结果也要记 进风险登记册。取决于具体的项目变量（如规模和复杂性）,风险登记册可能包含有限或广泛的风险信息。
当完成识别风险过程时，风险登记册的内容可能包括（但不限于）:
● 已识别风险的清单。在风险登记册中，每项单个项目风险都被赋予一个独特 的标识号。要以所需的详细程度对已识别风险进行描述，确保明确理解。可 以使用结构化的风险描述，来把风险本身与风险原因及风险影响区分开来。
● 潜在风险责任人。如果已在识别风险过程中识别出潜在的风险责任人，就要 把该责任人记录到风险登记册中。随后将由实施定性风险分析过程进行确认。
● 潜在风险应对措施清单。如果已在识别风险过程中识别出某种潜在的风险应 对措施，就要把它记录到风险登记册中。随后将由规划风险应对过程进行确 认。
根据风险管理计划规定的风险登记册格式，可能还要记录关于每项已识别风 险的其他数据，包括：简短的风险名称、风险类别、当前风险状态、一项或多项 原因、一项或多项对目标的影响、风险触发条件（显示风险即将发生的事件或条件）、受影响的WBS组件，以及时间信息（风险何时识别、可能何时发生、何 时可能不再相关，以及采取行动的最后期限）。
（题干关键词“项目发生意外已被之前识别、风险优先级、应对措施、应急 计划”,注意其记录了风险的具体条目。
风险管理计划：题干关键词“风险的角色与职责、方法论”,注意其不包含 具体的风险。）
33、蒙特卡洛分析（[email protected],P433）
在定量风险分析中，使用模型来模拟单个项目风险和其他不确定性来源的综 合影响，以评估它们对项目目标的潜在影响。模拟通常采用蒙特卡洛分析。对成 本风险进行蒙特卡洛分析时，使用项目成本估算作为模拟的输入；对进度风险进 行蒙特卡洛分析时，使用进度网络图和持续时间估算作为模拟的输入。开展综合 定量成本-进度风险分析时，同时使用这两种输入。其输出就是定量风险分析模 型。
用计算机软件数千次迭代运行定量风险分析模型。每次运行，都要随机选择 输入值（如成本估算、持续时间估算或概率分支发生频率）。这些运行的输出构 成了项目可能结果（如项目结束日期、项目完工成本）的区间。典型的输出包括： 表示模拟得到特定结果的次数的直方图，或表示获得等于或小于特定数值的结果 的累积概率分布曲线（S曲线）。
（题干关键词“定量风险分析，项目成功概率”。）
34、风险应对策略（[email protected],P442）
针对威胁，可以考虑下列五种备选策略：
● 上报。如果项目团队或项目发起人认为某威胁不在项目范围内，或提议的应 对措施超出了项目经理的权限，就应该采用上报策略。被上报的风险将在项 目集层面、项目组合层面或组织的其他相关部门加以管理，而不在项目层面。 项目经理确定应就威胁通知哪些人员，并向该人员或组织部门传达关于该威 胁的详细信息。对于被上报的威胁，组织中的相关人员必须愿意承担应对责 任，这一点非常重要。威胁通常要上报给其目标会受该威胁影响的那个层级。 威胁一旦上报，就不再由项目团队做进一步监督，虽然仍可出现在风险登记 册中供参考。（题干关键词“超出权限/范围”。）
● 规避。风险规避是指项目团队采取行动来消除威胁，或保护项目免受威胁的 影响。它可能适用于发生概率较高，且具有严重负面影响的高优先级威胁。 规避策略可能涉及变更项目管理计划的某些方面，或改变会受负面影响的目 标，以便于彻底消除威胁，将它的发生概率降低到零。风险责任人也可以采 取措施，来分离项目目标与风险万一发生的影响。规避措施可能包括消除威 胁的原因、延长进度计划、改变项目策略，或缩小范围。有些风险可以通过 澄清需求、获取信息、改善沟通或取得专有技能来加以规避。（题干关键词 “消除威胁/严重影响”。）
● 转移。转移涉及到将应对威胁的责任转移给第三方，让第三方管理风险并承 担威胁发生的影响。采用转移策略，通常需要向承担威胁的一方支付风险转移费用。风险转移可能需要通过一系列行动才得以实现，包括（但不限于） 购买保险、使用履约保函、使用担保书、使用保证书等。也可以通过签订协 议，把具体风险的归属和责任转移给第三方。（题干关键词“保险、担保、 外包”。）
● 减轻。风险减轻是指采取措施来降低威胁发生的概率和（或）影响。提前采 取减轻措施通常比威胁出现后尝试进行弥补更加有效。减轻措施包括采用较 简单的流程，进行更多次测试，或者选用更可靠的卖方。还可能涉及原型开 发，以降低从实验台模型放大到实际工艺或产品中的风险。如果无法降低概 率，也许可以从决定风险严重性的因素入手，来减轻风险发生的影响。例如， 在一个系统中加入冗余部件，可以减轻原始部件故障所造成的影响。（题干 关键词“多次测试、增加资源、降低影响/概率”。）
接受。风险接受是指承认威胁的存在，但不主动采取措施。此策略可用于低 优先级威胁，也可用于无法以任何其他方式加以经济有效地应对的威胁。接 受策略又分为主动或被动方式。最常见的主动接受策略是建立应急储备，包 括预留时间、资金或资源以应对出现的威胁；被动接受策略则不会主动采取 行动，而只是定期对威胁进行审查，确保其并未发生重大改变。（题干关键 词“接受、不再处理”。）
针对机会，可以考虑下列五种备选策略：
● 上报。如果项目团队或项目发起人认为某机会不在项目范围内，或提议的应 对措施超出了项目经理的权限，就应该取用上报策略。被上报的机会将在项 目集层面、项目组合层面或组织的其他相关部门加以管理，而不在项目层面。 项目经理确定应就机会通知哪些人员，并向该人员或组织部门传达关于该机 会的详细信息。对于被上报的机会，组织中的相关人员必须愿意承担应对责 任，这一点非常重要。机会通常要上报给其目标会受该机会影响的那个层级。 机会一旦上报，就不再由项目团队做进一步监督，虽然仍可出现在风险登记 册中供参考。 开拓。如果组织想确保把握住高优先级的机会，就可以选择开拓策略。此策略将特定机会的出现概率提高到100%,确保其肯定出现，从而获得与其相 关的收益。开拓措施可能包括：把组织中最有能力的资源分配给项目来缩短 完工时间，或采用全新技术或技术升级来节约项目成本并缩短项目持续时间。 （题干关键词“确保、100%”。）
● 分享。分享涉及到将应对机会的责任转移给第三方，使其享有机会所带来的 部分收益。必须仔细为已分享的机会安排新的风险责任人，让那些最有能力 为项目抓住机会的人担任新的风险责任人。采用风险分享策略，通常需要向 承担机会应对责任的一方支付风险费用。分享措施包括建立合伙关系、合作 团队、特殊公司或合资企业来分享机会。（题干关键词“合资”。） 提高。提高策略用于提高机会出现的概率和（或）影响。提前采取提高措施 通常比机会出现后尝试改善收益更加有效。通过关注其原因，可以提高机会 出现的概率；如果无法提高概率，也许可以针对决定其潜在收益规模的因素 来提高机会发生的影响。机会提高措施包括为早日完成活动而增加资源。（题 干关键词“提高概率/影响”。）
● 接受。接受机会是指承认机会的存在，但不主动采取措施。此策略可用于低 优先级机会，也可用于无法以任何其他方式加以经济有效地应对的机会。接 受策略又分为主动或被动方式。最常见的主动接受策略是建立应急储备，包 括预留时间、资金或资源，以便在机会出现时加以利用；被动接受策略则不 会主动采取行动，而只是定期对机会进行审查，确保其并未发生重大改变。
35、风险与问题的区别
风险代表对将来问题的预判，问题代表对过去问题事件的跟踪；两者联系： 风险发生后会变成问题，而问题可能导致新的风险。
36、残余风险与次生风险的区别
残余风险是指采取了保护措施之后剩下的风险；次生风险是由原风险及在风 险应对过程中产生的新的风险。
37、问题日志（[email protected],P96）
在整个项目生命周期中，项目经理通常会遇到问题、差距、不一致或意外冲 突。项目经理需要采取某些行动加以处理，以免影响项目绩效。问题日志是一种 记录和跟进所有问题的项目文件，所需记录和跟进的内容可能包括：
● 问题类型；
● 问题提出者和提出时间；
● 问题描述；
● 问题优先级；
● 由谁负责解决问题；
● 目标解决日期；
● 问题状态；
● 最终解决情况。
问题日志可以帮助项目经理有效跟进和管理问题，确保它们得到调查和解决。 作为本过程的输出，问题日志被首次创建，尽管在项目期间任何时候都可能发生 问题。在整个项目生命周期应该随同监控活动更新问题日志。
（题干关键词“记录、跟进问题”。）
38、经验教训登记册（[email protected],P104）
经验教训登记册可以包含情况的类别和描述，经验教训登记册还可包括与情 况相关的影响、建议和行动方案。经验教训登记册可以记录遇到的挑战、问题、 意识到的风险和机会，或其他适用的内容。
经验教训登记册在项目早期创建，作为本过程的输出。因此，在整个项目期 间，它可以作为很多过程的输入，也可以作为输出而不断更新。参与工作的个人 和团队也参与记录经验教训。可以通过视频、图片、音频或其他合适的方式记录 知识，确保有效吸取经验教训。
在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产 的一部分。
（题干关键词“防止再次发生、改善未来项目绩效、避免将来的问题”。） 3
39、监控项目工作的技术（[email protected],P111）
可用于本过程的数据分析技术包括（但不限于）:
● 备选方案分析。备选方案分析用于在出现偏差时选择要执行的纠正措施或纠 正措施和预防措施的组合。
● 成本效益分析。成本效益分析有助于在项目出现偏差时确定最节约成本的纠正措施。（题干关键词“干系人不想投入、要求增加质量测试项目”。）
● 挣值分析。挣值分析对范围、进度和成本绩效进行了综合分析。
● 根本原因分析。根本原因分析关注识别问题的主要原因，它可用于识别出现 偏差的原因以及项目经理为达成项目目标应重点关注的领域。
● 趋势分析。趋势分析根据以往结果预测未来绩效，它可以预测项目的进度延 误，提前让项目经理意识到，按照既定趋势发展，后期进度可能出现的问题。 应该在足够早的项目时间进行趋势分析，使项目团队有时间分析和纠正任何 异常。可以根据趋势分析的结果，提出必要的预防措施建议。
● 偏差分析。偏差分析审查目标绩效与实际绩效之间的差异（或偏差）,可涉 及持续时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指 标。 可以在每个知识领域，针对特定变量，开展偏差分析。在监控项目工作过程 中，通过偏差分析对成本、时间、技术和资源偏差进行综合分析，以了解项目的 总体偏差情况。这样就便于采取合适的预防或纠正措施。
40、显性知识和隐性知识（PMBOK@6-术语表，P704、P716）
显性知识：可以使用文字、数字、图片等符号进行编辑的知识。
隐性知识：难以明确表达和分享的个人知识，如信念、经验和洞察力。
四、敏捷相关知识
1、敏捷宣言（敏捷实践指南-2.2,P8）
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人， 由此我们建立了如下价值观：
● 个体与互动重于流程和工具
● 工作的软件重于详尽的文档
● 客户协作重于合同谈判
● 响应变化重于遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
2、敏捷12原则（敏捷实践指南-2.2,P9）
● 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
●欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过 程掌控变化。
● 经常地交付可工作的软件，相隔几个星期或一两个月，倾向于采取较短的周期。
● 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
● 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信 任，从而达成目标。
● 不论团队内外，传递信息效果最好效率也是最高的方式是面对面的交谈。 可以工作的软件进度的首要度量标准。
● 敏捷过程提倡可持续开发，责任人、开发人员和用户要能够共同维持其步调 稳定延续。
● 坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强。 以简洁为本，它是极力减少不必要工作量的艺术。 最好的架构、需求和设计出自自组织团队。
●团队定期地反思如何能够提高成效，并依此调整自身的举止表现。
3、敏捷核心实践和原则
包括但不限于以下：
● 在迭代中尽早演示交付的价值
用户故事反映商业价值和优先级
客户持续改进
所有需求的验收测试
回顾
可持续的节奏或速度
沟通
高度可视化
敏捷不包含什么:
预先的设计和需求收集 项目完工预测
死亡行军项目：项目团队为弥补估算差距无偿加班 强迫使用工具，例如任务管理工具 自上而下管理和控制 大量文件，特别的状态报告、软件架构图、软件需求规格说明书、测试计划
敏捷益处：
强调协同合作，团队授权，频繁过程演示
轻量级，依靠白板、概要卡片和便利性工具
吸引开发者的开发重点
更快的上市时间和高优先级特征驱动开发生命周期
关注，拉而不是推
容易理解
满足客户的需要
4、敏捷“3355”
三大角色：
Scrum团队由5到9个（7±2）团队成员组成。有三种类型角色：
①产品负责人（Product Owner）:
PO是指负责使产品实现最大价值的人员，其对所创建的终端产品负责并承 担最终责任。
·客户代表；
·定义所有产品功能；
·决定产品发布的内容以及日期；
·对产品的投入产出负责；
·根据市场变化对需要开发的功能排列优先顺序；
·合理地调整产品功能和迭代顺序；
·认同或者拒绝迭代的交付。
（题干关键词“优先级排序、与客户沟通、下次迭代做什么、接受或拒绝用 户故事”。）
②敏捷教练（Scrum Master）:
Scrum Master负责确保所有人都能正确地理解并实施Scrum。因此，Scrum Master要确保Scrum团队遵循Scrum的理论、实践和规则。
·起到教练的职责；
·领导团队完成Scrum的实践以及体现其价值；
·排除团队遇到的困难；
·确保团队能胜任其工作，并保持高效的生产率；
·使得团队紧密合作，使得团队个人具有多方面职能的工作能力；
·保护团队不受到外来无端影响。 （题干关键词“促进合作、清除障碍、指导团队”。）
③开发团队（Dev Team）:
·经典团队拥有5~9人；
·团队成员都是多面手：程序员，测试员，用户体验设计，等等；
·团队成员都全职工作：特殊职能可以除外（例如，数据库管理员）；
·团队自我组织和管理；
·团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发 生调整。
（题干关键词“通才型专家、自组织团队、让团队决策”。）
三个工件：
①产品待办列表（Product Backlog）:
·产品需求的列表；
·包含业务需求、技术需求、NFR等；
·理想情况下，每一个待完成的工作都将对客户产生价值；
·PO对该列表进行优先级排序；
·每个迭代开始前，优先级排序还需要再度修正；
·待办事项列表中的条目以用户故事的形式呈现。 （题干关键词“优先级排序、用户故事”。）
②冲刺/迭代待办列表（SprintBacklog）:
·Product Backlog的子集，只记录当前迭代的工作；
·将用户故事拆分成任务，团队成员主动领取任务；
·团队成员有共同的迭代目标，为交付可工作的成果而努力；
·团队成员可以添加、删减或者更改迭代中的任务；
·迭代列表中的任务进行了估算，剩余工作量的估计每天需要更新。 （题干关键词“任务、团队成员”。）
③产品增量（ProductIncrement）:
·团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交 付；
·每次交付的用户故事必须符合验收条件；
·每次交付的增量成果必须处于可用状态，而不管PO是否决定发布这个用户故事。
（题干关键词“集成、可用”。）
5种仪式：
①冲刺/迭代（Sprint）:
活动：澄清用户故事，理解商业价值，确立下个迭代需求范围及较细粒度任 务拆分，团队达成共识。
产出：关键产品PRD和流程、交互设计、待迭代故事（任务）列表（分配/ 排期/优先级）。
②迭代计划会（Sprint Planning）:
活动：一是选故事，即从产品待办事项列表中选择优先级高的用户故事，直 到本迭代饱和，PO参与讨论回答需求相关问题，但不干扰估算结果；二是拆任 务，即将用户故事拆分成任务，创建冲刺待办事项列表，由团队成员领取任务， 完成工作量估算，画出任务燃尽图。
产出：生成Sprint迭代开发计划（分配/排期/优先级）。
③每日站会（Daily Serum）:
活动：沟通进展，每日三问（昨天你做了什么?今天你将要做什么?你有需 要帮助的地方吗?）。
产出：对齐目标，更新任务板和燃尽图。
为每日站会规定时间盒，不超出15分钟。团队以某种方式“过一下”看板 或任务板，而团队中的任何人都可以主持站会。
站会中常见的一个反模式是，站会变成了状态报告会议。传统上在预测环境 中工作的团队可能倾向于采用这种反模式，因为他们习惯于报告状态。
另一个典型的反模式是，当问题变得明显时，团队才开始解决问题。站会是 为了发现存在问题，而不是解决它们。将问题添加到停车场区，然后创建另一次 会议，它可以在站会之后立即召开，并在会上解决问题。
团队可以举办自己的站会。只要体现了团队工作需要的密切合作，进行顺利， 站会便会非常有用。要针对团队何时需要站会、站会是否有效等问题有意识地做出决定。
④冲刺评审会（Sprint Review）:
活动：演示产品新功能特性，遇到的问题，按需调整待办。
产出：获取反馈促进合作（可根据需要是否需要该会议或者前置为技术架构 评审会议）。
⑤冲刺回顾会（Sprint Retrospective）:
活动：一是总结工作中的经验教训，进行反思；二是找到可以改进的工作； 三是做出计划，调整将来的工作，将可以改进的工作纳入产品待办事项列表，以 便在后续的过程中执行。
产出：鼓励团队在Scrum过程框架内改进开发过程和实践，使得下一个冲 刺更高效。
◆五个价值观：
开放Openness,专注Focus,勇气Courage,承诺Commitment,尊重Respect。
4、优先级技术
MoSCoW
MoSCoW技术是进行需求优先级排序的敏捷方法。在这种技术下，需求基 于以下方面排序：
1）Must必须有-这些需求是强制性的；
2）Should应该有-这些需求不是强制性的，但是高度渴望的；
3）Could可以有-这些需求如果满足会很好；
4）Won’t不会有-当下可以不去满足，但是将来可以加入。
在开始新一轮时间箱前，会有一个新的MUSTs加入。这些可能是新的需求， 或者现有需求被调整，优先级进而转移成为MUSTs。
计划扑克
计划扑克（Planning Poker）是一种在敏捷项目管理中广泛使用的技术，旨在 通过团队合作的方式估算任务的复杂性或工作量。这种技术通过标有数字的扑克牌来实现，使得团队成员能够在短时间内对任务进行相对准确的估算。
计划扑克通常在敏捷团队的冲刺规划会议中使用，帮助团队确定每个冲刺周 期内要完成的任务及其优先级。此外，它也可以用于其他需要估算任务工作量的 场景，如项目管理、产品规划等。
5、Kanban看板
看板在项目实施期间作为信息发射源运用，它有助于相关干系人去了解冲刺 或迭代的当下状态。
看板是一个跟精益和及时制生产相关的概念：
任务板被细分成段来反映关键活动。 故事是由索引卡或代表的便利贴来表示。
卡的状态由它在任务板上的位置来表示，并随着项目进展从开始到结束变化。 看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我 指挥。
kanban卡片：
Kanban任务板上的每一张卡片就是kanban卡片。 Kanban卡片用来显示迭代过程。
Kanban任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。 Kanban卡片反映所有需要被跟踪的事物。例如：用户故事、缺陷、任务。 在用户故事定义完整前，相关干系人需要对用户故事必须经历的部分进行评 估。
6、完成的定义-DoD
它是团队需要满足的所有标准的核对单，只有可交付成果满足该核对单才能 视为准备就绪可供客户使用。
通俗讲，DoD代表敏捷项目中用户故事的验收标准，在用户故事完成后， 开发团队可基于DoD进行测试。
7、准备就绪的定义-DoR
它是团队以用户需求为中心的核对单，其中包括团队开始工作所需的全部信 息。
通俗讲，DoR代表产品待办事项列表中的用户故事已得到清晰描述，可以 进入sprint。
8、MVP
最小可交付价值
最小可售单元
最小可行性产品
9、用户故事
它是针对特定用户的可交付成果价值的简要描述。它是对澄清细节对话的承 诺。
10、刺探
它是指项目中短暂的时间间隔，通常长度固定在此期间，团队开展研究或针 对方案的某个方面进行原型研究验证其可行性。
11、故事点
它是用于相关用户故事估算技术中的一种无量纲指标。
每个团队都有自己的能力。在使用故事点时，团队要认识到，在给定时间内 能够完成的故事点数量对一个团队而言是唯一的。
12、结对编程
结对编程（Pair Programming）是一种敏捷软件开发的方法，它强调两个程 序员在一个计算机上共同协作完成编程任务。在这种模式下，一个程序员担任“驾驶员”的角色，负责输入代码，而另一个程序员则作为“观察员”（或称为“导 航员”）,负责审查驾驶员输入的每一行代码，并提出改进意见或预测可能出现 的问题。两个程序员会经常互换角色，以促进知识和技能的共享。
13、测试驱动开发-TDD
测试驱动开发（Test-Driven Development,简称TDD）是一种软件开发过程， 它要求开发者在编写任何产品功能代码之前，首先编写用于测试这些功能的测试 用例。这种做法强调了测试在软件开发中的核心地位，并且认为通过先写测试可 以更有效地设计、开发和维护软件。
TDD的核心原则可以概括为“红-绿-重构”循环：
红色（Red）:首先编写一个针对即将开发的功能的测试用例，并预期它会 失败（通常是因为你还没有实现该功能）。这个失败的测试用红色标记来表示。 绿色（Green）:然后，编写或修改代码，直到测试通过，显示为绿色。这 意味着你的代码现在实现了测试所描述的功能。
重构（Refactor）:在测试通过后，你可以对代码进行重构，以改进其设计、 增加可读性、减少重复代码等，而不改变其外部行为。在这个过程中，你需要持 续运行测试，以确保重构没有破坏已有的功能。
14、利特尔法则
利特尔法则在项目管理中能帮助管理者理解项目流程的效率、优化资源分配、 预测和规划项目进度以及提高团队协同效率。
前置时间（LT）=WIP/吞吐率（Throughput）
前置时间：准备时间（排队时间）+完成时间（处理时间） 吞吐率：整个流程的速率（取决于最慢的那个活动）
WIP:在制品，即项目处理过程中任务，半成品
15、敏捷合同管理
敏捷合同管理强调灵活性、透明度、风险分担和快速交付。通过制定灵活的 合同条款、建立有效的沟通机制、实施敏捷开发方法和及时应对变更和风险等措 施，敏捷合同管理可以提高项目成功率、增强客户满意度、降低项目成本并提升 团队协作效率。
五、高频考点分析
1、组织变革
传统型组织→敏捷型组织转变；
变革就绪情况：管理层的变革意愿、员工认知的转变、集中或分散项目管理 职能、专注于短期目标而非长期、人才管理成熟度和能力。
2、商业文件
商业论证（是否值得所需投资、高管们决策的依据）反映了：
（1）一个项目在启动时，决定要不要做；
（2）发起人离职了，项目还要不要继续；
（3）包括商业需求和成本效益分析。
效（收）益管理计划：
包括量化的收益目标、每个阶段的收益、收益的跟踪、收益的测量。
3、需求排序
优先级=（商业价值十风险）/成本； 合规性是项目开展的前提，优先级最高。
4、干系人与沟通
（1）沟通：信息的正确传递（关键词：报告、信息、通知、邮件等）；
（2）干系人：支持与抵制（关键词：支持、抵制、不满意、拒绝）。
口诀：凡信息找沟通，不满意找计划。
瀑布型：
（1）干系人分析：基本信息、权力-利益表格；
（2）谈判：（优先级排序）。
获取资源：谈判一找领导一招募。
采购索赔：谈判—ADR一法院。
敏捷型：
（1）消除障碍：选项找财务部门、变更控制委员会、审计部门。
（2）领导风格：转变为仆人式领导（团队促进者、项目经理、Scrum主管、 项目团队领导、团队教练、敏捷教练）。职责：消除组织障碍、促进团队合作、 教育干系人、培训与发展团队。
（3）自组织：承担项目经理职责、轮换发挥领导作用、自行召开会议、拥 有一切资源。
5、培训
题干找技能有关、选项中找培训。
6、虚拟团队
选项找沟通。虚拟团队：分布式团队、分散团队、地理位置、不同国家、居 家办公；沟通：沟通管理计划、沟通需求、沟通技能、沟通技术、网络工具、虚 拟会议。
7、情商
识别自己和他人情绪的能力。
自我意识：（识别自己） 自我管理：（管理自己） 你如何影响团队、团队对你有何影响 三思而后行、建立信任
社交意识：（识别他人） 社交技能：（管理他人） 同理心、积极倾听 建立融洽关系、建设高效团队、管理态度
8、团队章程
题干纪律问题选项中找团队章程、基本规则、社会契约。 团队章程涉及团队价值观、沟通指南、决策标准和过程、冲突处理过程、会议指南、团队共识。
9、变更管理
瀑布型变更：
一次交付、尽量限制、确定性需求>风险储备
口诀：一个中心，两个基本点。
（1）一个中心：计划=执行
缺陷补救：让可交付成果正常（强调质量、范围）；
纠正措施：让绩效恢复正常（强调进度、成本、其他绩效领域）；
预防措施：防止将来的偏离（强调风险）；
调整计划：原基准或计划不再合适（强调基准、计划）。
（2）两个基本点：
内部变更先分析：分析原因、影响、解决方案；
外部变更先沟通：了解需求，正式提出，核对信息。
（3）口诀：凡变更，必流程；有变更，要沟通；动基准，先变更；有权变， 找变更；遇蔓延，找变更；有变更，要花钱。
敏捷型变更：
多次交付、拥抱变化、待办需求>确定性需求。 口诀：冲刺内谨慎，冲刺外待办。
重大问题、新增需求、需求变更交给PO（Product Owner）,随后加入待办 事项列表（PB）。
知识管理（瀑布型）
（1）经验教训：显性知识、隐形知识；
（2）项目管理信息系统：配置管理、信息管理。
Scrum（敏捷型）
流程：
（1）迭代计划会（选故事、领任务、拆任务）:输入产品Backlog、冲刺目标→输出冲刺Backlog、燃尽图、任务板。
（2）每日站会（15分钟、轮流开、不解决问题）:输入任务板/看板→输出 任务板更新、燃尽图更新、障碍日志、产品增量。
（3）迭代评审会（演示、评审、反馈）:输入产品增量→输出确认的产品 增量、干系人的反馈。
（4）迭代回顾会（总结、改进、计划）:输入问题日志、干系人的反馈→ 输出改进计划、新的待办事项。
10、监督风险流程
遇风险，先查册； 已知风险，应急计划； 未知风险，权变措施。
11、决策流程
问题处理流程
日志更新问题
问题日志、变更日志、风险登记册随时更新，但要依据场景：
（1）问题、变更紧急时，优先处理问题；
12、常见场景
4.2.1 一个新人加入
| 问题 | 原因 | 选项 |
|---|---|---|
| 团队绩效下降 | 关系不融洽 | 团队建设 |
| 个人绩效下降 | 能力不足 | 指导与培训 |
| 项目绩效下降 | 分歧较多 | 冲突管理 |
4.2.2 重要会议
| 问题 | 原因 | 选项 |
|---|---|---|
| 干系人不来开会 | 没有时间 | 单独确认 |
| 干系人经常不来 | 无明确原因 | 干系人分析 |
| 重要人员不来 | 时间紧张 | 找领导 |
| 重要干系人没来 | 会议已经开过 | 发送会议结果 |
4.2.3 干系人直接找团队成员
| 问题 | 原因 | 选项 |
|---|---|---|
| 敏捷干系人 | 直接了解信息 | 发射源、开会 |
| 干系人联系团队 | 传统项目 | 沟通管理计划 |
| 直接找团队 | 发起变更 | 变更流程、沟通 |
4.2.4 团队有分歧
| 问题 | 原因 | 选项 |
|---|---|---|
| 团队争议 | 震荡阶段 | 冲突管理 |
| 团队纪律问题 | 不配合、争吵 | 团队章程 |
| 无法达成一致 | 无共事经历 | 团队建设 |
六、考试技巧总结
1、提升做题速度
读题顺序：最后一句→选项→题干；
题干问法：“规避事先”找预防措施；“下一步、接下来”找纠正措施；“避 免将来”找经验教训；
问题原因大法（部分末句未提供信息，从后往前读）:找问题→找原因或背 景→找答案。
2、如何精准答题
流程题选大：变更流程、风险流程、问题解决流程、场景类流程。“分析并 给出解决方案”。
概念题选准：具体概念、选择什么工具、选择什么文件、更新什么计划。
3、如何避免干扰
基础知识：概念理解、概念辨析、流程顺序（谋定而后动、合规大于天、原 则优先、现成的解决方案）。
语文阅读：出题者思维、语义分析。
答题技巧：选大选小、人与事的逻辑（人的问题先沟通，事的问题先分析）、 手段与目的（手段和目的同时出现时，优先选择目的）。
软技能：高情商、工作常识、情景领导力（形成阶段指导式、震荡阶段教练 式、规范阶段参与式、成熟阶段委托式）。