PMP项目管理

最全PMP项目管理，引论-敏捷，包含重要考点，拥有必过，PMPBOK归纳考点知识，高通过率使用脑图，PMP项目管理考试最新考纲适用。

PMP项目管理

• 引论—— 项目是为创造独特的产品、服务或成果⽽进⾏的临时性工作
  • 项目的基本要素
    • 项目
      • 独特性的产品
      • 服务或成果
      • 临时性工作
    • 驱动变更
    • 启动背景
    • 创造商业价值
    • 考点
      • 项目的独特性和临时性
      • 项目管理和运营管
        • 运营管理是另外一个领域，运营管理关注产品的持续生产和（或）服务的持续运作。持续运营不属于项目的范畴，但是它们之间存在交叉点
          • 在新产品开发、产品升级或提高产量时
          • 在改进运营或产品开发流程时
          • 在产品生命周期结束阶段
          • 在每个收尾阶段
      • 项目启动背景和商业价值
        • 项目独特性&临时性
          • 启动背景
            • 应对影响组织的持续运营和业务战略的因素
              • 符合法规、法律或社会要求
              • 满足相关方的要求或需求
              • 执⾏、变更业务或技术战略
              • 创造、改进或修复产品、过程或服务
          • 驱动变更
          • 创造商业价值
  • 组织级项目管理（OPM）
    • 考点
      • 项目、项目集与项目组合
        • 项目管理
          • 注重项目本身的相互依赖关系，以确定管理项目的最佳⽅法
        • 项目集管理
          • 注重作为组成部分的项目与项目集之间的依赖关系，以确定管理这些项目的最佳方法
        • 项目组合管理
          • 是指为了实现战略目标的集中管理。项目组合中的项目集或项目不一定彼此依赖或直接相关。在开展组织和项目组合规划时，要基于风险、资⾦和其他考虑因素对项目组合组件排列优先级。
      • 组织级项目管理（OPM）
        • OPM 指为实现战略目标⽽整合项目组合、项目集和项目管理与组织驱动因素的框架。
  • 项目的生命周期和各个阶段
    • 考点
      • 项目的生命周期的类型
        • 项目生命周期指项目从启动到完成所经历的一系列阶段
        • 四大类型
          • 预测型/瀑布型
          • 增量型
          • 迭代型
          • 敏捷型
      • 项目关口
        • 阶段关口 在项目阶段结束时进⾏，将项目的绩效和进度与项目和业务⽂件比较，以判断是否可进入下个阶段
          • 项目商业论证
          • 项目章程
          • 项目管理计划
          • 效益管理计划
  • 项目管理的基本方法论
  • 项目商业管理文件
    • 项目经理需要确保项目管理⽅法紧扣商业文件的意图
    • • 需求评估
        • 需求评估通常是在商业论证之前进⾏，包括了解业务目的和目标、问题及机会，并提出处理建议。需求评估结果可能会在商业论证⽂件中进⾏总结。
      • 商业论证
        • 指文档化的经济可⾏性研究报告，用来对尚缺乏充分定义的所选⽅案的收益进⾏有效性论证，是启动后续项目管理活动的依据。例如，成本效益分析数据。
          • 项目启动之前通过商业论证，可能会做出继续/终止项目的决策
          • 商业论证是一种项目商业文件，可在整个项目生命周期中使用
          • 商业论证列出了项目启动的目标和理由。它有助于在项目结束时根据项目目标衡量项目是否成功
      • 效益管理计划
        • 项目效益管理计划描述了项目实现效益的⽅式和时间，以及应制定的效益衡量机制
          • 目标效益（例如预计通过项目实施可以创造的有形价值和无形价值；财务价值体现为净现值NPV）
            • Net Present Value，NPV
            • 净现值（NPV）=未来现金净流量现值一原始投资额现值
          • 战略一致性（例如项目效益与组织业务战略的一致程度）
          • 实现效益的时限（例如阶段效益、短期效益、⻓期效益和持续效益）
          • 效益责任人（例如在计划确定的整个时限内负责监督、记录和报告已实现效益的负责人）
          • 测量指标（例如用于显示已实现效益的直接测量值和间接测量值）
          • 假设（例如预计存在或显⽽易见的因素）
          • 风险（例如实现效益的风险）
        • 制定效益管理计划需要使用商业论证和需求评估中的数据和信息
        • 项目效益管理计划的制定和维护是一项迭代活动。它是商业论证、项目章程和项目管理计划的补充性文件
        • 项目经理与发起人共同确保项目章程、项目管理计划和效益管理计划在整个项目生命周期内始终保持一致
      • 项目章程和项目管理计划
        • 项目章程
          • 是由项目发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件
        • 项目管理计划
          • 是描述如何执⾏、监督和控制项目的一份⽂件
      • 项目成功标准
        • 确定项目是否成功是项目管理中最常见的挑战之一。时间、成本、范围和质量等项目管理测量指标历来被视为确定项目是否成功的最重要的因素
        • 主要相关⽅和项目经理应思考以下三个问题
          • 怎样才是项目成功？
          • 如何评估项目成功？
          • 哪些因素会影响项目成功？
• 第二章 项目运⾏环境
  • 影响项目的两大因素
    • 事业环境因素
      • 事业环境因素源于项目外部（往往是企业外部）的环境,组织过程资产源于企 业内部,可能来自企业自身、项目组合、项目集、其他项目或这些的组合
      • 外部
      • 内部
    • 内部组织过程资产
      • 过程、政策和程序
      • 组织知识库
  • 组织体系
    • 单个组织内多种因素的交互影响创造出一个独特的系统，会对在该系统内运⾏的项目造成影响
      • 管理要素
      • 治理框架
      • 组织结构类型
    • 项目管理办公室 (PMO)
      • 对与项目相关的治理过程进⾏标准化，并促进资源、⽅法论、工具和技术共享的一个组织结构
    • 项目
      • 运⾏项目时需要应对组织结构和治理框架带来的制约
    • 考点
      • 组织结构类型
        • 注：考试中不明确说明，默认使用平衡矩阵
      • 组织治理框架和管理要素
        • 组织治理框架
          • 治理指组织各个层面的有组织的或有结构的安排，旨在确 定和影响组织成员的⾏为。包括规则、政策、程序、规范、 关系、系统等。
          • 项目治理是指用于指导项目管理活动的框架、功能和过程。
        • 管理要素（职能）
          • 组织根据其选择的治理框架和组织结构类型分配一般管理要素。分配到各个层级的职责、终责和职权表明了各个层级的员工在组织结构内执⾏上述职能的⽅式。
        • 项目管理办公室（PMO）：对与项目相关的治理过程进⾏标准化，并促进资源、方法论、工具和技术共享的一个组织结构
          • 支持型
            • 担当顾问的⻆⾊，向项目提供模板、最佳实践， 以及来自其他项目的信息和经验教训。（资源库）
          • 控制型
            • 不仅给项目提供⽀持，⽽且通过各种⼿段要求项 目服从。（控制程度中等）
          • 指令型
            • 直接管理和控制项目。项目经理由 PMO 指定并 向其报告。（控制程度高）
          • PMO 的一个主要职能是通过各种⽅式向项目经理提供⽀持
            • 对 PMO 所辖的全部项目的共享资源进⾏管理；
            • 识别和制定项目管理⽅法、最佳实践和标准；
            • 指导、辅导、培训和监督；
            • 通过项目审计，监督对项目管理标准、政策、程序和模板的遵守程度；
            • 制定和管理项目政策、程序、模板和其他共享的⽂件（组织过程资产）；
            • 对跨项目的沟通进⾏协调。
• 第三章 项目经理角色
  • 项目经理作用
    • ⻆⾊与成员
      • 大型团队中项目经理可能领导上百位成员，各⾃有不同的职责和技能；
    • 在团队中的成员
      • 对团队成果负责，需要从整体的⻆度来看待团队产品，以便进⾏规划、协调和完成；
    • 知识和技能
      • ⽆需承担项目中的每个⻆⾊，但应具备项目管理知识、技术知识、理解和经验。项目经理通过沟通领导项目团队进⾏规划和协调。
  • 考点
    • 项目经理和职能经理的区别
    • 项目经理的影响⼒范围及能⼒三⻆
      • PMI人才三⻆©
        • 技术项目管理——与项目、项目集和项目组合管理特定领域相关的知识、技能和⾏为，即⻆⾊履⾏的技术⽅⾯。
        • 领导⼒——指导、激励和带领团队所需的知识、技能和⾏为，可帮助组织达成业务目标。
        • 战略和商务管理——纵览组织概括并有效协商和执⾏有利于战略调整和创新的决策和⾏动。
    • 项目经理的职业道德
      • 做一个圣人
    • 项目经理的技能
      • 通过以下方式管理关系和冲突：
        • 建立信任；
        • 解决顾虑；
        • 寻求共识；
        • 平衡相互竞争和对立的目标；
        • 运用说服、协商、妥协和解决冲突的技能；
        • 发展和培养个人及专业网络；
        • 以⻓远的眼光来看待人际关系是与项目同样重要；
        • 持续发展和运用政治敏锐性。
      • 通过以下⽅式进⾏沟通：
        • 花大量的时间沟通（研究显示，顶尖的项目经理投入约90%左右的时间在沟上）；
        • 管理期望；
        • 诚恳地接受反馈；
        • 提出建设性的反馈；
        • 询问和倾听。
• 第四章 项目整合管理
  • • 敏捷思想 渐进明细
    • 有的放矢 选择vs努⼒
  • 项目整合管理由项目经理负责。虽然其他知识领域可以由相关专家（如成本分析专家、进度规划专家、风险管理专家管理，但是项目整合管理的责任不能被授权或转移。
  • 4.1 制定项目章程
    • • 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
        • 一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。作用是明确项目与组织战略目标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺。
    • 项目章程是由项目启动者或发起人发布的，项目章程一旦被批准，就标志着项目的正式启动。在项目中，应尽早确认并任命项目经理，最好在制定项目章程时就任命，且总应在规划开始之前任命。项目章程可由发起人编制，或者由项目经理与发起机构合作编制。
    • 考点
      • 项目章程是由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理使用组织资源开展项目活动的文件。它记录了关于项目和项目预期交付的产品、服务或成果的高层级信息
        • 项目目的
        • 可测量的项目目标和相关的成功标准
        • 高层级需求
        • 高层级项目描述、边界定义以及主要可交付成果
        • 整体项目风险
        • 预先批准的财务资源
        • 总体⾥程碑进度计划
        • 关键相关方名单
        • 项目审批要求（如用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束）
        • 项目退出标准（如在何种条件下才能关闭或取消项目或阶段）
        • 委派的项目经理及其职责和职权；
        • 发起人或其他批准项目章程的人员的姓名和职权。
      • 项目由项目以外的机构来启动，如发起人、项目集或项目管理办公室（PMO）、项目组合治理委员会主席或其授权代表。 项目启动者或发起人应该具有一定的职权，能为项目获取资金并提供资源。（提供支持）
      • 输入文件
        • • 项目章程包含来源于商业文件中的相关项目信息。既然商业⽂件不是项目⽂件，项目经理就不可以对它们进⾏更新或修改，只可以提出相关建议。
          • 协议有多种形式，包括合同、谅解备忘录（MOU）、服务水平协议（SLA）、协议书、意向书、口头协议、电子邮件或其他书⾯协议。不要把项目章程看作合同，因为其中未承诺报酬或金钱或用于交换的对价。
      • 工具与技术
        • 工具
          • 专家判断
            • 专家判断是指基于某应用领域、知识领域、学科和⾏业等的专业知识⽽做出的，关于当前活动的合理判断，这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人。在PMBOK指南中，专家判断作为一种工具与技术，用在35个管理过程中。
          • 人际关系和团队技能
            • 冲突管理
              • 冲突管理有助于相关⽅就目标、成功标准、高层级需求、项目描述、总体⾥程碑和其他内容达成一致意见。
            • 引导
              • 引导是指有效引导团队活动成功以达成决定、解决⽅案或结论的能⼒。引导者确保参与者有效参与，互相理解，考虑所有意见，按既定决策流程全⼒⽀持得到的结论或结果，以及所达成的⾏动计划和协议在之后得到合理执⾏
            • 会议管理
              • 会议管理包括准备议程、确保邀请每个关键相关方群体的代表，以及准备和发送后续的会议纪要和⾏动计划
      • 输出
        • 假设日志
          • 在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程
          • 较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成
          • 假设日志用于记录整个项目生命周期中的所有假设条件和制约因素
  • 4.2 制定项目管理计划
    • 制定项目管理计划是定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。本过程的主要作用是，生成一份综合文件，用于确定所有项目工作的基础及其执⾏⽅式，它仅开展一次或仅在项目的预定义点开展
    • 定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。项目管理计划包括经过整合的项目基准和子计划
    • 项目团队把项目章程作为初始项目规划的起始点。而项目管理计划作为执⾏阶段的入口。
    • • 项目管理计划应基准化，即，至少应规定项目的范围、时间和成本方面的基准，以 便据此考核项目执⾏情况和管理项目绩效
      • 在确定基准之前，可能要对项目管理计划进⾏多次更新，且这些更新⽆需遵循正式 流程。但是，一旦确定了基准，就只能通过实施整体变更控制过程进⾏更新
    • 项目启动会（开工会议Kick-off meeting）
      • 在本过程中，可以通过会议讨论项目方法，确 定为达成项目目标⽽采用的工作执⾏⽅式，以及制 定项目监控方式。
      • 项目启动会通常意味着规划阶段结束和执⾏阶段开始
        • ①传达项目目标
        • ②获得团队对项目的承诺
        • ③阐明每个相关⽅的⻆⾊和职责
      • 项目启动会可能在不同时间点举⾏，对于多阶段项目，通常在每个阶段开始时都要举⾏一次项目 启动会
  • 4.3 指导与管理项目工作
    • 是为实现项目目标而领导和执⾏项目管理计划中所确 定的工作，并实施已批准变更的过程。本过程的主要作用 是，对项目工作和可交付成果开展综合管理，以提高项目 成功的可能性。本过程需要在整个项目期间开展。
    • 为实现项目目标⽽领导和执⾏项目管理计划中所确定的工作，并实施已批准变更的过程
    • 考点
      • 问题日志
        • 在整个项目生命周期中，项目经理通常会遇到问题、差距、不一致或意外冲突。项目经理需要采取某些⾏动加以处理，以免影响项目绩效。问题⽇志是一种记录和跟进所有问题的项目文件
          • 问题类型
          • 问题提出者和提出时间
          • 问题描述
          • 问题优先级
          • 由谁负责解决问题
          • 目标解决日期
          • 问题状态
          • 最终解决情况
        • 问题⽇志可以帮助项目经理有效跟进和管理问题，确保它们得到调查和解决。作为本过程的输出，问题日志被首次创建，尽管在项目期间任何时候都可能发生问题。在整个项目生 命周期应该随同监控活动更新问题⽇志
        • 什么时候使用《问题日志》
          • 1. 已经产生的问题、问题的跟踪、解决方案等都要查看/更新 问题日志
          • 2. 寻找“问题、缺陷、问题如何解决”等关键字
      • 变更请求
        • 变更请求是关于修改任何⽂件、可交付成果或基准的正式提议。任何项目相关方都可以提出变更请求，应该通过实施整体变更控制过程对变更请求进⾏审查和处理。变更请求源⾃项目内部或外部，是可选或由法律（合同）强制的。
          • 缺陷补救 为了修正不一致产品或产品组件的有目的的活动
          • 纠正措施 为使项目工作绩效重新与项目管理计划一致，⽽进⾏的有目的的活动
          • 预防措施 为确保项目工作的未来绩效符合项目管理计划，⽽进⾏的有目的的活动
          • 更新 对正式受控的项目文件或计划等进⾏的变更，以反映修改或增加的意见或内容
  • 4.4 管理项目知识
    • 使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程
    • 管理项目知识是使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。本过程的主要作用是，利用已有的组织知识来创造或改进项目成果，并且 使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展
    • • 知识管理指管理显性和隐性知识，旨在重复使用现有 知识并生成新知识。关键活动是知识分享和知识集成
      • 隐性知识虽蕴含情境，却很难编撰。它存在于专家个人的思想中，或者存在于社会团体和情境中，通常经由人际交流和互动 来分享。
      • 一个常见误解是，知识管理只是将知识记录下来用于分 享；另一种常见误解是，知识管理只是在项目结束时总结经 验教训，以供未来项目使用。这样的话，只有经编撰的显性知识可以得到分享。
    • • 从组织的⻆度来看，知识管理指的是确保在项目开始之前、开展期间和结束之后得到运用
    • 知识管理工具
      • 知识管理工具和技术将员工联系起来，使他们能够合作生成新知识、分享隐性知识，以及集成不同团队成员所拥有的知识
        • 讲故事
        • 人际交往，包括非正式社交和在线社交
        • 会议，包括虚拟会议
        • 工作跟随和跟随指导
        • 讨论论坛，如焦点小组
        • 知识分享活动，如专题讲座和会议
        • 实践社区和特别兴趣小组
        • 研讨会，包括问题解决会议和经验教训总结会议
        • 创造⼒和创意管理技术
        • 知识展会和茶座
        • 交互式培训
    • 信息管理
      • 信息管理工具和技术用于创建人们与知识之间的联系，可以有效促进简单、明确的显性知识的分享
        • 编撰显性知识的方法，例如，如何确定经验教训登记册的条目；
        • 经验教训登记册；
        • 图书馆服务；
        • 信息收集，例如搜索网络和阅读已发表的文章；
        • 项目管理信息系统(PMIS)。项目管理信息系统通常包括⽂档管理系统。
    • 考点
      • 输出——经验教训登记册
        • 经验教训登记册可以包含情况的类别和描述，经验教训登记册还可包括与情况相关的影响、 建议和⾏动⽅案。经验教训登记册可以记录遇到的挑战、问题、意识到的风险和机会，或其他适用的内容。
          • 经验教训登记册在项目早期创建，作为本过程的输出。
          • 在整个项目期间，它可以作为很多过程的输⼊，也可以作为输出⽽不断更新。
          • 在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产的一部分。
  • 4.5 监控项目工作
    • 监督是贯穿于整个项目的项目管理活动之一，包括收集、测量和分析测量结果，以及预测趋势，以便推动过程改进
    • 持续的监督使项目管理团队能洞察项目的健康状况，并识别须特别关注的任何方面
    • 控制包括制定纠正或预防措施或重新规划，并跟踪⾏动计划的实施过程，以确保它们能有效解决问题
    • • 跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程
    • 考点
      • 数据分析
        • 备选方案分析
        • 成本效益分析
        • 挣值分析
        • 趋势分析
        • 偏差分析
      • 变更请求
        • 通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或缩小项目范围与产品范围，或者提高、调整或降低质量要求和进度或成本基准。变更请求可能导致需要收集和记录新的需求。变更可能会影响项目管理计划、项目⽂件或产品可交付成果。应该通过实施整体变更控制过程对变更 请求进⾏审查和处理
          • 缺陷补救 为了修正不一致产品或产品组件的有目的的活动
          • 纠正措施 为使项目工作绩效重新与项目管理计划一致，⽽进⾏的有目的的活动
          • 预防措施 为确保项目工作的未来绩效符合项目管理计划，⽽进⾏的有目的的活动
          • 更新 对正式受控的项目文件或计划等进⾏的变更，以反映修改或增加的意见或内容
  • 4.6 实施整体变更控制
    • 实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项目⽂件和项目管理计划的变更，并对变更处理结果进⾏沟通的过程
    • 如果不考虑变更对整体项目目标或计划的影响就开展 变更，往往会加剧整体项目风险。本过程需要在整个项目期间开展
    • 审查所有变更请求，批准变更，管理对可交付成果、项目⽂件和项目管理计划的变更，并对变更处理结果进⾏沟通的过程。该过程贯穿项目始终
    • 实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任
    • 变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目⽂件
    • 在整个项目生命周期的任何时间
    • 参与项目的任何相关方都可以提出变更请求
    • • 在基准确定之前，变更⽆需正式受控于实施整体变更控制过程。一旦确定了项目基准，就必须通过本过程来处 理变更请求
      • 尽管也可以⼝头提出，但所有变更请求都必须以书面形式记录，并纳⼊变更管理和（或）配置管理系统中
    • 监控项目工作
      • • 配置管理活动
          • 识别配置项
          • 记录并报告配置项状态
          • 进⾏配置项核实与审计
        • 变更管理活动
          • 识别变更
          • 记录变更
          • 做出变更决定
          • 跟踪变更
        • 配置控制重点关注可交付成果及各个过程的技术规范，变更控制则着眼于识别、记录、批准或否决对项目⽂件、可交付成果或基准的变更
    • • 1、提出变更申请
        • 项目任何干系人都可以提出变更申请
        • 所有变更申请都必须要书⾯记录，并纳 ⼊配置管理系统
      • 2、变更影响分析
        • 项目经理负责，可⾃己或指定人员完成
      • 3、CCB审查批准
        • 每个变更申请都必须有一位责任人批准或否决，通常是项目发起人或项目经理
        • 必要时，由CCB进⾏审查批准
      • 4、变更实施
        • 不同时间的变更申请，涉及到 的实施人员也不同
      • 5、监控变更实施
        • 项目经理要负责已批准的变更得到正确的落实
      • 6、结束变更
        • 分发新文档
        • 成果纳⼊配置管理
        • 通知干系人
  • 4.7 结束项目或阶段
    • 结束项目或阶段是终结项目、阶段或合同的所有活动 的过程。
      • ①存档项目或阶段信息；
      • ②完成计划的工作；
      • ③释放组织团队资源以展开新的工作。它仅开展一次或仅在项目的预定义点开展。
    • • 终结项目、阶段或合同的所有活动的过程
    • 考点
      • 项目文件（最终版）
        • 可在本过程更新所有项目文件，并标记为最终版本。
        • 特别值得注意的是，经验教训登记册的最终版本要包含阶段或项目收尾的最终信息。
          • 效益管理
          • 商业论证的准确性
          • 项目和开发生命周期
          • 风险和问题管理
          • 相关方参与
          • 以及其他项目管理过程。
      • 关闭合同协议（供应商）
        • 为关闭项目合同协议或项目阶段合同协议所必须开展的活动
          • 确认卖方的工作已通过正式验收；
          • 最终处置未决索赔；
          • 更新记录以反映最后的结果；
          • 存档相关信息供未来使用。
      • 编写最终报告
        • 用最终报告总结项目绩效，其中可包含诸如以下信息
          • 项目或阶段的概述；
          • 范围、质量、成本、进度结果；
          • 关于项目过程中发生的风险或问题及其解决情况的概述。
          • 最终产品、服务或成果的确认信息的总结。
          • 关于最终产品、服务或成果如何满足商业计划所述业务需求的概述。
      • 通过最终产品、服务或成果验收
        • 确保所有文件和可交付成果都已是最新版本，且所有问题都已得到解决；
        • 确认可交付成果已交付给客⼾并已获得客⼾的正式验收；
        • 测量相关⽅的满意程度。
        • 验收的可交付成果可包括批准的产品规范、交货收据和工作绩效文件。对于分阶段实施的项目或提前取消的项目，还可能包括部分完成或中间的可交付成果
      • 产品移交
        • 项目交付的产品、服务或成果可转交给另一团队或组织，并由其在整个生命周期中进⾏运营、维护和支持
        • 本输出所指的正是把项目交付的最终产品、服务或成果（对于阶段收尾，则是所在阶段的中间产品、服务或成果）从一个团队转交到另一个团队。
      • 提前终止
        • 如果项目在完工前就提前终止，结束项目或阶段过程还需要制定程序，来调查和记录提前终止的原因。并把该项目的已完成和未完成的可交付成果移交他人。
      • 释放资源
        • 关闭项目账⼾
        • 重新分配人员
        • 重新分配项目设施、设备和其他资源
• 第五章 项目范围管理
  • 考点
    • 范围管理的步骤
      • 包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。
    • 项目环中“范围”的两种含义
    • 不同类型项目中的“控制范围”
      • 预测型
        • 开始时定义可交付成果，过程中对所有范围 变化进⾏渐进管理（变更）
      • 适应型或敏捷型
        • 整体范围分解为一系列产品未完项，多轮迭 代完成。每次迭代前开始时确定本轮范围， 每次迭代中，反复开展“收集需求-定义范围 -创建WBS”的流程。
    • 总结
      • 范围管理的各个过程
  • 规划范围管理
    • • 规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，⽽创建范围管理计划的过程。
      • 本过程的主要作用是，在整个项目期间对如何管理范围 提供指南和方向。
      • 本过程仅开展一次或仅在项目的预定义点开展
    • 考点
      • 规划范围管理的输出⽂件
  • 收集需求
    • • 收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。
      • 本过程的主要作用是，为定义产品范围和项目范围奠定基础，且仅开展一次或仅 在项目的预定义点开展。
    • 收集需求的技术
      • 收集需求的输出
        • 考点
          • 需求文件
            • 需求文件描述各种单一需求将如何满足与项目相关的业务需求
              • 只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。
            • 需求可以分为业务解决方案和技术解决方案。前者是 相关方的需要，后者是指如何实现这些需要。
            • 需求的类别
              • 业务需求
              • 相关方需求
              • 解决方案需求
                • 功能需求
                • 非功能需求
              • 过渡和就绪需求
              • 项目需求
              • 质量需求
          • 需求跟踪矩阵
            • 把产品需求从其来源连接到能满足需求的可交付成果的一种表格
            • 提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准 的每项需求在项目结束的时候都能交付
            • 需求跟踪矩阵还为管理产品范围变更提供了框架
      • 考点
        • 收集需求技术
        • 数据决策技术
        • 数据表现技术
          • 数据建模技术
            • 系统交互图
              • 对产品范围的可视化描绘，显示业务系统及其与人和其他系统（⾏动者）之间的交互⽅式。
            • 原型法
              • 原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈
                • 微缩产品
                • 计算机生成的二维和三维模型
                • 实体模型或模拟
              • 原型法支持渐进明细的理念
              • 故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径
        • 人际关系和团队技能
          • 观察
            • 也称为“工作跟随”，当产品使用者 难以或不愿清晰说明他们的需求时适用
          • 引导
            • 引导与主题研讨会结合使用，把主 要相关方召集在一起定义产品需求
            • 研讨会可用于快速定义跨职能需求并协调相关方的 需求差异
            • 与分别召开会议相比，研讨会能够更早发现并解决问题
  • 定义范围
    • • 定义范围是制定项目和产品详细描述的过程
      • 本过程的主要作用是，描述产品、服务或成果的边界和验收标准。
    • 考点
      • 输出-范围说明书
        • 定义范围是制定项目和产品详细描述的过程
        • 定义范围过程要从《需求文件》中选取最终的项目需求，然 后制定出关于项目及其产品、服务或成果的边界和验收标准
        • 包括内容
          • 1、产品范围描述：包括项目和产品范围。
          • 2、可交付成果。
          • 3、验收标准：可交付成果通过验收前必须满足的一系列条件。
          • 4、项目的除外责任：识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关⽅的期望及减少范围蔓延。
          • 5、项目边界基准：为评价变更请求或额外工作是否超过项目边界提供基准。
        • 项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同
  • 创建WBS
    • • Work Breakdown Structure
      • 创建工作分解结构（WBS）是把项目可交付成果 和项目工作分解成较小、更易于管理的组件的过程
      • 本过程的主要作用是，为所要交付的内容提供架构，它仅开展一次或仅在项目的预定义点开展。
    • WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作
    • 在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本⾝
    • WBS 最底层的组成部分称为工作包。
    • 考点
      • 技术-WBS分解技术
        • • 自上而下
            • 逐层细化分解
          • 自下而上
            • 用于归并较低层次组件
          • 滚动式规划
            • 要在未来远期才完成的可交付成果或组件，当前可能无法分解。
            • 项目管理团队因⽽通常需要等待对该可交付成果或组成部分达成一致意见，才 能够制定出 WBS 中的相应细节。
      • 输出-范围基准
        • WBS词典
  • 确认范围
    • • 确认范围是正式验收已完成的项目可交付成果的过程。
      • 本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。
      • 本过程应根据需要在整个项目期间定期开展。
    • 考点
      • 确认范围的概念
        • 由客⼾或发起人审查从控制质量过程输出 的核实的可交付成果，是对可交付成果的确认和最终验收
        • 确认范围过程与控制质量过程的不同之处 在于，前者关注可交付成果的验收，而后者关 注可交付成果的正确性及是否满⾜质量要求。
      • 确认范围的执行
        • 时间
          • 确认范围在每个可交付成果生成时或者在阶段审查点开展（阶段结束时）
        • 事件
          • 通过检查开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准
        • 人物
          • 符合验收标准的可交付成果应该由客⼾或发起人正式签字批准。应该从客⼾或发起人那⾥获得正式文件，证明相关方对项目可交付成果的正式验收。
  • 控制范围
    • • 控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
      • 本过程的主要作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。
    • 考点
      • 有变更，走流程
        • 在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展
          • 流程
            • 先了解；
            • 再分析；
            • 提申请。
        • 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。
      • 控制范围的数据分析技术
• 第六章 项目进度管理
  • 项目进度管理
    • 控制进度
      • 定义：监督项目状态，以更新项目 进度和管理进度基准变更的过程。
      • 作用：在整个项目期间保持对进度 基准的维护。
      • • 进度控制的重要工作之一，是决定需不需要针对进度偏差采取纠正措施。
          • 例如： ⾮关键路径上的某个活动发生较⻓时间的延误，可能并不会对整体项目进度产生影响； ⽽某个关键或次关键活动的少许延误，却可能需要立即采取⾏动
      • • 规划进度管理
          • 定义：为规划、编制、管理、执⾏和控制项目进度⽽制定政策、程序和文档的过程。
          • 作用：为如何在整个项目期间管理项目进度提供指南和方向。
        • 定义活动
          • 定义：识别和记录为完成项目可交付成果⽽需采取的具体⾏动的过程。
          • 作用：将工作包分解为进度活动，作为对项目工作进⾏进度估算、规划、执⾏、监督和控制的基础。
        • 排列活动顺序
          • 定义：识别和记录项目活动之 间的关系的过程。
          • 作用：是定义工作之间的逻辑 顺序，以便在既定的所有项目 制约因素下获得最高的效率。
        • 估算活动持续时间
          • 定义：根据资源估算的结果， 估算完成单项活动所需工作时 段数的过程。
          • 作用：确定完成每个活动 所需花费的时间量。
          • • 估算依据
              • 活动工作范围
              • 所需资源类型
              • 所需资源数量
              • 资源日历
            • 需要考虑因素
              • 收益递减规律
              • 资源数量
              • 技术进步
              • 员工激励
        • 制定进度计划
          • 定义：分析活动顺序、持续时间、 资源需求和进度制约因素，创建 进度模型，从⽽落实项目执⾏和 监控的过程。
          • 作用：把进度活动、持续时 间、资源、资源可用性和逻辑关 系代入进度规划工具，从而形成 包含各个项目活动的计划日期的 进度模型。
  • 考点
    • 项目进度管理的各个过程
    • 进度管理计划
      • 进度管理计划是项目管理计划的组成部分，为编制、监督和控制项目进度建立准则和明确活动。
      • 进度管理计划规定
        • 项目进度模型的确定
        • 项目进度模型维护
        • 准确度
        • 计量单位
        • 组织程序链接
        • 进度计划的发布和迭代⻓度
        • 控制临界值
        • 报告格式
        • 绩效测量规则
    • 分解及滚动式规划
      • 分解
        • 活动表示完成工作包所需的投入。定义活动过程的最终输出是活动⽽不是可交付成果。
      • 滚动式规划
        • 一种迭代式的规划技术，即详细规划近期要完成的工作（工作包），同时在较高层级上粗略规划远期工作（规划包）。它是一种渐进明细的规划方式。
    • 输出-活动清单、活动属性和⾥程碑清单
      • 活动清单
        • 活动清单包含项目所需的进度活动。包括每个活动的标识及工作范围详述，使项目团队成员知道需要完成什么工作。
      • 活动属性
        • 活动属性是指每项活动所具有的多重属性，用来扩充对活动的描述，活动属性随时间演进。
      • 里程碑清单
        • ⾥程碑是项目中的重要时点或事件，⾥程碑清单列出了所有项目⾥程碑，并指明每个⾥程碑是强制性的（如合同要求的）还是选择性的（如根据历史信息确定的）。⾥程碑的持续时间为零，因为它们代表的是一个重要时间点或事件。
    • 确定和整合依赖关系
    • 紧前关系绘图法（PDM）
      • 完成到开始（FS）
        • • 只有紧前活动完成，紧后活动才能开始的逻辑关系。
          • 例如，只有完成装配PC 硬件（紧前活动），才能开始在 PC 上安装操作系统（紧后活动）
      • 完成到完成（FF）
        • • 只有紧前活动完成，紧后活动才能完成的逻辑关系
          • 例如，只有完成文件的编写（紧前活动），才能完成文件的编辑（紧后活动）
      • 开始到开始（SS）
        • • 只有紧前活动开始，紧后活动才能开始的逻辑关系。
          • 例如，开始地基浇灌（紧前活动）之后，才能开始混凝土的找平（紧后活动）。
      • 开始到完成（SF）
        • • 只有紧前活动开始，紧后活动才能完成的逻辑关系。
          • 例如，只有启动新的应付账款系统（紧前活动），才能关闭旧的应付账款系统（紧后活动）。
    • 提前量和滞后量
    • 项目进度网络图
      • 表示项目进度活动之间的逻辑关系（也叫依赖关系）的图形。带有多个紧前活动的活动代表路径汇聚，而带有多个紧后活动的活动则代表路径分⽀。（紧前-紧后关系）
    • 资源日历
      • 资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。在规划活动期间，潜在的可用资源信息（如团队资源、设备和材料）用于估算资源可用性。
      • 所有人的排班表
    • 时间估算方法
    • 储备时间分析
    • 关键路径法编制进度计划
    • 资源优化调整匹配资源
      • 资源优化用于调整活动的开始和完成日期，以调整计划使用的资源，使其等于或少于可用的资源。（组织关系依赖）资源平衡导致关键路径改变，资源平滑不会改变关键路径。
    • 进度压缩技术
      • 进度压缩是指在不改变项目范围的前提下，缩短项目的进度时间，以满足进度制约因素、强制日期或其他进度目标
    • 敏捷发布规划
    • ⾥程碑进度计划
    • 概括性进度计划—横道图（甘特图）
    • 详细进度计划
    • 迭代燃尽图
• 第七章 项目成本管理
  • 成本管理的概念
    • 项目成本管理重点关注完成项目活动所需资源的成本，但同时也应考虑项目决策对项目产品、服务或成果的使用成本、维护成本和支持成本的影响。
      • 固定成本和变动成本
      • 直接成本和间接成本
      • 机会成本、边际成本和沉没成本
  • 成本管理的步骤
    • 规划成本管理
      • 规划成本管理——确定如何估算、预算、管理、监督和控制项目成本的过程。主要作用是，在整个项目期间为如何管理项目成本提供指南和方向。
        • 在开始成本管理的其他三个过程前，项目 管理团队需先⾏规划，形成一份成本管理计划。
        • 应该在项目规划阶段的早期就对成本管理 工作进⾏规划。
    • 估算成本
      • 估算成本是对完成项目工作所需资金进⾏近似估算的过程。本过程的主要作用是，确定项目所需的资金。
        • 本过程应根据需要在整个项目期间定期开展
    • 制定预算
      • 制定预算是汇总所有单个活动或工作包的估算 成本，建立一个经批准的成本基准的过程。
        • 本过程的主要作用是，确定可据以监督和控制项目绩效的 成本基准。
        • 本过程仅开展一次或仅在项目的预定义点开展。
      • 项目预算包括经批准用于执⾏项目的全部资金。
        • 而成本基准是经过批准且按时间段分配的项目 预算，包括应急储备，但不包括管理储备。
    • 控制成本
      • 控制成本是监督项目状态，以更新项目成本和管理成本基准变更的过程。本过程的主要作用是，在整个项目期间保持对成本基准的维护。本过程需要在整个项目期间开展
      • 只有经过实施整体变更控制过程的批准，才可以增加预算。有效成本控制的关键在于管理经批准的成本基准。
  • 考点
    • 固定成本和变动成本
      • 成本 = 固定成本 + 产量 × 变动成本
      • 销售额 = 销量 × 单价
      • 利润 = 销售额 - 成本
    • 直接成本和间接成本
    • 机会成本、边际成本和沉没成本
    • 项目成本管理的各个过程
    • 成本管理计划
      • 成本管理计划是项目管理计划的组成部分，描述将如何规划、安排和控制项目成本
        • 计量单位
        • 精确度
        • 准确度
        • 组织程序链接
        • 控制临界值
        • 绩效测量规则
        • 报告格式
        • 其他细节
    • 成本估算等级
      • 成本估算是对完成活动所需资源的可能成本的量化评估，是在某特定时点，根据已知信息所做出的成本预测
    • 成本估算的方法
      • 包括方面
        • ①对完成项目工作可能需要的成本；
        • ②应对已识别风险的应急储备；
        • ③以及应对计划外工作的管理储备的量化估算。成本估算可以是汇总的或详细分列的。成本估算应覆盖项目所使用的全部资源，包括（但不限于）直接人工、材料、设备、服务，以及一些特殊的成本种类，如融资成本（包括利息）、通货膨胀补贴、汇率或成本应急储备。如果间接成本也包含在项目估算中，则可在活动层次或更高层次上计列间接成本。
    • 成本基准
    • 项目资金需求
      • • 按时间段分配成本基准， 得到一条S曲线，根据成本 基准，确定总资金需求和 阶段性（如季度或年度） 资金需求。项目资金通常 以增量的⽅式投⼊，并且 可能是非均衡的，呈现出 图中所示的阶梯状。
    • 挣值分析（EVA）
      • EVA（Earned Value Analysis）是一种常用的绩效测量⽅法，可采用多种形式。它综合考虑项目范围、成本与进度指标，帮助项目管理团队评估与测量项目绩效和进展。
        • 挣值分析将实际进度和成本绩效与绩效测量基准进⾏比较，以判断现状（偏差），预测未来（趋势）
      • 计划价值。PV是为某活动或WBS组成部分的预定工作进度而分配且经批准的预算。PV应该与经批准的特定工作内容相对应，是项目生命周期中按时段分配的这部分工作的预算。PV 的总和有时被称为完工预算 BAC 。
      • 挣值。EV是项目活动或WBS组成部分的已完成工作的价值，用分配给该工作的预算来表示。EV的计算必须与BAC相对应，不得大于相应活动或WBS组成部分的PV预算值。EV常用来描述项目的完工百分比。
      • 实际成本。AC是为完成活动或WBS组成部分的工作，而实际发生并记录在案的总成本。它是为完成与EV 相对应的工作而发生的总成本。AC的计算口径必须与PV和EV 的计算口径保持一致。AC没有上限，为实现EV 所花费的任何成本都要计算进去。
      • 公式
        • 进度偏差（Schedule Variance）：SV = EV-PV 成本偏差（ Cost Variance ） ：CV = EV-AC
        • 进度绩效指数（ Schedule Performance Index ） ：SPI = EV/PV 成本绩效指数（ Cost Performance Index ） ：CPI = EV/AC
        • BAC，完工预算 ——所有的活，价值最初预算多少钱（总预算） BAC=完工时的PV总和
        • ETC，剩余工作的成本。有两种计算方式：
          • ETC 1= BAC-EV ，当前偏差被看作是非典型的。按最初，当前剩下的活，得花多少钱
          • ETC 2 = ETC1/CPI，当前偏差被看作是典型的。按当前，当前剩下的活，得花多少钱
        • EAC，完工估算——当前估计的项目总花费
          • EAC 1=AC + ETC =AC+（BAC–EV）
          • EAC 2= AC+（BAC-EV）/CPI = BAC/CPI
• 第八章 项目质量管理
  • 质量管理的内涵
    • ⼏组对比概念和理论
    • 质量管理水平有效性
    • 质量管理流程
    • 规划质量管理
      • 规划质量管理——识别项目及其可交付成果的质量要求和/或标准，并书面描述项目将如何证明符合质量要求和/或标准的过程
    • 管理质量
      • 管理质量——管理质量是把组织的质量政策用于项目，并将质量管理计划转化为可执 ⾏的质量活动的过程。
    • 控制质量
      • 控制质量——为了评估绩效，确保项目输出完整、正确且满⾜客⼾期望，⽽监督和记录质量管理活动执⾏结果的过程
    • 质量管理的输⼊输出
      • 质量管理的⽂件
    • 事业环境因素及组织过程资产
      • 事业环境因素
        • ISO9000族标准
          • 1. 帮助各种类型和规模的组织实施并运⾏有效的质量管理体系，增 进顾客满意度 2. ISO9000：表述质量管理体系基础知识并规定质量管理体系术语 3. ISO9001：规定质量管理体系要求，用于组织证实其具有提供满 ⾜顾客要求和适用的法规要求的产品的能⼒，目的在于增进顾客 满意 4. ISO9004：提供考虑质量管理体系的有效性和效率两⽅⾯的指南。 该标准的目的是组织业绩改进和顾客及其他相关方满意 5. ISO19011：提供审核质量和环境管理体系指
          • ISO八项基本原则
            • 以顾客为关注焦点
            • 领导作用
            • 全员参与
            • 过程方法
            • 管理的系统⽅法
            • 持续改进
            • 以事实为基础进⾏决策
            • 与供方互利的关系
    • 质量管理的工具和技术
  • 考点
    • 质量VS等级（朱兰理论）
      • 质量 作为实现的性能或成果，是“一 系列内在特性满足要求的程度”。
      • 等级 作为设计意图，是对用途相同但 技术特性不同的可交付成果的级别分类。
      • 朱兰三部曲 质量规划、质量控制、 质量改进的质量三元论。一些活动⼜在 整个过程的周而复始的循环中螺旋式上 升，称为质量螺旋曲线。
    • 管理质量VS质量保证
      • • 全⾯质量管理： 全员、全过程、全方位的质量管理
    • 预防VS检查（克鲁斯比理论）
      • 零缺陷管理：质量的定义即符合预先的要求。
      • 质量源于预防，⽽⾮检查。
      • 质量的执⾏标准是零缺陷。
      • 质量是用⾮一致性成本来衡量的。
    • 精确VS准确
      • 精确（Precision）是指重复测量的结果⾮常聚合，离散度很小；
      • 准确（Accuracy）是指测量值⾮常接近实际值；
    • 属性抽样VS变量抽样
    • 六西格玛管理
      • 核心是将所有的工作作为一种流程，即采用DMAIC（确定、测量、分析、改进、控制）对组织的关键流程进⾏改进
    • 五种质量管理水平的有效性
      • 项目质量管理需要兼顾项目管理与项目可交付成果两个方面
    • 能⼒成熟度模型CMMI
    • 项目质量管理的流程
    • 项目质量管理的流程
      • 规划质量管理
        • 关注工作需要达到的质量
      • 管理质量
        • 关注管理整个项目期间的质量过程
      • 控制质量
        • 关注工作成果与质量要求的比较，确保结果可接受
    • 质量管理计划
      • 质量管理计划是项目管理计划的组成部分，描述如何实施适用的政策、程序和指南以实现质量目标。
      • 质量管理计划包括（但不限于）以下组成部分：
        • 项目采用的质量标准；
        • 项目的质量目标；
        • 质量⻆⾊与职责；
        • 需要质量审查的项目可交付成果和过程；
        • 为项目规划的质量控制和质量管理活动；
        • 项目使用的质量工具；
        • 与项目有关的主要程序，如处理不符合的情况、纠正措施程序，以及持续改进程序。
    • 质量测量指标
      • 质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何验证符合程度。
      • 质量测量指标的例子包括按时完成的任务的百分比、以CPI测量的成本绩效、故障率、识别的⽇缺陷数量、每月总停机时间、每个代码⾏的错误、客⼾满意度分数，以及测试计划所涵盖的需求的百分比（即测试覆盖度）。
    • 输出-核实的可交付成果
    • 规划阶段
      • 标杆对照
        • 标杆对照是将实际或计划的项目实践或项目的质量标准与可比项目的实践进⾏比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照也允许用不同应用领域或⾏业的项目做类比。
      • 质量成本（COQ）
      • 成本效益分析
        • 成本效益分析是用来估算备选方案优势和劣势的财务分析工具，以确定可以创造最佳效益的备选⽅案。
        • 成本效益分析可帮助项目经理确定规划的质量活动是否有效利用了成本。
    • 发现问题
      • 审计与测试
        • 审计
          • 确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程
          • 质量审计通常由项目外部的团队开展，如组织内部审计部⻔、项目管理办公室 (PMO) 或组织外部的审计师
        • 测试/产品评估
          • 测试是一种有组织的、结构化的调查，旨在根据项目需求提供有关被测产品或服务质量的客观信息。测试的目的是找出产品或服务中存在的错误、缺陷、漏洞或其他不合规问题。
          • 不同应用领域需要不同测试。例如，软件测试可能包括黑盒测试、白盒测试等；在建筑项目中，测试可能包括水泥强度测试、混凝土和易用性测试等。
      • 核对单与核查表
        • 核对单
        • 核查表
          • 用于合理排列各种事项，以便有效地收集关于潜在质量 问题的有用数据。（可为帕累托图提供数据。）
      • 分析问题——根本原因分析
        • 5 WHY
        • 两个洞见
          • 1、项目经理（所有人）应该有打破沙锅问到底的精神，有透过现象看本质的能⼒；
          • 2、在工作中不能仅仅做问题的发现者和传递者，要做分析者和解决方案的提出人。
      • 数据表现技术
        • 亲和图
        • 思维导图
        • 流程图
          • 流程图是对一个过程的图形化表示，用来显示该过程中各步骤之间的相互关系。
          • 流程图展示了引发缺陷的一系列步骤。
          • SIPOC模型
            • 用来显示在一个或多个输 入转化成一个或多个输出 的过程中，所需要的步骤 顺序和可能分支。
        • 控制图
          • 控制图用于确定一个过程是否稳定，或者是否具有可预测的绩效。
          • 规格上限和下限是根据要求制定的，反映了可允许的最大值和最小值。
        • 直方图
          • 直⽅图可按来源或组成部分展示缺陷数量
        • 帕累托图
          • 将出现的质量问题和质量改进项目按照 重要程度依次排列而采用的一种图表。 帕累托法则（80/20原则）认为，相对少 量的原因通常造成大多数的问题或缺陷
        • 矩阵图
          • 矩阵图在⾏列交叉的位置展示因素、原因和目标之间的关系强弱。
        • 散点图
          • 展示两个变量之间的关系的图形
        • 因果图（鱼骨图、why-why分析图、石川图）
          • 将问题陈述的原因分解为离散的分支， 有助于识别问题的主要原因或根本原因。
      • 问题解决
        • 面向X的设计（Design for X）
          • 面向 X 的设计（DfX）是产品设计期间可采用的一系列技术指南，旨在优化设计的特定方面，可以控制或提高产品最终特性。
          • DfX 中的“X”可以是产品开发的不同⽅⾯，例如可靠性、调配、装配、制造、成本、服务、可用性、安全性和质量。
          • 使用 DfX 可以降低成本、改进质量、提高绩效和客⼾满意度。
• 第九章 项目资源管理
  • • 规划资源管理
      • 规划资源管理是定义如何估算、获取、管理和利用团队以 及实物资源的过程。本过程的主要作用是，根据项目类型和复 杂程度确定适用于项目资源的管理⽅法和管理程度。
      • 本过程仅开展一次或仅在项目的预定义点开展。
    • 估算活动资源
      • 估算活动资源是估算执⾏项目所需的团队资源，以 及材料、设备和用品的类型和数量的过程。
      • 本过程的主要作用是，明确完成项目所需的资源种 类、数量和特性。本过程应根据需要在整个项目期间定期开展。
    • 获取资源
      • 获取资源是获取项目所需的团队成员、设施、设备、材 料、用品和其他资源的过程。本过程的主要作用是，概述和 指导资源的选择，并将其分配给相应的活动。本过程应根据 需要在整个项目期间定期开展。
      • 项目所需资源可能来⾃项目执⾏组织的内部或外部。内 部资源由职能经理或资源经理负责获取（分配），外部资源 则是通过采购过程获得。
    • 建设团队
      • 建设团队是提高工作能⼒，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。
      • 本过程的主要作用是，改进团队协作、增强人际关系技能、激励员 工、减少摩擦以及提升整体项目绩效。
      • 本过程需要在整个项目期间开展。
      • 项目经理应该能够定义、建立、维护、激励、领导和鼓舞项目团队，使团队高效运⾏，并实现项目目标。团队协作是项目成功的关键因素，而建设高效的项目团队是项目经理的主要职责之一。
        • 通过以下⾏为可以实现团队的高效运⾏
          • 使用开放与有效的沟通；
          • 创造团队建设机遇；
          • 建立团队成员间的信任；
          • 以建设性⽅式管理冲突；
          • 鼓励合作型的问题解决方法；
          • 鼓励合作型的决策方法。
      • 建设项目团队的目标包括（但不限于）
        • 提高团队成员的知识和技能
          • 以提高他们完成项目可交付成果的能⼒，并降低成本、缩短工期和提高质量；
        • 提高团队成员之间的信任和认同感
          • 以提高士气、减少冲突和增进团队协作；
        • 创建富有生气、凝聚⼒和协作性的团队文化
          • （1）提高个人和团队生产效率，振奋团队精神，促进团队合作；
          • （2）促进团队成员之间的交叉培训和辅导，以分享知识和经验；
        • 提高团队参与决策的能⼒
          • 使他们承担起对解决⽅案的责任，从⽽提高团队的生产效率，获得更有效和高效的成果
      • 集成办公工具
    • 管理团队
      • 管理团队是跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程。
      • 本过程的主要作用是，影响团队⾏为、管理冲突以及解决问题。
      • 本过程需要在整个项目期间开展
    • 控制资源
      • 控制资源是确保按计划为项目分配实物资源，以及根据 资源使用计划监督资源实际使用情况，并采取必要纠正措施 的过程。
      • 本过程的主要作用是，确保所分配的资源适时适地 可用于项目，且在不再需要时被释放。
      • 本过程需要在整个项目期间开展。
  • 考点
    • 项目资源管理的各个过程
    • 组织论规划项目资源
      • 组织理论阐述个人、团队和组织部⻔的⾏为⽅式。有多种格式来记录和阐明团队成员的⻆⾊与职责。大多数格式属于层级型、矩阵型或文本型。⽆论使用什么⽅法来记录团队成员的⻆⾊，目的都是要确保每个工作包都有明确的责任人，确保全体团队成员都清楚地理解其⻆⾊和职责。
      • 层级型可用于表示高层级⻆⾊，⽽文本型则更适合用于记录详细职责。
      • 层级型
        • 资源分解结构是资源依类别和类 型的层级展现。信息细到可以与工作 分解结构（WBS）相结合。
        • 资源类别包括（但不限于）人⼒、 材料、设备和用品，资源类型则包括 技能水平、要求证书、等级水平或适 用于项目的其他类型。
        • 在规划资源管理过程中，资源分 解结构用于指导项目的分类活动。在 获取资源过程中，资源分解结构是一 份完整的文件，用于获取和监督资源。
      • 责任分配矩阵
        • 责任分配矩阵展示项目资源在各个工作包中的任务分配。在大型项目中，可以制定多个层次的RAM。矩阵图能反映与每个人相关的所有活动，以及与每项活动相关的所有人员，它也可确保任何一项任务都只有一个人负责，从而避免职权不清。
          • 责任分配矩阵RAM的一个例子是 RACI（执⾏、负责、咨询和知情）矩阵。分配给每项工作的资源可以是个人或小组，项目经理也可根据项目需要，选择“领导”或“资源”等适用词汇，来分配项目责任。如果团队是由内部和外部人员组成，RACI 矩阵对明确划分⻆⾊和职责特别有用。
      • 文本型
        • 如果需要详细描述团队成员的职责，就可以采用⽂本型。如职位描述、⻆⾊—职责—职权表。
      • 输出
        • 资源管理计划
          • 作为项目管理计划的一部分，资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南。资源管理计划可以根据项目的具体情况分为团队管理计划和实物资源管理计划
          • 资源管理计划可能包括（但不限于）：
            • 识别资源
            • 获取资源
            • 项目团队资源管理
            • 资源控制
            • 项目组织图
            • 角色与职责（角色-职权-职责-能力）
            • 团队建设
            • 培训策略
            • 认可计划
        • 团队章程
          • 团队章程是为团队创建团队价值观、共识和工作指南的文件。团队章程对项目团队成员的可接受⾏为确定了明确的期望。尽早认可并遵守明确的规则，有助于减少误解，提高生产⼒；讨论诸如⾏为规范、沟通、决策、会议礼仪等领域，团队成员可以了解彼此重要的价值观。
          • 团队章程可能包括（但不限于）：
            • 团队价值观
            • 沟通指南
            • 决策标准和过程
            • 冲突处理过程
            • 会议指南
            • 团队共识
    • 资源日历vs项目日历
      • 项目日历
        • 编排开展计划活动的工作 ⽇或轮流班次，以及不开展计 划活动的非工作日的日历。
        • 项目日历影响到所有的活动。
      • 资源日历
        • 识别了每种具体资源可用时的工作 日、班次、正常营业的上下班时间、周 末和公共假期。
        • 资源日历规定了在项目期间确定的 团队和实物资源何时可用、可用多久。
      • 工具
        • 决策
          • 多标准决策分析
            • 根据标准的相对重要性对标准进⾏加权，加权值可能因资源类型的不同⽽发生变化。
            • 可使用的选择标准包括：
              • 可用性、成本、能力；
              • 经验、知识、技能、态度、国际因素等。
        • 人际关系与团队技能
          • 谈判
            • 很多项目需要针对所需资源进⾏谈判，项目管理团队需要与下列各⽅谈判：
              • 职能经理。
              • 执⾏组织中的其他项目管理团队。
              • 外部组织和供应商
            • 在资源分配谈判中，项目管理团队影响他人的能⼒很重要，如同在组织中的政治能 ⼒一样重要。
        • 预分派
          • 预分派指事先确定项目的实物或团队资源，可在下列情况下发生
            • 在竞标过程中承诺分派特定人员进⾏项目工作；如施工单位签署的合同中会明确规定派出管理的项目经理人员。
            • 项目取决于特定人员的专有技能；
            • 在完成资源管理计划的前期工作之前，制定项目章程过程或其他过程已经指定了某些团队成员的工作分派
        • 输出文件
          • 实物资源分配单
            • 实物资源分配单记录了项目将使用的材料、设备、用品、地点和其他实物资源
          • 项目团队派工单
            • 项目团队派工单记录了团队成员及其在项目中的⻆⾊和职责，可包括项目团队名录，还需要把人员姓名插⼊项目管理计划的其他部分，如项目组织图和进度计划。
          • 资源日历
            • 资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。资源日历规定了在项目期间确定的团队和实物资源何时可用、可用多久
    • 团队建设五阶段
      • • 尽管这些阶段通常按顺序进⾏，但团队停滞在某个阶段或退回到较早阶段的情况也并⾮罕见；
        • 而如果团队成员曾经共事过，项目团队建设也可跳过某个阶段。
      • 工具
        • 集中办公和虚拟团队
        • 沟通技术
          • 在解决集中办公或虚拟团队的团队建设问题方面，沟通技术至关重要。它有助于为集中办公团队营造一个融洽的环境，促进虚拟团队（尤其是团队成员分散在不同时区的团队）更好地相互理解。
          • 可采用的沟通技术包括
            • 共享⻔⼾
              • 共享信息库（例如网站、协作软件或内部网）对虚拟项目团队很有帮助。
            • 视频会议
              • 视频会议是一种可有效地与虚拟团队沟通重要技术。
            • 音频会议
              • 音频会议有助于与虚拟团队建立融洽的相互信任的关系。
            • 电子邮件/聊天软件
              • 使用电子邮件和聊天软件定期沟通也是一种有效的方式。
        • 团队管理工具
        • 激励理论
          • 激励
            • 激励为某人采取⾏动提供了理由。提高团队参与决策的能⼒并鼓励他们独立工作。
          • 认可与奖励
            • 需要对成员的优良⾏为给予认可与奖励。只有能满⾜被奖励者的某个重要需求的奖励，才是有效的奖励。
            • 金钱是奖励制度中的有形奖励，然⽽也存在各种同样有效、甚⾄更加有效的无形奖励：大多数项目团队成员会因得到成⻓机会、获得成就感、得到赞赏以及用专业技能迎接新挑战，而受到激励。
        • 培训
          • 项目经理应该按资源管理计划中的安排来实施预 定的培训，也应该根据管理项目团队过程中的观察、 交谈和项目绩效评估的结果，来开展必要的计划外培 训，培训成本通常应该包括在项目预算中，或者如果 增加的技能有利于未来的项目，则由执⾏组织承担。
          • 培训包括旨在提高项目团队成员能⼒的全部活动，可以是正式或非正式的。
        • 领导⼒和影响⼒
          • 影响⼒
            • 矩阵环境中，项目经理对团队成员通常没有或 仅有很小的命令职权，适时施展影响⼒，对保证项 目成功⾮常关键。
            • 影响⼒主要体现在如下各⽅⾯：
              • 说服他人；
              • 清晰表达观点和立场；
              • 积极且有效的倾听；
              • 了解并综合考虑各种观点；
              • 收集相关信息，在维护相互信任的关系下，解决问题并达成一致意见。
          • 领导⼒
            • 成功的项目需要强有⼒的领导技能，领 导⼒是领导团队、激励团队做好本职工作的 能⼒。它包括各种不同的技巧、能⼒和⾏ 动。且领导⼒在项目生命周期中的所有阶段 都很重要。有多种领导⼒理论，定义了适用 于不同情形或团队的领导风格。领导⼒对沟 通愿景及鼓舞项目团队高效工作十分重要
        • 冲突管理
          • 情商
            • 谈判
              • 说服职能经理，让他/她看到项目具有良好的前景，会影响他/她把最佳资源分配给这个项目⽽不是竞争项目。
              • ⼽尔曼和其他研究者认为，情商由⾃我意识、控制情绪、⾃我激励、认知他人情绪和处理相互关系这五种特征组成。
                • 奥卡姆剃刀原则 若⽆必要，勿增实体
                • 汉隆剃刀原则 能用愚蠢解释的， 就不要用恶意
        • 团队建设
          • 团队建设是通过举办各种活动，强化团队的社交关系，打造积极合作的工作环境。团队建设活动既可以是状态审查会上的五分钟议程，也可以是为改善人际关系而设计的、在非工作场所专⻔举办的专业提升活动。
          • 非正式的沟通和活动有助于建立信任和良好的工作关系。团队建设在项目前期必不可少，但它更是个持续的过程。
          • 输出
            • 团队绩效评价
              • 有效的团队建设策略和活动可以提高团队绩效，从而提高实现项目目标的可能性。
              • 评价团队有效性的指标可包括：
                • 个人技能的改进，从⽽使成员更有效地完成工作任务；
                • 团队能⼒的改进，从⽽使团队成员更好地开展工作；
                • 团队成员离职率的降低；
                • 团队凝聚⼒的加强，从⽽使团队成员公开分享信息和经验，并互相帮助来提高项目绩效。
    • 管理团队的基本概念
      • 管理团队过程关注团队资源。包括（但不限于）：
        • ①促进团队协作，创建高效团队；
        • ②团队管理（运用沟通、冲突管理、谈判、领导技能）；
        • ③分配有挑战性的任务，表彰优秀绩效；
        • ④监督团队成员完成工作的意愿和能⼒，提供指导与⽀持。
    • 控制资源的基本概念
      • 控制资源过程关注实物资源，例如设备、材料、设施 和基础设施。
      • 控制资源过程关注
        • ①监督资源支出、缺乏/剩余情况；
        • ②确保按计划使用和释放资源；
        • ③在出现资源相关问题时通知相应的相关方；
        • ④对资源变更进⾏管理。
• 第十章 项目沟通管理
  • 项目沟通管理
    • 项目沟通管理包括通过开发工件，以及执⾏用于有效交换信息的 各种活动，来确保项目及其相关方的信息需求得以满足的各个过程
    • 项目沟通管理由两个部分组成：
      • 第一部分是制定策略，确保沟通对相关⽅⾏之有效；
      • 第二部分是执⾏必要活动，以落实沟通策略。
    • • 规划沟通管理
        • 规划沟通管理是基于每个相关⽅或相关⽅群体 的信息需求、可用的组织资产，以及具体项目的需 求，为项目沟通活动制定恰当的方法和计划的过程。
        • 本过程的主要作用是，为及时向相关方提供相关信息，引导相关方有效参与项目，而编制书面沟通计划。
        • 本过程应根据需要在整个项目期间定期开展。
      • 管理沟通
        • 管理沟通是确保项目信息及时且恰当地收集、 生成、发布、存储、检索、管理、监督和最终处置 的过程。
        • 本过程的主要作用是，促成项目团队与相关方之间的有效信息流动。
        • 本过程需要在整个项目期间开展
      • 监督沟通
        • 监督沟通是确保满足项目及其相关方的信息需 求的过程。
        • 本过程的主要作用是，按沟通管理计划和相关方参与计划的要求优化信息传递流程。
        • 本过程需要在整个项目期间开展。
  • 考点
    • 沟通活动的分类
      • 沟通是指有意或无意的信息交换。
        • 交换的信息可以是想法、指示或情绪。
      • 成功的沟通包括两个部分。
        • 第一部分是根据项目及其相关方 的需求而制定适当的沟通策略。
        • 第二部分从策略出发，制定沟通 管理计划，来确保用各种形式和手段 把恰当的信息传递给相关方。
    • 什么是有效的沟通
      • 让正确的信息在正确的时间通过正确的方式传递给正确的人，达到正确的效果。
        • 沟通目的明确；
        • 尽量了解沟通接收⽅，满⾜其需求及偏好；
        • 监督并衡量沟通的效果。
    • 沟通需求分析
      • 分析沟通需求，确定项目相关方的信息需求，包括所需信息的类型和格式，以及信息对相关⽅的价值。
      • 常用于识别和确定项目沟通需求的信息包括（但不限于）：
        • 相关方登记册及相关方参与计划中的相关信息和沟通需求；
        • 潜在沟通渠道或途径数量，包括一对一、一对多和多对多沟通；
        • 组织结构图；
        • 项目组织与相关方的职责、关系及相互依赖；开发方法；
        • 项目所涉及的学科、部⻔和专业；有多少人在什么地点参与项目；
        • 内部信息需要（如何时在组织内部沟通）；
        • 外部信息需要（如何时与媒体、公众或承包商沟通）；
        • 法律要求。
    • 沟通渠道数量
      • 通过沟通需求分析，确定项目相关方的信息需求，包括信息的类型和格式，以及 信息对相关方的价值。
      • 项目经理还应该使用潜在沟通渠道或路径的数量，来反映项目沟通的复杂程度。 潜在沟通渠道的总量为n(n-1)/2，其中，n代表相关⽅的数量。
      • 在规划项目沟通时，需要做的一件重要工作就是，确定和限制谁应该与谁沟通， 以及谁将接受何种信息。
    • 影响沟通技术的因素
      • 信息交换和协作的常见⽅法包括对话、会议、书⾯⽂件、数据库、社交媒体和网站。
    • 沟通模型
      • • 确认已收到：指接收⽅表示已经收到信息，但并不一定同意或理解信息的内容
        • 反馈/响应：即接收⽅在对信息进⾏解码和理解的基础上，向发送⽅做出回复
    • 沟通方式的选择
    • 沟通管理计划
      • 沟通管理计划描述将如何规划，结构化、执⾏与监督项目沟通，以提高沟通的有效性。
        • 5W（who、when、what、how、where）
        • 相关方沟通需求
        • 需要沟通的信息（语言、形式、内容和详细程度）、用于传递信息的方法或技术
        • 上报步骤
        • 发布信息的原因
        • 发布信息作出回应的时限和频率
        • 负责沟通信息及接收信息的人员
        • 为沟通活动分配的资源，包括时间和预算
        • 更新与优化沟通管理计划的⽅法
        • 项目信息流向图、工作流程（可能包含审批程序）、报告清单和会议计划
        • 通用术语表
        • 其他细节
    • 工具
      • 项目报告发布
        • 项目报告发布是收集和发布项目信息的⾏为。项目信息应发布给众多相关⽅群体。应 针对每种相关方来调整项目信息发布的适当层次、形式和细节。从简单的沟通到详尽的定制报告和演示，报告的形式各不相同。可以定期准备信息或基于例外情况准备。虽然工作绩效报告是监控项目工作过程的输出，但是本过程会编制临时报告、项目演示、博客，以及其他类型的信息。
    • 监督沟通的概念
      • 监督沟通过程可能引发重新开展规划沟通管理和/或管理沟通过程。对某些特定信息的沟通，如问题或关键绩效指标（如实际进度、成本和质量绩效与计划要求的比较结果），可能立即引发修正措施。
      • 应该仔细评估和控制项目沟通的影响和对影响的反应，以确保在正确的时间把正确的信息传递给正确的受众
• 第十一章 项目风险管理
  • 风险管理的内涵
  • 风险管理的ITTO
    • • 规划风险管理 定义实施风险管理活动
        • 定义如何实施项目风险管理活动的过程。
        • 本过程的主要作用是，确保风险管理的水平、⽅法 和可见度与项目风险程度，以及项目对组织和其 他相关方的重要程度相匹配
      • 识别风险 识别风险的来源
        • 识别风险是识别单个项目风险以及整体项目 风险的来源，并记录风险特征的过程。
        • 本过程的主要作用是，记录现有的单个项目风险，以及整体项目风险的来源；同时，汇集相关信息，以便项目团队能够恰当应对已识别的风险。
        • 本过程需要在整个项目期间开展。
      • 实施定性风险分析 评估单个风险影响，对风险进⾏优先排序
        • 实施定性风险分析是通过评估单个项目风险 发生的概率和影响以及其他特征，对风险进⾏优 先级排序，从⽽为后续分析或⾏动提供基础的过 程。
        • 本过程的主要作用是重点关注高优先级的风 险。
        • 本过程需要在整个项目期间开展。
      • 实施定量风险分析 对整体目标的影响，进⾏定量分析
        • 实施定量风险分析是就已识别的单个项目风险和 不确定性的其他来源对整体项目目标的影响进⾏定量 分析的过程。
        • 本过程的主要作用是，量化整体项目风险敞口，并提供额外的定量风险信息，以⽀持风险应对规划。
        • 本过程并非每个项目必需，但如果采用，它 会在整个项目期间持续开展
      • 规划风险应对 应对单个风险，制定应对策略
        • 规划风险应对是为处理整体项目风险敞⼝，以 及应对单个项目风险，⽽制定可选⽅案、选择应对 策略并商定应对⾏动的过程。
        • 本过程的主要作用是， 制定应对整体项目风险和单个项目风险的适当⽅法； 本过程还将分配资源，并根据需要将相关活动添加 进项目⽂件和项目管理计划。
        • 本过程需要在整个项 目期间开展。
      • 实施风险应对 执⾏商定的风险应对计划
        • 实施风险应对是执⾏商定的风险应对计划的过程。
        • 本过程的主要作用是，确保按计划执⾏商定的风险应 对措施，来管理整体项目风险敞⼝、最小化单个项目 威胁，以及最大化单个项目机会。
        • 本过程需要在整个项目期间开展
      • 监督风险 跟踪识别风险，识别新风险
        • 监督风险是在整个项目期间，监督商定的风险 应对计划的实施、跟踪已识别风险、识别和分析新 风险，以及评估风险管理有效性的过程。
        • 本过程的主要作用是，使项目决策都基于关于整体项目风险 敞⼝和单个项目风险的当前信息。
        • 本过程需要在整个项目期间开展。
  • 考点
    • 风险的基本概念
      • 风险定义：风险是一种不确定的事件或条件。一旦发生，会对至少一个项目目标造成影响。
      • 风险三要素：事件、概率、影响。
      • 项目风险管理旨在识别和管理未被其他项目管理过程所管理的风险。
    • 风险的处理流程
      • 风险管理的目标
        • 项目风险管理的目标在于提高正⾯风险的概 率和（或）影响，降低负⾯风险的概率和（或） 影响，从而提高项目成功的可能性。
    • 输出
      • 风险管理计划
        • 风险管理计划是项目管理计划的组成部分，描述如何安排与实施风险管理活动。
        • 风险管理计划可包括以下部分或全部内容：
          • 风险管理战略
          • 方法论
          • 角色与职责
          • 资金
          • 时间安排（时间和频率）
          • 风险类别
            • 确定对单个项目风险进⾏分类的⽅式。
              • 通常借助风险分解结构 (RBS)来构建风险类别。
            • 风险分解结构有助于项目 团队考虑单个项目风险的全部 可能来源，对识别风险或归类 已识别风险特别有用。
            • 组织可能有适用于所有项 目的通用风险分解结构，也可 能针对不同类型项目使用⼏种 不同的风险分解结构框架。
          • 相关方风险偏好
            • 风险追逐型 偏好冒险的选择，他们的风险应对策略首选项是接受
            • 风险中立型 在相同的预期回报条件下，对于确定结果和不确定结果⽆任何偏好
            • 风险厌恶型 对待风险持保守态度，对他们⽽⾔，风险应对的首选策略是回避
          • 风险概率和影响定义
          • 概率和影响矩阵
          • 修订的相关方承受力
          • 报告格式
          • 跟踪
    • 识别风险的工具技术
      • 工具技术
        • 数据收集技术
        • 数据分析技术
          • 根本原因分析
          • 假设条件和制约因素分析
            • 开展假设条件和制约因素分析，来探索假设条件和制约因 素的有效性，确定其中哪些会引发项目风险。从假设条件的不 准确、不稳定、不一致或不完整，可以识别出威胁，通过清除 或放松会影响项目或过程执⾏的制约因素，可以创造出机会。
          • SWOT分析
            • 对项目的优势、劣势、机会和威胁 (SWOT) 进⾏逐个检查，拓宽识别风险的范围。
        • 提示清单
          • 提示清单是关于可能引发单个项目风险以及可作为整体项目风险来源的风险类别的预设清单。在采用风险识别技术时，提示清单可作为框架用于协助项目团队形成想法。
          • 可以用风险分解结构底层的风险类别作为提示清单，来识别单个项目风险。
            • 某些常见的战略框架更适用于识别整体项目风险的来源，如：
              • PESTLE（政治、经济、社会、技术、法律、环境）、
              • TECOP（技术、环境、商业、运营、政治），
              • VUCA（易变性、不确定性、复杂性、模糊性）。
            • 风险分解结构（RBS）
      • 输出
        • 风险登记册
          • 风险登记册记录已识别单个项目风险的详细信息。随着实施定性风险分析、规划风险应对、实施风险应对和监督风险等过程的开展，这些过程的结果也要记进风险登记册。
            • 已识别风险的清单
            • 潜在风险责任人
            • 潜在风险应对清单（在规划风险应对中完善）
        • 风险报告
          • 风险报告提供关于整体项目风险的信息，以及关于已识别的单个项目风险的概述 信息。在项目风险管理过程中，风险报告的编制是一项渐进式的工作。
            • 整体项目风险的来源
            • 关于已识别单个项目风险的概述信息
    • 定性风险分析的工具技术
      • 数据分析
        • 风险数据质量评估
          • 风险数据是开展定性风险分析的基础。风险数据质量评估旨在评价关于单个项目风险的数据的准确性和可靠性。
          • 概率和影响矩阵是把每个风险发生的概率和一旦发生对项目目标的影响映射起来的表格。基于风险的概率和影响，对风险进⾏优先级排序，以便未来进一步分析并制定应对措施。
        • 其他风险参数评估
          • 其他风险特征包括：紧迫性、 临近性、潜伏期、可管理性、可控 性、可监测性、连通性、战略影响 ⼒、密切度等。
          • 如果使用了两个以上的参数对 风险进⾏分类，那就不能使用概率 和影响矩阵，而需要使用其他图形。 如气泡图能展示三位数据。
    • 实施定量风险分析工具技术
      • 模拟
        • 在定量风险分析中，使用模型来模拟单个项目风险和其他不确定性来源的综合影响，以评估它们对项目目标的潜在影响。模拟通常采用蒙特卡洛分析。
      • 敏感性分析
        • 敏感性分析有助于确定哪些单个项目风险或其他项目结果具有最大的潜在影响。敏感性分析的结果通常用龙卷风图来表示
      • 决策树分析
        • 用决策树在若干备选⾏动⽅案中选择一个最佳⽅案。在决策树中，用不同的分⽀代表不同的决策或事件，即项目的备选路径。通过计算每条分⽀的预期货币价值，就可以选出最优的路径。
    • 规划风险应对
      • 工具
        • 威胁应对策略
        • 应急应对策略
    • 监督风险
      • 监督风险的内容
        • 为了确保项目团队和关键相关⽅了解当前的风险敞⼝级别，应该通过监督风险过程对项目工作进⾏持续监督，来发现新出现、正变化和已过时的单个项目风险，监督风险过程采用项目执⾏期间生成的绩效信息，以确定
          • 实施的风险应对是否有效
          • 整体项目风险级别是否已改变
          • 已识别单个项目风险的状态是否已改变
          • 是否出现新的单个项目风险
          • 风险管理⽅法是否依然适用
          • 项目假设条件是否仍然成立
          • 风险管理政策和程序是否已得到遵守
          • 成本或进度应急储备是否需要修改
          • 项目策略是否仍然有效
      • 监督风险工具技术
        • 储备分析
          • 储备分析是指在项目的任一时点比较剩余应急储备与剩余风险量，从⽽确定剩余储备是否仍然合理。
        • 审计
          • 风险审计是一种审计类型，可用于评估风险管理过程的有效性。
          • 项目经理负责确保按项目风险管理计划所规定的频率开展风险审计。风险审计可以在⽇常项目审查会上开展，可以在风险审查会上开展，团队也可以召开专⻔的风险审计会。
• 第十二章 项目采购管理
  • 采购管理的内涵
    • 规划采购管理
      • 规划采购管理——记录项目采购决策、明确采购方法，及识别潜在卖方的过程
    • 实施采购
      • 实施采购——获取卖方应答、选择卖方并授予合同的过程
    • 控制采购
      • 控制采购——管理采购关系、监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程。
  • 考点
    • 规划采购管理
      • 确定自制或是外包
        • ⾃制或外购分析用于确定某项工作或可交付成果最好由项目团队⾃⾏完成，还是应该从外部采购。
        • 制定自制或外购决策时应考虑的因素包括：
          • 组织当前的资源配置及其技能和能⼒；
          • 对专业技术的需求；
          • 不愿承担永久雇用的义务；
          • 以及对独特技术专⻓的需求；
          • 还要评估与每个⾃制或外购决策相关的风险。
      • 确定采购管理计划
        • 采购管理计划包含要在采购过程中开展的各种活动。
        • 采购管理计划可包括以下内容：
          • 如何协调采购与项目的其他工作，例如，项目进度计划制定和控制；
          • 开展重要采购活动的时间表；
          • 用于管理合同的采购测量指标；
          • 与采购有关的相关⽅⻆⾊和职责；如果执⾏组织有采购部，项目团队拥有的职权和受到的限制；
          • 可能影响采购工作的制约因素和假设条件；
          • 司法管辖权和付款货币；
          • 是否需要编制独立估算，以及是否应将其作为评价标准；
          • 风险管理事项，包括对履约保函或保险合同的要求，以减轻某些项目风险；
          • 拟使用的预审合格的卖方（如果有）。
      • 采购策略
        • 交付方法
          • 一、专业服务项目的交付方法包括：
            • 买方或服务提供方不得分包、
            • 买方或服务提供方可以分包、
            • 买方和服务提供方设立合资企业、
            • 买方或服务提供方仅充当代表。
          • 二、施工项目的交付方法包括：
            • 交钥匙式、
            • 设计-建造 （DB）、
            • 设计-招标-建造 （DBB）、
            • 设计-建造-运营 （DBO）、
            • 建造-拥有-运营-转让 （BOOT）及其他。
        • 合同支付类型
      • 采购工作说明书（SOW）和工作大纲（TOR）
        • 依据项目范围基准，为每次采购编制工作说明书（SOW），仅对将要包含在相关合同中的那一部分项目范围进⾏定义。工作说明书会充分详细地描述拟采购的产品、服务或成果，以便潜在卖⽅确定是否有能⼒提供此类产品、服务或成果
        • 采购工作说明书应⼒求清晰、完整和简练。工作说明书的内容包括：规格、所需数量、质量水平、绩效数据、履约期间、工作地点和其他要求。
        • 对于服务采购，可能会用“工作大纲 （TOR）”这个术语。与采购工作说明书类似，工作大纲通常包括以下内容：
          • 承包商需要执⾏的任务，以及所需的协调工作；
          • 承包商必须达到的适用标准；
          • 需要提交批准的数据；
          • 由买方提供给承包商的，将用于合同履⾏的全部数据和服务的详细清单（若适用）；
          • 关于初始成果提交和审查（或审批）的进度计划。
      • 确定供方选择标准
        • 在确定评估标准时，买⽅要努⼒确保选出的建议书将提供最佳质量的所需服务。
        • 供⽅选择标准可包括（但不限于）：
          • 能⼒和潜能
          • 关键员工的资质、可用性和胜任⼒
          • 产品成本和生命周期成本
          • 公司的财务稳定性
          • 交付日期
          • 管理经验
          • 技术专⻓和⽅法
          • 知识转移计划，包括培训计划
          • 具体的相关经验
          • 用于响应工作说明书的工作方法和工作计划
      • 独立成本估算
        • 对于大型的采购，采购组织可以⾃⾏准备独立估算，或聘用外部专业估算师做出成本估算，并将其作为评价卖方报价的对照基准。如果二者之间存在明显差异，则可能表明采购工作说明书存在缺陷或模糊，或者潜在卖方误解了或未能完全响应采购工作说明书。
    • 实施采购
      • 发布招标广告（招标文件）
      • 举⾏投标人会议
        • 投标人会议（又称承包商会议、供应商会议或投标前会议）是在卖方提交建议书之前，在买方和潜在卖方之间召开的会议，其目的是确保所有潜在投标人对采购要求都有清楚且一致的理解，并确保没有任何投标人会得到特别优待。
      • 买方评估建议书（供方选择分析）
        • 最低成本
        • 仅凭资质
        • 基于质量或技术⽅案得分
        • 基于质量和成本
        • 独有来源
        • 固定预算
      • 结束谈判，签订合同
        • 合同是对双⽅都有约束⼒的协议。它强制卖方提供规定的产品、服务或成果，强制买方向卖⽅⽀付相应的报酬。合同建立了受法律保护的买卖双⽅的关系。
        • 协议⽂本的主要内容会有所不同，可包括（但不限于）：
          • 采购工作说明书或主要的可交付成果；
          • 保险和履约保函
          • 进度计划、⾥程碑，或进度计划中规定的⽇期
          • 下属分包商批准
          • 绩效报告
          • 一般条款和条件
          • 检查、质量和验收标准
          • 变更请求处理
          • 定价和支付条款
          • 终止条款和替代争议解决方法
          • 担保和后续产品支持
          • 激励和惩罚
    • 控制采购
      • 绩效审查、检查与审计
        • 绩效审查
          • 对质量、资源、进度和成本绩效进⾏测量、比较和分析，以审查合同工作的绩效。其中包括确定工作包提前或落后于进度计划、超出或低于预算，以及是否存在资源或质量问题。
        • 检查
          • 检查是指对承包商正在执⾏的工作进⾏结构化审查，可能涉及对可交付成果的简单审查，或对工作本身的实地审查。
        • 审计
          • 审计是对采购过程的结构化审查。应该在采购合同中明确规定与审计有关的权利和义务。买⽅的项目经理和卖⽅的项目经理都应该关注审计结果，以便对项目进⾏必要调整。
      • 合同-索赔管理
        • 如果买卖双⽅不能就变更补偿达成一致意见，或对变更是否发生存在分歧，那么被请求的变更就成为有争议的变更或潜在的推定变更。此类有争议的变更称为索赔。
          • 如果不能妥善解决，它们会成为争议并最终引发申诉。
        • 在整个合同生命周期中，通常会按照合同条款对索赔进⾏记录、处理、监督和管理。
        • 如果合同双⽅⽆法⾃⾏解决索赔问题，则可能不得不按合同中规定的程序，用替代争议解决方法（ADR）去处理。谈判是解决所有索赔和争议的首选方法。其次才选仲裁，诉讼。
          • 合同如果约定了不可抗⼒导致的损失不予索赔，这是除外责任。
• 第十三章 项目相关⽅管理
  • 相关方的概念
    • 识别相关方
      • 识别、分析、记录
        • 识别相关方是定期识别项目相关方，分析 和记录他们的利益、参与度、相互依赖性、影 响⼒和对项目成功的潜在影响的过程。
        • 本过程的主要作用是，使项目团队能够建立对每个相 关方或相关方群体的适度关注。
        • 本过程应根据需要在整个项目期间定期开展。
          • 本过程通常在编制和批准项目章程之前或 同时首次开展。并在过程中重复开展。
    • 规划相关方
      • 制定相关方参与项目的方法
        • 规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响，制定项目相关方参与项目的方法的过程。
        • 本过程的主要作用是，提供与相关⽅进⾏有效互动的可⾏计划。
        • 本过程应根据需要在整个项目期间定期开展。
          • 应该在项目生命周期的早期制定一份有效的计划；然后，随着相关方社区的变化，定期审查和更新该计划。会触发该计划更新的典型情况包括（但不限于）：
            • 项目新阶段开始；
            • 组织结构或⾏业内部发生变化；
            • 新的个人或群体成为相关⽅，现有相关⽅不再是相关⽅社区的成员，或特定相关⽅对项目成功的重要性发生变化；
            • 当其他项目过程（如变更管理、风险管理或问题管理）的输出导致需要重新审查相关⽅参与策略。
    • 管理相关⽅参与
      • 按计划促进相关⽅合理参与
        • 管理相关⽅参与是与相关⽅进⾏沟通和协作以满⾜其需求与期望、处理问题，并促进相关⽅合理参与的过程。
        • 本过程的主要作用是，让项目经理能够提高相关方的支持，并尽可能 降低相关方的抵制。
        • 本过程需要在整个项目期间开展。
    • 监督相关方参与
      • 修订参与策略与计划来引导相关⽅合理参与
        • 监督相关方参与是监督项目相关方关系，并通过修订参与策略和计划来引导相关⽅合理参与项目的过程。
        • 本过程的主要作用是，随着项目进展和环境变化，维持或提升相关方参与活动的效率和效果。
        • 本过程需要在整个项目期间开展。
  • 考点
    • 相关方的概念
      • 项目的相关方有哪些人？
      • 相关方核心概念
        • ①相关方与项目关系
          • 相关方会受项目的积极或消极影响， 或者能对项目施加积极或消极的影响。
        • ②识别相关方重要性
          • 为提高成功的可能性，应：
            • 尽早开始识别相关方
            • 进⾏相关⽅优先级排序
            • 引导相关方参与
    • 识别相关方
      • 数据收集
        • 问卷和调查
          • 问卷和调查可以包括一对一调查、焦点小组讨论，或其他大规模信息收集技术。
        • 头脑风暴
          • 用于识别相关⽅的头脑风暴技术包括头脑风暴和头脑写作。
            • 头脑风暴
              • 一种通用的数据收集和创意技术，用于向小组征求意见，如团队成员或主题专家。
            • 头脑写作
              • 头脑风暴的改良形式，让个人参与者有时间在小组创意讨论开始前单独思考问题。信息可通过面对面小组会议收集，或在由技术支持的虚拟环境中收集。
      • 相关方分析
        • 数据表现
          • 权⼒利益⽅格、权⼒影响⽅格、影响作用方格
            • • 权⼒利益⽅格
            • 适用
              • ①小型项目
              • ②相关方与项目的关系很简单的项目
              • ③相关方之间的关系很简单的项目
          • 凸显模型
          • 影响方向
      • 输出
        • 相关方登记册
          • 相关方登记册示例
    • 规划相关方参与
      • 工具与技术
        • 相关方参与评估矩阵
        • 相关方参与计划
          • 相关⽅参与计划是项目管理计划的组成部分。它确定用于促进相关⽅有效参与决策和 执⾏的策略和⾏动。基于项目的需要和相关⽅的期望，相关⽅参与计划可以是正式或⾮正式的，非常详细或高度概括的。
            • 相关⽅参与计划可包括（但不限于）调动个人或相关⽅参与的特定策略或⽅法。
    • 管理相关⽅参与
      • 沟通技能
        • 在开展管理相关⽅参与过程时，应该根据沟通管理计划，针对每个相关⽅采取相应的沟通⽅法。
        • 项目管理团队应该使用反馈机制，来了解相关⽅对各种项目管理活动和关键决策的 反应。反馈的收集⽅式包括（但不限于）：
          • 正式与非正式对话；
          • 问题识别和讨论；
          • 会议；
          • 进展报告；
          • 调查。
      • 人际关系团队技能
        • 适用于本过程的人际关系与团队技能包括（但不限于）：
          • 冲突管理。项目经理应确保及时解决冲突。
          • 文化意识。⽂化意识有助于项目经理和团队通过考虑⽂化差异和相关⽅需求，来实现有效沟通。
          • 谈判。谈判用于获得支持或达成关于支持项目工作或成果的协议，并解决团队内部或团队与其他相关方之间的冲突。
          • 观察和交谈。通过观察和交谈，及时了解项目团队成员和其他相关方的工作和态度。
          • 政治意识。通过了解项目内外的权⼒关系，建立政治意识。
      • 会议
        • 会议用于讨论和处理任何与相关⽅参与有关的问题或关注点。在本过程中需要召开的会议类型包括（但不限于）：
          • 决策；
          • 问题解决；
          • 经验教训和回顾总结；
          • 项目开工；
          • 迭代规划；
          • 状态更新。
    • 易混淆⽂件区分
      • 相关方参与计划VS相关方登记册VS沟通管理计划
• 第十四章 敏捷项目管理
  • 敏捷项目管理
  • 考点
    • 敏捷项目管理
      • 敏捷相关知识
      • 对比
        • 与客⼾的互动程度
        • 确定型和不确定型工作
          • 可确定的工作
            • 具有明确的流程，在以往类似的项目中被证明是⾏之有效的，不确定性和风险通常较低。
            • 传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。
          • 高度不确定的工作
            • 新的设计、解决的问题和之前未做过的工作都是探索性的。它要求主题专家携手合作，解决问题，并创建解决⽅案。高度不确定的项目变化速度快，复杂性和风险也高。
            • 敏捷方法的出现是为了在短时间内探讨可⾏性，根据评估和反馈快速调整。
      • Stacy斯泰西图
      • 生命周期的连续区间
        • 预测型生命周期
          • 高确定性的明确的需求、稳定的团队和低风险；
          • 项目活动以顺序方式执⾏，需要详细的计划。尽可能减少预测型项目的变更。监控可能影响范围、进度计划或预算的变更；
          • 预测型项目强调根据部⻔划分的、有效的、顺序的工作，通常不会在项目结束前交付商业价值；
          • 如果遇到变更或需求分歧，或者技术解决⽅案变得不再简单明了，预测型项目就将产生意想不到的成本。
        • 迭代型生命周期
          • 通过连续的原型或概念验证来改进产品或成果。每一个新的原型都能带来新的相关方反馈和团队见解；
          • 团队在下一周期重复一个或多个项目活动，纳入新的信息。特定迭代中使用时间盒；
          • 迭代有利于识别和减少项目的不确定性。迭代型生命周期可能需要更⻓的时间，因为它是为学习⽽优化，⽽不是为了交付速度。
        • 增量型生命周期
          • 为了加快交付速度。客⼾愿意接受整个解决⽅案的一部分。
          • 为客⼾提供一个单一功能或是交付一项完成的工作：先展示一间已完工的房间或一层楼；
          • 团队需要获得关于原型的反馈，然后可能选择将最小可⾏产品 (MVP) 交付给部分客⼾；
          • 敏捷团队的重要优势：经常交付商业价值。产品的功能得到增加，就能吸引更多的消费者。
        • 敏捷型生命周期
          • 敏捷环境中，团队期望需求会发生变更；
          • 基于迭代的敏捷：时间⻓度相等的时间盒，交付最重要的功能；
          • 基于流程的敏捷：根据功能⽽不是迭代进度进⾏开发。定义任务板的工作 流，并管理各列进⾏中的工作。
        • 四种生命周期对比
          • 每种生命周期都有计划要素； 不同之处在于完成多少计划以及何时完成
      • 敏捷思维
        • 敏捷思维模式由价值观定义，以原则为指导，并在许多不同的实践中体现。
        • 敏捷实践者根据⾃⾝需求选择不同的实践。
      • 敏捷宣言
        • 我们正在通过亲⾃开发和帮助他人开发，发现开发软件的更好⽅法。通过这项工作，我们开始更重视：
          • 个体以及互动
            • ⽽不是 流程和工具
              • 流程和工具在项目中是重要的，但是他们是“死”的
              • 参与项目的人是“活”的
              • 个体和互动是项目获得成功的最为重要的因素
          • 可用的软件
            • ⽽不是 完整的文档
              • 过多的⾯⾯俱到的⽂档，有时候比过少的⽂档更糟
              • ⽂档应尽量短小并且主题突出
          • 客⼾合作
            • ⽽不是 合同谈判
              • 客⼾很难做到一次性将需求完整清晰的表述在合同中
              • 有利于引导协同工作的合同才是好合同
          • 应对变更
            • ⽽不是 遵循计划
              • 初始计划总是不⾜的
              • 可以更多精⼒处理项目组不可避免的“变化”
              • 短期迭代的机会比中⻓期计划更有效
        • 十二原则
          • （1）我们的最高目标是，通过尽早持续地交付有价值的软件来满⾜客⼾的需求。
            • 关注：客⼾满意
            • 要点：
              • 尽早交付
              • 持续交付
              • 有价值
              • 客⼾满意
              • 合规、与群体决策
          • （2）即使在项目开发的后期，仍欢迎对需求提出变更。敏捷过程通过拥抱变化，帮助客⼾创造竞争优势。
            • 关注：拥抱变化
            • 要点：
              • 传统项目管理影响和控制会导致变化的因素
              • 敏捷预期到需求会变化
              • 拥抱变化，即使这些变化发生在项目后期
              • 通过原则、模式、实践来保证软件足够灵活
              • 迅速应对和适应变化能给客⼾带来显著的竞争优势，从⽽应对新的机遇
          • （3）要不断交付可用的软件，周期从⼏周到⼏个月不等，且越短越好。
            • 关注：频繁交付
            • 要点：
              • 经常交付可用的软件，时间间隔越短越好
              • Scrum的迭代周期大概为一个月
              • XP的迭代周期则会短至一周
              • 较短的迭代周期强化团队持续关注客⼾的价值
          • （4）在项目过程中，业务人员与开发人员要每天在一起工作。
            • 关注：一起工作
            • 要点：
              • 传统项目中负责商业价值的人员和软件开发人员是严格分开工作的
              • 让每⽀团队都可以集中精⼒做他们擅⻓的事情
              • 敏捷项目管理提倡他们同一个地方一起工作
              • 团队成员和用⼾能相互理解彼此的想法
              • 他们的共同目标就是通过可用的软件向客⼾传递价值
          • （5）要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。
            • 关注：提供环境和支持
            • 要点：
              • 激励人，人比拥有最好的流程和工具更重要
              • 建立强有⼒的团队并积极避免微观管理
              • ⾃律的团队⽽不是一个⾃上⽽下的指令
              • 分享空间：可视性和共同性
              • 给团队自由时间
          • （6）团队内部和各个团队之间，最有效的沟通方法是面对面的沟通。
            • 关注：面对面沟通
            • 要点：
              • ⾮正式的⼝头沟通在敏捷项目管理中远比正式的书⾯沟通更普遍
              • 敏捷项目中的沟通都是公开的，任何团队成员都可以自由参与对话
              • 最高效的沟通是面对面交谈
              • 渗透式沟通
              • 高带宽沟通
          • （7）可工作软件是衡量进度的首要指标。
            • 关注：衡量指标
            • 要点：
              • 传统项目往往极其纠结的是，项目的不断更新使得⽂件成为一种负担
              • 真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的
              • 可工作的软件是首要度量标准
              • 关注需求完成度
              • 关注软件的可用程度
          • （8）敏捷过程提倡可持续的开发。项目⽅、开发人员和用⼾应该能够保持恒久、稳定的进展速度。
            • 关注：可持续步调
            • 要点：
              • 敏捷项目比传统项目有更高的工作强度（尤其是使用XP这样的方法时）
              • 保持一个稳定的可持续的进展速度，从⽽使得团队成员不会在迭代周期的尾端匆忙赶工
              • 不允许过度的压⼒和过度疲劳
              • 不会借用明天的精⼒来在今天完成多一点工作
          • （9）对技术卓越和好的设计的持续关注有助于增强敏捷性。
            • 关注：技术卓越
            • 要点：
              • 设计越完善，维护越简单
              • 保持软件干净、整洁
              • 编写高质量代码
              • 重构
              • 稳定和优质的项目比劣质的项目更加允许团队快速应对变化
          • （10）尽量做到简洁，尽最大可能减少不必要的工作。这是一⻔艺术。
            • 关注：简洁
            • 要点：
              • 这个准则被所有的敏捷方法所拥护，尤其是精益方法
              • 关键点是对客⼾价值保持专注和毫不犹豫地削减不增加价值的活动
              • 保持简单是最基本的原则
              • 不构建华⽽不实的系统
          • （11）最佳的架构、需求和设计出自自组织团队。
            • 关注：自组织团队
            • 要点：
              • 自我组织是敏捷团队的核心元素之一
              • 任务是分配给整个团队的，⽽不是某个人
              • 自组织团队，即该团队自己去决定工作如何分配及谁去做某个特定的工作
              • 传统项目和敏捷项目最显著的区别
              • 不仅小团队是⾃我组织的，较大的跨职能团队也可以是⾃我组织的
              • 不存在某个人对架构、需求、测试负责的情况，整个团队共同承担这些责任
          • （12）团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的⾏为。
            • 关注：定期反思
            • 要点：
              • 传统项目⾥当项目或阶段完成时开会总结是最常见的做法
              • 敏捷项目以更频繁的回顾来完成这项工作
              • Retrospective Meeting
              • 在一个回顾活动中，查看上个迭代周期中已完成的工作或发布，并评估下一次如何改进他们的做法
              • 每⽇站立会议是另一项协调团队努⼒⽅向、团队⾃我评定和⾃我调整的重要⽅式
        • 敏捷是许多方法的总称
      • Scrum框架中的33355
        • • 三个支柱
            • 透明性（Transparency）
              • 过程中的关键环节对相关人是显⽽易见的，同时保证干系人对这些关键环节理解是统一的。
              • 管理生产成果的人不仅要能够看到过程的这些⽅⾯，⽽且必须理解他们看到的内容。
            • 检验（Inspection）
              • Scrum使用者必须经常检视Scrum的工件和完成Sprint目标的进展，检视频率应适宜。确保能够及时发现过程中的重大偏差。
            • 适应（Adaptation）
              • 如果检视发现一个或多个⽅⾯偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执⾏，如此才能减少进一步的偏离。
          • 三个⻆⾊
            • 产品负责人（Product Owner）
              • 主要负责确定产品的功能和达到要求的标准，维护产品待办事项列表，指定软件交付的内容，同时有权⼒接受或拒绝开发团队的工作成果。
            • 敏捷教练（Scrum Master）
              • 主要负责整个Scrum流程在项目中的顺利实施和进⾏，以及清除挡在客⼾和开发工作之间的沟通障碍，使得客⼾可以直接驱动开发。主要有服务团队、教导团队、保护团队、引导Scrum的有效应用职能。
            • 项目团队（Scrum Team）
              • 主要负责软件产品在Scrum规定流程下进⾏开发工作，人数控制在3~9人（PO，SM不包含在人数中，除⾮参加执⾏冲刺列表中的工作），团队获得授权，⾃组织和管理他们的工作。每个成员可能负责不同的技术⽅⾯，但要求每个成员必须要有很强的⾃我管理能⼒，责任属于整个开发团队。为团队提供了一种一起成功，一起失败，一起调整，一起改进的途径。
          • 三个工件
            • 用⼾故事（user story）
            • 产品待办事项列表（Product Backlog）
              • 产品待办事项列表是所有工作的有序列表，它以故事形式呈现给团队，价值越大的排在上面。
              • 产品负责人Product Owner制作一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规划路线图。
              • 产品负责人在迭代中的会议中与团队合作，为即将进⾏的迭代准备故事，细化⾜够的故事。
              • 向团队介绍故事创意、潜在的挑战或问题。 如不确定依赖关系，请求团队对相应功能进⾏刺探，以了解风险。
              • 团队每周用不超过 1 小时的时间来为下一批工作细化故事。团队希望把时间尽可能花在工作上，⽽不是计划上。
            • 冲刺待办事项列表（Sprint Backlog）
              • 定义了Sprint的目标，明确了Sprint过程中具体需要完成的任务
              • 尽量放在⽅便团队看到的地⽅
              • 任务不是分配下去的，⽽是团队讨论与个人挑选的结果（⾃管理）
              • 对每一个任务，每天更新剩余任务工作量的估算
              • Sprint 规划会议产出起始Sprint Backlog
              • 是团队的资产，团队可以增加、删除或者修改任务
              • 如果团队同意，对于一些事项，可以先做大的整体估算，在Sprint进⾏当中再分解成任务
        • • 冲刺（Sprint）
          • 冲刺计划会议（Sprint Planning）
            • 为即将要开展的Sprint制定计划
            • Sprint第一天，控制在8小时以内
            • 定义本Sprint要交付的内容如何完成
            • 会议基本内容：
              • 1.一般由PO来讲Product Backlog，团队来进⾏评估，得出Sprint Backlog
              • 2.拆分task以估算时间
              • 3.团队成员领取task
              • 4.更新Sprint待办列表
          • 每日站会（Daily Scrum）
            • 不超出15分钟；
            • 团队以某种方式“过一下”看板或任务板，而团队中的任何人都可以主持站会；
            • 每个人轮流回答问题
              • 上次站会以来我都完成了什么?
              • 从现在到下一次站会，我计划完成什么?
              • 我的障碍（或风险或问题）是什么?
            • 两种反模式：变成状态报告；站会是为了发现问题，而不是解决。
          • 迭代评审会议（Sprint Review）
            • 发生在Sprint结束时，控制在4小时以内
            • 参会者包括Scrum团队和产品负责人邀请的主要利益相关者
            • 主要会议内容：
              • 1.产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
              • 2.开发团队讨论在Sprint期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
              • 3.开发团队演示“完成”的工作并解答关于所交付增量的问题；
              • 4.产品负责人讨论当前的产品待办列表的情况。他∕她根据到目前为止的进度来预测可能的目标交付⽇期（如果有需要的话）；
              • 5.参会的所有人就下一步的工作进⾏探讨，这样，Sprint评审会议就能够为接下了的Sprint计划会议提供有价值的输入信息；
              • 6.评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；同时为下个预期产品功能或产品能⼒版本的发布评审时间表、预算、潜⼒和市场。
          • 迭代回顾会议（Sprint Retrospective）
            • Sprint回顾会议是Scrum团队检视自身并创建下一个Sprint改进计划的机会。
            • 回顾会议发生在Sprint评审会议结束之后，下个Sprint计划会议之前。对于⻓度为一个月的Sprint来说，回顾会议时间最⻓不超过3小时。对于较短的Sprint来说，会议时间通常会缩短。Scrum Master要确保会议举⾏，并且每个参会者都明白会议的目的。
            • Scrum Master确保会议是积极的和富有成效的。Scrum Master教导大家遵守时间盒的规则。Scrum Master 对Scrum过程负责，作为团队的一员参加该会议。
            • Sprint 回顾会议的目的在于：
              • 1.检视前一个Sprint中关于人、关系、过程和工具的情况如何；
              • 2.找出并加以排序做得好的和潜在需要改进的主要方面；同时制定改进Scrum团队工作方式的计划。
      • PMBOK中在敏捷或适应型环境中需要考虑的因素
        • 整合：自组织团队Self-Organising Teams
        • 范围：需求变化，多迭代版本，产品待办列表
        • 进度：燃尽图
        • 成本：根据严格的预算控制范围，产品待办列表
        • 质量：PDCA，频繁的增量交付，评审会议，回顾会议
        • 资源：具有通才的自组织团队，共同承担责任
        • 沟通：集中办公，面对面沟通，信息发射源，定期邀请相关方评审
        • 风险：及时响应，定期排列需求优先级
        • 采购：大型项目，适应型针对某些可交付成果，变更只针对适应型工作
        • 相关⽅：直接与客⼾对接，减少中间的层层管理级别；加快组织内部和组织之间的信息分享，敏捷提倡信息高度透明
      • 燃尽图Burn down Chart
      • 燃起图Burn up Chart
      • 敏捷交付过程
        • Sprint计划会
        • 每日站会
        • Sprint评审会
        • Sprint回顾会
      • 敏捷交付团队
      • 成功敏捷团队的⻆⾊
      • 仆人式领导The Servant-Leader
        • 定义：一种为团队赋权的方法。通过对团队服务来领导团队的实践，注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
        • 作用：促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。
        • 领导⼒的特征
          • 提升自我意识
          • 倾听
          • 为团队服务
          • 促进安全、尊重与信任
          • 引导与控制
          • 帮助他人成⻓
          • 促进他人精⼒和才智提升
        • 职责
        • 工作顺序
      • 敏捷的冲突解决
      • 项目整体状态
        • • 敏捷挣值只能在迭代中使用
          • 在敏捷中的挣值是基于已完成的功能
          • 迭代中计划完成 30 个故事点，但只完成了 25 个，SPI 是 25/30=0.83
          • CPI 是已完成的功能值除以实际的成本，$2.2M / $2.8M = 0.79
      • 任务板与看板
        • 看板方法原则
          • 源于“准时制”Just In Time库存系统：最初用于杂货店，商店会根据货架不⾜情况来补给货架商品。大野耐一开发看板，1953年用于丰田。
          • “看板”为“视觉符号”或“卡”。
          • 工作流的状态：要完成的工作、进⾏中的工作和已完成 工作。
          • 灵活性：不受时间盒限制，执⾏优先级最高的工作。
          • 提高工作效率和质量：限制在制品 (WIP)，团队成员专注当前工作。
          • 专注于持续交付：专注完成整个系统工作流，直至在制品完成才会开始新工作。
          • 提高效率：检查每个任务，清除非增值活动。
          • 减少浪费：透明使浪费可视化，消除浪费。
      • 适应回顾
      • 用⼾故事
        • 用⼾故事的INVEST原则：
          • I：独立的
          • N：可协商的
          • V：有价值的
          • E：可估计的
          • S： 短小的
          • T：可测试的
      • 风险调整后的待办事项列表
      • 制定迭代发布计划
        • 项目团队共同从产品待办事项列表中，挑出高优先级别的待办事项进⾏分解构成 本次迭代待办事项列表。
      • 制定迭代代办事项
      • 敏捷三⻆形
        • 技术实战
      • 敏捷项目章程
        • 我们为什么要做这个项目？这是项目愿景。
        • 谁会从中受益？如何受益？这可能是项目愿景和/或项目目标的一部分。
        • 对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准。
        • 我们将怎样合作？这说明预期的工作流。
        • 项目数据表是用一页纸概括主要商业和质量目标、产品功能和项目管理信息。这样便于干系人实时查阅项目章程主要内容，它与产品路线图构成了敏捷项目章程的主要部分。
      • 敏捷团队章程
      • 增量概念
        • 增量是一个Sprint完成的所有产品待办列表项的总和，以及之前所有Sprint所产生的增量的价值总和。在Sprint的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了Scrum团队“完成”的定义的标准。增量是在Sprint结束时支持经验主义的、可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。
      • 增量划分原则
      • 敏捷计划层次
        • 敏捷计划拥抱变化，⽽不是阻碍变化
        • 推测意味着确定⽅向，并期待更多变化
      • 敏捷的层次滚动计划
        • 敏捷相对估值
          • 故事点是故事相对规模的一个数值指标，注意它不是具体的时间值
      • 适合敏捷合同类型
        • 采购与合同