PMP备考终极导图

内涵PA7E四模块考点汇总大全（参照光环VIP课汇总）、配套高模拟度试题错题汇总、应试详细技巧（人员过程环境高频考点应试公式、考点识别、技巧汇总）。

中心主题

• 项目的基本概念
  • 项目的定义
    • 概念: 是为提供某项独特产品、服务或成果所做的临时性工作
  • 特点
    • 独特性: 独一无二的,没有完全一样的两个项目
    • 临时性: 也称一次性,阶段性的,项目总会有开始和结束
    • 渐进明细性: 项目的细节是随着项目的开展逐渐清晰和细化的
  • 项目与运营的区别
    • 项目特点: 临时的、独特的、渐进明细的(项目决定未来)
    • 运营特点: 重复进行、持续不断、明确的(运营决定现在)
• 项目管理的发展
  • 关注过程→关注成果
  • 聚焦制约→聚焦价值
    • 制约：多快好省/三角
  • 瀑布为主→混合为主
    • 混合：预测+敏捷
      • 混合方法 Hybrid Approach
        • 是指将预测型（传统）项目管理方法与敏捷方法相结合，根据项目具体需求灵活调整管理策略，以平衡计划性与适应性的方法体系。其核心特点如下
        • 方法融合的核心逻辑
          • 预测型方法（如瀑布模型）：适用于需求明确、变更较少的场景，强调前期规划 （如WBS分解、甘特图）、 阶段性交付 和 严格流程控制
          • 敏捷方法（如Scrum）：适用于需求多变、需快速迭代的场景，强调 增量交付 （如冲刺Sprint）、 持续反馈 和 团队自组织
          • 混合方法将两者优势互补。例如：
            • 前期规划阶段：用预测法制定整体项目章程和里程碑；
            • 执行阶段：采用敏捷迭代开发，每两周交付可测试的功能模块；
            • 监控阶段：结合挣值分析（预测法）和燃尽图（敏捷）跟踪进度。
        • PMP考试将混合方法作为重要考点（50%），要求考生：
          • 灵活选择工具：例如在风险高的项目中，用预测法制定风险应对计划，同时用敏捷每日站会快速识别新风险。
          • 适应动态环境：例如在客户频繁变更需求时，混合使用变更控制流程（预测法）和待办事项优先级排序（敏捷）。
          • 平衡效率与可控性：如用预测法管理预算和合同，用敏捷管理需求开发和测试。
  • 关注项目→关注产品
• 项目、项目集与项目组合
  • 第一级:战略——盈利
  • 第二级:项目组合——调整项目优先级,注重开展正确的项目集和项目
    • 做正确的事
  • 第三级:项目集——调整依赖关系,重点在于以正确的方式开展项目集和项目
    • 以正确的方式做事
  • 第四级:项目——为实现具体目标而设计的工作
  • 项目集管理&项目组合管理
    • program & portfolio management
    • 但凡强调了项目间相互影响的就是项目集管理，解决项目集中项目之间冲突是项目集经理的职责
      • PMO Leader在协调和支持项目上负责，对于协调项目集中项目冲突还是Program Leader更吻合
• 项目的关键组成部分
  • 项目生命周期：项目从开始到结束所经历的一系列阶段
    • 如
      • 可行性研究
      • 绘制图纸
      • 施工与验收
  • 项目管理过程组：项目管理输入、工具和技术以及输出的逻辑组合。包括启动、规划、执行监控和收发。
    • 规划执行和监控处于一个Loop
  • 项目阶段：一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束
  • 阶段关口：为做出进入下个阶段、进行整改或做项目集或项目的决定，而开展的阶段末审查
    • 审查一个阶段末的问题，做成本效益分析，以决定下个阶段的项目。
    • 关口在阶段和阶段之间，需要做决策
  • 项目管理过程：旨在创造最终结果的系统化的系列活动,以便对一个或多个输入进行加工,生成一个或多个输出
  • 项目管理知识领域：按照所需知识内容来定义的项目管理领域,并用其所含过程、做法、输入、输出、工具和技术进行描述。
• 裁剪
  • 是指根据项目实际需求，对项目管理方法论、过程、工具和技术进行选择性调整与优化，以确保管理活动与项目目标、环境及资源相匹配。其核心是“灵活应用”，而非机械套用《PMBOK指南》中的标准流程。
  • 裁剪对象
    • 方法论：选择适合项目类型的框架（如预测型生命周期用于建筑工程，敏捷用于软件开发）。
    • 过程：调整启动、规划、执行等过程组的执行深度（如简化风险分析流程）。
    • 工具与技术：按需选用模板（如WBS模板）、技术（如关键路径法）或数字化工具（如Jira）。
    • 输出：定制化文档（如仅保留必要会议纪要，省略冗长报告）
  • 剪裁的原因
    • 从团队承诺，客户为本，资源利用三个方面出发,更有效的利用资源和更好的达到项目目标。
    • 为达到“刚刚好”的目的，不臃肿
• 项目生命周期
  • 分类
    • 预测型生命周期（瀑布型）
      • 特点：在项目早期确定范围、时间、成本，变更需严格管理。适用于需求明确且稳定的项目。
      • 举例：建筑工程、传统制造业项目。
    • 迭代型生命周期
      • 特点：早期确定范围，但时间和成本随项目推进逐步细化。通过重复循环活动开发产品。
      • 举例：软件开发中的原型设计阶段，需求明确但技术需探索。
    • 增量型生命周期
      • 特点：通过多次迭代逐步增加功能，最终交付完整成果。适用于需求逐步明确的项目。
      • 举例：分阶段交付功能的互联网产品（如电商平台分批上线模块）。
    • 适应型生命周期（敏捷型）
      • 特点：迭代与增量混合，需求在迭代前定义但允许灵活调整。强调快速响应变化。
      • 举例：敏捷软件开发（Scrum、Kanban）。
    • 混合型生命周期
      • 特点：结合预测型和适应型，稳定部分用预测型，不确定部分用适应型。
      • 举例：硬件研发中，硬件设计用瀑布模型，配套软件开发用敏捷
  • 开发方法：重点区分表
    • • 迭代相当于炒一次菜试吃一下，再重炒调口味，全炒好才上菜
      • 增量是炒好一个上一个
      • 敏捷是二者融合
  • 开发方法：Stacey matrix
• 项目的环境
  • 价值交付系统 value delivery system
    • 价值交付定义
      • 做项目根本不是为用户创造有形的产品或无形的服务,而是为了产品或服务为用户交付价值
  • 事业环境因素与组织过程资产
    • 事业环境因素EEFs
      • Enterprise Environmental Factors
      • 指项目团队不能控制的,将对项目产生影响、限制或指令作用的各种条件
      • EEFs源于政府、行业协会、公司管理层
      • 用于遵守，被动接受，入乡随俗
        • 如项目面临历史数据缺乏，这是必须要接受的客观因素
    • 组织过程资产OPAs
      • （Organizational Process Assets, OPA）
      • 定义
        • 是组织在项目管理过程中积累的计划、流程、政策、程序、模板、知识库和历史信息等无形资产，用于提升项目管理效率、减少重复性工作，并支持项目团队做出更优决策。其本质是将个人经验转化为组织能力，形成可复用的系统性资源
        • 源于一些列SOPs，主动参与，更新维护
        • 如：以往类似项目中获得的教训 Lessons learned from similar projects in the past
      • 两大类
        • 第一类：流程、政策与程序
          • 指导性文件
            • 项目管理方法论（如敏捷、瀑布流程）、裁剪指南、标准化模板（如项目计划模板、风险登记册模板）。
            • 组织政策（如采购政策、质量政策、人力资源政策）。
            • 变更控制程序、问题与缺陷管理流程、财务控制程序。
          • 工具与模板
            • 工作授权系统、跟踪矩阵、合同模板（如总价合同、工料合同）。
            • 核对单（如需求评审核对单、交付验收清单）。
        • 第二类：组织知识库
          • 经验与数据
            • 历史项目档案（如范围基准、进度网络图、风险登记册）。
            • 经验教训总结（如项目失败案例、成功实践）。
            • 风险数据库（如风险分类、概率影响矩阵）。
          • 运营支持库
            • 配置管理库（如软件版本基线、硬件配置记录）。
            • 财务数据库（如人工成本、预算超支记录）。
            • 问题与缺陷数据库（如解决方案、行动结果）
  • 项目管理办公室PMO
    • 概念:对项目相关的治理过程进行标准化,并促进资源、方法论、工具和技术共享的一个组织结构
    • 关键字:指导、培训、整体。
  • 商业文件与效益管理
    • 商业论证
      • 四步走:业务需要、形势分析、提出建议、定义评估标准
      • 三要素:用户需求、经济可行性、技术可行性
        • 需求-创造价值
          • 1. 问题痛点
          • 2. 客户细分
          • 3. 独特卖点
          • 4. 解决方案
        • 技术可行性-传递价值
          • 渠道
          • 关键指标
        • 经济可行性-获取价值
          • 竞争壁垒
          • 成本分析
          • 收入分析
          • 成本效益分析
    • 效(收)益管理计划:量化的收益目标、每个阶段的收益、收益的跟踪、收益的测量
  • 项目组织结构
• 项目的角色
  • 角色及职责
    • 内部角色
      • 项目经理
      • 项目管理团队
        • 直接参与项目管理活动的项目团队成员
      • 主题专家
        • 在某一领域具备专业知识、技能、经验或培训经历的个人或小组
    • 外部角色
      • 高级管理层
      • 项目指导委员会
      • 发起人
        • 项目的发起者,赞助者,通常职位较高,能够给项目提供资源
      • 职能经理
      • 客户
        • 提供资金,并要求交付成果的个人或集体,甲方
      • 用户
        • 可交付成果的使用方,通常比较关注新产品上市情况
  • 发起人的职能
    • 1. 向团队沟通愿景、目标和期望。
    • 2. 成为项目和团队的拥护者。
    • 3. 促使高级管理层做出决策。
    • 4. 帮助获得资源。
    • 5. 使项目与商业目标保持一致。 发起人的职能
    • 6. 清除障碍。
    • 7. 解决项目团队职权之外的问题。
    • 8. 让高层管理人员注意到项目中出现的机会。
    • 9. 在项目结束后密切关注项目成果,以确保实现预期的业务收益
  • 项目经理的权力
    • 职位权力
      • 正式权力:职位相关奖励权:升职加薪惩罚权:停职解聘
    • 个人权力专家权
      • 专业威望参照权：潜示权
  • 领导力风格
    • 领导力:指导、激励和带领团队所需的知识、技能和行为,可帮助组织达成目标
    • 领导力风格类型:放任型领导、交易型领导、服务型领导、变革型领导、魅力型领导、交互型领导

中心主题

• 预测型项目总结
  • 预测型项目考点概念辨析
    • 项目组合与项目集
      • 项目集中的项目之间存在依赖和关联
    • 开发方法
      • Stacey矩阵
      • 预测迭代增量敏捷
    • 范围与质量
      • 需求的拆分
        • 需要（要什么）
          • 可交付成果描述
        • 要求（要多好）
          • 验收标准（质量）
            • 验收标准/质量问题是刚性的不容商量让步的，不存在和接受或与客户协商接受
        • 范围
      • 范围包括质量。明确说要求的标准未满足就只涉及质量管理
    • 冲突管理
    • 风险应对策略
    • 进度/成本估算工具
    • 沟通&干系人
      • 沟通
        • 信息的正确传递
        • 关键字：报告、信息、通知、邮件等
      • 干系人
        • 支持与抵制
        • 关键词：支持、抵制、不满意、拒绝
      • 凡信息，找沟通；遇抵制，干系人
        • 遇抵制但不是第一时间去找领导，干系人管理时PM的职责
    • 审计&审查
      • 审计
        • 检查过程&结果的合规性
        • 采购审计
        • 质量审计
          • 质量审计失败后优先执行整体变更控制进行缺陷补救，以及时修正问题
        • 风险审计
          • 审计风险应对过程有效性
      • 审查
        • 仅检查结果的合规性
        • 绩效审查
          • 审查供应商进度成本质量
          • 审查质量结果，而非审查发生的过程
          • 其中包括确定工作包提前或落后于进度计划、超出或低于预算，以及是否存在资源或质量问题
        • 风险审查
          • 审查新风险、旧风险
          • 风险再评估
      • 先审查看结果，有问题再深入审计
    • 进度压缩
      • 赶工增加成本
      • 快速跟进使任务并行，增加风险
        • 改变了网络图
    • 资源优化
      • 资源平滑
      • 资源平衡
      • 关键链法
        • 蒙特卡洛分析
          • 定义
            • 通过模拟大量随机样本，结合概率分布模型，预测项目可能结果的概率分布
          • 关键特征
            • 随机性：通过随机数模拟变量的可能取值
            • 概率分布：为每个不确定性变量（如工期、成本）设定概率模型（如正态分布、三角分布等）
            • 多次迭代：通常进行成百上千次模拟以逼近真实结果
          • 作用
            • 风险评估、预算制定与成本预测、进度预测、决策支持、绩效评估
        • 考虑了资源约束的关键路径法
    • 质量过程
      • 过程包含
        • 质量策划
          • 制定质量目标，规定必要运行过程以实现目标
        • 质量保证
          • 提升质量信心
            • 看某公司质量体系完整且流程规范，这才能提升质量管理的信心
        • 质量控制
          • 满足质量要求
            • 看具体的某产品质量是否达标，这就是满足质量要求
        • 质量改进
          • 增强满足质量要求的能力
      • 管理质量及控制质量区别
        • 书面
          • 管理质量
            • 面向过程，更宏观
            • 关键词
              • 信心、宏观、审计、过程、持续改进、增值
          • 控制质量
            • 面向结果，更具体
            • 关键词
              • 不良、测试、工作包
        • 通俗
          • 管理质量面向一整个质量管理体系，提升质量信心
          • 控制质量针对具体某个产品是否达到质量要求
    • 沟通技术、沟通技能、沟通方法
      • 技术指各类客观的通讯技术，如电话邮件通话等
        • 针对虚拟团队远程距离，技术更重要
      • 技能指人所拥有的一系列软技能，如反馈演示
      • 方法指传递信息方法，如推式拉式交互式
    • 塔克曼阶梯理论
      • 形成阶段很独立
      • 震荡阶段有争议
      • 规范阶段建信任
      • 成熟阶段最有序
    • 质量工具
      • 流程图
        • 整个项目的节点流程
          • 排查是项目哪个环节出现了问题
      • 控制图
        • 可监控过程
          • 如需要确保生产线运行符合技术规范
          • 如用于确定某服务的稳定性及可预测性
      • 鱼骨图
        • 用于寻找问题根本原因
      • 帕累托图
        • 用于发现问题的主要/影响最大的原因，二八原则
      • 散点图
        • 展示两个变量关系
      • 核查表
        • checksheets 主要用于计数
      • 核对单
        • checklist 用于检查避免遗漏
    • 收集需求的工具
      • 头脑风暴
        • 邀请所有干系人不受限制地提出创意
        • 关键词：不评价
        • 头脑风暴更多是提出创意，不适合用于解决问题
      • 访谈
        • 关键词：一对一、机密信息
        • PM与发起人谈话，了解其具体需求
      • 焦点小组
        • 关键词：针对主题、热烈讨论
        • PM召集主题专家共同讨论关于某一个可交付成果的需求
      • 问卷调查
        • 关键词：受众多样、地理位置分散、快速调查
        • PM向多国用户了解某产品需求
      • 标杆对照
        • 关键词：对比、参考
        • PM参考以往类似项目实践过程来确认新项目需求
      • 引导
        • 关键词：需求差异，需求冲突
        • 面对多个干系人需求差异，PM召开引导式研讨会
    • 质量与等级
      • 先确定产品的等级，再在这基础上规划质量
    • 问题和风险
      • 区分
        • 风险
          • 一旦发生，会对一个或多个项目目标产生正面或负面影响的不确定事件或条件
            • 着重预防
        • 问题
          • 可能对项目目标产生影响的当前条件或情形
            • 确定性，概率为1
        • 风险发生便会成为问题
        • 评估是风险还是问题，看概率和时间表（过去还是未来）
        • 评估是风险还是机会，看后果积极还是消极
      • 案例问题
        • 一个风险发生了应该更新哪个文件？
          • 风险发生最开始应该是及时根据风险登记册的应急预案处理问题，一次性解决便无需登记问题日志，未解决需要跟踪则登记至问题日志
    • 三大项目文件
      • 风险登记册 Risk Register
        • 风险是对将来可能发生问题的一个预判
      • 问题日志 Issue Log
        • 问题是对过去已产生问题的一个跟踪
      • 经验教训登记册 Lessons learned register
        • 已解决的问题防止再次发生
      • 问题日志容易和风险登记册混在一起，两者之间有使用场景上的区别，如果强调对问题的“聚焦”和“跟踪解决”，通常选择问题日志。如果强调对不确定性进行管理，一般选择风险登记册
    • 合同类型区分
      • 总价合同
        • 范围&需求明确
      • 工料合同
        • 范围不明确，聘请专家
      • 成本补偿合同
        • 范围会发生变化
          • 成本+奖励
            • 主观，不能申诉
          • 成本+激励
            • 客观，有明确绩效
    • 风险管理计划&风险登记册
      • 风险管理计划
        • 管风险的战略、方法论、风险应对角色、资金、风险类别、干系人风险偏好、风险报告格式
      • 风险登记册
        • 包括的是已知风险
        • 包括风险条目、风险优先级、概率及影响、应对措施、应急计划、次生风险
    • 干系人登记册&干系人参与计划
      • 干系人登记册
        • 包括基本信息：干系人身份信息、干系人需求、期望及分类
        • 试题如：干系人变更，需重新识别干系人，更新干系人登记册
      • 干系人参与计划
        • 包括应对策略：对干系人执行的策略、促进干系人参与的行动
        • 试题如：确保某干系人受邀参加会议
    • 治理与管理
      • 管理在治理的框架下
      • 项目治理要做的几件重要事
        • 1. 与组织治理保持一致
        • 2. 确保项目遵守法规
        • 3. 定义好干系人的RACI
        • 4. 支持项目决策
        • 5. ...
  • 预测型项目重点流程
    • 变更流程
      • 变更几大原则
        • 凡变更，必流程（审批前，三步骤）
          • 干系人提出变更
            • 不能够提出变更后就开始执行分配资源，还需要评估和审批
          • 分析影响
            • 如：评估该变更请求的影响
            • 先变更再分析影响
          • 提交CCB审批
            • 即向CCB提交变更请求，需要在分析评估之后！
        • 动基准，先变更
        • 遇蔓延，找变更
        • 有变更，要沟通
          • 变更请求过程包括了与提出变更干系人的沟通过程
        • 有变更，要花钱
        • 有权变，找变更
    • 风险流程
      • 风险整体流程
        • 识别风险
          • 识别-定性-定量
        • 更新文件
          • 先更新风险登记册
        • 新风险出现
          • 已发生先应对，未发生先定性
            • 如某不可抗力发生并影响了项目交付日期，此时动了基准，应当先应对，故提出变更请求
        • 变计划
          • 规划风险应对后，项目管理计划会变化
            • 如应对计划制定好后，需在项目管理计划中WBS中增加工作包，以便纳入至范围基准
            • 风险应对计划需要变化时，项目经理应当先确保获得管理层的批准
          • 使用应急储备应对风险只是风险应对计划中的情况之一
        • 入基准
          • 规划成本进度基准时纳入应急储备
        • 建储备
          • 针对已主动接受的风险建立应急储备
        • 应急计划
          • 遇到风险先查风险登记册
          • 针对已知风险执行应急计划
        • 权变措施
          • 针对未知风险发生，采用权变措施
            • 需要用到管理储备，实施的措施就是权变措施
          • 风险发生了再用权变
      • 规划风险应对流程
        • 规避
        • 减轻
        • 转移
        • 风险发生之前的措施，使现有的范围成本&进度基准变化，需变更
        • 接受
          • 与应急储备挂钩
      • 监督风险流程
    • 采购流程
      • 规划采购
        • 提出需求和SOW
        • 自制外购分析
      • 执行采购
        • 招标、投标人会议、谈判、签合同
    • 收尾流程&过程流程
  • 预测型项目常见场景
    • 干系人场景
      • 干系人管理决定成败
        • 当一个项目其干系人了解项目执行情况、高级管理层支持该项目且项目在技术方面无问题，最终产品被告知不被接受，大概率是未识别出某个关键的项目干系人
      • 尽早引导干系人参与
        • 答案中包含鼓励干系人尽早参与，一般都是正确的
      • 谈判和沟通管理干系人期望
    • 冲突处理场景
      • 三步骤
        • 自行解决-私下合作-正式程序
      • 成功的冲突管理可提高生产力改进工作关系；若管理得当意见分歧有利于提高创造力和改进决策
    • 项目经理权力
      • 专家权
        • 组织影响力，成员追随
        • PM并不应该处处都充分使用自己的职位权力，而是非正式权力：优先使用专家权
      • 奖惩权
        • 正式权力
      • 潜示权
        • PM背后角色的权力
    • 上报的场景
      • 什么时候找领导？
        • 批准项目章程
        • 风险上报
        • 项目启动之前
          • 项目未立项时
        • 项目是否继续
        • 收尾评估成败
        • 管理储备动用
      • 什么时候不找领导
        • 拥有相关规定文件规范的包含在内的小问题
    • 获取资源场景
      • 谈判获取资源
        • 谈判失败则找领导发起人
          • 找领导不成则自己招募
      • 获取资源优先谈判
        • 即便选项中不含有和其他PM/职能经理谈判的选项，也有类似含义的表达
          • 如根据项目优先级确定资源分配选项
            • 内在含义即用优先级这个道理去和拿走资源的人谈判
    • 索赔管理场景
      • 谈判-ADR-法院
    • 谋定而后动
      • 先定义问题，再分析问题，再解决问题
        • 分析
          • 问题影响、原因、解决方案
        • 解决
          • 提交解决方案、与领导沟通、提交变更
      • 先评估影响，若影响较大则下一步分析原因，之后再确定解决方案
• 项目整合管理
  • 启动：项目章程
    • 内容含义：4项3高3总3人
      • 4项：项目目的、成功标准、审批要求、退出标准。
      • 3高：高层级需求、高层级描述、高层级可交付成果。
      • 3总：总体里程碑、总体预算、整体风险。
      • 3人：项目经理、发起人、关键干系人。
      • 确立项目目标、为各个子计划提供依据和指导；对项目经理确权、签字批准项目成立
    • 项目目标
      • 内容
        • 项目目的
          • 明确项目的商业价值和战略意义，例如“开发一款满足用户需求的移动应用以提升市场份额”。
        • 可测量的目标与成功标准
          • 定义具体的、量化的目标，如“在12个月内完成开发，预算控制在500万元以内，用户满意度达90%”
        • 高层级需求
          • 概括性描述客户或市场的核心需求，例如“支持多平台兼容性”或“实现用户数据安全加密”
        • 主要可交付成果：
          • 列出项目最终产出的高层级成果，如“交付完整的软件系统及用户手册”
        • 整体项目风险
          • 别可能影响项目目标实现的高层级风险，如“技术选型不成熟可能导致延期”
        • 总体里程碑与预算
          • 规划关键时间节点和财务资源，例如“需求确认阶段需在3个月内完成，预算分配100万元
      • 干系人需求期望与项目章程中目标不一致怎么办？
        • 将干系人的期望与项目章程中的目标调整一致
    • 团队章程
      • 1. 团队价值观（Team Values）
        • 作用：明确团队共同遵循的行为准则，例如诚信、协作精神、尊重多样性等。
        • 示例：若团队跨文化合作，需特别注明尊重不同文化习惯。
      • 2. 沟通指南（Communication Guidelines）
        • 内容
          • 沟通工具（如企业微信、Slack、邮件）
          • 响应时间要求（如紧急事项需在30分钟内回复）
          • 会议频率与形式（如每周三下午3点站会）
      • 3. 决策机制（Decision-making Criteria and Process）
        • 类型
          • 投票制（多数同意）
          • 专家决策（技术问题由技术负责人决定）
          • 协商一致（需全员同意）
        • 场景：预算争议时，可能采用成本效益分析后由项目经理裁决。
      • 4. 冲突处理流程（Conflict Resolution Process）
        • 步骤
          • 1. 直接沟通解决
          • 2. 团队会议讨论
          • 3. 项目经理或中立方介入调解
        • 参考方法：结合PMP冲突解决技术（如合作、妥协等）。
      • 5. 会议指南（Meeting Guidelines）
        • 规则
          • 提前24小时发送议程
          • 迟到者需贡献团队活动基金
          • 会议记录由轮值记录员整理并共享
      • 6. 角色与职责（Membership Roles & Responsibilities）
        • 典型分工
          • Leader：统筹协调
          • Recorder：文档管理
          • Timekeeper：进度把控
          • Quality Controller：成果审核
        • 轮换机制：可制定周期轮换表（如每两周换岗）
        • 发起人与项目经理职责
          • 项目发起人通常负责项目商业论证文件的制定和维护
          • 项目经理负责提供建议和见解，使项目商业论证、项目管理计划、项目章程和项目效益管理计划中的成功标准相一致，并与组织的目的和目标保持一致
      • 7. 基本规则（Ground Rules）
        • 具体条款
          • 任务需在Deadline前24小时提交初稿
          • 请假需提前48小时告知团队
          • 使用共享文档时禁止覆盖他人内容
        • 案例
          • 某项目成员开会时总是拓展讨论主题花费更多时间，PM应提醒团队遵守基本规则
      • 8. 团队使命声明（Team Mission Statement）
        • 示例:“通过高效协作，在预算内按时交付高质量可交付成果，助力客户业务增长。”
      • 9. 其他补充内容
        • 联系方式：成员电话、邮箱及紧急联系人
        • 资源管理：共享文件存储路径、权限分配
        • 定期审查：每季度更新章程以适应项目变化
    • 高频易错考点
      • 1. 项目章程 ≠ 范围说明书
        • 章程：高层级、战略导向（如“开发一款APP”）。
        • 范围说明书：详细范围定义（如“APP需支持安卓和iOS系统”）。
      • 2. 谁负责修改章程？
        • 章程的修改必须由发起人或CCB批准，项目经理无权直接修改。
      • 3. 章程与变更的关系
        • 若变更涉及章程内容（如调整预算上限），需重新提交CCB审批。
      • 4. 开始新项目需要批准的项目章程
    • 章程-风险描述
      • 按风险性质分类
        • 1. 整体项目风险（Overall Project Risk）
          • 定义：影响项目整体目标的高层级不确定性（参考内容中强调“关系到项目生死存亡”）。
          • 示例
            • 项目范围与战略目标不一致（如“客户需求模糊导致交付物偏离预期”）；
            • 关键路径上的里程碑延误（如“原型测试失败导致项目整体延期”）。
        • 2. 假设条件风险（Assumption-Based Risks）
          • 定义：项目依赖的假设若不成立可能引发的风险（参考内容中“假设条件日志管理”）。
          • 示例
            • 假设供应商按时交付（否则导致进度滞后）；
            • 假设技术方案通过验收测试（否则需重新设计）。
        • 3. 制约因素风险（Constraint-Driven Risks）
          • 定义：由预算、时间或资源限制直接引发的风险。
          • 示例
            • 固定预算下无法应对突发成本（如“硬件采购价超预期导致预算耗尽”）；
            • 强制截止日期压缩测试周期（如“为赶工期牺牲质量验收标准”）
    • 资源管理
      • 资源管理计划
        • 直答
          • 1. 资源识别
            • 定义项目所需资源的类型（如人力、设备、材料等），并明确资源技能水平、经验要求等属性。例如，通过活动属性分析资源需求，结合资源日历判断可用性。
          • 2. 资源获取
            • 制定获取资源的策略，包括内部调配、外部采购或租赁等。例如，确定何时需要采购设备或招募具有特定技能的人员，并规划资源到位的时间表。
          • 3. 角色与职责
            • 通过工具（如RACI矩阵）明确团队成员的责任分工，区分“执行（R）”“负责（A）”“咨询（C）”和“知情（I）”角色，避免职责重叠或缺失。
          • 4. 项目组织图
            • 以层级结构或责任分配矩阵展示团队成员间的汇报关系和协作方式，帮助理解团队结构及资源归属。
          • 5. 团队资源管理
            • 包括团队建设活动（如培训、工作坊）、冲突解决机制、绩效评估标准等，旨在提升团队协作效率和能力。
          • 6. 培训计划
            • 根据团队技能差距设计培训方案，确保成员具备完成任务所需的能力。
          • 7. 资源控制
            • 定义资源监控方法（如资源使用率跟踪）、调整策略（如资源再分配）及释放资源的条件（如项目阶段结束后的遣散计划）。
          • 8. 认可计划
            • 建立对团队成员的激励机制（如奖金、表彰），结合麦克利兰的成就动机理论，针对不同需求（成就、权力、亲和）设计激励措施。
        • 包括 • 角色 • 职权 • 职责 • 能力。 子团队的工作职责不清，需要看资源管理计划。
      • 资源日历 Resourc Calendars
        • 识别了每种具体资源的可用时间，用于估算资源可用性
      • 团队建设
        • 定义
          • 团队建设是通过规划活动和策略，促进团队成员互动与合作，改善团队氛围，最终提高项目执行效率和成果质量的过程。其核心目标是建立高效、协作的团队文化，降低冲突，增强成员对项目目标的共同承诺
        • 团队建设的核心知识点
          • 塔克曼阶梯理论（团队发展阶段）
          • 团队建设的目的
            • 提升成员技能和知识水平；
            • 增强成员间的信任与认同感，减少冲突；
            • 创建协作性强、士气高的团队文化；
            • 提高项目整体绩效（如缩短工期、降低成本
          • 团队建设与冲突管理的区别
            • 冲突管理：针对具体冲突事件（如资源争夺、优先级分歧），采用谈判、妥协等策略解决
            • 团队建设：系统性提升团队协作能力，预防长期协作问题。
        • 团队建设的主要方式
          • 集中办公（紧密矩阵）
            • 将团队成员安排在统一物理地点工作，增强面对面沟通效率（例如通过共享工作区促进即时协作）。
            • 集中办公通常是对团队建设有最大贡献的形式
          • 团队建设活动
            • 组织专题研讨会、头脑风暴会议或非正式社交活动（如团队聚餐、户外拓展），促进成员关系；
            • 案例参考：某项目通过定期“午餐学习会”分享技术经验，提升团队凝聚力。
          • 认可与奖励机制
            • 根据成员需求设计激励措施（如公开表彰、奖金、晋升机会）；
            • 原则：及时性（任务完成后立即奖励）、个性化（结合成就动机理论）。
            • 项目经理应该在整个项目生命周期中尽可能地给予表彰，而不是等到项目完成时
          • 培训与发展
            • 针对技能差距提供专业培训（如敏捷方法培训）；
            • 费用规则：仅对当前项目有利的培训计入项目预算。
          • 基本规则与团队章程
            • 明确团队行为规范（如沟通方式、决策流程）；
            • 使用工具（如RACI矩阵）定义角色分工，避免责任模糊。
          • 虚拟团队管理
            • 通过视频会议、协作平台（如Slack、Microsoft Teams）维系远程团队协作；
            • 定期组织线上互动（如虚拟咖啡时间）。
          • 人际关系技能培养
            • 提升软技能（如倾听、同理心、谈判）；
            • 案例：项目经理通过“冲突模拟演练”帮助成员学习应对分歧的技巧
      • 组织理论
        • Organizational Theory 核心内容
          • 组织结构类型：如职能型（部门垂直管理）、矩阵型（弱/平衡/强矩阵，项目经理与职能经理共享权限）、项目型（项目经理全权主导）。不同结构决定项目经理的权限范围和资源调配能力。
          • 组织文化：包括价值观、沟通风格（开放或层级化）、风险容忍度等，直接影响团队协作方式和决策效率。
            • 什么时候需要审查组织文化、结构和治理
              • 题干关键词“全球项目”“不同地区”，团队成员产生矛盾，管理冲突需要先了解发生冲突的背景
          • 权力类型：项目经理的权威来源包括正式权力（职位赋予）、奖励权力（激励资源分配）、专家权力（专业技能）、参照权力（个人影响力）等。
        • 当项目团队成员积极性不高时，PM可采取的措施
          • 1. 明确责任与分工
            • 使用RACI矩阵：明确每个任务的“负责（R）”“批准（A）”“咨询（C）”“知情（I）”角色，避免责任模糊（参考案例中“责任不清”问题）。
            • 细化流程与目标：通过WBS（工作分解结构）将任务拆解到可执行层级，设定量化指标（如“能量化的量化，不能量化的以结果导向”）。
          • 2. 建立激励机制
            • 个性化激励：根据成员需求设计激励措施（麦克利兰成就动机理论
              • 成就需求：提供挑战性任务，如分配关键模块给自驱力强的成员；
              • 权力需求：赋予部分决策权，如让资深成员参与方案评审；
              • 亲和需求：通过团队活动（如案例中的“午餐学习会”）增强归属感。
            • 及时认可与反馈：公开表扬优秀表现（如“每周复盘时表扬做得好的员工”），并结合物质奖励（奖金、晋升机会）。
            • 需规避的激励误区
              • 1. 单一物质激励：易导致短期行为，忽视长期协作（如过度依赖奖金引发恶性竞争）
              • 2. 私下奖励：违背透明原则，破坏团队信任
              • 3. 平均主义：抑制高绩效者积极性（“公平≠平均”）
          • 3. 改善团队协作与沟通
            • 促进信任：允许适度失败并复盘（如“非原则性错误先解决问题，再分析原因”），减少成员对失误的恐惧。
            • 加强沟通管理
              • 定期会议同步进度（如“每日站会”或“周例会”）；
              • 使用协作工具（如Jira、Trello）透明化任务状态，减少信息差。
          • 4. 提升能力与参与感
            • 针对性培训：根据技能差距提供培训（如案例中“技术经验分享会”），提升成员信心。
            • 主动授权：将任务决策权下放（如“让员工负责子任务的全流程”），增强责任感。
          • 5. 优化组织环境
            • 调整流程与制度：若现有责任制度失效（如案例中“流程未下沉至个人”），重新设计细化规则，明确交接标准。
            • 推动文化建设：通过团队章程定义协作规范（如沟通方式、冲突解决机制），逐步形成“结果导向”文化
          • 总结
            • PM需结合组织理论分析团队动力不足的根源（如结构僵化、文化消极），并通过责任明晰、激励设计、能力提升和协作优化综合施策
      • 资源控制权限
        • 对于该权限问题，优先采用协商的方式解决
      • 资源变动
        • 矩阵型组织项目中遇到项目人员离职，PM如何处理
          • 首先与职能经理协商安排替代资源
          • 其次再修改资源管理计划，应对未来的辞职问题
        • 一位关键团队资源被开除，这一行动将对关键路径上的活动造成负面影响，PM能做什么
          • 最首先：分析对项目管理计划的影响并提交变更请求
          • 其次可能采取的行动
            • 与该职能领导协商，并影响其转变决定
            • 让发起人与该职能领导讨论这名资源的重要性
            • 遵循资源管理计划获取替代资源
          • 先看对原计划影响如何，再评估后续行动
      • 责任分配矩阵（RACI矩阵）
        • 包含内容
          • 角色定义
            • R（Responsible，执行人）：具体执行任务的人员，负责完成任务。
            • A（Accountable，负责人）：对任务结果负最终责任的角色，通常是审批或决策者。
            • C（Consulted，咨询）：需提供专业意见或信息的专家或干系人。
            • I（Informed，知情者）：需知悉任务进展或结果的人员，无需直接参与执行。
          • 核心作用
            • 避免职责重叠或遗漏，明确“谁该做什么”；
            • 促进跨职能协作，建立垂直（职能）与水平（项目）的双向责任链路；
            • 作为沟通和冲突解决的依据，帮助项目经理协调资源与优先级
          • 应用场景
            • 通常出现在项目规划阶段，随任务分解结构（WBS）同步制定，并在执行阶段动态调整以适应变更
    • 沟通管理计划
      • 1. 相关方沟通需求
        • 明确各相关方的信息需求类型（如进度报告、风险状态）、格式偏好（文字/图表）、语言要求（如多语言支持）及详细程度（摘要或深度分析）。
      • 2. 信息分发规则
        • 发布方式：推式（邮件、备忘录）、拉式（内网、知识库）、互动式（会议、即时通讯）
        • 时限与频率：例如每周五发送进度报告，紧急问题需2小时内响应。
        • 责任人：指定信息创建者（如项目经理）、审核者（如质量部门）和发布者（如团队协调员）。
      • 3. 沟通技术与管理流程
        • 选择适用的工具（如Jira跟踪任务、Zoom会议），并定义安全访问权限（如涉密信息需VPN登录）。
        • 上报路径：如团队成员发现问题→项目经理→发起人，逐级升级的步骤与时限。
      • 4. 资源分配与约束条件
        • 预算与时间：如每月预留10小时用于客户汇报准备，或采购企业版沟通软件的费用。
        • 法律法规约束：如跨境项目需遵守数据隐私法（GDPR），限制信息存储位置。
      • 5. 更新与优化机制
        • 定期审查周期（如每季度评估一次），以及触发更新的条件（如新相关方加入或项目阶段变更）。
      • 6. 辅助工具与模板
        • 标准化报告模板（如风险登记表格式）、会议议程范例（如站会15分钟议程）、术语表（统一项目术语定义）。
    • 假设日志
      • 假设条件和制约因素
  • 规划：项目管理计划
    • 制作步骤：程序性计划、实体计划、风险相关、变更相关、迭代编制..
      • 项目启动会议 initial meeting
      • 项目开工大会/会议 kick-off meeting
        • 开工会议意味着规划阶段结束和执行阶段开始
        • 旨在传达项目目标、获得团队对项目的承诺，以及阐明每个干系人的角色和职责
    • 将各类子计划集成到项目管理计划中
  • 执行：指导与管理项目工作
    • 项目管理信息系统 PMIS
      • 属于EEFs，包含各类自动化系统
      • 如CRM、一临云、易快报
    • 工作绩效数据
      • 工作效绩数据→收集数据
      • 工作效绩信息→提取信息
      • 工作校绩报告→完成决策
    • 变更请求
      • 变更请求四措施:缺陷补救、纠正措施、预防措施、更新
        • 缺陷补救 repair
        • 绩效跑偏了用纠正措施
    • 问题日志 Issue Log
      • 定义：用于记录和监督问题信息的项目文件
      • 用处：帮助PM有效跟进和管理问题，确保他们都得到调查和解决
    • 各类不断更新的项目文件汇总
      • 日志
      • 变更日志
        • 记录变更状态
      • 经验教训登记册
        • 防止同一个问题再次发生
      • 风险登记册
      • 干系人登记册
    • 管理项目知识
      • 知识管理
        • 显性知识
          • 可编撰已与表达的知识，如文字图片数字表格
      • 信息管理
        • 隐性知识
          • 无法编撰难以表达的知识，如经验直觉、信念洞察力、诀窍
  • 监控
    • 监控项目工具（顺序
      • 1. 挣值分析
        • 对范围进度和成本绩效综合分析
          • 收集项目数据
            • 提供数据基础（PV/EV/AC）；
        • 算清“干了多少活，花了多少钱”
          • 核心问题：当前项目进展是否符合计划？
            • PV、EV、AC
      • 2. 偏差分析
        • 审查目标与实际绩效之间差异
          • 比较收集的数据
            • 诊断问题（SV/CV/SPI/CPI）
        • 揪出“哪里出了问题”
          • 核心问题：成本和进度偏差有多大？原因是什么？
      • 3. 趋势分析
        • 根据以往结果预测未来绩效
          • 继续如此的话未来什么趋势
            • 预测结局（EAC/工期）并触发纠偏措施。
        • 预测“照这样下去会怎样”
          • 核心问题：按当前趋势，项目最终会超支多少？延迟多久？
      • 4. 根本原因分析
        • 可用于识别出现偏差的原因
          • 原因在哪里
      • 5. 备选方案分析
        • 出现偏差时要执行的纠正
      • 6. 成本效益分析
        • 确定最节约成本的纠正措施
      • 7. 监控总结：识别出计划与实际执行的不一致,然后利用一系列的分析问题的过程,得出解决方案,并通过变更请求来执行这些解决方案
      • 8. 项目效益跟踪的度量标准
        • 旨在客观地度量项目是否实现了它的目标
    • 实施整体变更控制
      • 变更控制系统
        • 变更控制委员会
          • 哪些情况需要对CCB发出申请？
            • 变更请求影响基准baseline时，变更控制委员会可决定变更
            • 基准变更类别
              • 1. 范围基准变更
                • 新增/删减项目可交付成果（如新增功能模块）。
                • 需求范围扩大导致WBS结构变更（如客户提出额外需求）。
              • 2. 进度基准变更
                • 关键路径调整导致里程碑延期（如关键资源不可用需重排进度）。
                • 进度压缩（如赶工或快速跟进需调整原定计划）。
              • 3. 成本基准变更
                • 预算超支需追加资金（如材料价格上涨超出应急储备）。
                • 管理储备的使用（注：管理储备不属于基准，使用时需先申请纳入基准）。
              • 4. 其他影响基准的变更
                • 质量标准的重大调整（如提高验收标准导致返工）。
                • 资源基准变更（如更换关键供应商影响原定资源计划）。
          • 无需CCB审批的情况
            • 不涉及基准的变更：由项目经理直接决策（如使用应急储备解决已知风险）。
            • 紧急变更：可先执行后补审（如突发事件需立即处理，但事后仍需提交CCB备案）。
          • 关键补充说明
            • 1. 提交CCB的材料要求
              • 变更请求需附带
            • 2. 具体解决措施 （如替代方案、影响分析）。
              • 需提供变更对项目目标的综合影响评估（如对范围、进度、成本的联动影响）。
            • 3. CCB的组成与职责
              • 通常包括项目发起人、客户代表、高层管理者等。
              • CCB不参与变更实施，仅负责审批变更对基准的调整。
            • 4. 考试常见陷阱
              • 混淆“应急储备”和“管理储备”：前者在基准内由项目经理控制，后者需CCB审批后方可使用。
              • 误认为所有变更均需CCB审批（仅基准相关变更需要）。
          • 如果变更被CCB否决的话
            • 底层原则
              • CCB 的决议就是权威结论，其决议不会被影响，项目执行情况也不能绕开CCB的决议
            • 处理逻辑
              • 变更基本上都是干系人提出的，PM负责传递变更申请至CCB；CCB否决那只有告知发起变更的干系人情况，解释否决理由及潜在风险
        • 配置管理
      • 变更控制必要环节
        • 1. 变更提出后,团队要分析整体的影响
        • 2. 基准未形成或不涉及基准的变更,由项目经理审批即可
        • 3. 一旦涉及到基准,则需要将含解决措施的变更请求提交给CCB
        • 4. 变更一旦获得批准,则需要先更新项目管理计划和项目文件
        • 5. 变更执行以前,一定要通知干系人
      • 变更管理计划？
        • 变更管理计划是项目管理计划的子计划，用于规范项目变更的控制流程
        • 核心内容
          • 1. 变更控制流程
          • 2. 变更控制委员会（CCB）的职责
            • 记录CCB的成员构成（如项目经理、关键干系人、技术专家）及其权限
          • 3. 变更分类与优先级
            • 区分变更类型（如纠正措施、预防措施、缺陷补救、更新），并制定不同优先级变更的处理规则
            • 定义紧急变更的快速处理机制
          • 4. 沟通与文档管理
          • 5. 风险与质量关联
            • 分析变更可能引入的新风险，并将其纳入风险管理计划
            • 确保变更执行后的成果符合质量要求，必要时进行质量审查
        • 需要审查变更管理计划的主要场景
          • 1. 提交变更请求时
            • 任何干系人提出变更请求后，需依据变更管理计划评估影响并决定是否启动审批流程
          • 2. 涉及基准调整时
            • 当变更影响范围、进度、成本等基准时，必须审查文件以确认是否符合CCB审批要求
          • 3. 风险或问题触发变更时
            • 若风险应对措施或问题解决方案需调整原计划（如技术方案不可行），需按计划流程处理
          • 4. 相关方需求变更时
          • 5. 外部环境变化时
          • 6. 项目阶段审查或复盘时
  • 项目结束收尾
    • 收尾流程
      • 1. 最终验收+移交
      • 2. 关闭合同
      • 3. 财务收尾
      • 4. 最终报告
        • 向干系人报告最终绩效
      • 5. 经验教训
      • 6. 归档工作
      • 7. 庆祝会
      • 8. 解散团队
    • 总结：验证项目成功、移交可交付成果、总结经验教训
    • 另一种收尾流程
      • 1. 项目发起人和客户对产品结果满意
      • 2. 获得项目干系人的正式验收并结束项目
      • 3. 结束采购并向承包商付款
      • 4. 向项目干系人提供最终审查报告，并获其反馈
      • 5. 解散项目团队并收集经验教训
    • 知识转移
      • 知识转移的内容与形式
        • 1. 经验教训总结与共享
        • 2. 跨团队或跨部门知识传递
        • 3. 相关方能力提升
        • 4. 隐性知识转化
  • 过程流程
    • 收集需求-定义范围-创建WBS-定义活动
    • 项目全生命周期-5大阶段-15项核心活动
      • 启动阶段（Initiating）
        • 项目立项与商业论证
          • 输入：市场需求、组织战略或客户需求。
          • 输出：商业可行性报告、初步范围说明书
        • 制定项目章程
          • 核心内容：授权项目经理职权、定义高层级目标、里程碑及预算。
          • 关键角色：发起人（Sponsor）签署章程，正式批准项目。
          • 制定项目章程的输入：事业环境因素EEFs
        • 识别相关方
          • 工具：权力利益矩阵、相关方登记册。
          • 输出：制定初步沟通策略，召开启动大会（Kick-off Meeting）
      • 规划阶段（Planning）
        • 范围管理规划
          • 活动：创建WBS（工作分解结构），定义验收标准。
          • 输出：范围基准（Scope Baseline）
        • 进度与成本计划
          • 工具：关键路径法（CPM）、三点估算、资源平衡。
          • 输出：甘特图、进度基准、成本基准
        • 风险管理计划
          • 活动：风险识别（SWOT分析）、定性/定量评估、制定应对策略。
          • 输出：风险登记册、应急储备方案。
        • 资源与沟通计划
          • 内容：团队角色分配（RACI矩阵）、沟通频率与渠道设计。
          • 输出：资源日历、沟通管理计划
        • 各大子计划整合为最终的项目管理计划→获得发起人及干系人的批准→开工大会→最后开始执行项目
      • 执行阶段（Executing）
        • 项目由规划转入执行阶段的关键节点
          • 项目管理计划批准 & 开工大会的召开（Kick-off Meeting）
        • 团队建设与资源分配
          • 活动：组建团队（内部调配或外部采购）、明确职责。
          • 工具：冲突管理、激励理论（如赫兹伯格双因素理论）
        • 质量保证与交付物开发
          • 方法：质量审计、持续改进（PDCA循环）。
          • 输出：可交付成果、变更日志（记录执行中的需求变更
        • 相关方参与管理
          • 活动：定期同步进展，解决相关方冲突（如客户需求变更）。
          • 输出：问题日志、相关方满意度报告。
      • 监控阶段（Monitoring & Controlling）
        • 绩效测量与偏差分析
          • 工具：挣值分析（EVM）、燃尽图（Burn-down Chart）。
          • 输出：进度偏差（SV）、成本偏差（CV）报告
        • 变更控制与纠偏
          • 流程：变更请求→CCB（变更控制委员会）评审→更新基准。
          • 输出：批准的变更请求、更新的项目管理计划
        • 风险监控与应对
          • 活动：跟踪已识别风险、触发应急计划。
          • 输出：风险审计报告、残余风险清单。
      • 收尾阶段（Closing）
        • 验收与移交
          • 活动：客户/发起人验收可交付成果，签署验收文件。
          • 输出：最终产品、合同收尾文件。
        • 经验总结与归档
          • 内容：组织复盘会议（Retrospective Meeting），分析项目得失。
          • 输出：经验教训登记册、组织过程资产更新。
    • 关键流程衔接关系
  • 绩效测量基准
    • 包含的内容
      • 1. 范围基准
        • 由项目范围说明书、工作分解结构（WBS）和WBS词典组成，明确项目可交付成果的边界及验收标准
      • 2. 进度基准
        • 经批准的进度计划，包含关键路径、里程碑和活动顺序，用于评估进度偏差（SV）
      • 3. 成本基准
        • 包含应急储备的预算分配，用于计算成本偏差（CV）和成本绩效指数（CPI）
    • 应用
      • 使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。 向发起人提供绩效测量基准，将绩效比较结果告之
• 项目范围管理
  • 收集需求
    • 需求跟踪矩阵
      • 定义:需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
      • 解析:需求跟踪矩阵能够跟踪需求的全生命周期。
      • 使用需求跟踪矩阵，可以把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值
        • 当业务目标达成但交付未获关键干系人批准时，优先审查需求可追溯矩阵
      • 收集需求-得到需求文件、定义范围-得到范围基准、指导与管理项目工作-可交付物、结束阶段得到最终可交付物
  • 定义范围&创建WBS
    • 定义范围
      • 范围说明书
        • 范围说明书记录了项目和产品范围、描述了可交付成果,代表了与干系人的共识,指出了不属于本项目的范围。
    • WBS
      • 做且只做的范围内容
      • WBS（工作分解结构）可以理解为“把大象装进冰箱”的步骤拆解方法，只是它拆解的不是大象，而是复杂的项目
        • 提前穷尽所有必要任务，避免遗漏
      • 关键特征：从“做什么”到“谁来做”
        • 以结果为导向
          • 只关注“要交付什么”，而不是“怎么做”。例如：拆解到“制作婚礼请柬”而不是“设计请柬的字体”。
        • 层级分明
          • 像大树的分支，从顶层目标到底层任务逐级细化（一般不超过6层）。
        • 责任到人
          • 每个最小任务（工作包）必须有唯一负责人，避免推诿。例如：“订酒店”只能由小明负责，即使其他人协助。
      • 示例
        • 西藏旅行计划
          • 行程规划
            • 确定天数（责任人：你）
            • 路线设计（责任人：旅行社）
          • 物资准备
            • 购买氧气瓶（责任人：张三）
            • 收拾衣物（责任人：李四）
          • 费用管理
            • 预算分配（责任人：王五）
            • 记账（责任人：赵六）
      • 与常见工具的区别
        • WBS vs 待办清单：WBS是结构化分解，强调层级和归属关系；待办清单是平铺直叙的任务罗列。
        • WBS vs 甘特图：WBS明确“要做什么”，甘特图解决“何时做”和“顺序关系
      • WBS词典
        • WBS词典又称工作分解结构词典,是在创建工作分解结构的过程中编制的,是工作分解结构的支持性文件,用来对工作分解结构中的控制账户和工作包做详细解释。
          • 对WBS工作包的解释文件
      • 100%规则
        • 通过把WBS底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作
        • 所以工作包即使外包，也不能删除
      • 滚动式规划
        • 要在未来远期才完成的可交付物或组件，当前可能无法分解
        • 项目管理团队因而通常需要等待对该可交付物或组成部分达成一致意见，才能够制定出 WBS 中的相应细节。这种技术有时称作滚动式规划。滚动式规划符合项目渐进明细的特点
  • 确认范围&控制范围
    • 范围蔓延（未走变更流程） vs 镀金（主动增加未批准内容）
      • 范围蔓延（Scope Creep）
        • 驱动因素
          • 外部需求变更（如客户频繁追加需求）或内部管理失效（如变更流程缺失）
        • 特征
          • 被动性、渐进性，常伴随资源消耗增加和风险上升
        • 例如，客户在开发过程中临时要求新增直播功能但未走变更流程
      • 镀金（Gold Plating）
        • 驱动因素
          • 内部团队文化（如技术导向型团队过度自信）或规避核心功能缺陷
        • 特征
          • 主动性、非客户驱动，成果可能不被认可。
        • 例如，开发团队擅自为电商系统添加未要求的动画效果
    • 涉及范围蔓延的请求时应当委婉拒绝
      • 应当遵守合同，专注范围内工作
  • 范围管理过程
    • 根据范围管理计划内容收集需求→再通过定义范围把范围定义清楚→再通过创建WBS将范围分解为WBS工作包→执行项目→项目做完后进行范围确认（验收）→验收完毕后通过控制范围确保范围通过变更控制过程
• 项目进度管理
  • 定义活动
    • 活动清单
      • 包含项目所需活动
    • 活动属性
      • 描述活动属性
    • 里程碑清单
      • 项目里程碑的重要时点和事件
  • 排列活动顺序
    • 紧前关系绘图法PDM
      • Precedence diagramming method
      • S：Start
      • F：Finish
      • 是什么？
        • 是创建进度模型的一种技术，用节点表示活动，用一种或多种逻辑关系连接活动，以显示活动的实施顺序
        • 紧前活动
          • 紧前活动是在进度计划的逻辑路径中，排在非开始活动前面的活动
        • 紧后活动
          • 在进度计划的逻辑路径中，排在某个活动后面的活动。
      • 四种依赖关系：
        • FS: Finish to Start
          • 紧前活动完成，紧后活动才能开始的逻辑关系
        • FF
          • 前完成，后才能完成
        • SS
          • 前开始，后才能开始
        • SF
          • 前开始，后才能完成
    • 确定和整合依赖关系
    • 提前量和滞后量
  • 估算活动持续时间
    • 2定律
      • 帕金森定律
        • 只要还有时间，工作便不断扩展，直到用完所有时间
      • 学生综合征
        • 只有在最后一刻即将到期时才会付出最后努力
    • 重点理解几大估算
      • 应试关键区分技巧
        • 类比估算
          • 出现“快速/低准确性”“相似项目”“专家经验”“早期数据不足”等描述
            • 适用于项目早期或信息不足时（如启动阶段）
        • 参数估算
          • 提及“单位成本模型”“统计关系”“乘法/除法计算”等
            • 适用于有成熟参数模型的领域（如建筑每平米造价、代码行成本）
        • 三点估算
          • 涉及“风险概率”“最悲观/乐观值”“标准差计算”
            • 适用于不确定性高或需量化风险时（如新技术项目）。
        • 自上而下估算
          • 强调“高准确性但耗时成本高”“分解细节”“精确汇总”“WBS底层任务
            • 适用于需求明确且准确性要求高时（如详细规划阶段）。
  • 制定进度计划
    • 依赖材料
      • 活动清单
      • 项目进度网络图
      • 里程碑清单
      • 持续时间估算
    • 关键路径法
      • 关键路径 Critical Path
        • 是 决定项目最短工期的任务序列，由项目网络图中 总耗时最长的路径 构成
        • 核心特征
          • 时间刚性：路径上任何活动延迟将直接导致项目总工期延长
          • 浮动为零：关键路径活动的总浮动时间（Total Float）≤0
          • 动态可变：资源调整或进度变更可能使非关键路径转为关键路径
      • 关键路径法用于在进度模型中估算项目最短工期，确定逻辑网络路径的进度灵活性大小
        • 最短工期：某活动最短需要多少时间
        • 灵活性：可以选择在什么时点进行某活动
    • 资源优化
      • 定义：资源优化技术是根据资源供需情况，来调整进度模型的技术。
      • 解析：资源优化解决的是资源被过度分配,或者安排不合理的问题。
      • 资源有限的情况下适用
      • 引申
        • 资源平滑 Resource Smoothing
          • 定义：
            • 在不改变关键路径和总工期的前提下，通过调整非关键活动的浮动时间，减少资源需求波动。
          • 核心特点
            • 不改变关键路径，仅利用活动的自由浮动时间和总浮动时间
            • 适用于资源限制相对宽松但需优化使用率的场景
            • 通常在资源平衡后进行，属于二次优化
          • 典型使用情景
            • 资源使用率不均：例如某周需要10名测试人员，但后续周仅需2名
            • 减少资源浪费：避免资源在高峰期被过度占用，低谷期闲置
            • 预算控制：在固定成本下，尽量保持资源需求平稳
          • 案例
            • 某建筑项目中，通过将非关键路径的室内装修任务推迟1周，使工人数量从峰值30人降至平均20人
        • 资源平衡 Resource Leveling
          • 定义
            • 通过调整活动的开始/结束日期，使资源需求与供给匹配，消除资源过度分配或短缺问题
          • 核心特点
            • 可能改变项目的关键路径，通常导致项目总工期延长
            • 适用于资源严重受限的场景（如关键资源数量有限、仅在特定时间可用）
            • 用于项目计划阶段，确保资源全局均衡分配
          • 典型使用情景
            • 资源冲突：例如同一工程师被同时分配到多个并行任务。
            • 政策限制：如某设备每天最多使用8小时，需重新安排任务时间。
            • 优先级调整：当关键路径活动资源不足时，需从非关键路径调用资源。
          • 案例
            • 某IT项目中，若开发人员仅3名，但需同时完成5个模块开发，需通过资源平衡将部分非关键模块延后
        • 资源平衡&平滑核心区别总结
          • 资源平衡解决资源冲突的“硬限制”，资源平滑优化资源使用的“软需求
    • 进度压缩
      • 引申
        • 赶工 Crashing
          • 以最小成本代价，加资源压缩进度工期
        • 快速跟进 Fast Tracking
          • 将按顺序进行的活动改为部分并行开展
          • 减少时间表，但增加风险
        • 不缺资源情况下适用
      • 衡量项目健康度的核心指标
        • CPI
          • Cost Performance Index
          • 公式：CPI = EV（已获价值） / AC（实际成本）
          • 本质：反映每花费1元实际产生多少预算价值
          • 阈值判断
            • ▪ CPI >1：成本结余（例：花90万完成100万预算工作）
            • ▪ CPI=1：成本符合预期
            • ▪ CPI <1：成本超支（例：花110万仅完成90万预算工作）
        • SPI
          • Schedule Performance Index
          • 公式：SPI = EV（已获价值） / PV（计划价值）
          • 本质：反映实际进度与计划进度的比率
            • 进度比率
          • 阈值判断
            • ▪ SPI >1：进度超前（例：3天完成计划5天任务）
            • ▪ SPI=1：进度符合预期
            • ▪ SPI <1：进度滞后（例：5天仅完成3天计划任务）
    • 进度基准
      • 甘特图
• 项目成本管理
  • 规划成本管理
    • 成本管理计划
    • 估算成本
      • 估算精度
        • 粗略量级估算区间为-25% 到 +75%，确定性估算区间可缩小至-5% 到 +10%
    • 制定预算
      • 应急储备与管理储备
        • 应急储备已经包含在了项目预算当中，动用也不会影响项目预算。而管理储备是在成本基准之外的，一旦动用，需要通过变更的方式调整到成本基准当中，影响预算
      • 成本基准
        • 成本基准是经过批准的、按时间段分配的项目预算,不包括任何管理储备,只有通过正式的变更控制程序才能变更,用作与实际结果进行比较的依据。
  • 控制成本
    • 收集数据--挣值分析
      • 挣值四大基础概念
        • BAC:完工预算
          • Budget at Completion
          • 成本基准
          • 按照原计划，完成所有工作所需的预算成本
        • PV:计划价值
          • Planned Value
          • 应该完成多少工作
            • 按照计划截止目前应该花费的预算
            • 只与时间有关
        • EV:挣值
          • Earned Value
          • 已经完成了多少预算的工作
            • 实际完成的工作，按照预算标准应该有的花费
            • 只与进度有关
        • AC:实际成本
          • Actual Cost
          • 完成工作的实际成本是多少
      • 挣值管理（Earned Value Management, EVM
        • 是项目成本与进度控制的核心工具，通过整合范围、时间和成本数据，量化评估项目绩效
      • 挣值曲线/S曲线
        • 该曲线可对累计值进行监督和报告，可同时报告成本与进度情况。适用于预测和敏捷项目
    • 对比偏差--偏差分析
      • SV=EV-PV(进度偏差SV：SV>0 提前，SV<0 落后)
        • Schedule Variance
      • CV=EV-AC(成本偏差CV：CV>0 节约，CV<0超支)
        • Cost Variance
      • SPI=EV/PV(进度绩效指数SPI：SPI>1提前，SPI<1落后);
        • Schedule Performance Index
      • CPI=EV/AC(成本绩效指数CPI：CPI>1节约，CPI<1超支)
        • Cost Performance Index
        • 案例：计划10万干10天，第5天干了6天活，花了8万，CPI为多少？
          • EV=6 PV=5
      • 小于1都是坏事儿
    • 评估趋势--趋势分析
      • 完工估算EAC
        • 当前偏差不具备代表性EAC=AC+(BAC-EV)
        • 当前偏差具备代表性EAC=BAC/CPI
        • 最初计划不再有效EAC=AC+自下而上的估算
        • SPI与CPI均会影响,EAC=BAC/(SPI*CP1)
      • 完工尚需估算ETC
      • 完工尚需绩效指数: TCPI
• 项目质量管理
  • 规划质量管理-规划
    • 质量
      • 定义：一系列固有特性满足要求的程度。
    • 质量成本
      • 一致性成本
        • 定义
          • 项目花费资金规避失败
          • 一致即和项目目标保持一致
        • 分类
          • 预防成本
            • 通过打造某种高质量产品，预防产品失败
            • 如培训、文件过程、设备
          • 评估成本
            • 如做一些破坏性测试评估产品质量
            • 如测试、破坏性试验损失
      • 不一致性成本
        • 定义
          • 项目前后由于失败花费的资金
          • 项目目标不一致
        • 分类
          • 内部失败成本
            • 团队内部发现的返工和报废
            • 如返工和报废
          • 外部失败成本
            • 客户发现的产品失败
    • 质量管理计划
      • 定义
        • 质量管理计划描述如何实施适用的政策、程序和指南以实现质量目标。
      • 内容
        • 质量管理计划中定义了项目的质量标准与质量目标,以及其他与质量相关的程序（质量改进）。
  • 管理质量-执行
    • 图工具
      • 因果图
        • 石川图、鱼骨图、Why-Why分析图,将原因分解为离散的分支,识别根本原因
      • 直方图/帕累托图
        • 用于识别造成大多数问题的少数重要原因（二八原则）
      • 散点图
        • 展示两个变量之间关系
    • 审计
      • 定义
        • 审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。
        • 有好的结果不一定存在好的过程
      • 好处颇多
        • 降低质量成本，获取经验教训
    • 面向X的设计
      • 定义
        • 面向 X 的设计(DfX)是产品设计期间可采用的一系列技术指南，旨在优化设计的特定方面,可以控制或提高产品最终特性。
  • 控制质量-监控
    • 核对单 Checklist
      • 核对单有助于以结构化方式管理控制质量活动。
      • 核对单最大的作用，就是防止遗漏
        • 如旅行前物品清单
    • 核查表 Check sheet
      • 又称计数表,用于合理排列各种事项,以便有效地收集关于潜在质量问题的有用数据。
      • 核查表最大的作用,就是可以计数。
    • 控制图
      • 用于确定一个过程是否稳定，或是否具有可预测的绩效
      • 规格上下限一旦超过则出现不良。控制上下限一旦超过,则需要关注或分析。
• 项目资源管理
  • 规划资源管理
    • 层级型
      • 使用组织结构图，自上而下地显示角色与职责
      • 工作分解结构(WBS)
        • 基于事的角度，在细分的任务下分配负责的人员
        • 有助于明确高层级职责
      • 组织分解结构(OBS)
        • 在每一个组织部门下方划分对应的工作包
        • 采取部门架构，助于每个部门清晰看到自己职责
      • 资源分解结构(RBS)
        • 按资源分类展示，直到可接合WBS
    • 责任分配矩阵(RAM)
      • 最典型RAM即RACI
      • 若团队由内部和外部人员组成，RACI便极其有用
    • 资源管理计划
      • 资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南
      • 包括的内容
        • 识别资源方法、获取资源的指南、角色与职责、项目团队资源管理、项目组织图、团队建设的方法、资源控制的方法、认可计划
    • 团队章程(高频考点)
      • 团队章程是为团队创建团队价值观、共识和工作指南的文件。
  • 估算活动资源
    • 资源日历
      • 识别了每种具体资源可用时的工作日、班次、上下班时间、周末和公共假期。
      • 资源日历规定了在项目期间确定的团队和实物资源何时可用、可用多久。
  • 获取资源-要人
    • 谈判
      • 不能获得项目所需的资源时,可能会影响项目进度、预算、客户满意度、质量和风险;资源或人员能力不足会降低项目成功的概率,最坏的情况可能导致项目取消。
      • 谈判对象
        • 职能经理、其他项目的项目经理、外部组织和供应商
    • 虚拟团队
      • 具有共同目标、在完成角色任务的过程中很少或没有时间面对面工作的一群人
      • 虚拟团队考试重点
        • 虚拟团队的不同表述
          • 分布式团队、分散团队、地理位置分散、不同国家、居家办公、虚拟团队
        • 虚拟团队找沟通
          • 沟通技术(优先选)、沟通管理计划、沟通需求、网络工具、虚拟会议、沟通技能
  • 建设团队
    • 塔克曼阶梯理论-Tuckman Team Model
      • 组建期/形成阶段（Forming）
        • 特点：团队初建，成员相互试探，角色模糊，依赖性强。
        • 行为表现
          • 成员礼貌但疏离，存在焦虑感（如“不知道该做什么”）
          • 对任务目标有初步认知但缺乏清晰行动路径
        • 领导策略
          • 指导式管理：事无巨细，明确角色分工、任务目标及流程规范
          • 示例：项目经理通过启动会议展示项目章程，分发岗位说明书
        • 也即形成阶段，新成员加入后也属于该阶段
        • 关键词
          • 独立、自我、不引发冲突、组建
      • 2. 震荡期（Storming）
        • 特点：矛盾集中爆发，团队面临信任危机与效率低谷。
        • 行为表现
          • 成员因工作习惯、理念差异产生冲突（如开发与测试团队对工期的争执）
          • 质疑团队目标或他人能力，出现“小团体”分化
        • 领导策略
          • 教练式引导：强硬些，主动调解冲突，强调共同目标（如组织需求评审会协调利益）
          • 示例：项目经理使用“冲突解决技术”中的合作/妥协方法化解分歧
        • 关键词
          • 冲突、反对、争执、质疑不信任
      • 3. 规范阶段（Norming）
        • 特点：建立协作规则，团队凝聚力增强。
        • 行为表现
          • 成员主动调整行为适应团队（如自发制定代码审查流程）
          • 出现非正式沟通渠道（如团队内部表情包文化）
          • 喜欢互动
        • 领导策略
          • 参与式支持：PM应参与到具体的每一个事中，授权部分决策权，强化正向反馈（如设立“最佳协作奖”）
          • 示例：项目经理推动团队自组织每日站会，仅参与关键节点决策
        • 关键词
          • 信任、开始建立、规范、喜欢互动
      • 4. 成熟期（Performing）
        • 特点：团队高效自治，产出达到峰值。
        • 行为表现
          • 成员跨职能协作（如测试工程师主动协助排查生产环境问题）
          • 无需监督即可快速响应变化（如敏捷团队自主调整迭代计划）
        • 领导策略
          • 委任式放权：放权委托，聚焦战略层面，提供资源支持（如协调跨部门资源）
          • 示例：项目经理将80%精力投入风险管控，仅审核里程碑成果
        • 关键词
          • 组织有序、相互协助
      • 5. 解散期（Adjourning）
        • 特点：任务完成，团队面临情感疏离与动力下降。
        • 行为表现
          • 成员出现“项目后倦怠”（如提交代码频率降低）
          • 对后续安排存在不确定性焦虑
        • 领导策略
          • 情感维系与知识沉淀
            • 举办结项仪式并颁发纪念品
            • 组织经验教训总结会，归档文档至组织过程资产
        • 关键词
          • 结束
    • 建设团队工具
      • 集中办公
        • 集中办公能够增进沟通,增强集体感。
        • 临近性、曝光效应
      • 沟通技术
        • 用于项目干系人之间传递信息的特定工具、系统或计算机程序等。
      • 团建
        • 团队建设是通过举办各种活动,强化团队的社交关系,打造积极合作的工作环境。
      • 认可与奖励
        • 在建设项目团队过程中,需要对成员的优良行为给予认可与奖励。
        • 注意
          • 1. 奖励计划在《资源管理计划》中
          • 2. 只有能满足被奖励者某个重要需求的奖励才是有效的
          • 3. 金钱是有形奖励
          • 4. 无形奖励更有效：成长计划、成就感、赞赏
          • 5. 需在项目过程中给予奖励，而非项目完成时
      • 培训
        • 培训包括旨在提高项目团队成员能力的全部活动
        • 团队成员培训内容对应负责人
          • 需培训项目管理的知识和技能
            • 项目经理负责
          • 需培训业务技术和专业技能
            • 职能经理负责
          • 需培训公司管理规章制度
            • 人力资源部负责
  • 团队效绩评价
    • 项目管理团队应该对项目团队的有效性进行正式或非正式的评价。
    • 团队绩效是指团队本身的凝聚力、离职率等指标。
    • 综上团建手段都是为使团队尽快步入塔克曼理论的成熟阶段，增加团队凝聚力
  • 管理团队
    • 通过跟踪团队成员绩效、管理冲突等方式确保团队成员能够有意愿和能力完成工作
    • 冲突管理
      • 定义
        • 在项目环境中,冲突不可避免。项目经理要善于处理冲突。
      • 来源
        • 资源稀缺、进度优先级、意见分歧
      • 冲突解决关键步骤
        • 自行解决→私下合作→正式程序
      • 冲突解决技术
        • 1. 合作/解决问题（Collaborating/Problem Solving）
          • 特点
            • 双赢策略，通过公开对话整合多方意见，达成共识。
          • 适用场景
            • 需长期解决方案、涉及核心利益冲突、团队信任度较高时。
          • 例
            • 团队成员就技术方案争执不下，项目经理组织会议分析各方案优缺点，最终综合形成新方案。
          • 结果
            • 双赢
        • 2. 面对/直面（Confronting）
          • 特点
            • 直接选择某一方方案，放弃其他方案。
          • 适用场景
            • 时间紧迫且某一方案明显更优时。
          • 例
            • 项目进度严重滞后，项目经理基于数据分析强制采用某成员的高效方案。
        • 3. 妥协/调解（Compromising）
          • 特点
            • 双方部分让步，实现暂时性平衡（双输中的部分共赢）。
          • 适用场景
            • 冲突双方势均力敌且需快速推进项目时。
          • 例
            • 开发与测试团队就上线时间争执，最终各让一步：开发提前3天交付，测试压缩2天周期。
          • 结果
            • 双赢或双输
        • 4. 缓和/包容（Smoothing/Accommodating）
          • 特点
            • 强调共同目标，弱化分歧（对事不利但对人有利）
          • 适用场景
            • 维护关系比解决问题更优先的非原则性冲突
          • 例
            • 设计师与产品经理对界面风格意见不合，项目经理先表扬双方创意，再建议后续优化。
          • 结果
            • 冲突依然存在
        • 5. 撤退/回避（Withdrawing/Avoiding）
          • 特点
            • 暂时搁置问题或转移责任人。
          • 适用场景
            • 冲突激烈需冷静期，或问题优先级较低时。
          • 例
            • 两名资深工程师激烈争论架构设计，项目经理暂缓讨论并安排技术委员会评估。
          • 结果
            • 未解决问题
        • 6. 强迫/命令（Forcing）
          • 特点
            • 利用职权快速决策（赢输局面）
          • 适用场景
            • 紧急突发事件或涉及合规性争议时。
          • 例
            • 安全事故发生后，项目经理直接叫停当前施工流程并强制执行新安全规范。
          • 结果
            • 输赢
      • 应试选择策略
        • 默认首选合作/解决问题（80%考题适用），尤其涉及跨部门、多角色协作时。
        • 强迫用于紧急场景（如合规风险、工期红线）， 妥协适合短期平衡、回避适用非关键冲突
        • 考试中若出现“开会讨论”“综合分析”等关键词，通常指向合作/解决问题；出现“立即执行”“权力强制”则对应强迫。
      • 冲突级别-拓展
        • 解决问题
          • 语言开放并基于事实，信息的分享
        • 争执
          • 个人保护胜过协作；言语是戒备的，但允许解释
        • 争辩
          • 胜利重于解决，言语包含个人攻击
        • 圣战
          • 保护自己族群成了焦点目的，语言具备意识形态
        • 世界大战
          • 很少或没有言语交流，目的即毁灭对方
    • 情商
      • 识别自己和他人情绪的能力
      • (包括:自我意识、自我管理、社交意识、社交技能)
• 项目沟通管理
  • 概念
    • 包括通过开发工件,以及执行用于有效交换信息的各种活动,来确保项目及其干系人的信息需求得以满足的各个过程。
    • 沟通的本质是项目信息的正确传递
    • 引申补充
      • 在项目管理实践中,项目经理大部分精力都在沟通
      • 干系人越多,沟通越复杂,如有N个干系人,则沟通渠道有N*(N-1)/2个
      • 沟通活动的分类
        • 1. 内部与外部:内部团队与外部干系人沟通。
        • 2. 正式与非正式
        • 3. 向上、向下、橫向沟通
        • 4. 书面与口头沟通
  • 规划沟通管理
    • 沟通模型
      • 发送方和接收方之间的信息理解被多因素影响。
        • 发送方负责信息传递，确保信息的清晰性和完整性，并确认信息已被正确理解
        • 接收方负责完整接收信息并正确理解，并告知已收到或作出适当回应
    • 沟通方法-信息传递方向
      • 推式沟通
        • 定义
          • 单向推送信息至特定受众，如邮件、报告、通知等
        • 适用情况
          • 1. 信息发布与合规
            • 需确保关键信息传达到位（如项目状态报告、合同条款变更通知）
          • 2. 受众明确且被动接收
            • 向固定相关方推送定期更新（如每周进度邮件发送给发起人
          • 3. 低互动需求
            • 无需即时反馈的公告类信息（如政策变更、流程调整）
        • 限制
          • 无法验证接收者是否理解信息（如邮件未读或误读风险）
      • 拉式沟通
        • 定义
          • 接收者主动获取信息，如知识库、企业内网、文档管理系统
        • 适用情况
          • 信息量大且受众分散
            • 项目文档、培训资料、历史经验库（如团队成员自主查阅技术规范
          • 长期参考需求
            • 需长期保存并随时调用的信息（如项目章程、风险管理计划）
          • 跨项目复用
            • 组织级资产库（如敏捷项目的迭代回顾会议记录供其他团队参考）
        • 限制
          • 依赖接收者主动性，可能导致信息滞后（如未及时更新文档引发误解
      • 交互式沟通
        • 定义
          • 实时双向或多向交流，如会议、视频通话、即时消息等
        • 适用情况
          • 复杂决策或争议解决：需多方实时讨论并达成共识（如需求变更会议、风险应对方案研讨）。
          • 团队协作：敏捷项目中的每日站会、迭代评审会议（如Scrum团队演示可交付成果
          • 建立信任：新团队组建或跨部门合作初期，通过面对面交流消除误解。
        • 限制
          • 依赖参与者时间同步，不适用于分散时区团队或信息存档需求高的场景
    • 文化意识
      • 文化意识指理解个人、群体和组织之间的差异,并据此调整项目的沟通策略。
      • 文化意识相同是冲突管理的前提，两波完全不同的人需要处理的是文化意识上的差异冲突
    • 沟通管理计划
      • 沟通管理计划是项目管理计划的组成部分,描述将如何规划,结构化、执行与监督项目沟通,以提高沟通的有效性。
    • 总结
      • 基于团队与干系人沟通需求,制定沟通管理计划,以确定把什么信息在什么时间以什么方式传递给什么人
  • 管理沟通
    • 沟通技能
      • 沟通胜任力：经过裁剪的沟通技能组合
      • 反馈：项目经理关于沟通的反馈能力
      • 非口头技能：肢体语言/表情
      • 演示：PPT演讲能力
• 项目风险管理
  • 风险是什么
    • 定义
      • 一旦发生，会对一个或多个项目目标产生正面或负面影响的不确定事件或条件
    • 最重要的三要素是:
      • 事件、影响、概率
    • 风险与VUCA(广义的不确定性）
      • 模糊性、复杂性、易变性
  • 规划风险管理
    • 风险管理计划
      • 描述如何安排与实施风险管理活动
    • 风险的临界值与敞口
      • 风险临界值:干系人能够接受的风险程度,敞口超出临界值,则直接终止项目
      • 风险敞口:实际暴露的风险大小,在临界值内可接受,超出临界值不可接受
    • 规划风险管理总结
      • 对项目章程与于系人进行分析,确定其风险的接受程度,制定风险管理计划,以确立风险的临界值以及整体的管理方法论
  • 识别风险
    • 识别风险方法
      • SWOT分析(S优势 W劣势 O机会 T威胁)
      • 核对单分析 Checklist analysis
      • 敏感性分析（Sensitivity Analysis）
        • 敏感性分析通过量化不确定性因素（如成本、进度、资源、技术等）的变化对项目目标（如净现值NPV、内部收益率IRR、投资回收期等）的影响程度，帮助项目团队
          • 识别关键风险因素
          • 评估影响范围
          • 支持决策制定
        • 其典型表现形式为龙卷风图（Tornado Diagram），通过条形图按影响程度排序展示各因素的重要性
    • 提示清单
      • 提示清单是关于可能引发单个项目风险以及可作为整体项目风险来源的风险类别的预设清单。
    • 识别风险总结
      • 基于项目的假设、制约、估算文件、经验教训等文件,使用头脑风暴、核对单、SWOT分析等工具,对项目的风险进行全方位的识别。
  • 实施定性风险分析
    • 风险数据质量评估
    • 风险概率影响矩阵
    • 实施定量风险分析(第一步:建模)
      • 蒙特卡洛分析
  • 规划风险应对
    • 风险应对策略
      • 负面威胁应对策略
        • 风险上报&接受
          • 上报 Escalation
            • 风险超出项目经理权限时，提交给更高层决策
            • 项目涉及政策变动风险，需由公司高层与政府沟通解决
            • 适用：风险涉及组织战略或外部因素，项目经理无法独立处理
              • 如影响到多个项目资源的使用
              • 如不可预见的新风险
            • 关键字
              • 超出权限/范围
          • 接受 Acceptance
            • 承认风险存在，但不主动干预，而是准备应急计划
            • 项目预算中预留“应急储备金”，若风险发生则用这笔钱应对
            • 适用：风险影响较小，或应对成本高于风险本身带来的损失
            • 关键字
              • 接受/不在处理
              • 建立应急储备、定期审查不采取行动
        • 风险规避 Avoidance
          • 直接绕开风险，让风险无法发生
          • 项目原计划在雨季施工，为避免天气延误风险，改为提前施工
          • 适用：风险发生概率高且影响严重，可通过调整计划、范围或技术手段消除根源
          • 关键字
            • 消除威胁/严重影响
        • 风险减轻 Mitigation
          • 降低风险发生的概率或减轻后果
          • 软件开发中增加测试次数，减少上线后出现重大漏洞的可能性
          • 适用：风险无法完全消除，但可以通过预防措施（如冗余设计、培训）降低影响
          • 关键字
            • 多次测试/增加资源/降低影响/减少概率
        • 风险转移 Transfer
          • 把风险“甩锅”给第三方，让其他人承担后果
          • 为关键设备购买保险，如果设备损坏，保险公司负责赔偿
          • 适用：风险发生概率低但影响大，且可通过合同、保险等经济手段转移责任
          • 关键字
            • 保险/担保/外包
      • 正面机会应对策略
        • 风险上报&接受
        • 风险开拓 Exploit
          • 将特定机会出现的概率提高到100%确保其肯定出现
          • 发现新技术可缩短工期，额外投入资源加速研发。
          • 适用场景：机会的收益明显，且团队有能力实现
          • 关键字
            • 确保、100%
            • 分配最有能力的资源、使用全新技术
        • 风险增强/提高 Enhance
          • 增加机会发生的概率或扩大其积极影响
          • 通过市场调研优化产品功能，提升客户满意度
          • 适用场景：机会存在但概率或影响不足，需主动优化条件
          • 关键字
            • 为早日完成活动增加资源
        • 风险分享 Share
          • 与其他方合作，共同抓住机会
          • 与供应商签订分成协议，共同开发新产品市场
          • 适用场景：机会需要多方协作才能最大化收益
          • 关键字
            • 合资
            • 建立合伙关系、合作团队、特殊公司、合资企业
        • Enhance和Exploit区别
          • 增强是增加几率，没到100%，开拓是直接干到100%
      • 应急应对
        • 存在一个风险的触发，随即采取应急应对措施
      • 整体应对
      • 核心区别总结
        • 负面风险：要么“躲”（规避）、要么“甩”（转移）、要么“防”（减轻）、要么“认”（接受）
        • 正面机会：要么“抢”（开拓）、要么“放大”（提高）、要么“分钱”（分享）
    • 实施风险应对
  • 监督风险
    • 风险审计
  • 总结
• 项目采购管理
  • :项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。
  • 规划采购管理-组织过程资产
    • 合同类型(重点)
      • 三大类七小类合同
        • 总价类-明码标价，风险可控
          • 固定总价
            • FFP，Fixed-Price Contracts
            • 价格完全固定，仅当需求变更（如加购配件）时调整
            • 买方/甲方风险最小，卖方需承担成本超支风险
            • 适用
              • 需求明确的项目（如标准软件开发）
          • 总价加激励费用合同
            • FPIF，Fixed Price Incentive Fee
            • 类比
              • 打车设定一口价，司机若提前到达可得奖金
            • 特点
              • 基础价格固定，但根据绩效（如提前交付）增减费用
            • 适用
              • 需兼顾成本控制和激励效率（如工程工期优化）
          • 总价加经济价格调整合同
            • FP-EPA，Fixed Price with Economic Price Adjustment
            • 类比
              • 签长期租房合同，租金随通胀指数每年微调
            • 特点
              • 允许因通货膨胀等经济因素调整总价
            • 适用
              • 长期合作项目（如3年设备维护合同）
          • 甲方风险最低（FFP风险最小），乙方需自行消化超支
        • 成本补偿合同-实报实销，灵活应对
          • 成本加固定费用合同
            • CPFF，Cost Plus Fixed Fee
            • 类比
              • 请装修队，材料费全报，另付固定人工费
            • 特点
              • 报销实际成本+固定利润，卖方风险较低，买方需监督成本
              • 利润固定，成本实报实销
            • 适用
              • 高风险探索性项目（如新药研发）
          • 成本加激励费用合同
            • CPIF，Cost Plus Incentive Fee
            • 类比
              • 装修时约定预算100万，省下的钱双方分成
            • 特点
              • 设定目标成本，超支/节支按比例分摊激励费用
            • 适用
              • 需平衡成本与质量的合作（如定制化产品开发
          • 成本加奖励费用合同
            • CPAF，Cost Plus Award Fee
            • 类比
              • 家政服务结束后，根据满意度支付额外奖金
            • 特点
              • 基于买方主观评价支付奖励费，常用于研发类项目
              • 利润基于主观评价（如甲方满意度）
            • 适用
              • 难以量化绩效的领域（如咨询服务）
          • 甲方风险最高（CPFF风险最大），但适合需求模糊的项目
        • 工料合同
          • T&M，Time and Material Contract
          • 按工时/材料量计价，适用于短期或范围不明确的项目
          • 可行性研究，不确定性较大
          • 甲乙双方风险均摊，常用于快速启动但范围不确定的项目
    • 自制外购分析
      • 在自制或外购分析中，可以使用回收期、投资回报率(ROI)或其他分析技术，来确定某种货物或服务是应该在项目内部自制,还是从外部购买。
    • 招标文件
      • 招标文件用于向潜在卖方征求建议书
      • 注意区分三类招标文件
        • 信息邀请书 RFI
          • Request for Information
          • 需要卖方提供更多信息
        • 报价邀请书 RFQ
          • Request for Quotation
          • 买方明确产品型号/规格/数量，卖方仅需提供报价。流程最简化，常用于比价采购
        • 建议邀请书 RFP
          • Request for Proposal
          • 买方仅提出目标/功能需求，卖方需自主设计完整技术方案并报价。侧重综合能力评估，创新空间大
    • 采购工作说明书SOW
      • SOW会充分详细地描述拟采购的产品、服务或成果,以便潜在卖方确定是否有能力提供此类产品、服务或成果。
      • 甲方依据自己的范围基准,详细描述自己想买的产品。
      • 总结
        • SOW是对最终可交付成果的详细描述
    • 供方选择标准
      • 甲方依据自己对某些方面的重视程度,赋予不同权重。如,更重视价格,可以增加价格的权重。
    • 独立成本估算
      • 项目经理与采购部门需要具有一定的专业性,一旦与独立估算结果存在明显差异,则需要进一步分析原因
  • 实施采购
    • 投标人会议
      • 在卖方提交建议书之前,在买方和潜在卖方之间召开的会议。
      • 目的是确保所有潜在投标人对采购要求都有清楚且一致的理解,并确保没有任何投标人会得到特别优待。
      • 投标人会议两个作用：确保对采购要求的理解；保证公平。
    • 协议
  • 控制采购
    • 索赔管理
      • 定义
        • 如果买卖双方不能就变更补偿达成一致意见,或对变更是否发生存在分歧,那么被请求的变更就成为有争议的变更或潜在的推定变更。此类有争议的变更称为索赔。
      • 解析
        • 采购中经常会有甲方口头向乙方提出变更需求，乙方执行后向甲方索要费用失败的案例。
      • 谈判→ADR→法院
        • 谈判是解决所有索赔和争议的首选方法
        • ADR 替代争议解决方法
          • Alternative Dispute Resolution
          • 适用领域
            • 项目采购管理中的合同纠纷处理
          • 核心作用
            • 通过非诉讼方式解决合同双方争议，常见于合同执行阶段的索赔或纠纷。
          • 常见形式
            • 调解（Mediation）：由第三方协助双方自愿达成协议（无强制约束力）。
            • 仲裁（Arbitration）：由第三方作出裁决（通常具有法律约束力）
    • 绩效审查
      • 对照协议,对质量、资源、进度和成本绩效进行测量、比较和分析,以审查合同工作的绩效。
    • 采购审计
      • 是对采购过程的结构化审查
    • 控制采购总结
      • 依据合同,监督采购的执行情况,并处理一些采购争议,最后成功结束采购。
• 项目干系人管理
  • 识别干系人
    • 干系人 Stakeholder
      • 干系人的本质
        • 任何与项目有关联（出钱、出力、受影响）的人，都是干系人
        • 能影响项目决策、活动或结果的人
      • 干系人的关键特征
        • (1) 利益与权力的“双维度”
          • 高权力+高利益
            • 你（发起人）——决定目的地和预算，直接承担旅行结果。
          • 高权力+低利益
            • 配偶（项目发起人的领导）——对预算有一票否决权，但对行程安排兴趣不大。
          • 低权力+高利益
            • 孩子（用户代表）——对迪士尼乐园有强烈需求，但无法决定是否去。
          • 低权力+低利益
            • 邻居（被动干系人）——只需知道出发时间帮忙收快递。
        • (2) 动态变化性
          • 旅行前
            • 旅行社是重要干系人（负责订票）
          • 旅行中
            • 酒店前台变为关键干系人（影响住宿体验）
          • 旅行后
            • 同事可能成为新干系人（想看旅行照片）
      • 干系人管理的生活化逻辑
        • (1) 识别干系人——“谁会来掺和？”
          • 列清单：谁出钱？谁提要求？谁会抱怨？谁帮忙？
          • 如：不识别“孩子想去迪士尼”的需求，可能导致家庭矛盾（项目验收失败）。
        • (2) 分类管理——“区别对待”
          • 重点管理：每天向配偶汇报预算使用情况（高权力+高利益）；
          • 随时告知：出发前通知邻居具体日期（低权力+低利益）；
          • 保持满意：给孩子买迪士尼门票（高利益需求必须满足）。
        • (3) 期望管理——“提前打预防针”
          • 提前告诉孩子：“如果下雨，迪士尼可能取消”（管理范围变更预期）；
          • 向父母承诺：“全程人均不超过3000元”（明确成本基准）。
      • 考试中易混淆的点
        • 干系人 ≠ 项目成员：旅行社不是你的团队成员，但属于关键外部干系人
        • 被动干系人也要管理：不通知邻居可能导致快递丢失（看似无关的人也会影响项目）
        • 态度会变化：原本支持旅行的配偶，可能因工作安排突然反对（需持续监督干系人参与
      • 临床试验项目中的关键干系人（按影响力排行）
        • 1. 发起人/申办方：药企或研究机构，提供资金并承担最终责任
        • 2. 研究者/临床医生：直接执行试验，负责医学判断（参考内容第六条明确其决策权）
        • 3. 受试者（患者）：核心参与者，其安全性和数据质量直接影响试验结果
        • 4. 伦理委员会：审批试验方案，监督是否符合伦理规范
        • 5. 监管机构（如国家药监局）：审批试验许可，监督合规性
        • 6. 数据监查委员会（DMC）：独立评估试验数据安全性及有效性
        • 7. 合同研究组织（CRO）：外包执行部分试验流程（如数据管理）
        • 8. 医院/机构管理层：提供场地、设备及行政支持
    • 干系人分析
      • 定义
        • 干系人分析会产生干系人清单和关于干系人的各种信息。
      • 解析
        • 通过干系人的分析，了解干系人的基本信息并记录。
        • 兴趣、权利、所有权、知识、贡献
        • 例如，在组织内的位置、在项目中的角色、与项目的利害关系、期望、态度（对项目的支持程度），以及对项目信息的兴趣
      • 干系人映射分析
        • 权力/利益方格，权力影响方格，凸显模型
          • 凸显模型 Salience Model
            • 用处
              • 通过综合分析干系人三个维度评估其优先级
            • 干系人评级
              • 权力 Power：对项目决策或资源有较大影响力；
              • 紧迫性 Urgency：需求或问题需要被及时响应；
              • 合法性 Legitimacy：与项目有正式或合理的关联性
        • 记录到干系人登记册
        • 先进行干系人分析，再更新参与计划
      • 为什么面对客户内部不配合，执行干系人分析是问题解决关键？
        • 1. 识别核心决策者与潜在阻力来源
          • 客户公司内部不同层级的干系人可能对项目目标、优先级或执行方式存在分歧。通过干系人分析，可明确：
          • 哪些人是关键决策者（如高层管理者），哪些人仅是执行层；
          • 不配合的根源是对项目方向不满、个人利益受损，还是信息传递偏差；
          • 干系人的权力、影响力和态度（支持、中立或反对），进而优先处理高影响力但低支持的群体。
        • 2. 制定差异化沟通与管理策略
          • 不同层级的干系人对项目的关注点可能截然不同。例如：
          • 高层关注战略价值与投资回报；
          • 中层关注流程合规性与部门利益；
          • 执行层关注任务难度与资源支持。
          • 通过分析，可定制沟通内容（如对高层强调商业价值，对执行层提供技术指导），减少信息错配导致的抵触。
        • 3. 预防风险并推动共识
          • 干系人分析能提前识别潜在冲突点。例如：
          • 某部门因项目影响其绩效考核而消极应对；
          • 跨部门协作因权责不清导致推诿。
          • 通过早期介入（如谈判、调整项目计划），可协调利益分歧，避免问题升级为项目延误。
        • 4. 优化资源分配与优先级
          • 当资源有限时，需集中力量争取关键干系人的支持。例如：
          • 对高权力且高兴趣的干系人（如项目发起人），需频繁汇报进展；
          • 对低兴趣但有否决权的干系人（如合规部门），需满足其基本要求以避免阻碍。
        • 5. 总结
          • 干系人分析的本质是通过系统性识别、评估和管理各方利益关系，将“人的问题”转化为可操作的解决方案，从而降低项目阻力，提升协作效率。这一过程贯穿项目全生命周期，是PMP强调的核心能力之一。
    • 需要重新识别干系人的几大情况
      • 1. 项目进入生命周期的不同阶段
      • 2. 当前干系人不再与项目工作有关/干系人社区出现新的干系人
      • 3. 组织内部干系人社区发生重大变化
  • 规划干系人参与
    • 干系人参与计划
      • Stakeholder Engagement Plan）是项目干系人管理的核心输出，旨在制定有效策略以引导干系人合理参与项目
      • 具体内容
        • 1. 干系人分类与优先级
          • 干系人登记册：记录干系人身份信息、利益、影响力和分类（如权力/利益矩阵、凸显模型）。
          • 优先级排序：基于干系人的利益、权力、影响程度，确定关键干系人及其管理优先级（如高权力高利益干系人需重点管理
        • 2. 参与策略与行动方案
          • 参与度差距分析：使用 干系人参与度评估矩阵 ，对比当前参与水平（C）与期望参与水平（D），例如：
            • 不了解型→ 领导型 ：需通过沟通提升认知；
            • 抵制型→ 支持型 ：需谈判或调整策略减少阻力。
          • 具体策略：针对不同干系人群体制定策略
            • 抵制型：通过利益协调或风险缓解降低反对；
            • 中立型：通过定期沟通转化为支持者；
            • 领导型：赋予决策权以维持其参与。
        • 3. 沟通与信息管理
          • 沟通方式：明确信息传递的渠道（如邮件、会议）、频率（如周报、里程碑会议）及责任人。
          • 信息内容：定义干系人需接收的特定信息（如项目进展、风险状态、变更影响）。
          • 反馈机制：设置干系人反馈收集方式（如调查、一对一访谈），确保双向沟通。
        • 4. 变更与冲突应对机制
          • 变更管理：规定干系人提出变更的流程（如变更请求路径）、审批角色（如发起人、CCB）。
          • 冲突解决：预设冲突处理策略（如协商、妥协），并明确冲突升级路径。
        • 5. 参与计划动态调整
          • 监控机制：定期审查干系人参与度（如通过绩效审查、参与度矩阵更新），识别偏差。
          • 触发更新条件：包括项目阶段变更、干系人群体变化（如新增/退出）、外部环境变化（如政策调整）。
        • 6. 与其他计划的关联
          • 资源管理计划：明确干系人角色与职责（如风险责任人、活动执行人）。
          • 风险管理计划：将干系人相关风险（如抵制、期望偏差）纳入应对策略。
          • 沟通管理计划：细化干系人沟通依赖关系，避免信息遗漏或重复。
        • 7. 核心工具与输出
          • 工具：干系人参与度评估矩阵、思维导图（可视化干系人关系）、根本原因分析（定位参与问题根源）。
          • 输出文档：更新后的干系人登记册、问题日志（记录干系人争议）、变更日志（关联干系人变更请求）。
      • 看一下这个干系人该不该来，或者说是不是该来没来是源于PM没通知到
    • 干系人参与度评估矩阵
  • 管理干系人参与
    • 包含内容
      • 监控干系人关系
        • 跟踪干系人的情绪变化、参与度及对项目的态度，识别潜在冲突或支持流失风险。
      • 评估参与策略有效性
        • 分析现有沟通计划、参与策略是否满足干系人需求，例如通过满意度调查或反馈会议验证。
      • 修订策略与计划
        • 根据监控结果调整干系人沟通频率、方式或内容（如升级报告路径、变更会议形式
      • 更新相关文档
        • 动态更新干系人登记册 （新增或移除干系人）、 问题日志 （记录干系人投诉或建议）及 变更日志 （因干系人需求触发的计划调整
    • 关键工具与技术
      • 干系人分析矩阵（重新评估优先级）、沟通方法审计、决策分析（如平衡多方利益冲突）以及绩效审查（如项目状态报告对干系人信心的影响）。
    • 作用
      • 避免因干系人期望偏差导致项目偏离目标，确保关键干系人持续支持，降低项目阻力
    • 案例
      • “项目发起人”做为一个关键干系人没有对项目表示出积极的态度
        • 需要对问题进行分析，然后加以解决
        • 先与干系人会面了解他的期望是正确的管理实践
          • 讨论任何话题都行，关键是借此分析清楚需求
      • 项目由于人员流动，干系人登记册经常发生变化？
        • 确保更新和沟通干系人参与计划
          • 该行动可能包括了
            • 定期与所有干系人召开面对面会议
            • 每当新的干系人加入项目时，安排一次团队建设活动
            • 让干系人在下一次团队建设活动中进行非正式自我介绍
      • 一个中型项目的项目经理最近得知一些干系人强烈反对正在实施的项目？
        • 安排干系人研讨会，以解决为何不应该执行项目的任何顾虑
        • 管理干系人参与是与干系人进行沟通和协作以满足其需求与期望、处理问题，并促进干系人合理参与的过程。在管理干系人过程中，我们可以使用会议的方式解决与干系人参与相关的问题
      • 在审查项目可交付成果时，干系人之间就是否正式接受可交付成果存在分歧？
        • 干系人参与计划是项目管理计划的组成部分。
        • 它确定用于促进干系人有效参与决策和执行的策略和行动。“是否正式接受”，没有提到是质量问题所造成的分歧。分歧的焦点是由对项目存有不同的期望，所以要从干系人管理上去解决问题，而不是从范围管理上去解决问题
      • “干系人通知新需求之前未沟通”“若要避免这个问题”
        • 干系人的需求未识别。所以需要进行干系人分析来确认干系人对项目的期望
      • 项目经理对干系人的权利和利益有了更深的了解。项目经理应将这些信息记在何处？
        • 干系人登记册或者干系人参与计划
  • 公式
    • 新的干系人加入，第一步应做
      • 发布更新联系人列表和干系人登记册的变更请求，以包含该新加入干系人
      • 向干系人展示项目状态使其了解情况
    • 干系人之间彼此存在分歧冲突，第一步
      • 首先执行干系人分析，以获取每个干系人的需求目标及期望
    • 项目存在干系人变动（不再参与）
      • 审视干系人所在社区，并更新干系人参与计划
    • 开始识别干系人需要做什么
      • 寻找识别干系人的工具以及识别干系人的产出
      • 如：将项目发起人和项目团队成员纳入干系人名单，然后举办启动研讨会，从而发现其他干系人
    • 项目启动阶段最先进行的活动永远是识别干系人
    • 项目变更后的第一步，通知所有利益相关干系人，获取其支持
    • 干系人未参加相关会议
      • 参考干系人参与计划，是否有问题或者未得到执行

Agilit

• 敏捷价值观与原则
  • 价值观
    • 个体&互动＞流程&工具
      • 让开发团队集中办公，并配备一名经过授权的产品负责人
    • 工作的软件＞详尽的文档
      • 文档勉强够用即可
        • 需要文档的场景
          • 交付文档
          • 重要决议
          • 高价值文档
          • 合规性文档
    • 客户合作＞合同谈判
      • 不限制范围变更
      • 邀请客户参加敏捷实践并知道客户
    • 响应变化＞遵守计划
  • 十二原则
    • 1. 客户价值优先
      • 持续不断尽早交付
    • 2. 拥抱需求变更
    • 3. 高频交付可运行成果
    • 4. 跨职能协作
    • 5. 激发团队自主性
    • 6. 面对面沟通优先
    • 7. 可运行成果为进度标准
    • 8. 可持续开发节奏
      • 保持稳定产出速度，避免过度加班
        • 每周40h为顶峰
    • 9. 技术卓越与设计优化
      • 技术债
        • 在采用最佳方案时进行了妥协，短期内加速但长期内增添额外开发负担
        • 管理技术债
          • 让技术债可见
          • 有债就还-下个冲刺立即改善
          • 分期偿还-多个冲刺中改善
          • 直接开一个冲刺只偿还技术债
    • 10. 减少不必要工作
      • 先试行MVP最小可行产品
    • 11. 自组织团队决策
    • 12. 定期反思与改进
      • 总结-改进-计划
• Scrum方法
  • Scrum方法整体流程：
    • 产品待办事项列表→冲刺待办事项列表→一个冲刺→可交付物增量
  • 3355
    • 三个角色
      • PO, Product Owner
        • 为团队创建待办事项列表，或者与团队共同创建
          • 同时在基于冲刺的敏捷中，产品负责人往往在冲刺中期的一次或多次会议中与团队合作，为即将进行的冲刺准备一些故事，更新待办事项列表
        • 管理需求优先级
        • 与客户沟通、规划下个冲刺内容
          • 范围问题
          • 开发团队或者SM遇到范围变更问题都优先找PO沟通
          • PO负责的对外沟通是在需求优先级、产品定义和范围上
            • 关于信息的传递问题还是SM负责
        • 接受/拒绝User Story
          • 由产品负责人负责确定工作是否完成
        • 必须存在，单人足够，对开发过程有发言权
          • 不能由开发团队人员单人
        • 核心工作定位
          • 创建待办列表并排序、确认工作优先顺序、提供反馈、指导开发方向
      • SM, Scrum Master
        • 负责流程推进、清除障碍、指导团队
          • 不可以直接替团队做决定
            • 例如团队缺乏某种培训，不能直接聘请专业培训师过来培训；而是应该与团队合作，引导他们自己发现问题
          • 确保团队的工作条件，包括工作量，是适当的和可持续的。
        • 团队工作无需向SM汇报、SM是让所有团队能够自行组织Scrum、SM无法兼任PO
        • 关于自组织团队以及为其清除障碍的矛盾点
          • 1. 对自组织的误读
            • 团队自组织并非完全不需要外部支持，而是强调决策权的下放
              • 提供工具和资源：例如引入自动化测试工具减少技术债务
              • 建立沟通桥梁：例如通过每日站会同步信息，避免信息孤岛导致障碍积累
            • 自组织团队也不能负责对外沟通
          • 2. 障碍类型的区分
            • 外部障碍（如组织政策限制、资源不足）：Scrum Master需直接介入解决
            • 内部障碍（如技术方案分歧、任务优先级争议）：Scrum Master引导团队通过协作达成共识，而非强制决策
          • 3. 矛盾化解原则
            • 80/20法则：80%的障碍由团队自行解决，20%复杂问题由Scrum Master介入
            • 透明化处理：通过看板可视化障碍状态，避免隐性风险积累
      • Develop Team
        • 3-9人小团队，通才型专家（懂开发的所有技能）专注交付、自组织团队、职能调整在冲刺后
        • 团队越小效率越高，团队越大越需要流程，而敏捷反流程
        • 开发团队十大特征
          • 自组织
          • 跨职能
          • T型技能
            • 团队同时具备广度和深度
          • 责任共担
          • 广泛沟通
          • 透明沟通
            • 最小惊讶原则
              • 充分沟通尽量不产生惊讶
          • 专注
            • 全职本项目
          • 可持续
            • 避免死亡行军
          • 稳定性
          • 规模适中
        • 开发团队可自行决定任务优先顺序
          • 需求顺序由PO决定，每个需求拆分成不同的任务由团队决定顺序
        • 还负责找到问题的根本原因
    • 三大工件（Artifacts）
      • Product Backlog（产品待办列表）
        • 产品需求列表
          • 含业务需求、技术需求及非功能需求
          • 由PO管理，排序需求
        • 每个待办事项都对客户产生价值
        • 其条目以用户故事形式呈现
      • Sprint Backlog（迭代待办列表）
        • 由开发团队管理
        • Product Backlog的子集，仅记录当前冲刺的工作
        • 将用户故事拆分成任务，团队成员主动领取
      • Increment（可交付增量）
        • 团队在冲刺阶段内完成的可交付成果，集成到以往成果形成增量式交付
        • 每次交付的用户故事须符合验收条件
        • 从技术层面交付（给PO），从管理层面发布（给用户）
      • 用户故事
        • 史诗故事拆解-PO
          • 将战略级需求拆分为用户故事，明确价值优先级
        • 故事技术细化-开发团队 + PO
          • 拆分技术任务，定义验收标准。
        • 故事优化-Scrum Master
          • 通过回顾会议调整拆分方法，确保故事可执行。
    • 五个关键事件
      • 冲刺-冲刺计划会-每日站会-冲刺评审会-冲刺回顾会
        • 鸡和猪开店出鸡蛋培根的故事
          • 鸡
            • 客户、管理者、供应商
            • 下蛋/动嘴即可
            • 计划会、回顾会可来可不来。评审会参与比重大
              • 每日站会绝对不允许鸡来
          • 猪
            • SM、PO、开发团队
            • 需要真正割肉干活儿
        • P-冲刺计划会议（Sprint Planning）
          • 目的：确定Sprint目标及可交付成果，拆解任务并分配职责
          • 选故事-拆任务-领任务
          • 时间盒：最长8小时（针对1个月Sprint）
          • 速度
            • 一个冲刺中能完成的故事点数量
            • 用于衡量能力与预测交付期限
          • 可以邀请
        • D-每日站会（Daily Scrum）
          • 目的：快速同步进度，暴露障碍，确保团队目标一致。
            • 每天都规划每一天的事儿
          • 15分钟三件事
            • ① 上次站会后完成了什么？/昨天做了什么
            • ② 下次站会前计划完成什么？/今天要做什么
            • ③ 遇到哪些障碍？/发生了哪些问题待解决
              • 每日站会只暴露问题，不展开对问题的讨论，不审查冲突
          • 角色
            • 由开发团队成员主持
            • 不邀请干系人
          • 不讨论问题
            • 只提出问题不解决问题
              • 主要就是个信息互通会，起到信息更新和同步的作用
          • 对齐
            • 更新任务版，起到沟通对齐作用
          • 避免站会沦为长时间状态会议的措施
            • 让团队成员代替项目经理来引导站会
        • C-冲刺评审会议（Sprint Review）
          • 关键词：向客户演示产品增量
          • 目的：向利益相关者展示已完成成果并获取反馈
            • 需要邀请内外部干系人
              • 邀请干系人参加冲刺评审不需要产品负责人的批准
          • 关键活动
            • 演示可交付增量（Potentially Shippable Product Increment）；
            • 讨论未完成项及后续优先级调整；
            • 更新产品待办列表（Product Backlog）
            • 冲刺评审会议的作用是展示本次冲刺的可交付特性，并不是报告为什么删除了哪些特性，以及下个冲刺要做哪些特性
          • 输入产品增量及冲刺目标，输出确认的产品增量及干系人反馈
          • 依赖产品负责人PO在场，才能确定其价值，否则没有意义
        • A-冲刺回顾会议（Sprint Retrospective）
          • 目的：总结改进点，优化团队协作流程
            • 最重要的实践，使团队螺旋上升
          • 关键词：让团队反思和调整
          • 内容
            • 1. 总结工作中经验教训
            • 2. 改进可改进的工作
            • 3. 计划接下来的改进工作
          • 参与者
            • 整个scrum团队参加，非团队成员如干系人受邀才可参加
              • 通常是邀请运维团队
        • 冲刺（迭代周期）（Sprint）
          • 本质：固定时间盒的迭代开发周期（非会议，但属于事件范畴）
          • 冲刺是有时间限制的，冲刺结束，我们便停止工作，并将未完成的任务返回待办事项列表，进行重新规划
    • 五个价值观
      • 开发、尊重、勇气、专注、承诺
• 敏捷产品管理
  • Product Backlog 产生流程
    • 1. 产品愿景-电梯演讲
      • 简要表明产品如何支持公司战略
      • 设定产品目标-创建远景草案-确认与修改-最终确定声明
      • 敏捷的项目/产品愿景类似于预测型项目中的项目章程
        • 描述项目目标与产品价值等
    • 2. 用户画像-目标用户
      • 收集用户信息以了解客户需求
    • 3. 用户故事-需求描述
      • 促进开发人员对用户需求的理解
      • 用户多数情况只提解决方案而不是真正的需求
      • User Story的3C原则
        • 卡片、交谈、确认
    • 4. 用户故事地图-二维地图
    • 5. 产品待办事项列表
      • PB梳理步骤
        • 建立并细化→估算→排列优先级
        • 就绪的定义 DoR，Definition of Ready
      • 估算方法
        • 宽带德尔菲
          • 准确估算项目规模
        • T恤尺码估算
        • 亲和估算
          • 估算大规模用户故事
        • 计划扑克
      • 用户故事优先级排序
        • 优先级=（商业价值+风险）/成本
          • 最先验证高风险事物，快速失败
          • 船小好掉头
      • 其中装的是需求不是活动
  • 敏捷价值流
    • 敏捷项目章程
      • 产品路线图
        • 仅包含该项目应该发布的产品功能
        • 与产品范围关系不大
      • 敏捷项目中项目章程由高级管理层签署，其他角色各司其职
    • 敏捷发布规划
      • 可确定发布的迭代或冲刺次数
    • 每日站会
    • 冲刺回顾会
    • 价值流图
      • 用于记录、分析和改善为客户生产产品或提供服务时所需的信息或材料流的精益企技术
  • 精益 Lean
    • 精-小，物质中最纯粹部分；益-好处，有价值
      • 用最小成本创建最大价值
      • 源于丰田精益生产
    • 精益生产五大原则
      • 识别价值
      • 识别价值流
      • 创造流动
      • 拉动式生产
      • PDCA
    • 最后决策时刻
      • 为了使团队考虑全面，推迟决策时间点，直到Until进一步推迟将导致成本超过收益
      • 决策太早因方案不充分导致浪费
      • 决策太晚导致延迟成本大幅增加
      • 在最后一刻不遗漏重要的备选方法
    • WSJF
      • Weighted Shortest Job First
      • 对工作优先级排序使其经济效益最大化的模型
• 敏捷项目管理
  • 敏捷项目经理
    • 混合项目中项目经理具备存在必要性
    • 纯敏捷中并不必需项目经理，考试中将其理解为如下定义即可
      • 仆人式领导、团队促进者、项目经理、Scrum主管、项目团队领导、团队教练、敏捷教练
  • 敏捷范围管理
    • 传统方法中范围是固定的，进度成本可变
    • 敏捷方法中只有进度和成本是固定的，范围可变，把范围纳入PB，需要则列优先级开办
    • 敏捷的范围变更
      • 冲刺内不变，冲刺外可变更，不允许镀金
        • 每日站会中探讨做过了什么东西进行了什么敏捷实践有助于避免镀金
    • 冲刺目标按稳定速度水平来符合实际地制定
  • 敏捷进度管理
    • 产品路线图→产品Backlog→发布计划→冲刺Backlog
  • 敏捷成本管理
    • 通过管控速度来管理成本
    • 自筹资产品
  • 敏捷质量管理
    • 内建质量
      • 开发团队在设计过程中完成质量的计划执行与测试，而非由他人测试
    • 质量反馈循环
  • 敏捷资源管理
    • 仆人式领导：促进合作，清除障碍，防干扰
    • 自组织团队
    • 可持续发展
  • 敏捷沟通管理
    • 面对面沟通-沟通透明化
      • 更倾向于面对面，采取轻量级的信息发射源
      • 对干系人表态，有需要了解的信息就直接来我信息源这里看，不用找我汇报
    • 信息发射源（Information Radiators）
      • 是指通过高可视化方式展示项目关键信息的工具或图表，旨在增强团队和干系人对项目状态的可见性、促进透明沟通，并辅助决策。其核心作用是通过直观展示实时数据，减少信息传递的延迟和误解
      • 主要类型
        • 包括任务板、燃尽图、燃起图、看板、累计流量图、故事地图等
        • 燃尽图
          • 燃尽图是剩余工作与时间盒内剩余时间关系的一种图形化表示形式
          • 团队能通过燃尽图看到在冲刺过程中完成的工作，使用燃尽图查看项目随时间的进展情况
          • 燃尽图并不是专注为客户展现交付的价值，交付价值靠的是直接给客户ppt演示啥的
      • 何时需要使用信息发射源？
        • 敏捷项目管理场景：
          • 在Scrum或看板等敏捷方法中，信息发射源是日常运作的核心工具。例如：
            • 每日站会：用任务板跟踪任务状态（如“待办”“进行中”“已完成”）。
            • 迭代规划会：通过燃尽图预测剩余工作量，或通过燃起图展示已完成功能的增长趋势。
            • 回顾会议：用累计流量图分析工作流程中的瓶颈。
        • 需要提升干系人参与度时：
          • 在干系人会议中，使用看板或故事地图展示项目整体进度，帮助非技术背景的干系人快速理解复杂信息。
          • 通过街灯（物理/电子展示板）实时显示构建状态或测试结果，减少重复沟通。
        • 风险管理与问题暴露：
          • 当项目存在延期风险时，燃尽图可预警剩余工作量与时间的不匹配。
          • 累计流量图能突显流程中的阻塞点（如某阶段任务堆积），促使团队及时调整。
        • 跨团队协作与知识同步：
          • 分布式团队通过共享电子任务板（如Jira看板）确保所有人对优先级和任务分配的认知一致。
          • 新成员加入时，信息发射源可快速提供项目全景视图，缩短适应周期。
        • 应对变更或复杂需求：
          • 用户故事地图帮助团队在需求频繁变更时保持功能优先级清晰。
          • 复杂项目中，通过分层展示的信息发射源（如宏观燃起图+微观任务板）实现多维度管理。
  • 敏捷风险管理
    • 快速失败 Fail-Fast
      • 核心理念
        • 通过低成本、小规模的实验快速验证假设，失败后迅速调整方向而非追求一次性成功。例如，互联网公司推出最小可行产品（MVP）测试市场反应
      • 价值
        • 降低资源浪费，加速迭代效率。如麦肯锡指出，软件企业更倾向于“做6个正确决定和4个错误决定”，而非过度规划
    • 风险价值矩阵
    • 识别风险和确定新技术可行性的方法
      • 刺探 Spike
        • 基于风险的刺探是团队研究某个问题而进行的快速的概念验证活动，基于风险的刺探也常用来测试陌生的或全新的技术，在深入采用这种技术之前，探测的结果能够避免陷入太深
        • 针对的是全新的陌生的东西
          • 一种尝试的形式
        • 刺探对学习很有用，可在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。在团队需学习一些关键技术或功能要素时刺探会有帮助
      • SWOT
        • SWOT 分析会对一个组织、项目或方案的优势、劣势、机会和威胁进行评估
    • 评估和管理风险的敏捷方法
      • 利用定期的反馈循环，如每日站会、迭代演示和回顾会议
        • 每日站会中成员可提出任何发现的问题或风险
      • 在敏捷场景下，风险应该通过短周期迭代（2-4周）中的仪式和评审产品增量去识别，分析和监控风险，并且通过信息发射源和产品待办事项列表来跟踪和管理风险以及应对措施
        • 即可以通过冲刺内管理风险&频繁审查产品增量来识别风险
  • 敏捷采购/合同管理
    • 多层结构
      • 固定内容+灵活内容
    • 强调价值交付
      • 传统项目里程碑交付& 敏捷项目价值交付
    • 总价增量
      • 传统项目按整个项目写一个合同，而敏捷项目中按每个故事写增量式合同
    • 固定时间和材料
      • 管理给定能力
    • 累进的时间和材料
      • 共担财务风险
    • 提前取消方案
      • 不支付剩余费用
      • 只要满足需求则合作停止
    • 动态范围
      • 允许特定点该范围
      • 敏捷项目不需要额外的合同，因其范围是可变化和调整的
    • 团队扩充
      • 对供应商的暂时性收购，资助其团队保留其决策权力
    • 支持全方位供应商
      • 传统项目中避免独供，尽可能分散采购源
      • 敏捷项目中希望能有供应商能够全方位供应
        • 好处是促进供应商对我项目的全面理解
  • 敏捷干系人管理
    • 教育干系人
      • 指导干系人敏捷实践
      • 避免干系人干扰团队
      • 管理干系人对变革的抵制
• 其他敏捷方法
  • かんばん看板方法
    • kanban日语原意
      • 卡片、信号
    • kanban作用
      • 可视化工作流程
      • 限制进行中地工作
      • 度量和管理流动
      • 明确过程策略
      • 持续改进
    • kanban方法工作流
      • 梳理工作流程
        • 如软件开发中的：分析-开发-测试-发布
      • 画出看板面板
        • 每一步流程分成ongoing和done(泳道）
      • 设定WIP限制
        • WIP, work in process(在制品)
          • 所有未完成的事物事项均为在制品
        • 每一个流程都存在某种限制，如设备/人员限制，此处每个流程需要设定的一个最多的同时进行在制品的数量
        • 做WIP限制的理由？
          • 利特尔法则
            • 前置时间LeadTime =WIP/吞吐率Throughput
              • LT:准备/排队时间+完成/处理时间
              • 吞吐率=整个流程的速率（取决于最慢的那个活动）
                • 通过提高速率降低LT时间
              • WIP：在制品，即项目处理过程中的任务半成品
                • 通过限制WIP降低LT时间
      • 定义完成规则
      • 召开每日站会
      • 度量和管理流动
    • 累积流程图
      • 已完成功能的累积流程图是用于累积流程图是用于管理流程和改善服务交付结果的重要工具。它有助于确定瓶颈和改进领域。虽然它可以帮助确定绩效问题，但它不如其他分析团队绩效的工具有用。
  • 极限编程XP
    • 关键词
      • 结对编程、重构、TDD、代码所有权
        • 测试驱动开发 Test-Driven Development，TTD
          • 定义
            • 是一种敏捷开发实践，其核心是通过先编写测试用例再编写功能代码的流程驱动软件开发
          • 示例
            • 开发一个计算器功能时，先编写“加法运算”的测试用例，再实现加法逻辑代码，最后优化代码结构
          • 适用TDD的场景
            • 1. 频繁变更
            • 2. 复杂逻辑
            • 3. ...
          • TDD可作为质量保证工具融入以下环节
            • 1. 迭代规划：将测试用例编写纳入任务拆分（如用户故事验收标准）。
            • 2. 风险管理：通过测试覆盖率量化技术债务，辅助决策重构优先级。
            • 3. 团队赋能：Scrum Master可推动TDD培训，提升团队工程效能
    • 作用
      • 1-2周冲刺，短周期，工程技术领域
  • 特性驱动开发FDD
    • 关键词：特性
    • 作用
      • 基于产品特性开发，能够在很短时间内实现
  • 动态系统开发DSDM
    • 作用
      • 以业务为中心，快速有效系统开发
      • 二八原则，用20%精力开发80%业务
    • 关键词：业务、商业需求
  • 水晶方法Crystal
    • 作用
      • 通过水晶的不同颜色表示项目复杂度和团队数量大小
    • 关键词：颜色
  • 改善Kaizen
    • 旨在对系统加以改善的活动
    • 作用
      • 持续不断获得小进步
    • 关键词
      • PDCA，持续改善
• 敏捷实践指南精要-4条暗线
  • 项目
    • 利用混合型方法的过渡实现瀑布型→敏捷型
      • 结合了敏捷的预测
      • 预测为主，敏捷为辅
      • 敏捷为主，预测为辅
      • 混合生命周期作为过渡
    • 瀑布管理？
      • 是一种基于传统瀑布模型的项目管理方法，强调按线性顺序分阶段推进项目，每个阶段需严格完成并通过评审后才能进入下一阶段
      • 适用场景
        • 需求明确且稳定：如政府合规项目、传统制造业升级。
        • 高度结构化项目：需严格遵循法规或行业标准（如医疗设备开发）。
        • 经验丰富的团队：熟悉领域知识，可准确预估风险与工作量。
      • 与敏捷方法的对比
        • 瀑布模型：计划驱动，注重文档和阶段性成果，变更成本高
        • 敏捷方法：价值驱动，通过迭代和客户反馈适应变化，灵活性高但依赖团队协作。
  • 组织
    • 1. 利用组织内部变革：传统→敏捷型组织
      • 敏捷变革主要在于中层职能领导上，削其权力使权力集中到自组织团队
      • 员工认知转变、集中或分散项目管理职能、专注短期目标而非长期、人才管理成熟度和能力
      • 遇到对变革的抵制直接找到一把手领导辅助变更
    • 2. 敏捷合同管理
    • 3. 多团队协作与PMO
      • 多团队合作框架
        • SAFe
        • LeSS
        • SoS
          • 由多个Scrum团队使用的一种技术，每个团队包含三到九名成员来协调其工作。每个团队的代表会与其他团队代表定期召开会议，每日例会，或是一周两次或三次。其目标是确保团队协调工作并清除障碍，以优化所有团队的效率。 有依赖关系的Scrum团队，需要开SoS会议来优化效率。
          • 还有套娃式的SoSoS
  • 领导
    • 管理型领导风格转变→仆人式领导
      • 消除组织障碍
        • 仆人式领导应该关注其他冗长过程，这些过程往往造成瓶颈问题且阻碍团队或组织敏捷性
        • 其可能需要处理的流程或部门包括
          • 财务部门、变更控制委员会或审计部门
        • 系统分类
          • 流程冗长的部门-与之合作（CCB、审计、财务）
          • 不懂的干系人-教育干系人
          • 不守实践的团队-及时制止
          • 有干扰的环境-排除干扰
      • 促进团队合作、教育干系人、培训与发展团队
      • 培养和发展团队成员帮助其超越自身当前角色，即使团队失去他们也在所不惜
  • 团队
    • 孤岛式团队→角色转变→自组织团队
      • 3-9专职团队
        • 传统团队切换任务时，效率损失20%-40%；同时再做多个项目，效率损失呈指数提升
      • 克服组织孤岛
        • 孤岛即按照职能型部门分组团队，临时组合一个团队有助于克服
      • 通才型/T型专家
        • 每一个人都是T型选手的话会比传统项目中个别顶尖成员的情况创造的绩效高得多
      • 自组织团队
        • 团队主动领取、估算和分配任务
      • 团队工作场所
        • 集中办公效率更高
• 敏捷项目概念辨析
  • DoD和DoR
    • DoR，Definition of Ready-就绪的定义
      • 产品待办事项列表准备到哪种程度能算就绪，可进入冲刺
    • DoD，Definition of Done-完成的定义
      • 冲刺到哪种增量才能算完成
    • AC，Acceptance Criteira 验收标准
      • AC与DoD核心区别
        • 目的差异
          • AC确保“做正确的事”（验证需求是否实现）。
          • DoD确保“正确地做事”（保证开发流程和质量的标准化）。
        • 责任主体
          • AC主要由产品负责人（PO）定义，需与开发团队协商确认
          • DoD由团队协作制定，可能涉及多个团队或组织级标准。
        • 总结
          • AC是需求的“终点”，验证是否满足用户需求
            • AC是用户故事或特定需求的验收条件，关注的是外部质量，即用户是否满意
          • DoD是交付的“底线”，确保流程和质量可控
            • DoD是整个项目或迭代必须满足的完成标准，确保内部质量和长期可持续性
  • 冲刺与发布
    • 发布计划
      • 每个时间节点发布哪些功能的一个计划
      • 其中每个发布都包括多个冲刺，每个冲刺后交付一个产品增量，最终统一交付
      • 在技术层面交付，在产品层面发布
  • MMF & MVP
    • MMF：最小的可市场化特性、最小可售卖的功能
    • MVP：最小成本以验证其价值的可用产品
      • 向MVP添加更多功能和测试是无意义的，如果最小可行产品都不能满足需求质量要求，添加更多功能也是无意义的
      • 当前这个功能原型还缺什么功能，补全后才叫MVP；而未来可添加的功能是附加功能，交付MVP没必要加入
  • Change 变更与变革/转型
    • 项目层面的变更
    • 组织层面的变革/转型
  • 看板与任务版
    • 看板是一整套敏捷方法论，包括WIP限制、价值流拉动管理
    • 任务版只是简单的任务呈现与变化
      • 类似于Scrum板
  • 产品Backlog&冲刺Backlog
    • 内容
      • 用户故事
        • 描述需求
      • 任务
        • 描述解决需求所采取的开发活动
    • 管理责任人
      • PO
      • 开发团队
    • 优先级谁来定
      • PO
      • 开发团队
  • 项目经理&敏捷教练
    • PM将需求/变更管理划分给PO
    • 将培养团队清除障碍分给SM
    • 将协调任务质量保证分给Dev Team
  • 燃尽图、燃起图与累积流量图
    • 燃尽和燃起图更多用在Scrum项目中，因其具备封闭固定时间，存在截止时间
    • 看板类项目使用累积流量图
    • 发布燃尽图&迭代燃尽图
      • 发布看一个发布内多个冲刺下完成的用户故事量
        • 横坐标为每个冲刺点，纵坐标总故事量
        • 折线节点突然曲率变大向上则代表新增了变更
      • 迭代看一个冲刺内时间所完成的任务量故事点
        • 横坐标日期，纵坐标故事点
  • 项目目标&产品愿景
    • 项目目标以产品愿景或项目章程的形式呈现
    • 无论哪种形式都需要在团队工作场所张贴并与干系人分享
  • 传统&敏捷项目章程
    • 传统
      • 正式，内容丰富
    • 敏捷
      • 轻量级，张贴至工作场所，与干系人共享
  • 信息发射源与看板
    • 看板只是信息发射源的一小部分
    • 信息发射源的要求：
      • 简单、明确不模糊、实时信息、高度可见信息透明、能影响到干系人和团队解决问题、只显示关键的最小数量信息
  • 史诗、特性与用户故事
    • 用户故事
      • 一个冲刺内完成
    • 产品特性
      • 三个月内完成
    • 史诗故事
      • 更长甚至跨年完成
  • 用户故事规模估算
    • 用户故事规模估算是项目管理中确定任务复杂度和工作量的常用方法
    • 宽带德尔菲
      • 耗费精力多，估算相对准确、收集的形式，匿名
    • 计划扑克 Planning Poker
      • 做法
        • 团队成员每人分到一组标有数字（如斐波那契数列：1, 2, 3, 5, 8…）的扑克牌。针对一个用户故事，大家同时出牌代表估算值，若差异大，则由最高和最低分的人解释理由，讨论后重新投票，直到达成共识
      • 优点
        • 避免“从众心理”，通过讨论暴露理解偏差。
      • 关键词
        • 相对规模小、故事点明确
    • T恤尺码估算 T-Shirt Sizing
      • 做法
        • 用XS、S、M、L、XL等尺码类比故事大小
      • 优点
        • 直观易懂，适合快速分类
      • 关键词
        • 主观简单、无须数字计算
    • 亲和/相对估算 Affinity Estimating
      • 做法
        • 将用户故事卡片按复杂度分组（如“小”“中”“大”），通过对比确定相对大小。例如，先定“用户注册”为基准（M=5点），再判断“订单查询”是否更简单（S=3点）
      • 关键词
        • 规模较大、分类、快速
  • 用户故事优先级排序
    • MoSCow
      • 按需求划分为Must Have, Should have, Could have, Wont have
      • 关键词
        • 优先级、必须
      • 适用场景：
        • 适合时间紧迫的项目，快速砍掉非核心需求
    • 卡诺模型 Kano
      • 根据用户需求对满意度的影响分类，优先满足“基本需求”，再追求“惊喜体验”
      • 魅力、期望、必备、反向属性
        • 必须型：没它用户根本不用产品（如“登录功能”）。
        • 期望型：越多用户越满意（如“搜索速度越快越好”）。
        • 惊喜型：用户没想到，但能带来惊喜（如“智能推荐”）。
    • WSJF
      • Weighted Shortest Job First, 加权最短作业优先
      • 核心逻辑
        • 把任务想象成“赚钱机会”，优先做那些 单位时间内收益最大 的任务
      • 公式：WSJF=延迟成本（CoD） ÷ 任务规模（工期/复杂度）
        • 延迟成本（CoD）：如果现在不做这个任务，未来每月会损失多少钱/用户/机会
        • 任务规模：完成这个任务需要的时间或资源（比如开发3个月、投入5人）
      • 关键词
        • 延迟的成本、持续的时间
    • 相对量级估算
      • 核心逻辑
        • 不需要精确计算每个任务的工作量，而是 通过对比确定相对大小
      • 优先级=（价值+风险）/成本（规模）
      • 关键词
        • 价值、风险、成本
  • 敏捷合同
    • 多层结构、强调价值交付、总价增量、固定时间和材料、累进实践和材料、提前取消方案、动态范围方案、团队扩充、支持全方位供应商
  • 敏捷方法辨析
    • Scrum、看板、极限编程
    • 特性驱动开发FDD
      • 基于产品特性开发，可在短时间内实现
    • 动态系统开发DSDM
      • 每个冲刺前商业分析，预先固定进度资源，不断调整需求
  • Scrum3355
• 敏捷项目重点流程
  • Scrum流程
  • 敏捷变更流程
    • 冲刺内谨慎，冲刺外待办
    • 预测型项目变更走变更审批流程
    • 敏捷型项目变更则先找PO更新产品待办事项列表
  • 合规性需求优先级高
• 敏捷项目常见场景
  • 仆人式领导
  • 自组织团队
  • 情境领导
    • 形成阶段-指导式，震荡阶段-教练式
    • 规范阶段-参与式，成熟阶段-委任式
  • 敏捷团队可持续性
    • 速度稳定步调一致
      • 敏捷团队不加班
      • 根据团队能力调整计划
      • 资源固定、范围可变

PMBOK7&ECO

• 考试大纲目录
  • 三个部分按ATBN评级
    • Above Target
    • Target
    • Below Target
    • Needs Improvement
  • 业务环境占8%、过程占50%、人员占42%
    • 过程内容非常多但考试只占50%
    • 高性价比应试就在于把业务环境和人员部分学透
• 业务环境
  • 1. 规划和管理项目的合规性
  • 2. 评估并交付项目的利益和价值
    • 指标
      • ROI, Return on Investment投资回报率
        • =年均净收益/原始投资，如某设备投资回报率为20%
          • 越大越好
      • NPV, Net Present Value 净现值
        • 各年净现金流量折现到项目初期，如今年赚了20w，考虑通胀，实际赚了18.9w
          • 越大越好
      • PP, Payback period投资回收期
        • 项目净收益抵偿全部投资所需时间，如该设备100w，一年挣20w，可五年回本
          • 越短越好
      • IRR, Internal Rate of Return内部收益率
        • NPV等于0时的折现率
          • 越大越好
      • BCR, Benefit-Cost Ratio效益成本比率
        • 收益现值/成本现值*100%
          • 越大越好
  • 3. 评估并应对外部业务环境变化对范围的影响
    • PM需具备商业敏锐度
      • PESTLE
        • politics, economy, society, technology, law, environment
      • TECOP
        • technology, environment, commercial, opperation, politics
      • VUCA
  • 4. 为组织变革提供支持
    • 组织变革的障碍
      • 组织变革意味着让人走出舒适区
      • 其成败可能决定项目人员的职业生涯发展
      • 其意味着有一些权力的部分领导会被削弱
      • 组织变革是一把手工程
        • 需要老板自上而下，如遇阻碍先找领导
• 过程
  • 1. 执行需要紧急交付商业价值的项目
    • 审视项目整个实施过程的商业价值：用户故事优先级=（商业价值+风险）/成本or规模
      • 成本和规模越大，优先级越低
      • 商业价值和风险越高，优先级越高
    • MVP
      • 适用：需求不明确的项目
  • 2. 管理沟通
    • 沟通模型
      • 发送方
        • 确保信息清晰完整，确认信息已被正确理解
      • 接收方
        • 确保完整接收信息并正确理解，并需要告知收到或做出适当的回应
  • 3. 评估和管理风险
    • 根据风险调整待办事项列表
  • 4. 让干系人参与进来
  • 5. 规划管理预算和资源
    • 类比、三点、参数、自下而上
  • 6. 规划和管理进度计划
    • CPI&SPI
  • 7. 规划和管理产品/可交付成果质量
    • 质量标准：质量管理计划、DOD、验收标准
    • 当产品交付时，出现了需要重新工作并且延迟新功能开发的重大问题。项目经理应该采取哪种行动来解决质量问题?
      • 计划对产品进行持续验证。Plan for continuous validation of the product.
  • 8. 规划和管理范围
  • 9. 整合项目规划活动
    • 敏捷项目中管理整合项目最佳方法是让团队确定如何整合计划和组件
  • 10. 管理项目变更
    • 预测型则实施整体变更控制、敏捷型则保证冲刺内不变，冲刺外变
  • 11. 规划和管理采购
    • 规划采购→实施采购→控制采购
    • 遇到超范围情况首先看的是具有法律效应的文件，合同
    • 涉及与供应商合作时，应遵循正式的采购流程和程序；而不是直接咨询PO聘请他们推荐的供应商，权限不够没走审批
  • 12. 管理项目工件
  • 13. 确定适当项目方法论/方法和实践
    • 预测
      • 为管理成本
        • 仅执行一次
    • 迭代
      • 为解决方案的正确性
        • 反复执行直至修正
    • 增量
      • 为达到速度要求
        • 对给定增量执行一次
    • 敏捷（适应型）
      • 为更好更快实现客户价值
        • 反复执行直至修正
  • 14. 制定项目治理结构
    • 项目如何合法合规？
    • 遇事如何上报，上报给谁，有无CCB？
    • 阶段关口结束时要审查什么东西？
    • 公司用什么总结项目知识和经验?
  • 15. 管理项目问题
  • 16. 确保进行知识交流，使项目得以持续开展
    • 回顾会议不能拿来共享知识，需要开一个专门的知识共享会议
  • 17. 规划管理项目/阶段的收尾和过度工作
    • 收尾八步骤
      • 最终验收-关闭合同-财务收尾-最终报告-经验教训-归档工作-庆祝会-解散团队
• 人员-14条都必考
  • 1. 管理冲突
    • Tuckman
  • 2. 领导团队
    • PM领导风格
  • 3. 支持团队绩效
    • 四个阶段四个支持风格
  • 4. 向团队成员和干系人授权
    • 遇到问题优先让团队自行处理
    • 自组织团队解决技术难题
    • 自组织团队成员老带新
    • 应赋予自组织团队决策权
  • 5. 确保团队成员/干系人完成适当培训建设团队
  • 6. 建设团队：尽快促成团队整体从形成迈向成熟阶段
    • 获取资源
      • 要人
    • 建设团队
      • 形成-成熟
    • 管理团队
      • 管人
  • 7. 清楚团队面临的障碍
    • 流程冗长的部门——与之合作
    • 不懂得干系人——教育干系人
    • 不守实践的团队——及时制止
    • 有干扰的环境——排除干扰
  • 8. 谈判确定项目协议
    • 获取资源:谈判-找领导-招募
    • 采购索赔:谈判-ADR-法院
  • 9. 与干系人合作
    • 1. 正确的识别干系人并管理干系人参与,决定着项目的成败
    • 2. 为提高项目成功的可能性,应尽早开始识别干系人并引导干系人参与。
    • 3. 识别干系人的工作要迭代开展
    • 4. 干系人满意度应该作为项目目标加以识别和管理
    • 5. 项目干系人包括自认为被项目影响到的人员
    • 6. 通过谈判和沟通管理干系人期望
  • 10. 凝聚共识
    • 优先当面沟通
  • 11. 让虚拟团队参与进来并为其提供支持
    • 优先找沟通技术
  • 12. 定义团队的基本规则
    • 纪律问题找团队章程、基本规则、社会契约
  • 13. 指导有关的干系人
    • 干系人不懂敏捷对其的指导方法
      • 邀请开会
      • 指导培训
      • 查看信息发射源
  • 14. 运用情商提升团队绩效
    • 自我意识
      • 识别自己情绪
        • 你如何影响团队，团队对你有何影响
    • 自我管理
      • 管理好自己情绪
        • 建立信任/三思而后行
    • 社交意识
      • 同理心&积极倾听
    • 社交技能
      • 即管理好他人情绪的能力
        • 建立融洽关系
        • 建设高效团队
        • 管理态度
• 模型方法和工件
  • 模型
    • 如PDCA，是解释过程、框架或现象的一种思考策略
  • 方法
    • 获得成果输出可交付物的方法，如根本原因分析，是一种工具与技术
  • 工件
    • 工件（Artifacts）是项目执行过程中产生的各类文件、成果或数据记录
    • PMP中的工件主要分为以下五类
      • 项目管理计划
      • 项目文件
      • 可交付成果
      • 工作绩效数据
      • 沟通工件
      • 考过的
        • 产品路线图
          • 关于项目的可视化概述，不是产品功能的简要描述
        • 发布计划
          • 针对每个版本发布的功能描述
        • 项目章程
          • 包含愿景、任务和成功标准、为产品的设计目的提供概述并为测试者执行探索性的测试提供向导
            • 愿景即产品功能的简要描述
        • 项目数据表
          • 用一页纸概括主要商业和质量目标、产品功能数据和项目管理信息
• 裁剪
  • 裁剪原因理由
    • 1. 为获得团队承诺
    • 2. 客户为本
    • 3. 资源利用
  • 裁剪五个方面
    • 1. 生命周期和开发方法
    • 2. 过程
      • 审计、格式修改、会议记录、站会等
    • 3. 参与
      • 是否放权，是否整合供应商
    • 4. 工具
      • 软件、设备
    • 5. 方法和工件
      • 文档模板工件
  • 裁剪步骤
    • 1. 选方法，预测/敏捷/混合
    • 2. 对组织裁剪
      • 由PMO和VDO对裁剪审批
    • 3. 对项目裁剪
    • 4. 实施持续改进
• 项目管理8大绩效域
  • 干系人
    • 干系人分析文件对干系人保密
  • 团队
    • 领导力技能之一：决策
      • 数控型/直觉型
      • 独裁型决策
        • 快速，易出错影响团队积极性
      • 群体决策
        • 准确，团队认同、耗时长
        • 单一阶段：直接讨论并选择方案。
      • 发散/汇聚模式决策
        • 快速且准确，需提前制定方案
        • 罗马式表决
        • 两阶段：发散（创意生成）→ 汇聚（筛选优化）。
      • 参与式决策
        • 定义
          • 让团队参与决策而非书写形式
        • 分类
          • 简单投票
          • 拇指投票
          • 决策分级
          • 五指投票
  • 开发方法和生命周期
    • 开发方法
      • 迭代
        • 尝试不同想法澄清范围、方法和需求
      • 增量
        • 逐步开发特性和功能
      • 交付节奏
        • 整个项目期间所开展活动的节律
  • 规划
    • 范围规划
    • 进度规划
    • 预算
    • 项目管理
      • 渗透式沟通
        • 通过无意听取和非语言提示，不直接沟通获取信息
      • 虚拟团队
    • 沟通
    • 实物资源
      • 提前期采购
    • 采购
    • 变更
  • 项目工作
    • 建立过程：使用裁剪技术优化过程
      • 精益生产
      • 回顾或经验教训
      • 阶段末审查
    • 执行工作
  • 交付
    • 价值
      • 分预测型和适应型价值交付
        • 适应型类似敏捷
    • 需求
      • 需求启发、需求演变阶段
    • 范围
      • 范围分解：WBS用户故事
      • 范围验收：DOD验收标准技术测量指标
      • 范围变化：完成偏移范围蔓延
    • 质量
      • 质量成本曲线、变更成本图
  • 测量
    • SMART原则
      • 目标Specific
      • 目标必须是Measurable
        • Meaningful
      • 目标必须是Attainable
      • 必须与组织目标是Relevant的
      • 实现时间必须是Time-based有时限的
    • 测量陷阱
      • 霍桑效应
        • 测量什么员工专注什么，测量活动会对团队成员行为产生影响
      • 虚荣指标
        • 看起来有用但无法产生有效决策的指标
          • 比如网站总访问量为虚荣指标，不如新客访问量
      • 士气低落
        • 当目标难以达成时，士气会因持续未达成而失落
      • 误用度量指标
        • 人们可能扭曲测量指标或做错误的事
          • 专注在不重要指标
      • 确认偏见
        • 给测量数据不合理解释
      • 相关因果错误
        • correlation does not equal causation
  • 不确定性
    • VUCA
      • 易变性Volatility
        • 指环境变化的频率和幅度超出常规预期，导致项目需求、资源或技术快速且不可预测地波动
        • 应用场景：例如市场政策调整、供应链突发中断、技术迭代加速（如AI技术颠覆传统流程）等
      • 不确定性Uncertainty
        • 指未来事件缺乏可预测性，难以通过现有信息预判结果
        • 应用场景：如疫情对项目进度的冲击、客户需求临时变更、关键干系人退出等
      • 复杂性Complexity
        • 指项目涉及多维度因素（如技术、法律、文化等）交织，且存在非线性因果关系
        • 应用场景：跨地域团队协作、多技术集成项目（如智能工厂建设）、复杂利益相关方网络等
      • 模糊性Ambiguity
        • 指信息不完整或存在多重解释，导致决策依据不清晰
        • 应用场景：新兴市场开拓、创新产品研发（无先例可循）、政策解读差异等
      • 风险
        • 以上一旦发生会对一个或多个项目目标产生积极或消极影响
• 项目管理12原则
  • 人-人员
    • 管家精神 Stewardship
      • 管家：仔细和负责任地管理
    • 促进团队协作
      • 团队章程、组织结构、过程
    • 有效干系人参与
      • 干系人管理决定项目成败
      • 沟通与频繁互动是关键
      • 必须让干系人参与提高成功率
    • 领导力
      • 是一种影响力，是影响人们心甘情愿和满怀热情为实现组织目标而努力的艺术或过程
  • 事-过程
    • 聚焦价值
      • outcome 成果
        • 某过程地最终结果或后果，包括输出和工件，重视价值
      • output 输出
        • 过程的输出，可以为中间件
      • value 价值
        • 使用价值
    • 裁剪
      • 对项目管理方法、治理和过程做出深思熟虑的调整，使之更适合特定环境和目前工作
    • 内建质量
      • 质量的积极成果
    • 优化风险应对
  • 系统-业务环境
    • 系统思维
      • 看全貌而非局部
      • 看结构而非表象
      • 看变化而非静止
      • 条理清晰而非杂乱
    • 驾驭复杂性
      • 复杂性
        • 具有涌现和自组织行为的复杂系统的特性
      • 涌现
        • 指突然产生的一种质变
    • 拥抱适应性和韧性
      • 适应性
        • 应对不断变化条件的能力
          • 短反馈循环
          • 小规模原型法和实验
            • 原型可包括所有功能，其功能多余MVP
          • ...
      • 韧性
        • 吸收冲击的能力
          • 通才型团队
          • 最后决策
    • 驱动变革
      • 系统韧性反而是组织变革的最大障碍
• 序言
  • PMBOK7针对系列问题的改善方向
    • 项目复杂性→系统性思维
    • 过于关注过程→八大绩效域结果为先
    • 当前PM体系无法适应VUCA一类新环境→适应性
    • 过度填充书内内容→原则指导

中心主题

• 待分类
  • 掌握了
  • 项目成员未使用经验教训更新项目文档，PM如何应对
    • was not using lessons learned to update the project documentation
    • 属于流程上的小问题，直接举行培训会议即可
  • 项目经理在分配任务和调用团队成员方面遇到问题，某些团队成员也在做一些与项目无关的任务，为何发生如此问题？
    • 项目经理没有行使应有的职权，影响力以及调配项目工作
  • 若客户对于信息的获取出现了问题，问题出在沟通上，则事先应该与客户就信息的传递达成共识，即起草制定一份沟通管理计划
  • 涉及某材料延迟交付导致项目进展停滞
    • 非关键材料可通过更换供应商并采购材料
    • 关键材料的话更换供应商不一定能够有效解决，需要要求供应商设法找到另一种交付方法
  • PM需识别潜在的项目团队成员，如何做
    • 应创建一份资源管理计划
      • 资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南
      • 特别要注意的是”潜在的项目团队成员“，也就是正在规划职责角色阶段，人员还没有开始进入团队
      • 组织结构图用于自上而下地显示各种职位及其相互关系，用于看公司架构，和项目成员识别无关
  • 范围蔓延应该怎么做？
    • A-执行风险评估和范围变更管理程序
      • 变更往往产生连锁效果，范围的蔓延也可能影响到进度基准和成本基准，所以只对范围进行变更是片面的
    • B-调查为何会发生范围蔓延，并立即启动变更管理程序
  • 即便是鼓励面对面解决直面问题，如果干系人结构发生变化是需要先更新沟通管理计划再与变化后的干系人沟通解决问题的
  • 新PM未和项目团队成员合作过，PM应该如何做以开始建立良好关系？
    • 团建和个人会面双管齐下
      • 团队建设活动可以促进团队成员之间的相互理解和合作
      • 个人会面则可以帮助项目经理更好地了解每个成员的特点、需求和目标
  • PM需要从不同职能经理招募团队成员，需怎么做
    • 优先使用资源日历
      • 资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、 周末和公共假期
    • 通过资源日历得知哪些资源可用，再和职能经理协商获取资源
    • 如果无法获取，最后再考虑其他获取方式，例如招募
  • 由于所需的验收标准未得到满足，公司应采用哪种质量管理过程来避免再次发生该问题
    • 质量保证(QA) Quality assurance (QA)
    • 质量保证着眼于项目使用的过程，旨在高效地执行项目过程，包括遵守和满足标准，向干系人保证最终产品可以满足他们的需求、期望和要求
    • 质量控制(QC) Quality control (QC)通常用于在提交给客户验收前的内部测试
  • 客户验收通过后对最终产品反悔，PM要解决该问题应查阅
    • 需求文件 Requirements documentation
    • 验收已通过，查阅验收标准不能阻止客户反悔，此时最好的办法是去查阅收集需求的记录
  • 涉及高层级关键词需要与项目章程相关答案相联系
  • 一家公司正在冒险进入一项新业务，但之前在该市场中没有经验，项目经理应使用什么工具或技术来收集需求？
    • 原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。 新业务，缺少经验，可以采用模型来验证市场的办法确定产品需求
  • 若题干已交代原因，则无需再进行分析，直接采取措施执行即可
  • 如何实现一个高度敬业的团队目标？
    • 敏捷团队是自组织和跨职能的，每个人都对项目负责，所以每个人都需要理解他们的角色和贡献将如何影响整个项目，以增强团队成员的主人翁意识和参与感
    • 营造一种环境，让每个人都知道自己的贡献对整个项目意味着什么
  • 干系人需求不一致怎么办？
    • 开会，开引导式研讨会
    • 在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键干系人， 使他们就项目可交付物以及项目和产品边界达成跨职能的共识。 引导干系人达成跨职能的共识。
  • 敏捷项目中遇到技术问题，即便SM是这个领域专家，也应该是让团队自行解决问题
    • 技术问题，优先团队自行解决，若是解决不了，再提供帮助。
  • 行业领域的事情，一般都找专家判断。
    • PM处理不好的专业事情找主题专家
  • 持续改进方法
    • PDCA是持续改进的方法
    • 全面质量管理（TQM）、六西格玛和精益六西格玛等质量改进举措也可以提高项目管理的质量以及最终产品、服务或成果的质量
  • 先分任务WBS，再定责任RACI，WBS管事，RACI管人
  • 敏捷项目向客户提供最优价值
    • 产品负责人PO负责向客户提供最优价值
  • 故事点也是一种预算评估技术，特别是在scrum中
• 其他待分类概念
  • 培训手册 Training manual
    • 培训包括旨在提高项目团队成员能力的全部活动，可以是正式的，也可以非正式的
  • 标杆对照Benchmarking
    • 定义
      • 标杆对照是将实际或计划的项目实践（如产品、流程、质量标准）与其他可比组织（内部或外部）的实践进行比较，以发现差距并制定改进措施
      • 例如，在开发电商平台时，可对比行业领先企业的用户界面设计或支付流程效率。
    • 作用
      • 识别最佳实践：通过横向对比，提炼行业或跨行业的先进方法。
      • 提升绩效：为项目质量管理、需求管理、相关方管理等提供改进方向。
      • 风险控制：通过借鉴已验证的实践，减少试错成本。
  • 作战室 War Room
    • 定义
      • War Room是项目团队集中办公的专用空间，通常以会议室或特定区域为载体，通过视觉化管理工具（如白板、进度图、风险看板）展示项目关键信息，形成高度透明的协作环境。其名称源于军事领域的作战指挥室概念，强调快速响应和集中资源解决核心问题
    • War Room的作用
      • 1. 促进实时沟通与决策
      • 2. 强化跨部门协作
      • 3. 提升问题解决效率
      • 4. 增强团队凝聚力
    • War Room的应用场景
      • 1. 项目启动与规划阶段
      • 2. 关键里程碑或交付节点
      • 3. 高风险或复杂任务执行期
      • 4. 远程项目的虚拟替代
    • War Room的局限性
      • 成本与资源占用
      • 过度依赖风险
    • 考点
      • 通常用于指代集中办公

中心主题

• 考情分析
  • 考试难度分析
    • 6月考期反馈试题最难？
    • 难点具体表现
      • 1. 题干选项都难理解
      • 2. 题干好理解，选项极限二选一
      • 3. 考察知识点模糊
      • 4. 难度分配不均影响考试心态
  • 试题考察情况
    • 题型
      • 单选+多选共180
      • 多选5~10，会说明选项数量
    • 考核方式
      • 概念题
        • 5~20，问PM应采用那种工具技术、查什么文件谁负责
      • 场景题
        • 占比最大，一般问PM应该做什么
      • 计算题
        • 几乎不考
        • 一般都是挣值，CPI SPI
    • 场景考察类型
      • 预测
      • 混合
      • 敏捷
    • 考试难度提升四大试题类型
      • 1. 复杂场景题
        • 题干长场景复杂，理解耗时
        • 题干短场景简单但问题绕
        • 考察知识点模糊..
        • 提取关键词
      • 2. 复杂概念题
        • 做好充分复习避开陷阱
      • 3. 翻译题
        • 看英文
      • 4. 广度题
        • 遇到生词按常规答题思路进行即可
• 基础精讲
  • 引论
    • 背景
      • 经济形势下行，利益走薄，竞争加剧的时候，哪怕是垄断企业也会来学项目管理
      • 当前市场需求千变万化
        • 如手机当前研发和销售就各自4个月时间，过了时间就不好卖了
      • 企业逐渐以项目为运行中心
        • 典例如HRBP
    • 项目管理目标
      • 理想层面：多快好省
      • 最优工期
        • 直接成本和间接成本交替达到的最低预算下最省时间和成本的点
        • 合理工期，最优前后一个区间，该区间内项目成本不超预算
      • 高层次战略目标
        • 如马云担任菜鸟物流网络董事长
        • 有些项目就是纯亏，主要目标就是客户满意；
    • 项目管理与运营的区别
      • 项目
        • 概念
          • 为公司产品研发、为客户交付服务、管理变革等项目团队的工作
        • 特点
          • 项目独一无二，时间有限，革命性（没办法重来，无容错率，而运营有不断优化来过的机会）、责权不平衡（PM责任很多，权力却十分有限）、效果导向、不确定性
      • 运营
        • 概念
          • 持续重复且流程化的工作
        • 特点
          • 重复多次、持续不断、标准化流程、确定性、效率导向、责权均衡（如只对1w以内报销负责，有权决定过不过审）
        • 示例
          • 财务
            • 重复定期去处理报销，去税务局报税
          • BDS
      • 项目专注于成果交付，运营聚焦在实现商业价值
    • project, program, portfolio & Strategy
      • 让子集更好的运营管理
      • 项目组合
        • 企业按照不同战略目标为项目分组并设定优先级，按照优先级配置资源就是项目组合管理的涵义
        • 市场占有率和销售增长率的四分类矩阵
          • 明星
          • 金牛
          • 问题
          • 瘦狗
            • 过渡/练手需要
      • 项目集
        • 示例
          • 蚂蚁金服：支付宝余额宝蚂蚁小贷
          • 围绕客户的一系列金融服务，属于项目集管理
        • 项目集中的项目一定存在关联，而项目组合中的项目没有必然联系，只是说在一个大的战略布局下
      • 三者对比
    • 交付价值体系
      • 价值交付
        • 只要是对客户有价值的事情，短期内看不到利益也去做
      • 价值流映射
    • 敏捷
      • 敏捷宣言
        • 个体与交互胜过过程与工具
          • 强调团队每个人的潜能，专注团队每个人一起讨论创造
        • 可用的软件胜过完备的文档
          • 软件开发中软件能用才是最重要的
        • 客户协作胜过合同谈判
          • 甲乙双方合作一起创意
        • 响应变化胜过遵循计划
      • 颠覆思想
      • 敏捷十二原则
        • 客户满意
          • 不断交付有价值的内容使客户满意
        • 拥抱变化
          • 变化需评估合理性，不是想怎么改怎么改
          • 不代表朝令夕改
        • 短周期
          • 产出交付周期短
        • 相互合作
          • 获取所有客户、供应商甚至用户的反馈，建立合作关系
        • 激发和信任
        • 面对面
          • 张嘴就能沟通吵架
        • 可工作软件
          • 开发出来的东西必须是可用好用
        • 可持续开发、技术卓越（有新不用旧）、简洁（减少不必要工作量）、自组织（最好的架构需求和设计出自自组织团队）、回顾总结（定期反思如何提高成效
    • 应试
      • 统计考点分布规律
      • 归纳各题型解题攻略
        • 概念题
        • 场景题
        • 计算题
      • 分析试题库发展趋势
      • 拿捏命题人出题思维
        • 变成PMI美国人的思维方式
    • 项目管理价值观与方法论
      • 未雨绸缪
        • 提前计划，风险管理
      • 防微杜渐
        • 持续监控计划，产生偏差及时发现和干预
      • 资源集成
        • 资源不为你所有，仅为你所用
        • 把最专业的事情交给最专业合适的人，不要把活儿揽完
        • 整合管理：分好工，排好计划，协调好冲突
      • 恰到好处
        • 不自发做out of scope的
      • 循规蹈矩
        • 先走变更控制程序，按规矩办
          • change order
      • 锲而不舍
        • 保证目标达成
      • 积微成著
        • 组织好过程资产，经验教训都在发生的时候记
        • 变更日志、需求更新册等
      • 公开透明
        • 强调沟通，拟定计划需所有人共同参与
        • timeline那些业务自己写
      • 同舟共济
        • 诚信共赢
          • 如供应商出反常低价，让其重新评估需求重新报价，不贪便宜
          • 让每一方都有合理的利润，挣该挣的钱
      • 各司其职
        • 人员权限管理
  • 环境
    • 组织结构类型
      • 职能型组织
        • 跨部门沟通效率低
        • 项目绩效不足，员工积极性不高
        • 多一事不如少一事
      • 矩阵型组织
        • 当前时期通用主流的组织模式
        • 既是项目组成员也是职能体系下员工
          • 每个人员两个领导，职能领导和项目经理
      • 项目型组织
        • 机构设置重复，资源浪费
        • 工作内容不饱和，有人忙有人闲，人浮于事
        • 因地制宜
    • 项目复杂性
      • 三个维度
        • 系统行为
          • 工作内容种类多，量大，人多，组织多
        • 不确定性
        • 人类行为
      • 驾驭方式
        • 拥抱变化
        • 管理知识
        • 持续学习
    • 知识管理
      • 显性隐性知识
      • PSCA循环
        • Produce
        • Stockpile
        • Communication
        • Application
    • 适应性和韧性
      • 敏捷方法
        • Scrum
      • Sprint
        • 冲刺/迭代
      • 项目韧性
        • 维持状态、迅速恢复、增长经验更好应对未来
    • Minimal Valuble Product
      • 先用最少资源最少时间做实验反馈给客户，获得最早期的客户反馈，真正查明客户需求，验证产品的价值
      • 思路
        • 先探查是否有对应方向的足够市场需求
        • 仿真、众筹、预售、访谈
    • 根据环境剪裁
      • 充分考虑环境对项目的影响，即审时度势、因地制宜
    • 优化风险应对
      • 风险敞口 risk exposure
      • 单个与整体风险
    • 干系人风险态度
      • 风险偏好
        • 为预期回报，干系人愿意承受不确定性程度，属主观意愿
      • 风险承受力
        • 干系人能承受的风险程度和数量，属客观能力
    • 风险识别
      • 德尔菲 Delphi Method
        • 专家组成员以匿名形式提交意见，并且不知道其他专家的存在，自由独立地发表意见
      • 假设分析
    • 项目收尾
      • 合同收尾与行政收尾
        • 行政收尾在任何阶段都在进行
      • 组织过程资产
  • 人员
    • 项目涉及人
      • Sponsor
        • 项目发起人，出钱做项目的
      • CCB(change control board)
        • 能决定项目是否变更的人
          • CCB&PM
        • 决定变更原则的是
          • 基准baseline:范围、进度、成本
        • 变更请求影响基准baseline时，变更控制委员会可决定变更
      • PMO（project management office）
        • 项目管理岗办公室支持服务公司中的多个项目，提供支持和&帮助时监控其绩效
      • Functional Managers
        • 职能经理，为项目提供资源和支持
      • Project Managers
        • 项目经理，整合资源&制定计划&带领团队实现项目目标
      • Team、Stakeholder
        • 项目团队和项目干系人
    • 项目经理
      • 项目经理角色
        • 资源整合者-整合组织内专业人员、分包商和供应商资源
        • 信息沟通者-沟通规则的制定者、流畅沟通的推动者、沟通效果的保障者
        • 氛围创造者-创造良好、积极、健康、友好的团队气氛
        • 决策制定者-带领团队高效做出决策
        • 团队领导者-成为团队主心骨,为团队指引方向
        • 领导面前当专家、专家面前当领导
      • 影响范围
        • 项目
        • 组织
        • 行业
        • 专业领域
        • 跨领域
    • PMI人才三角
      • 项目管理专业技能
        • 全面的知识体系、工具方法、良好实践
      • 战略与商务管理技能
        • 理解企业战略和项目关系，理解sponsor发起的项目对其客户的商业价值
      • 领导力技能
        • 卓越领导者5种行为习惯
          • 以身作则、共启愿景、挑战现状、使众人行、激励人心
            • 所谓使众人行，就是通过强调共同目标和建立信任来促进合作，并通过分享权利来增强他人的实力
            • 可让下属变得高度敬业
        • 受人尊敬的领导者品质
          • 诚实、有胜任力、能激发别人、有前瞻性
    • 敏捷团队项目经理
      • Product Owner
      • 敏捷专家
      • 开发团队
    • 项目管理团队与项目团队
      • 项目管理团队
      • 项目团队
    • 自组织团队
    • 敏捷场景下的团队管理
      • 每天上班8小时,工作6小时,因为团队成员需要自由思考时间
    • 干系人分析
      • 识别干系人维度
        • 按照干系人密切程度
          • 内部、本地、国内、国外
        • 按照干系人特征类型
          • 客户投资人、供应分包商
          • 职能经理、项目团队
        • 按照干系人影响程度
          • 干系人影响力从0分~4分进行打分
          • 干系人的态度 从-2分~2分进行打分
    • 共创模式
      • “共创”是将受项目影响或对项目影响较突出的干系人作为合作伙伴,构建价值共同体
    • 干系人影响力强度和态度
    • 干系人权力/利益矩阵
    • 领导力与管理
      • 项目经理权力来源
        • 用户客户的评价，给团队/领导怎么说，说多少，都是自己决定
        • 职位
          • 法定权力对职位的授权,例如:项目经理可以使用项目预算
          • 奖惩权力有权奖励、惩罚他人,例如:项目经理可以表扬优秀成员
          • 施压权力 给别人施加压力的权力,例如:这个BUG今晚必须解决
          • 信息权力通过获取、管理和发布信息影响他人,例如:用户的反馈、评价
        • 人际互动
          • 关系的权力/迎合的权力/愧疚的权力/说服的权力/回避的权力! 情景权力
        • 自身
          • 专家权力拥有专业知识、经验
          • 自身 参照权力 —— 获得认可和欣赏,称为榜样
          • 魅力权力用个人魅力影响他人
      • 项目经理领导风格
        • 放任型领导 - 无为而治:充分信任团队成员,鼓励团队成员自己设定目标、规划方案、采取 行动等
        • 交易性领导 赏罚分明:强调赏罚分明、有言在先、论功行赏、规则精细并严格执行
        • 服务型领导 无微不至:服务型领导是对成员无微不至的关怀和周到细致的服务,使其愿意 追随
          • 星巴克，公司所有层级都为做咖啡的员工服务
          • 海底捞等同，海底捞公司全心全意为一线员工服务，同时也给员工力量全心全意为客人服务
        • 变革型领导情怀至上:关注组织,强调集体的力量,带领团队一起努力,让组织越来越好
        • 魅力型领导 - 活力四射:依靠领导者的专业、人格魅力来影响和带动团队
        • 交互型领导 - 全面均衡:综合了交易型、变革型和魅力型领导的特征
    • 展现领导力行为
      • 诚实
      • 有胜任力
        • Dunning-Kruger Effect
      • 能激发别人
      • 有前瞻性
        • 扎实的知识积累
        • 关注细节的习惯
        • 相信专家的力量
    • 团队章程
      • 团队价值观、沟通指南、决策标准和过程、冲突处理过程、会议指南、团队共识
    • 塔克曼阶梯理论-Tuckman Team Model
    • 项目经理不同发展阶段的管理风格
      • 形成阶段 - 指令型:直接、明确、清晰
      • 震荡阶段影响型:引导、斡旋、调解
      • 规范阶段 参与型:帮助、参与、促进
      • 表现阶段 授权型:信任、授权、支持
    • 虚拟团队与实体团队
      • 虚拟团队优势
        • 1、打破了地域对人才的局限
        • 2、降低了差旅、通勤、场地等成本
        • 3、对于兼职人员和零工的使用更加灵活
      • 虚拟团队劣势
        • 1、沟通效率低,效果差
        • 2、管理难度大,标准难统一
        • 3、团队难建立信任感,问题容易积累
      • 虚拟团队的参与方案
        • 清晰的规则、标准的流程、具体的任务、合适的工具、民主的机制、积极的互动、充足的准备、及时的复盘
    • 5 Stages of team development
      • Stage 1: Forming 组建阶段
        • Host a kickoff meeting
        • Define team roles
        • Set team objectives
      • tage 2: Storming 激荡阶段
        • Align on project outcome
        • Redefine responsibilities
        • Resolve conflict.
      • Stage 3: Norming 规范阶段
      • Stage 4: Performing 成熟阶段
      • Stage 5: Adjourning 解散阶段
  • P
    • 效益实现计划benefits realization plan
      • 它描绘了项目的预期效益（商业价值），以及这些效益如何通过项目的执行来实现
      • 这个计划可以包括诸如预期的收益、项目投资回报率、期望的成本效益分析等信息
      • 项目经理需要频繁地监控和更新这个计划，以确保项目的执行与预设的商业价值保持一致
    • 组织运行环境
    • 收益管理和商业文件
      • 商业论证
        • 项目商业论证指文档化的经济可行性报告，用来对尚缺乏充分定义的所选方案的收益进行有效论证。
        • 新了解到的信息要重新进行商业论证，用来论证项目的可行性
        • 无论本财年年度预算是否紧张，新项目可用资金的拨付也是建立在商业论证结果的基础上
        • ROI投资回报率是商业论证的一个维度但不是全部
      • 项目章程
        • 在项目启动阶段时仅有项目章程，涵盖了高层及的需求
    • 变更日志
      • 变更日志用于记录项目期间发生的变更
      • 当前干系人对变更请求存在争议，首先查看变更日志中的审批记录
  • 考试大纲
    • 考题三领域
      • 过程50%
        • 项目绩效管理
          • 工作方式
            • 把事情做好
      • 人员42%
        • 干系人满意
          • 影响力
            • 把人管好
              • 团队和干系人都能管理好
      • 业务环境8%
        • 商业与战略
          • 商业敏锐度
            • 能给组织挣钱，为公司创造高价值
    • PA7E参考书
      • 复习内容重点在P&A&E
        • Process Groups A Practice Guide
        • Agile Practice Guide
        • Examination Content Outline
    • 应试要点
      • 概念术语多看书
      • 场景归纳多做题
  • 项目治理框架
    • 参考关于工作邮件语言、计划模板和评审流程等问题
    • 项目治理框架定义了项目的决策过程、角色和职责、以及项目的政策和程序。这包括沟通的标准和流程，因此它是最合适的参考文档。
• 直播
  • 三模型、冲刺题和必刷题难度及风格最接近考试
  • 现金流
    • 主业熟练后用来搞副业
    • 投资理财
      • 优选稳定缴费稳定收入的
      • 香港保险
      • 美元资产-避险神器

中心主题

• 高频考点
  • 基础概念
  • 过程组核心考点
    • 启动过程组
      • 项目章程
        • 触发条件：新项目/新阶段/更换PM
        • 核心内容
          • 三高（需求/风险/描述
          • 二总（预算/里程碑）
          • 发干委（发起人/干系人/委派PM）
        • 题干关键词：质疑PM职权、高层级描述 → 选章程
      • 商业论证
        • 场景：评估项目投资价值 → "是否值得启动项目？"
        • 三大适用情况
          • 1. 项目启动时决定要不要做
          • 2. 发起人离职，项目要不要继续
          • 3. 包括商业需求和成本效益分析
    • 规划过程组
      • 范围管理
        • - WBS分解至工作包（80小时规则）
          • 80小时原则指的是一个任务在拆分为子任务时，每个子任务的工作量最好不要超过80小时
        • - 范围基准=WBS+词典+范围说明书
          • 范围蔓延（未走变更流程） vs 镀金（主动增加未批准内容）
      • 进度管理
        • - 关键路径法（总浮动=0）
        • - PERT三点估算（公式：(O+4M+P)/6）
        • 进度压缩：快速跟进（并行） vs 赶工（加资源
      • 成本管理
        • - 挣值计算（EV/PV/AC，CV=EV-AC，SV=EV-PV）
        • - EAC=BAC/CPI（典型偏差）
        • 非典型偏差用 EAC=AC+(BAC-EV)
    • 执行过程组
      • 团队建设
        • 塔克曼阶段：形成→震荡→规范→成熟→解散
        • 冲突解决：合作/妥协（首选） > 缓和/撤退 > 强制（慎用）
      • 质量保证
        • 关键词：过程改进、预防缺陷 → 选质量审计
    • 监控过程组
      • 变更控制
        • 铁律：所有变更必须走流程（提交→评估→审批→更新）
        • 例外：紧急情况可先处理，后补流程
      • 质量控制工具
    • 收尾过程组
      • 强制步骤：验收→移交→更新资产（经验教训）→释放资源
      • 易错点：合同收尾必须在行政收尾前完成
      • 行政收尾
        • 具体内容
          • 1. 成果验收与移交
          • 2. 文档归档与知识管理
            • 整理项目全周期文档
          • 3. 经验教训总结
          • 4. 财务与资源收尾
            • 完成财务结算，关闭项目账户，处理剩余预算或未结款项
            • 释放项目资源（如人员、设备），并更新资源技能库。
          • 5. 正式收尾程序
        • 行政收尾与合同收尾的区别
          • 对象不同
            • 行政收尾面向项目内部，而合同收尾针对外部供应商或客户的合同履行
          • 核心活动
            • 行政收尾侧重文档归档和经验总结，合同收尾则需完成采购审计、支付尾款和合同终止确认
          • 顺序
            • 通常先完成合同收尾，再执行行政收尾
  • 敏捷专项考点（新考纲重点）
  • 数据工具速查表
  • 备考技巧
    • 1. 题干关键词法
      • 看到"新项目阶段" → 项目章程
      • 看到"过程稳定性" → 控制图
      • 看到"根本原因" → 鱼骨图
    • 2. 错题整理法
      • 按知识领域分类错题（如所有挣值题集中分析）
      • 记录易混淆点（如确认范围 vs 质量控制）
    • 3. 冲刺策略
      • 重点突破五大过程组交叉考点（如监控阶段的变更+风险应对）
      • 考前3天集中背诵《三色笔记》红色高频点
• 考点公式
  • 问题处理顺序
    • 先问是不是，再问为什么
    • 任何问题先分析评估，再执行再记录/汇报
      • 汇报上报记录前需要对当前环境问题有充分的理解和可能的解决方案
      • 审查
        • 审查在中文语境中是检查对象事物是否合理有误，而不是拿一个参考文件用于评估其他事物
      • 进行实际项目操作之前，应与相关合同条件规定的一致
    • 团队遇到的问题优先团队内部找替代方案解决，客户方没有义务为团队解决问题
      • 遇到问题不能让涉及的两个干系人自己会面解决问题，而是应该积极主动参与问题解决
  • 哪些东西不敏捷
    • 涉及计划就是不敏捷的
    • 敏捷不写文档，包括组织过程资产和事业环境因素等
    • 敏捷反感各类报告
    • WBS-传统管理范围的方式
      • 敏捷用待办事项列表
    • 含有分配、要求、安排等字眼
  • 敏捷团队中，但凡出现项目经理“要求”团队做什么，都是不对的
    • 敏捷中PM时仆人式领导
  • 解答多选题时，排除法是个很好的选项
    • 剔除明显错误项以及没听过的知识点（自创捏造）即可排除到正确答案
    • 因多选题不像单选题可能4个选项都是正确的，但分情况
    • 陌生词不理会
  • 上过敏捷课的PM就是敏捷专家了，不要聘请额外的敏捷顾问
  • 新人加入团队，无论如何第一优先级是为其提供辅导指导
    • 新人要指导，成熟团队要放权
    • 技能提升方法
      • 指导-新人
      • 培训
        • 技能问题找培训
        • 培训需要是PM安排某培训，不要让人自行参加培训项目
      • 老带新-结对
  • 新加入团队的成员，直接与所有干系人开会，比起看干系人登记册那些更直观快速
  • 绝大部分题无需脑补，打直球即可
  • 绝大部流程提需要先谋定-评估情况
  • 如何确保商业价值尽早交付？
    • 将可交付物分解为冲刺，增量式交付价值
  • 质量管理计划无论再简单的工作也需要，没有质量管理计划的话连质量标准都不清楚
  • 沟通管理计划只能约束项目经理和项目团队
    • 无法约束你的领导和外部干系人
  • 冲突管理不选什么警告性质的
    • 可能的选项包含用情商培养冲突双方自我意识
  • 行业和法规两大关键词优先选专家
  • 已获批的变更就不要再提出变更请求了，而是直接将该获批的变更情况同步给干系人，遵循变更请求的流程，要开始执行变更了
  • 开会没空的几大解决方案
    • 1. 提前确认
    • 2. 提供代理替代人员
    • 3. 紧急项目还是可以找领导/发起人
    • 4. 实在没办法还是可以先开会，后续发其会议记录
    • 不要硬等也不必直接找领导
  • 提供培训涉及两个点
    • 资源管理计划
    • 风险登记册
  • 如何促使干系人参与到项目
    • 无决策不参与
      • 让干系人参与治理与决策过程
  • 项目经理进入新项目第一件事
    • 找项目章程，确定项目目标
  • 依赖关系做好沟通
  • 确保与干系人保持沟通的文件
    • 是沟通管理计划
      • 干系人登记册&干系人参与计划会影响沟通效果但不是最关键的因素
  • 如何确保项目持续交付预期效益
    • 制定管理计划时确保收益，要交付收益，就要全面评估所有产品的目标，要确定目标。
  • 虚拟团队找沟通
  • 技术问题，团队自行解决
  • 敏捷中两大团队处理故事点的速度不可比
    • 只能比质量
  • 缺乏目标找章程
  • 敏捷应对变更的方式
    • 在每次迭代之后采取行动重新确定待办事项列表优先级，以评估用户故事对业务是否仍然有价值
      • 不能根据需要变更迭代目标，而是根据用户故事对业务的价值
  • 看板方法中工作出现堆积的时候，要求其他人能够协助瓶颈点，从而缓解阻碍。
    • 敏捷通才型团队，可以临时换岗
  • 怎么确保成功推出产品？
    • 需要成功标准-可量化可测量的绩效指标
  • 模板做好之后需要发表培训计划用于帮助使用者填写
  • 遇到问题，先内部解决，不行再请求外部支持
    • 包括缺资源的时候
  • 情商可预防冲突
    • 项目管理团队能用情商来了解、评估及控制项目团队成员的情绪，预测团队成员的行为，确认团队成员的关注点及跟踪团队成员的问题，来达到减轻压力、加强合作的目的
  • 对产品和功能的改进优先找PO
  • 只有满足被奖励者的某个重要需求的奖励才是有效的奖励
    • 需根据员工的动力和兴趣来奖励
  • 识别风险的参与者，理论上越多越好
  • 发现团队成员做法不符合敏捷规范时，与其一起澄清他们在敏捷项目中的角色和敏捷仪式的范围
    • 如PO不能关注成本高于产品本身
  • 项目经理在敏捷项目中承担2种角色
    • 仆人式领导
      • 促合作清障碍、教育干系人培训团队
    • 教练技术
      • 激励激发、潜能释放、强力提问、赋能
  • 冲刺之中不变更
  • 项目经理打外围，让团队所处环境畅通无障碍
  • 找领导-带方案
    • 澄清解释问题没用，需要带方案找干系人才能减轻其担忧
  • 产品原型
    • 可运用迭代，也可增量，也可持续性反馈
  • 敏捷如何处理风险
    • 团队协作
    • 频繁审查
    • 每个冲刺
  • 过程合规、结果合格，过程审计，结果审查
  • 产品待办事项列表优先级判断
    • 价值+风险/成本
  • 敏捷项目涉及重新设计的，都是需要变更的意思
  • 涉及采购过程中某风险应对失效，审查评估的应该是风险应对过程，不是审计采购过程
  • 风险识别
    • 有一类题干风险未能精准识别到，就是PM在执行项目合同过程中识别到某某重大差异，出现额外的待办工作
      • 这里不应该选择更新WBS，只有正常的范围内的工作需要更新WBS
      • 这里范围外的意外范围应该更新风险登记册
    • 一位新加入管理团队的主管引入了一项会影响所有项目任务的限制性合规要求。项目经理接下来该做什么？
      • 这里的新主管不是抵制而是帮助，应该定义为风险而非需要分析干系人
  • 先恢复当前问题再预防
  • 敏捷价值观
    • 项目经理之前参加的是预测型项目，最近新加入一个敏捷团队，项目正在启动阶段，项目经理坚持要求团队在第一个迭代前完成项目章程，下面哪一个敏捷宣言可以给项目经理作出解释
      • 提了文件了就不要写相应变化胜过遵循计划了，直接工作软件高于详尽文档
      • 启动阶段也还没有计划的事儿
    • 项目发起人要求项目经理为一个新项目探索一种混合方法。该项目的产品经理已经准备了详细的产品规范。项目经理应该怎么做来推进项目管理计划？
      • 选项沾增加价值就选
• 应试技巧
  • 1. 做题提速
    • 读题顺序：最后一句→选项→题干
    • 题干问法
      • 规避事先-找预防措施
      • 下一步/接下来-找纠正措施
      • 避免将来-找经验教训
    • 问题原因大法（从后往前读）
      • 找问题→找原因/背景→找答案
  • 2. 精准答题
    • 流程题选大
      • 分析给出解决方案，越笼统涵盖越大越好
    • 概念题选准
      • 精确
  • 3. 避免干扰
    • 基础知识类
      • 内容
        • 概念理解/辨析、流程顺序
      • 原则
        • 谋定而后动、合规大于天、原则优先、现成的解决方案
    • 答题技巧
      • 人的问题先沟通、事的问题先分析
      • 手段和目的同时出现时优先选目的
      • 程序性的回答优先选，过于具体的不选
        • 程序性回答即官话套话毫无错误无懈可击的正确废话
          • 即越笼统越包罗万象越好
• 考前集训
  • 题目分析
    • 瀑布还是敏捷？
      • 通过关键词区分
        • 例如频繁交付是敏捷
        • 储备、基准、计划CCB、审计、WBS甘特图都是瀑布
        • 同时出现即是混合
      • 不同答题策略
        • 瀑布
          • 一、 一切流程按计划
            • 1. 有计划，要执行
            • 2. 不一致，要变更
              • 产品和计划不一致-缺陷补救
              • 绩效和计划不一致-纠正措施
              • 避免和计划不一致-预防措施
              • 让计划与实际一直-更新
            • 3. 遇风险，先查册
            • 4. 对客户，不惯着
            • 5. 凡信息，找沟通
              • 信息：各类报告、通知、进度信息
          • 二、 遇到问题走流程
            • 1. 遇催促，走流程
              • 催项目开始？制定项目章程。
              • 催进入下给项目？把上个项目收尾。
              • 催变更？走完变更流程。
            • 2. 凡变更，必流程
            • 3. 先分析，再决策
            • 4. 有合规，优先做
            • 5. 找领导，带方案
              • 什么时候找领导？
                • 批准项目章程
                • 风险上报
                • 项目启动之前
                  • 项目未立项时
                  • 如强调项目在建议书谈判期间
                • 项目是否继续
                • 收尾评估成败
                • 管理储备动用
              • 只让领导做选择题
          • 三、 解决不了找专家
            • 懂行业，懂法律
        • 敏捷
          • 一、 以人为本
            • 1. 敏捷人，不加班
              • 敏捷团队可持续性
              • 团队为本，非计划为本
              • 不竭泽而渔，超出团队能力的计划需改变
            • 2. 仆人式，要下放
              • 看到项目经理在敏捷项目中把所有事情都做了就是错的
            • 3. 通才型，很自律
            • 4. 促合作，清障碍
              • 项目经理负责清扫外围，外部遇到问题由PM来清除障碍
            • 5. 做不完，改计划
          • 二、 价值为先
            • 1. 换敏捷，看价值
              • 由瀑布切换至敏捷时，优先看产品价值
            • 2. 高风险，低成本
            • 3. 按冲刺，交价值
              • 如何确保价值尽早交付？将可交付物分解为冲刺按增量交付
          • 三、 拥抱变化
            • 1. 有变更，找PO
              • 重大问题、新增需求、需求变更时找PO
            • 2. 待办项，优先级
  • 场景分析
    • 怎么做决策/决策流程
      • 公式
        • 发现问题
        • 分析问题
        • 解决问题
      • 变更
        • 提出变更
        • 影响分析
        • 提交方案给CCB
      • 监控项目工作
        • 挣值分析
        • 偏差分析
        • 趋势分析
        • 根本原因分析
        • 备选方案分析
        • 成本效益分析
        • 提交变更
      • 风险流程
        • 识别风险
        • 定性、定量分析
        • 规划风险应对
        • 实施风险应对
        • 监督风险
      • 干系人流程
        • 识别干系人
        • 干系人分析
        • 权力利益方格
        • 干系人参与度评估矩阵
        • 规划干系人参与
      • 先更新册子还是先解决问题？
        • 已已发生的问题就优先处理问题，再更新问题日志或变更日志
        • 未发生的则先更新风险登记册，发生后再处理问题
    • 常见场景
      • 一个新人加入
      • 重要会议
      • 干系人直接找团队成员
      • 团队有分歧
  • 技巧分析
    • 做题太慢？
      • 一道题最重要的是题干最后一句话
        • 最后一句-选项-回读题干
      • 从后往前读-问题原因法
    • 选大选小？
      • 场景类问题选笼统大
        • 分析并给出解决方案
      • 概念类问题选精准小
        • 使用什么工具
        • 查看什么文件
        • 更新什么计划
    • 纠结二选一？
      • 高分=（基础知识+语文阅读+答题技巧+软技能）/纠结程度
      • 基础知识
        • 概念辨析
          • 反复看PA7E辨析
        • 流程顺序
          • 谋定而后动
          • 合规大于天
          • 原则优先
          • 现成的解决方案
            • 谋过的就别谋了直接解决问题
      • 语文阅读
        • 出题者思维、语义分析
  • 倒着读题不会的果断弃，努力一下选不出也果断弃
• 时间
  • 9:00
  • 10:00
    • 1-60
  • 11:00
    • 120
  • 12:00
    • 180

中心主题

• 过程
  • （1） 变更流程4/8，基础概念不清晰
  • （2） 风险应对2/8
    • 需要动用应急储备的时候不看成本管理计划
  • （3） 谋定后动0/7
  • （4） Scrum五仪式1/5
    • P
      • 迭代计划会
        • 选故事、领任务、拆任务
    • D
      • 每日站会
        • 15min、轮流开、不讨论不解决问题
        • 只识别记录障碍，其他什么事儿都不做
    • C
      • 迭代评审会
        • 演示、评审、反馈
    • A
      • 迭代回顾会
        • 总结、改进、计划
        • 还是别让团队以外的人来
  • （5） 敏捷价值观4/5
    • 价值为先，第一优先级，能越直接得交付价值就不选间接增加价值的
  • （6） 敏捷角色与职责1/4
    • 找PO的情况
      • 优先级、产品待办事项列表、优先级有冲突、需求变更
      • 需求待明确
        • 需求不明确和DOD团队质量工具无关
    • 制定发布计划和路线图谁做的
      • PO和干系人
    • 团队不对外
  • （7） 项目治理2/3
    • 如何理解？
      • 治理是管理的管理
      • 理解为更高层也更底层的管理
      • 治理涉及问题
        • 项目如何合法合规？
        • 遇事上报给谁？有无CCB？
        • 阶段关口结束后审查什么东西？
        • 公司用什么总结项目知识和经验？
    • 应试
      • 题干涉及没有治理政策，则需要以评估最佳治理政策并采用的答案，直球
      • 治理也是专家精通，不是项目经理能直接选择的
        • 请专家不能专家自己做事情，需要与团队合作
      • 项目关键决策遇到干系人矛盾冲突，项目存在外部阻力，纯粹通过沟通管理计划沟通是解决不好问题的
        • 但是但凡选项中有治理，都优先选
  • （8） 原型法2/3
    • 作用
      • 便于更好地让发起人澄清需求
      • 便于让终端用户了解到完整用户体验
    • 原型与MVP区别
      • 原型便于验证，可交付可不交付，大概率不可交付；而MVP专供交付
    • 应试
      • 一些其他的澄清需求选项存在歧义的时候首选原型法
        • 例如本是团队之间对需求理解不同，选项就不能让干系人之间开会，而应是团队之间
  • （9） MVP/MMF 0/3
    • MVP用来验证，MMF用来即时卖钱
  • （10） DoD 0/3
    • 质量管理工具，表现形式是一列清单，实现就打勾
• 人员
  • 虚拟团队2/9
    • 应试
      • 虚拟团队找沟通
        • 不能强求所有全球成员都能在同一时间开会，首选涉及调整虚拟沟通方法的选项
      • 团队不同城市地点，优先关注物理位置大于文化差异
        • 物理位置是组建跨地域团队时首要明确的要素
      • 要求使用的沟通工具既要实时，又要促进开放协作
        • 远程协作网站优于即时沟通工具
    • 知识拓展
      • 追逐太阳/日不落开发
        • 每天结束时将工作移交给下一个工作地点的方法，以加快产品开发
      • 鱼缸窗口
        • 长期的视频会议链接，视频会议一直在
      • 远程结对
        • 通过使用虚拟会议工具来共享屏幕，包括语音和视频链接:建立远程结对。只要考虑了时区差异因素，这种方法几乎和面对面的结对一样有效。
    • 投资一个虚拟的协作/主机托管环境
  • 冲突管理1/5
    • 直面、谈判、妥协、缓和、强制
      • 强制是last measure，不到万不得已紧急情况不选
    • 无法由团队解决的问题，直接上报HR
  • 清除障碍3/6
    • 障碍分类
      • 流程冗长的部门-与之合作（CCB、审计、财务）
      • 不懂的干系人-教育干系人
      • 不守实践的团队-及时制止
      • 有干扰的环境-主动解决
    • 外部障碍都是项目经理自己清理，不找团队
  • 促进合作0/5
    • 含义
      • 团队绩效高于个人绩效、团队能力高于个人能力
    • 应试
      • 促进合作的项目领导方式？
        • 秒选仆人式领导
      • 针对独狼型选手怎么办？
        • 鼓励其合作
      • 关键词
        • 鼓励合作、达成一致、在线协作
  • 干系人分析1/5
    • 什么是干系人属性变化?
      • 如职权范围变化，会导致其参与度下降。
      • 应当先分析其属性变化再执行措施如让其参与决策
  • 人的问题先沟通1/3
    • 先开会沟通再采取措施
  • 培训0/2
    • 一定要先明确差距（培训需求），实际与培训目标的差距
  • 自组织团队1/3
    • 应试
      • 项目经理收到一份进度报告，显示敏捷项目没有步入正轨。由于所有的工作都是经过精心选择和排序的，以满足更高层次的目标，项目经理对报告感到惊讶。在未来，项目经理如何防止这种类型的沟通失误？
        • 这些工作应该是自组织团队来做的
      • “团队该使用哪种技术？”
        • 技术问题团队自行处理
  • 创建安全环境2/2
    • 含义
      • 只有在安全、诚实和透明的环境中，团队成员和领导才可以真正反思其成功，确保项目持续进步，或者应用从失败项目中所吸取的教训，不再重蹈覆辙。
      • 为了让冲刺回顾会效果更好，应当让成员愿意表达自己经历过的失败和错误，创建安全环境即让他们表达失败时觉得心理环境是安全的，愿意表达
    • 应试
      • 在一个敏捷项目中，项目经理注意到一个团队成员在日常检查中很少报告阻碍因素。此外，这个团队成员很害羞，不愿意参加团队活动，更愿意单独向项目经理提供状态更新。项目经理应该如何纠正这种情况？
        • 为状态更新创造一个安全的空间，并鼓励团队与项目经理沟通。
        • 回顾团队文化和个人性格特征，以解决状态更新差距
      • 不发言？
        • 激励团队成员在会议中自由发言
        • 为其创造安全环境鼓励其发言
  • 获取资源3/3
    • 一个优先级很高的重要资源被“分配到项目组合级别”
      • 共享现有的技术架构师，以便他们可以分配到当前项目和其他项目
  • 情境领导力1/3
    • 新团队加入遇到问题，不要再谋定后动分析根本原因，直接对其进行指导
  • 团队建设0/2
  • 团队章程2
• 业务环境
  • 合规性4/5
    • 含义核心
      • 合规大于天
      • 合规优先于其他一切需求
      • 需项目经理介入
    • 应试
      • 高级管理层建议项目经理忽略这些合规问题，因为当项目达到该阶段时他们会做好准备，并继续制定提案。项目经理首先应该做什么？
        • 验证监管要求并建立合规策略
      • 打直球推进合规执行的选项都选
      • 不清楚合规政策，找专家
    • 关键词
      • 合规、监管、健康安全要求
  • 商业论证3/5
    • 应试
      • 在迭代审查会议期间，当产品进入生产环境时，由于高运营成本，一些产品功能有被取消的风险。项目负责人应该进行什么类型的分析来避免这种情况？
        • 如果能够把单个项目风险的影响进行货币量化，那么就可以通过成本收益分析来确定备选风险应对策略的成本有效性。 特性要取消，要想继续做的话，就得看能不能给组织带来收益。
      • 想要实施新技术
        • 当一个公司考虑引入新的技术或项目时,项目经理的第一步通常是制定商业论证。商业论证将帮助分析该项新技术的可行性、益处、成本、风险和其他相关因素，从而帮助决策者决定是否引进这个技术。
      • 高管要决策建造还是购买
        • 在自制或外购分析中，可以使用回收期、投资回报率（ROI）、内部报酬率（IRR)、现金流贴现、净现值（NPV）、收益成本（BCA）或其他分析技术，来确定某种货物或服务是应该在项目内部自制，还是从外部购买
      • 项目需要和合作伙伴签订协议后才能开始启动阶段，但是因为前一个项目经理没提交协议，合作伙伴不想敲定这件事。项目经理要怎么做？
        • 说服项目发起人起草协议
        • 项目的启动与否取决于发起人
    • 关键词
      • 成本、商业需求、价值度量、提案
  • 收益管理计划1/2
    • 含义
      • 看项目完成后能挣多少钱
      • 商业论证和收益管理计划是商业文件，与组织战略挂钩
    • 关键词
      • 当前项目目的是否与战略一致
    • 应试
      • 商业论证、效益、愿景这些找项目发起人
  • 组织变革2
    • 先从组织层面解决问题，再从团队层面
      • 先获得全面的管理支持
• 其他低正答率题目
  • 项目优先级
    • 评分最高就是指优先级最高
  • 成本估算
    • 没有历史数据时选三点估算
  • 挣值管理
    • 测量项目进度绩效？（Schedule）
      • SPI
      • SV
      • CPI
  • 索赔管理
    • 先礼后兵，再提醒一次再采取其他手段
  • 依赖关系
    • 规划阶段，依赖关系优先包含在进度计划中
  • 信息发射源
    • 可以有效防止镀金
      • 镀金对代码审查一类的质量验收是没用的，镀金是范围层面
  • 项目章程
    • 初始会议/启动会议遇到干系人说不达期望，首先强调项目的总体目标、使命和愿景
  • 澄清需求
    • 请求客户审查并澄清当前冲刺的功能定义
      • 这也是变相的澄清需求
    • 澄清需求无需每周会议澄清，单个问题需澄清就一次性解决澄清清楚
  • 敏捷合同
    • 多层结构、强调价值交付、总价增量、固定时间和材料、累进实践和材料、提前取消方案、动态范围方案、团队扩充、支持全方位供应商
  • 刺探
    • 题干：新的法律、新的技术、新的市场/需求/想法
    • 刺探即预研，摸索
  • 根本原因分析
    • 在项目管理中，项目问题优先团队内解决，解决不了再寻求外界专家等人的帮助/支持。
    • 根本原因分析的首先执行者应该是团队本身
    • remediation
  • 过程改进
    • 如何解决过程改进问题？
      • 了解成员过程背景和相互依赖关系，然后定义改进措施
    • 精益生产
      • 增值活动
      • 不增值活动
        • 多删减该部分
  • 过程流程
    • 启动阶段第一件事
      • 创建项目章程，紧随其后识别干系人
    • 定义好需求之后急着看方案对预算的影响？
      • 先制定工作分解结构（WBS）并执行基于活动的成本估算
      • 后应用挣值技术，将计划的价值与项目关键点上交付的实际价值进行比较
    • 先定义完范围需求WBS再定义质量相关标准
  • 敏捷的运营支持
    • 拉运营代表到评审会议即可，别单独开研讨会
    • 尽早参与
  • 敏捷的资源分配
    • 团队成员想自己组队
      • 目前不同团队成员都在自己的项目中，在项目没有结束并释放资源之前，项目经理需要和大家表明资源是已经分配好的
    • 团队自组织是已建设好的现有团队自组织，不是让其组成小团体
    • 劳动力优化
  • 管理干系人参与
    • 新的干系人不支持
      • 先澄清，后获取支持
    • 干系人因承诺未实现而沮丧
      • 不能直接邀请了，先建立信任
  • 项目成功与项目目标相关联，锁死
  • 敏捷估算
    • 敏捷项目估算不准的解题思路：首先通过分解故事来让故事变小，其次考虑通过敏捷建模或刺探来理解故事。
    • 教育产品负责人项目团队成员是评估工作量的最合适群体
  • 通才
    • 对不同技能是否有专注的专长和丰富的经验
  • 敏捷风险管理
    • 团队协作
    • 频繁审查
    • 每个冲刺中管理
  • 验收标准
    • 在创建项目验收标准时包括项目干系人的期望和需求
      • 原话
    • 安排定期会议与项目干系人讨论，确保他们满意
      • 定期与干系人沟通很重要，但单靠会议无法确保验收标准的有效制定，不如早期阶段就确定清晰的验收标准，然后在整个项目过程中持续关注
  • 什么时候找领导？
    • 批准项目章程
    • 风险上报
    • 项目启动之前
      • 项目未立项时
      • 如强调项目在建议书谈判期间
    • 项目是否继续
    • 收尾评估成败
    • 管理储备动用
  • 收尾流程
    • 交接和交付物验收都已经完成
      • 捆绑
    • 项目的合同交付物已被接受
      • 合同交付物只代表对外，不包括对内
    • 项目结束时提供项目绩效信息
      • 提供状态报告
        • 过程中的报告，不适用于结束
      • 在最终项目报告中记录关键绩效指标（KPIs）
  • DOR
    • 在冲刺计划期间，一些新的待办事项列表项目被优先考虑，但是没有被估计。产品负责人需要一组新的测试来验证项目的唯一属性。在将其添加到冲刺待办事项列表之前应该发生什么？
      • 在评估之前，应定义具体的验收标准，并在任何受影响项目的就绪定义中进行检查，以确保所有工作都得到考虑
      • 添加之前确保用户故事是可行就绪的
  • 资源管理计划
    • 角色和职责信息在责任分配矩阵和资源管理计划中包括
      • 而不是WBS
  • 内建质量
    • 敏捷团队集体对工作负责，质量属于工作的一部分
  • 决策权
    • 要决策权，找发起人申请
    • 干系人参与计划包含谁有决策权
  • 采购谈判
    • 预期的供应商超预算，怎么办
      • 与采购团队合作，找采购团队谈判
  • 敏捷项目章程
    • 敏捷项目的干系人感到不满，因为一些最终产品未能满足他们的期望。当项目经理询问团队关于干系人期望时，团队只提到项目的目标。除了提醒团队干系人期望、利益和影响在项目中的重要性外，项目经理还应该如何改进这种情况？
      • 激励团队创建并使用敏捷项目章程
      • 用户画像还是集中在对干系人的分析上，但根据题干对干系人分析的重要性已得到提醒注意
  • 开发方法
    • 敏捷项目中，产品开发用scrum，维护用看板
  • 商业价值
    • 项目经理向项目发起人提出了关于项目可行性和成功的严重担忧
      • 提议关闭项目，因为它不再符合组织的商业价值
  • 正面机会应对策略
    • 风险上报&接受
    • 风险开拓 Exploit
      • 关键字
        • 确保、100%
        • 分配最有能力的资源、使用全新技术
    • 风险增强/提高 Enhance
      • 关键字
        • 为早日完成活动增加资源
    • 风险分享 Share
      • 关键字
        • 合资
        • 建立合伙关系、合作团队、特殊公司、合资企业
    • Enhance和Exploit区别
      • 增强是增加几率，没到100%，开拓是直接干到100%
  • 在三次敏捷迭代显示出一个越来越长的测试工作的趋势之后，团队执行了一个集中的待办细化。什么指标可以表明问题得到了有效的解决？
    • 精化的结果是更小、更少的复杂故事，这使得团队能够更快地完成它