pmp备考笔记

以PMBOK指南核心框架为核心依托，系统拆解项目全生命周期管理流程，涵盖启动、规划、执行、监控、收尾五大过程组，精准提炼范围管理、时间管理、成本管理等十大知识领域核心要点，去繁就简、聚焦核心。适配PMP备考群体与职场项目管理者，可助力快速梳理知识逻辑、掌握专业管理方法，有效规避项目管理痛点，提升项目管控效能。其层级清晰、重点突出，兼具专业性与实用性，可引导使用者深入研读，精准掌握专业项目管理精髓，高效应对各类项目管理场景与难题。

pmp

• 基本要素
  • 项目
    • 项目的定义
      • 项目是为创造独特的产品、服务或成果而进行的临时性工作
    • 项目的分类
      • 研发项目
        • 目的是开发新产品，如研发手机、汽车、游戏
      • 交付项目
        • 为满足客户需求而提供的服务，如建筑施工、软件定制开发、广告策划
      • 变革项目
        • 企业流程、制度、组织架构等的改变，如信息化、敏捷转型、兼并重组
    • 项目的特征
      • 特征
        • 独特性
          • 独一无二，没有完全一样的两个项目，没法简单重复过去的做法
        • 临时性
          • 也称一次性、阶段性，项目总有开始和结束，是“临时性”的工作
        • 不确定性
          • 项目总是在不断应对变化，风险如影随形，只能渐进明细
      • 举例
        • 开发一款微信小程序就是一个具有独特性的项目，它为了满足某些特定的需求而产生，没有完全一样的代码可以照搬（独特性）；也许几天就可以完成，也许要几周，总之它是可以完成的，所以这是个临时性的工作，甚至项目团队也是临时组建的，干完就散了（临时性）。就算你想好了小程序有哪些功能，也想好了怎么实现，并且制订了严密的时间计划，不过当你真正执行时依旧会遇到很多麻烦。例如低估了某些技术的难度，高估了某些队友的能力，需要修改需求，用户对你提供的功能并不买账等等（不确定性）。你要有能力应对这些不确定性，不断调整计划，直到目标实现
    • 项目和运营
      • 项目
        • 公司产品研发、为客户交付服务、管理变革等项目团队的工作
      • 运营
        • 持续、重复、流程化的工作。
        • 例如，财务部门每天都要记账，每周都要处理报销，每个月都要报税
        • 这些工作过去这么做，现在这么做，将来还是这么做，这就是运营
      • 两者区别
        • 项目：独一无二；运营：重复多次
        • 项目：有始有终；运营：持续不断
        • 项目：革命性（只有一次成功的机会）；运营：渐进性（逐步改进）
        • 项目：责权不均衡；运营：责权均衡
        • 项目：临时性组织；运营：稳定性组织
        • 项目：效果导向；运营：效率导向
        • 项目：不确定（风险）；运营：确定性（经验）
        • 项目：针对性计划；运营：标准化流程
      • 举例
        • 投资建设一个酒店是项目，经营这家酒店为客人提供服务就是运营
        • 互联网公司开发一款App是项目，“拉新-促活-留存-转化”就是运营
      • 总结
        • 开发项目可以创造新产品、新机会
        • 通过运营可以实现其商业价值
    • 项目生命周期和产品生命周期
      • 产品生命周期
        • 产品生命周期是指“概念—交付—成长—成熟—衰退”的全部演变过程
        • 产品生命周期通常比项目生命周期长很多
      • 项目生命周期
        • 项目生命周期一般指的是产品交付阶段， 即“分析—设计—开发—测试”的过程， 只占了产品生命周期一小段周期
    • 开发生命周期
      • 预测型生命周期
        • 预测型生命周期也称为瀑布型生命周期
        • 在生命周期的早期阶段确定项目范围、时间 和成本，对任何范围的变更都要进行仔细管理
        • 对变更不友好，尤其是项目后期，变更代价太大，几乎让人无法接受
      • 迭代型生命周期
        • 项目范围通常于项目生命周期的早期确定，但时间及成本 估算将随着项目团队对产品理解的不断深入而定期修改
        • 迭代方法是通过一系列重复的循环活动来开发 产品，而增量方法是渐进地增加产品的功能
        • 特点
          • 反复求精，从模糊到清晰
        • 举例
          • 画蒙娜丽莎
            • 1.全部画完，但没有上色
            • 2.依次上色直到完成
      • 增量型生命周期
        • 团队先交付一部分成果，之后每个阶段再交付一部分成果，生产产品就像搭积木一样，一块一块搭起来，只有在最后一次迭代之后，可交付成果才能被视为完整的
        • 特点
          • 逐块构建，每次构建一点点
        • 举例
          • 画蒙娜丽莎
            • 1.画头和眼睛
            • 2.画脖子和胸膛
            • 3.画手和腹部
      • 适应型生命周期
        • 适应型生命周期也称为敏捷或变更驱动型生命周期
        • 面对需求易变的场景时，项目团队固定迭代周期和资源，并获得相关方的持续参与
        • 敏捷周期比一般的迭代周期更短，对变更的相应速度更快
      • 混合型生命周期
        • 内涵比较丰富，既包含了狭义的混合敏捷方法，如Scrum与XP的混合、Scrum与看板方法的混合等，也包含了广义的混合型生命周期，如敏捷（适应型）与瀑布开发（预测型）的混合，PMP考试中的混合型生命周期主要是指后者
        • 举例
          • 研发一款新游戏，在预研阶段，采用敏捷方法去确认用户的真实需求， 在正式开发阶段，采用瀑布开发方法来加强计划性和控制能力
    • Stacey矩阵
      • 简单项目（需求明确，解决方案也确定）
        • 例如注册一家新公司
        • 团队最好提前把计划做到位，预测型生命周期最适合
      • 烧脑项目（解决方案很确定，需求却不明确）
        • 例如为客户开发一个信息系统，不需要采用新的技术， 但系统应包含哪些功能，客户总是说不清楚
        • 建议采取混合型开发模式。例如在开发产品原型时用敏捷方法， 在确认需求并验证方案后，在正式开发时用瀑布开发方法
      • 棘手项目（需求很明确，解决方案不确定）
        • 例如“无人驾驶”，需求是明确的，但是技术仍未成熟
        • 建议采取混合型开发模式。例如针对软件部分， 采用敏捷开发，针对硬件部分，采用迭代开发
      • 混乱项目（需求不明确，解决方案也不明确）
        • 失败的概率很高，建议不要碰
      • 混沌项目（需求还在挖掘，解决方案也需探索）
        • 最好采用敏捷开发，因为敏捷开发适应性强、灵活机动，可以拥抱变化
  • 项目集
    • 项目集是一组相互关联且被协调管理的项目、子项目集 和项目集活动，以便获得分别管理所无法获得的利益
    • 项目集不是大项目，规模特别大的项目称为“大型项目”
      • 一般定义，大型项目通常需要 10 亿美元 或以上的成本，可影响上百万人，并且将持续数年
    • 项目集举例
      • 建立一个新的通信卫星系统就是项目集的一个实例，其所辖 项目包括卫星与地面站的设计和建造、卫星发射以及系统整合
  • 项目组合
    • 项目组合是指为实现战略目标而组合在一起 管理的项目、项目集、子项目组合和运营工作
    • 在开展组织和项目组合规划时，要基于风险、 资金和其他考虑因素对项目组合组件排列优先级
    • 项目组合管理
      • 项目组合管理是指为了实现战略目标而对一个或多个项目组合进行的集中管理
      • 项目组合中的项目集或项目不一定彼此依赖或直接相关
      • 此外，项目组合管理还可确定项目组合是否符合组织战略
        • 要实现项目组合价值的最大化，需要精心检查项目组合的组成部分
        • 确定组成部分的优先顺序，使最有利于组织战略 目标的组成部分拥有所需的财力、人力和实物资源
        • 例如，以“投资回报最大化”为战略目标的某基础设施公司， 可以把油气、供电、供水、道路、铁路和机场等项目归并成一个项目组合
        • 在这些归并的项目中，组织又可以把相互关联的项目作为项目组合来管理。 所有供电项目归类成供电项目组合，同理，所有供水项目归类成供水项目组合
        • 然而，如果组织的项目是设计和建造发电站并运营发电站，这些相互 关联的项目可以归类成一个项目集。这样的话，供电项目集和类似的 供水项目集就是该基础设施公司项目组合中的基本组成部分。
    • 从组织的角度来看项目、项目集和项目组合管理
      • 项目集和项目管理的重点在于以“正确”的方式开展项目集和项目
      • 项目组合管理则注重于开展“正确”的项目集和项目
• 十大知识领域
  • 项目整合管理
    • 包括为识别、定义、组合、统一和协调各项目 管理过程组的各个过程和活动而开展的过程与活动
  • 项目范围管理
    • 包括确保项目做且只做所需的全部工作以成功完成项目的各个过程
  • 项目进度管理
    • 包括为管理项目按时完成所需的各个过程
  • 项目成本管理
    • 包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程
  • 项目质量管理
    • 包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求，以满足相关方的期望的各个过程
  • 项目资源管理
    • 包括识别、获取和管理所需资源以成功完成项目的各个过程
  • 项目沟通管理
    • 包括为确保项目信息及时且恰当地规划、收集、生成、发布、存储、检索、管理、控制、监督和最终处置所需的各个过程
  • 项目风险管理
    • 包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程
  • 项目采购管理
    • 包括从项目团队外部采购或获取所需产品、服务或成果的各个过程
  • 项目相关方管理
    • 包括用于开展下列工作的各个过程：
      • 识别影响或受项目影响的人员、团队或组织
      • 分析相关方对项目的期望和影响
      • 制定合适的管理策略来有效调动相关方参与项目决策和执行
• 五大过程组
  • 分类
    • 启动过程组
      • 定义一个新项目或现有项目的一个新阶段，授权开始该项目或阶段的一组过程
    • 规划过程组
      • 明确项目范围，优化目标，为实现目标制定行动方案的一组过程
    • 执行过程组
      • 完成项目管理计划中确定的工作，以满足项目要求的一组过程
    • 监控过程组
      • 跟踪、审查和调整项目进展与绩效，识别必要的计划变更并启动相应变更的一组过程
    • 收尾过程组
      • 正式完成或结束项目、阶段或合同所执行的过程
  • 备注说明
    • PMI根据大量企业的实践总结出49个过程，按照 启动、规划、执行、监控和收尾把项目管理分成五大过程组
    • 五大过程组并不是简单地按顺序发生，而是同时存在、相互作用的
• 项目经理的角色
  • 项目经理的定义
    • 项目经理是由执行组织委派，领导团队实现项目目标的个人
  • PMI 人才三角
    • PMI人才三角是项目经理应具备的能力
      • 技术项目管理
        • 与项目、项目集和项目组合管理特定领域 相关的知识、技能和行为，即角色履行的技术方面
        • 技术项目管理技能指有效运用项目管理知识实现项目集或项目的预期成果的能力
        • 顶尖的项目经理会持续展现出几种关键技能，包括（但不限于）：
          • 重点关注所管理的各个项目的关键技术项目管理要素， 简单来说就是随时准备好合适的资料。最主要的是：
            • 项目成功的关键因素
            • 进度
            • 指定的财务报告
            • 问题日志
          • 针对每个项目裁剪传统和敏捷工具、技术和方法
          • 花时间制定完整的计划并谨慎排定优先顺序
          • 管理项目要素，包括（但不限于）进度、成本、资源和风险
      • 领导力
        • 指导、激励和带领团队所需的知识、技能和行为，可帮助组织达成业务目标
        • 领导力技能包括指导、激励和带领团队的能力
        • 这些技能可能包括协商、抗压、沟通、 解决问题、批判性思考和人际关系技能等基本能力
      • 战略和商务管理
        • 关于行业和组织的知识和专业技能，有助于提高绩效并取得更好的业务成果
        • 战略和商业技能有助于项目经理确定应为其项目考虑 哪些商业因素，这些因素包括（但不限于）：
          • 风险和问题
          • 财务影响
          • 成本效益分析（例如净现值、投资回报率），包括各种可选方案
          • 商业价值
          • 效益预期实现情况和战略
          • 范围、预算、进度和质量
  • 卓越领导者的五种行为习惯
    • 以身作则
      • 明确自己的价值观，使行动与价值观保持一致，为他人树立榜样
    • 共启愿景
      • 展望未来，想象令人激动的各种可能；描绘共同愿景，感召他人为共同愿景而奋斗
    • 挑战现状
      • 通过掌握主动权和从外部获取创新的方法来寻求改进的机会； 进行尝试和冒险，不断取得小小的成功，从实践中不断学习
    • 使众人行
      • 通过建立信任和增进关系来促进合作，通过增强 团队成员的自主意识和发展能力来增强他们的实力
    • 激励人心
      • 通过表彰来认可他人的贡献，通过创造一种集体主义精神来庆祝价值的实现
  • 邓宁—克鲁格心理效应（达克效应）
    • 胜任力的培养需要经历四个阶段
      • 第一阶段：虽然你的能力不行，但是觉得自己无所不能。 这样的“自信”是“谁”给的？是”无知“！正所谓，无知者无畏
      • 第二阶段：真正面对问题，发现自己”学啥啥不会，干啥啥不成“！ 从此，你的自信心崩塌，跌入绝望之谷，终于知道自己不知道
      • 第三阶段：通过不断学习，你的认知边界开始扩展，你开始重建自信。 不过，你已知的越多，发现的未知也就越多。你在这个阶段获得了正确 认识自己的能力，开始变得理性、客观
      • 第四阶段：你将知识内化为自己的能力，优秀变成了自己的习惯， 自己有多牛自己都不知道，你成了真正的大师。你很谦逊，因为 你能看清在浩瀚的知识海洋面前自己是多么的渺小
  • 管理与领导力
    • 管理
      • 管理主要是通过项目经理这个职位获得授权，例如，项目经理可以 抽调人员组建团队，可以做出项目方案决策，进行变更管理，绩效评价等
    • 领导力
      • 领导力是通过激发、指引、鼓励和帮助团队成员，使其获得成果或进步
    • 两者区别
      • 管理：直接利用职权；领导力：利用关系的力量指导、影响与合作
      • 管理：维护；领导力：建设
      • 管理：关注系统和架构；领导力：关注人际关系
      • 管理：依赖控制；领导力：激发信任
      • 管理：关注近期目标；领导力：关注长期愿景
      • 管理：了解方式和时间；领导力：了解情况和原因
      • 管理：关注盈利；领导力：关注范围
      • 管理：接受现状；领导力：挑战现状
      • 管理：正确地做事；领导力：做正确的事
      • 管理：关注可操作的问题和问题的解决； 领导力：关注愿景、一致性、动力和激励
  • 领导力风格
    • 项目经理领导团队的方式可以分为很多种。项目经理可能会出于 个人偏好或在综合考虑了与项目有关的多个因素之后选择领导力风格
    • 根据作用因素的不同，项目经理可能会改变风格。 要考虑的主要因素包括（但不限于）：
      • 领导者的特点（例如态度、心情、需求、价值观、道德观）
      • 团队成员的特点（例如态度、心情、需求、价值观、道德观）
      • 组织的特点（例如目标、结构、工作类型）
      • 环境特点（例如社会形势、经济状况和政治因素）
    • 研究显示项目经理可以采用的多种领导力风格。 在这些风格中，最常见的包括（但不限于）：
      • 放任型领导
        • 放任型领导充分信任团队成员，激励团队成员 自己设定目标、规划方案、采取行动，追求无为而治
      • 交易型领导
        • 交易型领导强调赏罚分明、有言在先、论功行赏，规则清晰并严格执行
      • 服务型领导
        • 通过对团队成员无微不至的关怀和周到细致的服务，使其愿意追随。
        • 服务型领导也叫”仆人式领导“，领导者愿意做下属的”仆人“，并尽可能地满足下属的合理要求，与员工之间建立关爱、尊重、信任、接纳的关系，进而建立起领导者的影响力及威信，并以此来激励员工发挥最大潜能，为实现企业的共同目标而努力工作
      • 变革型领导
        • 变革型领导关注组织，强调集体的力量，带领团队一起努力，让组织越变越好
      • 魅力型领导
        • 魅力型领导是靠领导者的专业、人格魅力来影响和带动团队
      • 交互型领导
        • 交互型领导综合了交易型、变革型和魅力型领导的特征
  • 执行整合
    • 整合是项目经理的核心工作， 在执行整合中应专注以下方面
      • 一个宗旨
        • 以成功交付项目并为客户/用户创造价值为宗旨
      • 两个角色
        • 团队之外
          • 整合发起人、公司高级管理层、相关方的需求，使项目成果与战略目标相一致
        • 团队之内
          • 整合不同专业、不同背景的团队成员，使其协同一致，交付价值
      • 三个层面
        • 过程层面
          • 梳理、裁剪、配置项目管理的49个过程
        • 认知层面
          • 梳理、裁剪、配置十大知识领域，应用已有的知识，积累新知识
        • 背景层面
          • 梳理、裁剪、配置跨组织、跨行业、跨文化等环境因素
      • 四个对象
        • 整合资源
          • 包括人、资金、设备、材料等
        • 整合需求
          • 从众口难调到达成共识
        • 整合信息
          • 从纷繁复杂到清晰有序
        • 整合方法
          • 包括工具、技术、方案等
      • 五个满意
        • 用户满意
        • 投资人满意
        • 合作伙伴满意
        • 团队成员满意
        • 领导满意
  • 复杂性的三个维度
    • 系统行为
      • 组成部分与系统之间的依赖关系
    • 人类行为
      • 不同个体和群体之间的相互作用
    • 不确定性
      • 因出现问题、缺乏理解、造成困惑而引起的不确定性
• 组织运行环境
  • 分类
    • 事业环境因素（EEF）
      • 源于项目外部（往往是企业外部）的环境，事业环境因素可能对整个企业、项目组合、项目集或项目产生影响
      • 指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。这些条件可能来自于组织的内部和（或）外部
        • 组织内部的事业环境因素
          • 组织文化、结构和治理
            • 例如包括愿景、使命、价值观、信念、文化规范、领导 风格、等级制度和职权关系、组织风格、道德和行为规范
          • 设施和资源的地理分布
            • 例如包括工厂位置、虚拟团队、共享系统和云计算
          • 基础设施
            • 例如包括现有设施、设备、组织通讯渠道、信息技术硬件、可用性和功能
          • 信息技术软件
            • 例如包括进度计划软件工具、配置管理系统、进入其他在线自动化系统的网络界面和工作授权系统
          • 资源可用性
            • 例如包括合同和采购制约因素、获得批准的供应商和分包商以及合作协议
          • 员工能力
            • 例如包括现有人力资源的专业知识、技能、能力和特定知识
        • 组织外部的事业环境因素
          • 市场条件
            • 例如包括竞争对手、市场份额、品牌认知度和商标
          • 社会和文化影响与问题
            • 例如包括政治氛围、行为规范、道德和观念
          • 法律限制
            • 例如包括与安全、数据保护、商业行为、雇佣和采购有关的国家或地方法律法规
          • 商业数据库
            • 例如包括标杆对照成果、标准化的成本估算数据、行业风险研究资料和风险数据库
          • 学术研究
            • 例如包括行业研究、出版物和标杆对照成果
          • 政府或行业标准
            • 例如包括与产品、生产、环境、质量和工艺有关的监管机构条例和标准
          • 财务考虑因素
            • 例如包括货币汇率、利率、通货膨胀率、关税和地理位置
          • 物理环境要素
            • 例如包括工作环境、天气和制约因素
      • 事业环境因素是很多项目管理过程，尤其是大多数规划过程的输入
    • 组织过程资产 （OPA）
      • 源于企业内部，可能来自企业自身、项目组合、项目集、其他项目或这些的组合
      • 是执行组织所特有并使用的计划、过程、政策、 程序和知识库，会影响对具体项目的管理
      • 分类
        • 过程、政策和程序
          • 过程、政策和程序是用来规范和指导项目管理的， 比如，项目立项要经过哪些步骤，项目验收要满足哪些条件，需求变更该走什么程序
          • 包括PMO管理和编撰的项目计划模板、操作手册、项目管理指南等
        • 组织知识库
          • 整个项目期间会持续更新与财务绩效、经验教训、 绩效指标和问题以及缺陷相关的信息，便于以后的项目团队参考
    • 组织系统
      • 组织治理框架
        • 规则
        • 政策
        • 程序
        • 规范
        • 关系
        • 系统
        • 过程
      • 管理要素
        • 基于专业技能开展工作
        • 组织授予的工作职权
        • 合理分派的工作任务
        • 具有纪律性的行为
        • 统一领导和指导原则
        • 组织总体目标高于个人目标
        • 支付合理的薪酬
        • 资源的优化使用
        • 畅通的沟通渠道
        • 人尽其才，物尽其用
        • 公平和平等地对待所有员工
        • 明确岗位安全职责
        • 允许员工广泛参与
        • 保持员工士气
      • 组织结构类型
        • 系统型或简单型
          • 创业团队
        • 职能（集中式）
          • 按职能划分部门
        • 多部门（分布式）
          • 事业部、产品事业群、地区公司
        • 弱矩阵型
          • 项目经理<职能经理
        • 平衡矩阵型
          • 项目经理=职能经理
        • 强矩阵型
          • 项目经理>职能经理
        • 项目型
          • 项目公司
        • 虚拟组织
          • 通过网络协作
      • 组织级项目治理
        • 项目组合治理
        • 项目集治理
        • 项目治理
      • 项目管理办公室（PMO）
        • 支持型
        • 控制型
        • 指令型
      • 组织结构原则
        • 与组织目标一致
        • 发挥专业能力
        • 可控、高效
        • 明确的决策升级渠道
        • 明确的职权边界和范围
        • 明确的授权机制
        • 职责分配和终责承担
        • 尽量简单且保持灵活
        • 成本和效率优化
        • 恰当的物理距离
        • 清晰的沟通
  • 事业环境因素和组织过程资产区别
    • 出自
      • EEFs：政府、行业协会、公司管理层；OPA：历史项目团队及PMO
    • 用途
      • EEFs：遵守；OPA：参考
    • 方式
      • EEFs：被动接受，入乡随俗；OPA：主动参与，更新维护
  • 治理和管理
    • 治理
      • 治理可以被理解为“定规矩”，实现责、权、利的合理分配与制衡。 例如公司里谁向谁汇报，谁对谁负责
    • 管理
      • 管理是在治理的框架下实现经营目标的所有举措
    • 两者区别
      • 定位
        • 治理：宏观，稳定；管理：具体，灵活
      • 目的
        • 治理：设计组织制度、制定规划、定义决策机制； 管理：提高组织效率、达成经营目标
      • 主体
        • 治理：董事会；管理：经营层

文件/概念

• 项目管理商业文件
  • 项目商业论证
    • 文档化的经济可行性研究报告，用来对尚缺乏充分定义的 所选方案的收益进行有效性论证，是启动后续项目管理活动的依据
    • 商业论证列出了项目启动的目标和理由，它有助于 在项目结束时根据项目目标衡量项目是否成功
    • 由项目发起人负责
  • 项目效益管理计划
    • 对创造、提高和保持项目收益的过程进行定义的书面文件
    • 描述了项目实现效益的方式和时间，以及应制定的效益衡量机制
    • 项目效益指为发起组织和项目预期受益方创造 价值的行动、行为、产品、服务或成果的结果
    • 描述了效益的关键要素，可能包括（但不限于）记录以下内容：
      • 目标效益
        • 例如预计通过项目实施可以创造的有形价值和无形价值；财务价值体现为净现值
      • 战略一致性
        • 例如项目效益与组织业务战略的一致程度
      • 实现效益的时限
        • 例如阶段效益、短期效益、长期效益和持续效益
      • 效益责任人
        • 例如在计划确定的整个时限内负责监督、记录和报告已实现效益的负责人
      • 测量指标
        • 例如用于显示已实现效益的直接测量值和间接测量值
      • 假设
        • 例如预计存在或显而易见的因素
      • 风险
        • 例如实现效益的风险
    • 由项目经理负责
  • 项目章程
    • 项目章程是由项目发起人发布的，正式批准项目成立， 并授权项目经理动用组织资源开展项目活动的文件
    • 由项目发起人负责
  • 项目管理计划
    • 项目管理计划是描述如何执行、监督和控制项目的一份文件
    • 由项目经理负责
• 关键技术
  • 专家判断
    • 专家小组法
    • 德尔菲技术

计算

• 财务评价
  • 静态评价
    • 投资回报率（ROI）
      • 投资带来的年化收益率
    • 投资回收期（PBP）
      • 收回投资的年限
  • 动态评价
    • 复利计算
      • 终值=现值x(1+i)n
    • 折现计算
      • 现值=终值/(1+i)n
    • 常用指标
      • 净现值（NPV）
        • IRR一样，NPV越高越好，意味着回报越高
      • 内部收益率（IRR）
        • NPV一样，IRR越高越好，意味着抗风险能力越强
      • 效益成本比率（BCR）
        • 增加的效益和相应多投入的成本之间的比值

重要结论

• 敏捷专项
  • 当前冲刺中未完成的故事不能直接安排在下一个冲刺，需要重新返回到产品待办事项列表，让PO重新调整了优先级之后，再按优先级的顺序来流入到下一个冲刺中
  • 敏捷方法
    • 看板
      • 定义
        • 它是一种受到看板库存控制系统启发的敏捷方法，专门用于知识工作
      • 作用
        • 可视化、灵活、提高效率、减少浪费
      • 关键字
        • 工作流可视化，限制在制品，提高协作性
    • Scrum
      • 定义
        • 它是一种复杂产品开发与维持的敏捷框架，它由特定的角色、事件和工件等元素组成
      • 作用
        • 通过待办列表，不断地增加产品增量
      • 关键字
        • 待办列表、每日站会、冲刺、PO、SM等
    • 水晶
      • 定义
        • 它是轻量级敏捷软件开发方法的集合，其重点关注特定情况的适应性
      • 作用
        • 用水晶的不同颜色表示项目的复杂度和团队数量大小
      • 关键字
        • 透明色（<8）、黄色（10-20）、橙色（20-50）、红色（50-100）
    • 改善
      • 定义
        • 它是旨在对系统加以改善的活动
      • 作用
        • 持续不断地获得小进步过程
      • 关键字
        • PDCA，持续改善
  • 在成熟的敏捷环境里，项目经理是仆人式领导的角色，很多决定让自组织成员去做
  • 在敏捷或适应型环境中需要考虑的因素，在适应型环境下，整合管理的核心概念中所述的对项目经理的期望不变，但是把对具体的产品的规划和交付授权给团队控制
  • 仆人式领导的一个作用是消除组织障碍
    • 仆人式领导还应该关注其他冗长的过程，这些过程往往造成瓶颈问题，阻碍团队或组织的敏捷性。可能需要处理的过程或部门的例子包括，财务部门、CCB或审计部门
    • 合规性一般都会成为敏捷项目的障碍，因此要消除这些障碍，只做必要的工作
  • 待办事项优先级排序根据风险的高低与价值的大小进行优先排序
    • 高风险、高价值（最先执行）
    • 低风险、高价值
    • 低风险、低价值
    • 高风险、低价值（尽量避免）
  • 在敏捷项目中，需求的变化是先通过产品负责人纳入到产品待办事项列表中，然后在每一个迭代的规划会议上根据价值的优先级由开发团队确认是否纳入到迭代中。而传统项目是需要走整体变更控制流程的，敏捷则不需要走
  • 用户故事代表客户需求的具体点，为客户增加价值，一般由3部分组成：作为一个【角色】；我需要一个【功能】以便我能【达成目的】。是给客户增值的最小工作单元
  • 只有需求发生变化时，才会审查DOD
  • 增量是团队在Sprint中实际交付的结果。团队在Sprint之初想要完成的待办项与他们实际做的工作并不完全一致。增量是实际发生的结果，在真正交付之前，团队并不知道当前Sprint的增量会包含什么
  • 在一个Scrum团队中，产品负责人的工作就是与利益相关者（或关键相关方)会面，帮助他们了解问题，并向团队沟通解决方案。团队成员尽量不要直接单独向利益相关者提出问题，要确保始终有产品负责人的参与
  • 高绩效团队的两个主要特点，一是工作方式自组织，二是设定挑战性目标，以实现绩效为根本目的
  • 敏捷中的风险应对方式跟传统的瀑布的风险应对流程比较相似，同时，敏捷提倡风险要尽早曝光和处理。所以，风险出现后要让风险曝光出来，以便在站会上提出
  • 敏捷对于迭代规划采用的是滚动式规划的方式，为了避免项目中的短视问题，因此应该快速识别未知事项，并扩大实践，包含规划和展望
  • 敏捷一般不会专门强调要去更新相关方登记册，而是直接让相关方参与到实际工作中
  • 敏捷中遇到风险、变更，都要先添加到待办事项列表，确定其优先级，再决定什么时候处理这些问题
  • 冲刺中发现本项目团队与其他团队之间的信息不同步，最有可能的就是项目的冲刺板的内容没有进行更新，因为涉及到多个团队之间的协作，有关整个冲刺的待办事项以及信息都会同步在项目冲刺板中，这个如果没有更新，团队之间的信息就无法进行同步
  • 在敏捷场景里面，对于变更的处理，正确的敏捷实践应该是在下个冲刺开始的时候制定冲刺计划的时候来确定是否变更和排定优先级
  • 看板
    • 看板是带有卡片的物理看板面板，它能够推动和实现整个系统中工作流的可视化，让每个人都可以看到。“卡片上编写用户故事”“指示何时可以提取新的工作”“有助你看见工作流程”都是看板的特点
  • Scrum板
    • Scrum版是一种用于管理产品代办事项列表和冲刺代办事项列表的信息发射源，它能够清楚地展现团队角色及职责，帮助团队更新任务进度，促进团队信息共享，及时发现任务过程中的异常现象，从而查漏补缺
  • 任务板
    • 任务板跟Scrum板是一样的，它们流动的都是任务
  • 用户故事板
    • 用户故事板可以理解为铺上所有用户故事的一块板子，它类似用户故事地图，不过用户故事地图画有发布分支线，单纯的用户故事板没有这条线
• 项目风险管理
  • 整体项目风险应对策略。取消项目范围中的高风险工作，是一种整个项目层面的规避措施
  • 针对单个风险的应对计划过于具体，不适合汇报，提供风险报告较为合适
  • 成本效益分析侧重于从财务视角评估投入产出效果
  • 头脑风暴通常用于识别风险
  • SWOT分析是识别风险的工具
  • 应急储备专项专用，未用到的需要通过变更释放资源
  • “如何避免”避免指风险不在发生，选择规避策略。上报，减轻，转移都无法避免风险的发生
  • 一个已被识别的风险应当规划并实施应对，其中实施应对的一个关键措施就是分配资源以应对风险
  • “审核期间，识别的风险已通过审核”表明风险应对已实施，可以关闭，并将结果更新到风险登记册上。确实应该继续监督该风险直到项目完成，但不是因为该风险还会发生，而是因为需要监督风险是否发生变化而导致之前实施的应对不再起作用了
  • 由于风险关闭而释放的应急储备应该释放给组织，而不是在项目内继续使用
  • 已关闭的风险不用再继续监督。若有新风险或此生风险应该再记录在登记册中
  • 识别出来的风险要首先记录到风险登记册，然后对风险进行分析评估，根据评估的结果制定风险应对计划
  • 风险管理计划是在项目实施期间的风险管理活动，针对单个风险编订的是应急计划和弹回计划
  • “风险已经成为问题”，风险被触发，查阅风险登记册，实施预设的风险应对计划
  • 风险已识别所以不能用管理储备
  • “执行了风险应对措施，已经成功构建”表示风险应对已实施，后续就是总结经验用于后续项目。项目经理应该更新经验教训登记册
  • 已识别风险，之后做什么，那么按照顺序分别为定性分析，定量分析，规划应对
  • 风险已发生，先解决再登记
  • 风险报告是向相关方提供的风险的情况信息；风险应对计划是用来应对风险降低风险发生概率或危害的；风险登记册是用来跟踪风险的，都不是用来管理风险的
  • 次生风险是实施风险应对措施而直接导致的风险， 如不实施风险应对措施，次生风险就不存在
  • 残余风险是采取风险应对措施后仍然存在的风险，是没有主动应对的、被动的风险
  • 风险再评估
    • 控制风险中需有计划地（次数和详细程度，应该根据相对于目标的进展情况而定）识别新风险，对现有风险进行再评估，以及删去已过时的风险
  • 实施定性风险分析是通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程。 识别完风险后要定性分析
  • 风险分解结构就是对风险进行分类的
  • 制定应急计划属于风险接受
• 上下文图
  • 建立了参与者和系统之间的本质关系。最重要的是区分出什么是系统内的，显示出哪些参与者与系统交互
• 例外管理
  • 例外管理指的是项目经理只对极端的情况进行管理， 其他的工作都交由团队来处理。不适用于正在转型中的团队
• 六大分析
  • 1.备选方案分析
    • 备选方案分析用于在出现偏差时选择要执行的纠正措施或纠正措施和预防措施的组合
  • 2.成本效益分析
    • 成本效益分析有助于确定最节约成本的纠正措施
    • 成本效益分析可帮助项目经理确定规划的质量活动是否有效利用了成本
  • 3.挣值分析
    • 挣值分析对范围、进度和成本绩效进行了综合分析
  • 4.根本原因分析
    • 它可用于识别出现偏差的原因
  • 5.趋势分析
    • 趋势分析根据以往结果预测未来绩效
  • 6.偏差分析
    • 偏差分析审查目标绩效与实际绩效之间的差异
  • 分析顺序：365412，做完后就是实施变更整体控制流程了
• 项目采购管理
  • 工料合同是兼具成本补偿合同和总价合同特点的混合型合同。这种合同往往 适用于：在无法快速编制出准确的工作说明书的情况下扩充人员、聘用专家或寻求外部支持
• 塔克曼阶梯理论
  • 形成阶段
    • 成立新团队
    • 项目经理风格：指导式
  • 震荡阶段
    • 这人怎么这样
    • 项目经理太霸道了
    • 我凭什么相信你
    • 关键字
      • 对立、争吵
    • 项目经理风格：教练式
  • 规范阶段
    • 这人接触多了，感觉还行
    • 试着信你一下
    • 我们按照规则来
    • 关键字
      • 开始尝试，建立信任，学习相互信任
    • 项目经理风格：参与式
  • 成熟阶段
    • 这个晚上加班到12点给你搞定
    • 这活我来
    • 人多就是力量大
    • 关键字
      • 组织有序，互相帮助
    • 项目经理风格：委任式
  • 解散阶段
    • 不想说再见
• 项目变更管理
  • 如果题目是考变更，基本上选项只要有实施整体变更控制这几个字就是正确选项
  • 变更审批前三步骤
    • 相关方提出变更
    • PM与团队分析影响
    • 提交变更
• 应急储备
  • 应急储备通常是一个估算，风险发生时，就会变得明晰。 可能会多用，也可能会少用，多用的部分和少用的部分，按照规定应该进行变更。
  • 如果有的风险没有发生，那么针对那个没发生的风险， 应急储备就应该撤销，也是走变更控制程序
• 收尾流程
  • 项目中止，项目经理正常安排收尾，调查原因并总结经验教训
  • 如果项目在完工前提前终止，则需要在正式的收尾文件中说明项目终止 的原因，并规定正式程序，把该项目的已完成和未完成的可交付成果移交他人
  • 第一步 核实
    • 英文 Verified
    • 质量控制后的核实，好不好
    • 一般用于内部
  • 第二步 验收
    • 英文 Accepted
    • 确认范围后的验收，对不对
    • 一般用于外部
  • 第三步 中止
    • 项目中止，先要调查原因，再更新经验教训。调查原因的目的是经验教训
  • 第四步 移交
    • 英文 Transition
    • 交付所有权，转交给运营团队
• 项目范围管理
  • 范围确认是让主要相关方（如：客户）正式验收 本阶段完成的可交付成果。是每阶段结束时都要做
    • 确认范围是对项目交付成果的验收
  • 项目范围说明书是定义范围的输出，属于规划阶段
  • 收集到的需求要经过筛选决策才能列入范围
    • 不是所有的需求都会列入范围基准
  • 项目经理刚进入规划阶段，那么需要制定相应的范围 管理计划才能开始执行收集需求等制定范围的工作
  • 工作分解结构和范围说明书都依赖范围管理计划
  • 范围有歧义，要查看合同中对可交付成果的定义
  • 项目章程最后一条记录着批准章程人员的姓名。当项目发起人没有空正式授权项目启动时，项目经理可以审查项目章程以查看是否有另一方可以对其进行授权
  • 通常，在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。 工作环境的潜在问题属于假设与制约，应该记录在项目章程中
  • 如果项目在完工前提前终止，则需要在正式的收尾文件中说明项目终止的原因，并规定正式程序，把该项目的已完成和未完成的可交付成果移交他人。法院已经是最后的纠纷解决方案了，因此要中止项目
  • 需求文件用于证明符合项目范围。 批准方离职，就在收尾阶段将范围与需求文件对比，得出结论
• 项目资源管理
  • 资源管理计划
    • 认可计划。将给予团队成员哪些认可和奖励，以及何时给予
  • RACI（执行、负责、咨询和知情）矩阵是责任分配矩阵RAM的其中一种类型，在团队是由内部和外部人员组成的情况下，RACI 矩阵对明确划分角色和职责特别有用
• 引导
  • 引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求。 研讨会可用于快速定义跨职能需求并协调相关方的需求差异
• 工作绩效报告
  • 根据沟通管理计划的定义，工作绩效报告会通过本过程传递 给项目相关方。工作绩效报告的典型示例包括状态报告和进展报告
• 文化意识
  • 具有文化意识并采取后续行动，能够最小化因项目相关方社区内的文化差异 而导致的理解错误和沟通错误。文化意识和文化敏感性有助于项目经理依据 相关方和团队成员的文化差异和文化需求对沟通进行规划
• 项目相关方管理
  • 思维导图用于对相关方信息、相互关系以及他们与组织的关系进行可视化整理
  • 相关方参与度评估矩阵用于将相关方当前参与水平与期望参与水平进行比较
  • 项目相关方被替换了，第一件事就是更新相关方登记册
  • 相关方参与计划
    • 是项目管理计划的组成部分。它确定用于促进相关方有效参与决策和执行的策略和行动。相关方参与计划可包括（但不限于）调动个人或相关方参与的特定策略或方法
  • 管理相关方参与是执行阶段做的事
  • 要想确保一个相关方参与，则需要对比他现在的参与水平 和期望的参与水平，这个对比的工具就是相关方参与度评估矩阵
  • 相关方的权力/利益方格在相关方登记册里
• 管理团队
  • 项目经理应该向团队成员分配富有挑战性的任务，对优秀绩效进行表彰。项目经理应留意团队成员是否有意愿和能力完成工作，然后相应地调整管理和领导力方式。相对那些已展现出能力和有经验的团队成员，技术能力较低的团队成员更需要强化监督
  • 团队建设的主要作用，就是通过团队建设提高团队绩效，进而提高项目绩效
• 项目进度管理
  • 从未做过的项目，意味着存在着较大的不确定性和风险， 这种时候通过三点估算来估算成本
  • 资源平衡会带来关键路径延长，影响工期
  • 进度网络分析
    • 进度网络分析是创建项目进度模型的一种综合技术，它采用了其他几种技术， 例如关键路径法，资源优化技术和建模技术。进度网络分析是一个反复进行 的过程，一直持续到创建出可行的进度模型
  • 关键路径法用于在进度模型中估算项目最短工期，确定逻辑网络路径的 进度灵活性大小。关键链法就是考虑了资源约束的关键路径法
• 机密文件的处理
  • 机密文件的处理需要审查合同中的要求，以确保正式关闭项目
• 储备分析
  • 在整个项目执行期间，可能发生某些单个项目风险，对预算和进度应急储备 产生正面或负面的影响。储备分析是指在项目的任一时点比较剩余应急储备 与剩余风险量，从而确定剩余储备是否仍然合理
• 项目成本管理
  • 挣值分析的核心就是综合了成本和进度的数据来评价项目绩效和预测未来趋势
  • 挣值分析是项目过程中的绩效评估，主要不是用于项目完成时评估
• 项目质量管理
  • 管理质量又称质量保证 QA，针对质量管理过程的有效性， 这个过程中可能发现过程可以优化的机会，就是过程改进的含义
  • 帕累托图的原理就是将缺陷按原因归类后排序（缺陷从多到少），然后画出缺陷累计曲线，少数原因造成的缺陷已占到总缺陷数量的大部分。帮助项目经理集中精力针对少数原因就能解决大部分缺陷
  • 成本效益分析是用来估算备选方案优势和劣势的财务分析工具，以确定可以创造最佳效益的备选方案。“投资培训”还是“投资设备”，存在两个选择，成本效益分析适用
  • 质量管理计划
    • 质量管理计划可能列出了受不确定性或模糊性影响 的一些领域，或者关键假设可能引发风险的一些领域
  • “将测试结果与质量需求进行对比”，属于控制质量活动
  • 质量报告是管理质量过程的的输出
  • “似乎存在同样的缺陷”，属于大面积出现的共性问题，此时要从流程上和标准上去分析导致质量问题发生的根源。如果针对的是孤立的个案，宜采用根本原因分析
  • 质量管理计划包括（但不限于）以下组成部分：项目采用的质量标准； 项目的质量目标；质量角色与职责；需要质量审查的项目可交付成果 和过程； 质量检查请求的活动在质量管理计划里
  • 两个变量之间的相关性，用散点图判断。或看到相关性，找散点图
• 项目整合管理
  • 不确定是否满足客户需求，可交付成果与需求之间的关系就是需求跟踪矩阵

项目整合管理

• 2.制定项目管理计划
  • 输入
    • 项目章程
    • 其他过程的输出
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 数据收集
    • 人际关系与团队技能
    • 会议
  • 输出
    • 项目管理计划
• 4.管理项目知识
  • 输入
    • 项目管理计划
    • 项目文件
      • 经验教训登记册
      • 项目团队派工单
      • 资源分解结构
      • 供方选择标准
      • 相关方登记册
    • 可交付成果
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 知识管理
    • 信息管理
    • 人际关系与团队技能
      • 积极倾听
      • 引导
      • 领导力
      • 人际交往
      • 政治意识
  • 输出
    • 经验教训登记册
    • 项目管理计划更新
    • 组织过程资产更新
• 6.实施整体变更控制
  • 输入
    • 项目管理计划
      • 变更管理计划
        • 变更管理计划为管理变更控制过程提供指导，并记录变更控制委员会（CCB）的角色和职责
      • 配置管理计划
        • 配置管理计划描述项目的配置项、识别应记录和 更新的配置项，以便保持项目产品的一致性和有效性
      • 范围基准
        • 范围基准提供项目和产品定义
      • 进度基准
        • 进度基准用于评估变更对项目进度的影响
      • 成本基准
        • 成本基准用于评估变更对项目成本的影响
    • 项目文件
      • 估算依据
        • 估算依据指出了持续时间、成本和资源估算是如何 得出的，可用于计算变更对时间、预算和资源的影响
      • 需求跟踪矩阵
        • 需求跟踪矩阵有助于评估变更对项目范围的影响
      • 风险报告
        • 风险报告提供了与变更请求有关的整体和单个项目风险的来源的信息
    • 工作绩效报告
    • 变更请求
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 变更控制工具
    • 数据分析
      • 备选方案分析
        • 该技术用于评估变更请求，并决定哪些请求可接受、应否决或需修改
      • 成本效益分析
        • 该分析有助于确定变更请求是否值得投入相关成本
    • 决策
      • 投票
        • 投票可以采取一致同意、大多数同意或相对多数 原则的方式，以决定是否接受、推迟或否决变更请求
      • 独裁型决策制定
        • 采用这种决策技术，将由一个人负责为整个集体制定决策
      • 多标准决策分析
        • 该技术借助决策矩阵，根据一系列预定义的准则，用系统分析方法评估变更请求
    • 会议
  • 输出
    • 批准的变更请求
    • 项目管理计划更新
    • 项目文件更新
      • 变更日志
• 7.结束项目或阶段
  • 输入
    • 项目章程
    • 项目管理计划
    • 项目文件
      • 假设日志
        • 假设日志记录了与技术规范、估算、进度和风险等有关的全部假设条件和制约因素
      • 估算依据
        • 估算依据用于根据实际结果来评估持续时间、成本和资源估算，以及成本控制
      • 变更日志
        • 变更日志包含了整个项目或阶段期间的所有变更请求的状态
      • 问题日志
        • 问题日志用于确认没有未决问题
      • 经验教训登记册
        • 在归入经验教训知识库之前，完成对阶段或项目经验教训的总结
      • 里程碑清单
        • 里程碑清单列出了完成项目里程碑的最终日期
      • 项目沟通记录
        • 项目沟通记录包含整个项目期间所有的沟通
      • 质量控制测量结果
        • 质量控制测量结果记录了控制质量活动的结果，证明符合质量要求
      • 质量报告
        • 质量报告的内容可包括由团队管理或需上报的全部质量保证事项、 改进建议，以及在控制质量过程中发现的情况的概述
      • 需求文件
        • 需求文件用于证明符合项目范围
      • 风险登记册
        • 风险登记册提供了有关项目期间发生的风险的信息
      • 风险报告
        • 风险报告提供了有关风险状态的信息，用于确认项目结束时没有未关闭的风险
    • 验收的可交付成果
    • 商业文件
      • 商业论证
        • 商业论证记录了作为项目依据的商业需求和成本效益分析
        • 商业论证用于确定项目是否达到了经济可行性研究的预期结果
      • 效益管理计划
        • 效益管理计划概述了项目的目标效益
        • 效益管理计划用于测量项目是否达到了计划的效益
    • 协议
    • 采购文档
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 数据分析
      • 文件分析
        • 评估现有文件有助于总结经验教训和分享知识，以改进未来项目和组织资产
      • 回归分析
        • 该技术分析作用于项目结果的不同项目变量之间的相互关系，以提高未来项目的绩效
      • 趋势分析
        • 趋势分析可用于确认组织所用模式的有效性，并且为了未来项目而进行相应的模式调整
      • 偏差分析
        • 偏差分析可通过比较计划目标与最终结果来改进组织的测量指标
    • 会议
  • 输出
    • 项目文件更新
      • 经验教训登记册
    • 最终产品、服务或成果移交
    • 最终报告
    • 组织过程资产更新
      • 项目文件
        • 在项目活动中产生的各种文件，例如项目管理计划， 范围文件、成本文件、进度文件和项目日历，以及变更管理文件
      • 运营和支持文件
        • 组织维护、运营和支持项目交付的产品或服务时 所需的文件。可包括新生成的文件，或对已有文件的更新
      • 项目或阶段收尾文件
        • 包括表明项目或阶段完工的正式文件，以及用来将完成的项目或阶段 可交付成果移交给他人（如运营部门或下一阶段）的正式文件
      • 经验教训知识库
        • 将在整个项目期间获得的经验教训和知识归入经验教训知识库，供未来项目使用
• 5.监控项目工作
  • 输入
    • 项目管理计划
    • 项目文件
      • 假设日志
        • 假设日志包含会影响项目的假设条件和制约因素的信息
      • 估算依据
        • 估算依据说明不同估算是如何得出的，用于决定如何应对偏差
      • 成本预测
        • 成本预测基于项目以往的绩效，用于确定项目是否 仍处于预算的公差区间内，并识别任何必要的变更
      • 问题日志
        • 问题日志用于记录和监督由谁负责在目标日期内解决特定问题
      • 经验教训登记册
        • 经验教训登记册可能包含应对偏差的有效方式以及纠正措施和预防措施
      • 里程碑清单
        • 里程碑清单列出特定里程碑的实现日期，用于检查是否达到计划的里程碑
      • 质量报告
        • 质量报告包含质量管理问题，针对过程、项目和产品的改善建议，纠正措施建议（包括返工、缺陷（漏洞）补救、100% 检查等），以及在控制质量过程中发现的情况的概述
      • 风险登记册
        • 风险登记册提供在项目执行过程中发生的各种威胁和机会的相关信息
      • 风险报告
        • 风险报告提供关于整体项目风险和单个风险的信息
      • 进度预测
        • 进度预测基于项目以往的绩效，用于确定项目 是否仍处于进度的公差区间内，并识别任何必要的变更
    • 工作绩效信息
    • 协议
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 数据分析
      • 备选方案分析
        • 备选方案分析用于在出现偏差时选择要执行的纠正措施或纠正措施和预防措施的组合
      • 成本效益分析
        • 成本效益分析有助于在项目出现偏差时确定最节约成本的纠正措施
      • 挣值分析
        • 挣值分析对范围、进度和成本绩效进行了综合分析
      • 根本原因分析
        • 根本原因分析关注识别问题的主要原因，它可用于识别 出现偏差的原因以及项目经理为达成项目目标应重点关注的领域
      • 趋势分析
        • 趋势分析根据以往结果预测未来绩效，它可以预测项目的进度延误，提前让项目经理意识到，按照既定趋势发展，后期进度可能出现的问题。应该在足够早的项目时间进行趋势分析，使项目团队有时间分析和纠正任何异常。可以根据趋势分析的结果，提出必要的预防措施建议
      • 偏差分析
        • 偏差分析审查目标绩效与实际绩效之间的差异（或偏差），可涉及持续 时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指标
    • 决策
    • 会议
  • 输出
    • 工作绩效报告
    • 变更请求
    • 项目管理计划更新
    • 项目文件更新
      • 成本预测
        • 本过程引起的成本预测的变更应通过成本管理过程进行记录
      • 问题日志
        • 在本过程中产生的新问题应该记录到问题日志中
      • 经验教训登记册
        • 更新经验教训登记册，记录应对偏差的有效方式以及纠正措施和预防措施
      • 风险登记册
        • 在本过程中识别的新风险应记录在风险登记册中，并通过风险管理过程进行管理
      • 进度预测
        • 本过程引起的进度预测的变更应通过进度管理过程进行记录
• 3.指导与管理项目工作
  • 输入
    • 项目管理计划
      • 任何组件
    • 项目文件
      • 变更日志
        • 变更日志记录所有变更请求的状态
      • 经验教训登记册
        • 经验教训用于改进项目绩效，以免重犯错误。 登记册有助于确定针对哪些方面设定规则或指南，以使团队行动保持一致
      • 里程碑清单
        • 里程碑清单列出特定里程碑的计划实现日期
      • 项目沟通记录
        • 项目沟通记录包含绩效报告、可交付成果的状态，以及项目生成的其他信息
      • 项目进度计划
        • 进度计划至少包含工作活动清单、持续时间、资源，以及计划的开始与完成日期
      • 需求跟踪矩阵
        • 需求跟踪矩阵把产品需求连接到相应的可交付成果，有助于把关注点放在最终结果上
      • 风险登记册
        • 风险登记册提供可能影响项目执行的各种威胁和机会的信息
      • 风险报告
        • 风险报告提供关于整体项目风险来源的信息，以及关于已识别单个项目风险的概括信息
    • 批准的变更请求
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 项目管理信息系统
    • 会议
  • 输出
    • 可交付成果
    • 工作绩效数据
    • 问题日志
    • 变更请求
    • 项目管理计划更新
    • 项目文件更新
      • 活动清单
      • 假设日志
      • 经验教训登记册
      • 需求文件
      • 风险登记册
      • 相关方登记册
    • 组织过程资产更新
• 1.制定项目章程
  • 输入
    • 商业文件
      • 商业论证
      • 效益管理计划
    • 协议
      • 合同
      • 谅解备忘录（MOUs）
      • 服务水平协议（SLA）
      • 协议书
      • 意向书
      • 口头协议
      • 电子邮件
      • 其他书面协议
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 数据收集
      • 头脑风暴
      • 焦点小组
      • 访谈
    • 人际关系与团队技能
      • 冲突管理
      • 引导
      • 会议管理
    • 会议
  • 输出
    • 项目章程
    • 假设日志

项目整合管理

• 发展趋势
  • 使用自动化工具
    • PMIS
    • 配置管理软件
  • 可视化管理工具
    • 横道图
    • 网络图
    • 看板
    • 燃尽图
  • 项目知识管理
    • 知识的收集、整理、传达、分享
  • 增加项目经理的职责
    • 从前期商业论证到后期运营更多参与
  • 混合型方法
    • Scrum
    • 精益
    • 看板
    • 极限编程XP
• 敏捷场景下的变更管理
  • 小步快跑
  • 高效反馈
  • 保持节奏
  • 价值交付
• 项目收尾流程
  • 最终验收
    • 对可交付成果进行形式上的验收并移交
  • 关闭合同
    • 关闭采购合同，了解合同当事人在项目上的关系
  • 财务收尾
    • 完成项目的财务结算与决算
  • 相关方满意度
    • 向相关方报告最终绩效，并调查相关方满意度
  • 归档工作
    • 收集工作流程、工作数据、工作模版并归档
  • 经验教训
    • 项目后评价、项目审计、总结经验教训、更新组织过程资产
  • 庆祝会
    • 举行完工庆祝会，认可与奖励相关方业绩
  • 解散团队
    • 释放项目资源，解散项目团队
• 整合什么
  • 资源分配
    • 搭团队、分工
  • 平衡竞争性需求
    • 摆平冲突、矛盾
  • 研究各种备选方法
    • 收益、风险整合
  • 为项目目标裁剪过程
    • 49个过程的取舍、怎么搭
  • 知识领域的关系
    • 进度、成本、质量...
• 管理项目知识
  • 显性知识
    • 可以编撰、易于表达
    • 文字、图片、数字、表格
  • 隐性知识
    • 无法编撰、难于表达
    • 经验、直觉、洞察力、诀窍
• 变更应对措施
  • 预防措施
    • 防患未然
  • 纠正措施
    • 知错就改
  • 缺陷补救
    • 亡羊补牢
• 配置管理计划
  • 产品的功能、组件、文档......
  • 项目的基准、计划、文件......
  • 组织过程资产（知识、经验、教训）
  • 目标
    • 完整性
    • 一致性
    • 可控性
    • 追溯性
• 合同收尾&行政收尾
  • 合同收尾
    • 定义：买卖双方完成交接，结清账目；时间：合同结束时；总结：采购审计；审批：买方向卖方签发书面确认；交接：与外部卖方/买方交接
  • 行政收尾
    • 定义：企业内部项目收尾程序；时间：项目或每个阶段结束时；总结：回顾，经验教训总结；审批：管理层向项目经理签发书面确认；交接：与公司内部交接
  • 顺序
    • 先与外部交接，再与公司内部交接，完成合同收尾后再完成行政收尾
• 项目章程
  • 由项目启动者或发起人发布的
  • 正式批准项目成立
  • 授权项目经理动用组织资源开展项目活动的文件
  • 标志
    • 项目执行组织与发起组织之间建立起伙伴关系
    • 项目的正式启动
    • 给项目经理正式授权
• 项目管理数据和信息
  • 工作绩效数据
    • 产生于：执行过程；频率：极高（随时）；用途：跟踪记录项目状态； 对象：项目团队；特征：是什么（what）；举例：本周产生成本50万，完成产值75万
  • 工作绩效信息
    • 产生于：监控过程；频率：较高（定期）；用途：分析偏差/预测趋势； 对象：项目团队；特征：为什么（why）；举例：当前成本偏差+15万，进度偏差-20万
  • 工作绩效报告
    • 产生于：监控过程；频率：较低（按要求）；用途：汇报进展/辅助决策； 对象：发起人/PMO/高级管理层；特征：怎么办（how）； 举例：拟增加资源赶上进度（挣值报告）
• 整合管理过程
  • 制定项目章程
  • 制定项目管理计划
  • 指导与管理项目工作
  • 管理项目知识
  • 监控项目工作
  • 实施整体变更控制
  • 结束项目或阶段
• 敏捷场景中的整合管理
  • 范围动态
    • 工作范围中不但内容可以变，优先级也可以变
  • 过程精简
    • 一切不为用户创造价值的活动都是浪费
  • 状态可视
    • 原型设计、看板、燃尽图、实际效果展示
  • 质量内建
    • 测试驱动开发、结对编程、一次把事情做对
  • 团队自组织
    • 去中心化、高效互动、民主氛围、集体决策
• 数据分析
  • 备选方案分析
    • 多种方案中选择最优
  • 趋势分析
    • 根据已知情况预测未来发展
  • 偏差分析
    • 实际执行与计划的偏差，比如进度偏差、成本偏差、质量偏差
• CCB变更控制委员会
  • 一个由项目发起人组成的常设但非固定的正式团体
  • 项目经理只能去决策不影响基准的变更
  • 影响到基准的变更一律需要走CCB

项目范围管理

• 2.收集需求
  • 输入
    • 项目章程
    • 项目管理计划
    • 项目文件
    • 商业文件
    • 协议
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 数据收集
    • 数据分析
    • 决策
    • 数据表现
    • 人际关系与团队技能
    • 系统交互图
    • 原型法
  • 输出
    • 需求文件
    • 需求跟踪矩阵
• 4.创建WBS
  • 输入
    • 项目管理计划
    • 项目文件
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 分解
  • 输出
    • 范围基准
    • 项目文件更新
• 6.控制范围
  • 输入
    • 项目管理计划
    • 项目文件
    • 工作绩效数据
    • 组织过程资产
  • 工具与技术
    • 数据分析
  • 输出
    • 工作绩效信息
    • 变更请求
    • 项目管理计划更新
    • 项目文件更新
• 5.确认范围
  • 输入
    • 项目管理计划
    • 项目文件
    • 核实的可交付成果
    • 工作绩效数据
  • 工具与技术
    • 检查
    • 决策
  • 输出
    • 验收的可交付成果
    • 工作绩效信息
    • 变更请求
    • 项目文件更新
• 3.定义范围
  • 输入
    • 项目章程
    • 项目管理计划
    • 项目文件
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 数据分析
    • 决策
    • 人际关系与团队技能
    • 产品分析
  • 输出
    • 项目范围说明书
    • 项目文件更新
• 1.规划范围管理
  • 输入
    • 项目章程
    • 项目管理计划
    • 事业环境因素
    • 组织过程资产
  • 工具与技术
    • 专家判断
    • 数据分析
    • 会议
  • 输出
    • 范围管理计划
    • 需求管理计划

项目范围管理

• 目标
  • 要做什么
  • 只做什么
• 范围
  • 产品范围
    • 产品、服务或成果所具有的特性和功能
  • 项目范围
    • 为交付产品、服务或成果而必须完成的工作
• 范围管理过程
  • 确保
    • 项目团队、项目发起人和项目相关方
    • 对项目的可交付成果，以及对形成这些可交付成果所进行的工作达成共识
• 人际关系与团队技能
  • 名义小组
    • 小组成员先不通气，独立思考
    • 各自写下备选方案和意见
    • 轮流陈述自己的方案和意见
    • 小组成员对全部备选方案投票
    • 得票最多的备选方案入选
    • 当然，管理者有权否决这一方案
  • 观察法
  • 引导式研讨会
    • 跨部门，跨专业，集中讨论，集思广益
    • 有一个主持人负责引导各部门各专业的人去发言
    • 专门用于去解决需求不一致的问题
• 收集需求
  • 专家判断
  • 数据收集
  • 数据分析
  • 决策
  • 数据表现
  • 人际关系与团队技能
  • 系统交互图
  • 原型法
• 管理需求的工具
  • 用户故事
    • 作为一个<角色>，我想要<活动>，以便于<商业价值>
    • 比如，作为一个用户，我想要自动同步我的微信头像，以便于统一我的网络形象
  • 用户故事卡片
    • 将用户故事写在卡片上，再贴在墙上，最后采用亲和图归类
  • 用户故事地图
• 项目章程&项目范围说明书
  • 项目章程和项目范围说明书，有的时候有些内容是一致的，但项目章程里的 内容是纲领性的，比较粗略，而项目范围说明书里的内容是具体化的，比较细致
• 范围基准
  • 项目范围说明书
    • 项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述
  • 工作分解结构（WBS）
  • WBS词典
• 敏捷场景下的需求管理
  • 卡诺模型
    • 期望属性
      • 用户的满意度和属性具备的程度成线性正相关
      • 属性具备的程度越高，用户的满意度越高
      • 比如手机的待机时长
    • 魅力属性
      • 锦上添花的属性，没有也可以
      • 比如折叠屏，无线充电
    • 无差异属性
      • 用户不关心的属性，比如手机主板用了多少个线路板
    • 必备属性
      • 一定要具备的属性，少了就不行
      • 比如手机一定要能打电话
    • 反向属性
      • 这种属性越多用户越不满意
      • 比如手机的预装软件，预装软件越多，用户越不满意
    • 启发
      • 人手和时间都有限的情况下
        • 优先满足必备属性
      • 稍有余力的情况下
        • 满足期望属性
      • 再有余力的情况下
        • 满足魅力属性
      • 无论何种情况下
        • 都不要做反向属性
  • 精益画布
    • 将所有的需求分析都摆放在一张画布上
    • 举例
      • 用户细分
        • 不会用智能手机的老人
        • 残障人士
        • 带电话手表的学生
      • 需求痛点
        • 老人不会用智能手机就打不到车
        • 支付车费不方便
      • 解决方案
        • 比如拨打95XXXX一呼即到
        • AI语音识别
        • 算法智能定位
      • 价值主张
        • 科技解决老人出行
        • 司机手机刷脸支付
        • 儿女绑定监控路线
      • 市场渠道
        • 社区、街道、公益组织、政府、媒体、儿女推荐
      • 收入来源
        • 平台提成
        • 政府补贴
        • 合作分红
      • 成本结构
        • 平台开发
        • 营销推广
        • 运营成本
      • 关键指标
        • 服务单量
        • 司机注册
        • 用户活跃
  • 最小可发布版本（MMR）
    • 真正意义上开发的第一个版本的产品
  • 最小可行性产品（MVP）
    • 不一定是真实产品，可能是模型
    • 只是为了快速了解产品的市场情况
  • 莫斯科法则（MoSCoW Laws）
    • Must Have
      • 必须有
    • Should Have
      • 应该有
    • Could Have
      • 可以有
    • Won't Have
      • 不该有
• 不同生命周期的范围管理对比
  • 预测型（瀑布）
    • 定义范围的时间：项目开始； 确认范围的时间：项目或阶段结束； 范围控制文件：范围基准； 发起人/客户参与：里程碑
  • 迭代型/增量型
    • 定义范围的时间：每个迭代开始； 确认范围的时间：每个迭代结束； 范围控制文件：版本配置文件； 发起人/客户参与：周期性
  • 适应型（敏捷）
    • 定义范围的时间：随时； 确认范围的时间：随时反馈； 范围控制文件：用户故事； 发起人/客户参与：持续性
• 工作分解结构（WBS）
  • 层次划分
    • 项目
    • 子项目
    • 控制账户
    • 工作包
      • WBS最低层次的单元
      • 项目经理负责的最低层次的单元
      • 工作包以下的都不包含在WBS里
    • 规划包
      • 暂时没办法做或者不做的，但是未来肯定要做的
      • 和工作包是同一层级的
    • 活动
      • 执行团队负责的最低层次的单元
      • 工作包之下的结构
    • 任务
      • 个人负责的最低层次的单元
      • 活动之下的结构
  • 分解方式
    • 树状分解
    • 目录式分解
  • WBS的编码系统，例"4.1.3.2"，主要是展现 WBS元素的层级和隶属关系，不是用于区分优先级的
• WBS词典
  • 针对每个WBS组件，详细描述可交付成果活动和进度信息的文件
• 范围与需求
  • 需求管理计划
    • 规划、跟踪和报告需求
    • 配置管理活动
    • 需求优先级排序过程
    • 确定产品测量指标
    • 跟踪矩阵的跟踪结构
  • 范围管理计划
    • 制定详细范围说明书
    • 创建WBS和WBS词典
    • 创建责任分配矩阵
    • 正式验收可交付成果
    • 处理对项目范围变更
  • 需求就是他想要的，范围就是我要做的
  • 范围来自于需求，但范围不等同于需求，并不是所有的需求都能做
• 责任分配矩阵（RAM）
  • 将WBS工作包分配到具体的个人
  • 通常用于划分活动和资源之间的职责关系
• 需求识别工具
  • 头脑风暴
    • 头脑风暴的特征也叫诸葛亮会议
  • 访谈
  • 焦点小组
  • 问卷调查
  • 标杆对照
  • 联合应用设计或开发（JAD）
    • 适用于软件开发行业，这种研讨会注重把业务主题专家 和开发团队集中在一起，以收集需求和改进软件开发过程
• 需求收集工具
  • 亲和图
    • 把所有需求整理归类
  • 质量功能展开（QFD）
    • 展开层次
      • 产品规划矩阵
        • 用户需求->设计要求
      • 零件规划矩阵
        • 设计要求->零件特性
      • 工艺规划矩阵
        • 零件特性->工艺要求
      • 工艺/质量规划矩阵
        • 工艺要求->生产要求
    • 制造行业采用QFD这种引导技能来帮助确定新产品的关键特征
    • 从收集客户需要（又称"客户声音"）开始，然后客观地对 这些需要进行分类和排序，并为实现这些需要而设定目标
  • 思维导图
• 需求决策与表现
  • 投票
    • 一致同意
    • 大多数同意
    • 相对多数同意
  • 独裁
  • 多标准决策
• 需求跟踪矩阵
  • 把需求从其来源连接到能满足需求的可交付成果的一种表格
  • 使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来
  • 需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法
  • 需求跟踪矩阵还为管理产品范围变更提供了框架

项目进度管理

• 看板六大核心实践
  • 可视化工作流程
    • 待办、分析、设计、开发、测试、完成
  • 限制在制品（WIP）
    • 每个工作流程设置了限制个数
  • 管理和度量流动
    • 让看板中的工作快速且毫无中断地流动起来
  • 显示化流程规则
  • 建立反馈环路
  • 协作式改进
• 进度管理过程
  • 规划进度管理
  • 定义活动
  • 排列活动顺序
  • 估算活动持续时间
  • 制定进度计划
  • 控制进度
• 滚动式规划
  • 滚动式规划指的是近期工作详细描述，远期工作粗略描述， 随着项目进展，获取信息越来越丰富，一次次逐渐细化的规划方法
• 紧前关系绘图法（PDM）
  • 四种逻辑关系
    • FS
      • 淘宝购物的支付和发货
    • SS
      • 煎饼果子的摊面糊和打鸡蛋
    • FF
      • 拍电影的拍摄和剪辑
    • SF
      • 系统升级的新系统开启和旧系统关闭
• 关键路径法（CPM）
  • 单元格结构
    • 最早开始（ES）、活动历时（DU）、最早结束（EF）
    • 活动名称或代号（Activity）
    • 最晚开始（LS）、总浮动时间（TF）、最晚结束（LF）
  • 计算公式
    • 最早开始+活动历时=最早结束（ES+DU=EF）
    • 最晚结束-活动历时=最晚开始（LF-DU=LS）
    • 最晚结束-最早结束=总浮动时间（LF-EF=TF）
    • 最晚开始-最早开始=总浮动时间（LS-ES=TF）
  • 关键路径决定了项目的总工期
  • 关键路径所需要的时间最长
  • 关键路径上的浮动时间最少
    • 关键路径上的浮动时间可能大于0，小于0，等于0，但是一定是最少的
  • 一个项目可能存在不止一条关键路径
  • 关键路径上的活动和技术含量高低无关
  • 活动延误可能导致关键路径变化
  • 关键路径上的活动工期是可以压缩的，但是 压缩了之后，可能导致非关键路径也变成了关键路径
  • 关键路径上的活动一旦顺延，总工期肯定立刻改变
• 项目的三种浮动时间
  • 自由浮动时间
    • 不影响后续工作最早可以开始时间的前提下，当前工作可以拖延的时间
    • 比如A活动干完后还有4天富余，也不影响后续活动B，这4天就是自由浮动时间
  • 总浮动时间
    • 不影响项目总工期（可能影响了后续活动最早可以开始的时间）的前提下，活动可以拖延的总时间
    • 比如A活动的自由浮动时间都用完了还没干完工作，延期了2天， 耽误了B活动最早可以开始的时间，B活动因此受到A活动的牵连而延后2天开始工作，但即使这样也不影响项目总工期，那么这2天就是总浮动时间
  • 项目浮动时间
    • 在你排的总工期的基础之上，客户或者领导主动又多给你 让出来的时间，你就可以多干几天，这几天就是项目浮动时间
• 关键链法（CCM）
  • 帕金森定律
    • 工作会自动膨胀，占满所有可用时间
  • 项目缓冲
    • 项目经理掌控的用于活动干不完的情况下，腾出来的多余时间
  • 接驳缓冲
    • 项目经理为让前续活动按时完成的概率增大而主动增加的缓冲时间
  • 路径汇聚风险
    • 当前活动最早可以开始的时间受制于前续活动，比如D活动的前续活动有三个，分别为ABC，这三个活动按时完成的概率为50%，那么D活动最早可以按时开始的概率为50%x50%x50%=12.5%
• 燃尽图
  • 英文名称 Burn-down Chart
  • 代表着还有多少工作没干完
• 依赖关系
  • 强制性依赖
    • 比如先穿袜子才能穿鞋
  • 选择性依赖
    • 比如先吃饭再看电影，也可以先看电影再吃饭
  • 内部依赖
    • 比如PDM的四种逻辑关系
  • 外部依赖
    • 比如二胎政策的开放
• 进度压缩技术
  • 快速跟进
    • 让紧后活动提前开始，和紧前活动并行一部分时间，这提前开始的时间就是快速跟进的时间，使得原来FS的逻辑关系变成了FS-X（X为紧后活动提前开始的时间）
    • 代价：增加了紧后活动返工的风险来换取时间
  • 赶工
    • 加班加人
    • 代价：增加了资源来换取时间，增加了项目成本
  • 不管是快速跟进，还是赶工，要想达到压缩 工期的目的，首先考虑压缩关键路径上的活动
    • 既然已经决定压缩关键路径上的活动了，那么应该先压缩关键路径上先发生的活动。 因为只有这样，关键路径上后发生的活动以后才有机会进行压缩， 如果先压缩了后面的活动，那么就错过了先发生的活动的压缩机会了
• 资源优化
  • 资源平衡
    • 解决某一时间段的资源过载问题，但有可能导致工期延长
  • 资源平滑
    • 利用非关键路径上的浮动时间，修改非关键路径上活动的 开始或结束时间，削峰填谷，减少资源在时间分布上不均衡的情况
• 滞后量&提前量
  • 滞后量
    • 紧前活动做完后腾出一部分时间再做紧后活动， 而不是让紧后活动马上开始。这个腾出来的时间称作等待时间
    • 表示：FS+X
  • 提前量
    • 紧前活动还未做完，紧后活动就已经提前了 一部分时间开始做，也就是紧后活动和紧前活动并行一段时间
    • 表示：FS-X
• 活动历时估算方法
  • 三点估算
    • 乐观估计时间O
      • 最理想的情况下的耗时
    • 最可能的时间M
      • 最可能的耗时
    • 悲观估计时间P
      • 最坏情况下的耗时
    • 期望时间T=（O+4M+P）/6
    • 标准差=（P-O）/6
      • 衡量概率分布曲线的胖瘦，就是概率分布数据与均值（期望值）的离散程度
    • 左右各一倍标准差：68.26%
    • 左右各两倍标准差：95.46%
    • 左右各三倍标准差：99.73%
    • 成本较高，准确度较高
  • 三角估算
    • 期望时间=（O+M+P）/3
  • 自下而上估算
    • 估算准确度高
    • 周期长，成本高
  • 类比估算
    • 成本低，准确度低
  • 参数估算
    • 成本低，准确度无法判断，其依赖参数模型的准确性
  • 专家判断
    • 成本较低，准确度无法判断，其依赖专家的能力
• 项目的风险分类
  • 已知风险
    • 风险，概率，影响都已知
  • 已知-未知风险
    • 风险已知，但概率或影响未知
  • 未知-未知风险
    • 风险，概率，影响都未知
• 储备分析
  • 应急储备
    • 项目经理支配
    • 针对已知-未知风险
    • 在成本基准里，考核项目经理绩效
  • 管理储备
    • 高层管理者支配
    • 针对未知-未知风险
    • 不在成本基准里，但在项目预算中，不考核项目经理绩效
• 项目预算的组成
  • 管理储备
  • 成本基准（完工预算）
    • 控制账户
      • 应急储备
      • 工作包成本估算
        • 活动应急储备
        • 活动成本估算
• 网络图
  • 单代号网络图（AON）
    • 四种逻辑关系
  • 双代号网络图（AOA）
    • 仅FS一种逻辑关系
  • 虚工作
    • 不耗时间，不占资源，仅表示逻辑关系
  • 时标网络图
  • 进度前锋线图

项目成本管理

• 挣值分析
  • 三指标
    • PV（计划值）
      • PV=计划单价x计划工作量
    • AC（实际成本）
      • AC=实际单价x实际工作量
    • EV（挣得值）
      • EV=计划单价x实际工作量
  • 两偏差
    • 成本偏差CV=EV-AC
    • 进度偏差SV=EV-PV
  • 挣值曲线
    • AC>EV>PV
      • CV<0；SV>0；成本效率较低
      • 宜采取的措施：降低成本，提高成本效率
    • EV>AC>PV
      • CV>0；SV>0；成本效率较高
      • 宜采取的措施：可适当抽调一部分人员加速其他进度较低的项目进展
    • AC>PV>EV
      • CV<0；SV<0；成本效率很低
      • 宜采取的措施：及时预警，全面强化成本绩效管理，必要时变更基准
    • EV>PV>AC
      • CV>0；SV>0；成本效率很高
      • 宜采取的措施：可以根据需要提前完成项目，或释放部分资源
    • PV>EV>AC
      • CV>0；SV<0；成本效率较高
      • 宜采取的措施：加大资源投入，采取激励措施，加速项目进展速度
    • PV>AC>EV
      • CV<0；SV<0；成本效率较低
      • 宜采取的措施：强化监督考核，加速项目，同时控制成本
  • 两指数
    • 成本绩效指数CPI=EV/AC
      • 比值大于1说明节省了成本
    • 进度绩效指数SPI=EV/PV
      • 比值大于1说明进度超前了
  • • 项目预算（PB）
      • 英文Project Budget
      • 项目预算=完工预算+管理储备
    • 完工预算（BAC）
      • 英文Budget at Completion
      • 项目经理把项目所有的成本都加在一起的那个值 就叫做完工预算，也就是项目结束时计划要花的所有成本
      • 同时也是绩效测量基准（PMB）和成本基准（Cost Baseline）
    • 完工估算（EAC）
      • 英文Estimate at Completion
      • 根据项目当前的评估状态，去预测项目结束时总共需要花多少钱
      • 完工估算=实际成本AC+完工尚需估算ETC
      • 计算公式
        • 按当前实际单价继续直到完成项目（剩余工作的成本都不做纠正）
          • EAC=BAC/CPI
        • 成本和进度都按当前状态继续直到完成项目（剩余工作的成本和进度都不做纠正）
          • EAC=AC+[(BAC-EV)/(CPIxSPI)]
        • 接下来的工作将按计划单价完成（剩余工作的成本都做纠正）
          • EAC=AC+(BAC-EV)
    • 完工尚需估算（ETC）
      • 英文Estimate to Complete
      • 从评估时刻往后看，还得花多少钱
  • • 完工尚需绩效指数（TCPI）
      • 英文To-Complete Performance Index
      • 从评估时刻开始，接下来应该要保持一个什么样的成本绩效指数
      • 计算公式
        • TCPI=(BAC-EV)/(BAC-AC)
          • 公式含义：还剩多少工作没完成/还剩多少预算
        • TCPI=(BAC-EV)/(EAC-AC)
    • 完工偏差VAC
      • VAC=BAC-EAC
      • 和原计划相比，我们要多花多少的成本
  • 挣值的获取方法
    • 百分比法
      • 计算每个工作包的完成百分比，最后累加求和即为总的有效的被认可的百分比
    • 五十五十法则
      • 每个工作包都在评估时刻开始的时候问一遍，当前工作包开始了没有， 开始了算完成了一半，结束的时候也算一半，中间任何时候都不算
    • 二十八十法则
      • 开始的时候算20%，结束的时候算80%
    • 零一百法则
      • 只评估结束，结束100%
    • 里程碑法
      • 事先约定好到达第一个里程碑算百分之多少，到达第二个又算百分之多少
    • 主材消耗法（容器法）
      • 比如供应土豆条，给供应商装土豆条的箱子或者说是容器，只要土豆条合格，一整箱都算被认可的工作量，就把土豆条和箱子一起带走，不合格，箱子和土豆条就留下
      • 再比如给公路刷白油漆，统计已做了多少工作量的时候并不需要每次去跑一遍公路看看完成了多少，而只是数数自己剩下了多少桶油漆没有用完，就可以大致估算出已完成和未完成的工作量了，这种数油漆消耗了多少的方法就是主材消耗法
  • • 实际时间AT
      • 项目开始到评估时刻实际花了的时间
    • 挣得进度（ES）
      • ES=EV/PAR
      • 评估时刻的EV挣值曲线和PV计划线交接的那个点对应的进度， 即为挣得进度，含义为只有这部分进度的工作量才是被认可的
    • 偏差时间TV
      • 实际时间-挣得进度之后剩余的时间，这段时间里的工作被认为是无效的
    • 完工进度（SAC）
      • 预计干完项目的总时间或者工期
    • 时间完工估算（TEAC）
      • 按评估时刻开始的状态直到项目结束，预计要花的总时间
      • 公式有两个
        • 接下来的日子用计划的速度干完
          • TEAC=SAC-TV
        • 接下来的日子里还是按照当前评估时刻的速度干完
          • TEAC=SAC/TPI
    • 完工时间偏差（TVAC）
      • TVAC=TEAC-SAC，含义是照评估时刻的状态直到项目结束，比预计多花的时间
    • 时间完工尚需估算（TETC）
      • TETC=TEAC-AT，含义是照评估时刻的状态直到项目结束，还需要多少时间完工
  • 计划的完成速度（PAR）
    • PAR=BAC/SAC
    • 含义是 我单位时间应该完成的工作=我整个项目的预算/我整个项目的工期
  • 时间绩效指数（TPI）
    • TPI=ES/AT
    • 含义是 时间绩效指数=被认可的时间/实际花掉的时间
• 敏捷场景下的成本管理
  • 采用最小可用产品思路来验证产品的市场真实需求
  • 最小可用产品可采取的方法
    • 产品介绍视频
    • 仿真
    • 众筹
    • 原型法
    • 预售
    • 访谈
• 成本估算精确度等级
  • 粗略级估算
    • 项目阶段：启动阶段；目的：可行性研究； 常用方法：类比估算；估算精确度：-25%+75%
  • 预算级估算
    • 项目阶段：规划阶段；目的：编制预算； 常用方法：自下而上；估算精确度：-10%+25%
  • 确定性估算
    • 项目阶段：规划阶段；目的：签订合同； 常用方法：自下而上；估算精确度：-5%+10%
• 成本的分类
  • 直接成本
  • 间接成本
  • 固定成本
  • 可变成本
  • 机会成本
    • 未选择的那些方案中，带给自己的最大的潜在收益
  • 沉没成本
    • 已经投入了的所有的成本，这些成本已经收不回来了
  • 全生命周期成本
• 资金限制平衡
  • 把项目资金支出计划与项目资金到位承诺进行对比，识别资金限制与计划支出 之间的差异，必要时调整工期，减少资源投入强度，以避免资金链断裂而导致项目失败
• 成本管理过程
  • 规划成本管理
  • 估算成本
  • 制定预算
  • 控制成本
• 项目预算的组成
  • 管理储备
  • 成本基准（完工预算）
    • 控制账户
      • 应急储备
      • 工作包成本估算
        • 活动应急储备
        • 活动成本估算

项目质量管理

• 质量管理过程
  • 规划质量管理
  • 管理质量
  • 控制质量
• 精确度&准确度
  • 精确度
    • 衡量样本的密集程度，也就是精确度高，说明样本数据之间的距离小
  • 准确度
    • 衡量样本和目标的偏差程度，也就是准确度高，说明样本数据和目标数据的距离小
• 质量管理水平
  • 由低到高层次依次为
    • 用户发现缺陷
      • 代价最大，商誉和口碑受损
    • 检查和纠正（QC）
      • 检查结果和纠正缺陷来控制质量
    • 过程保证（QA）
      • 过程的保证和持续改进
    • 设计优化（DFX）
      • 质量融入规划设计中
    • 全面质量管理（TQM）
      • 全员参与的质量管理文化
• 质量矩阵图
• 逻辑数据模型
• QA&QC
  • 质量保证（QA）
    • 过程组：执行；对象：Process过程； 目标：合规；工具技术：分析、审计
    • 比如专业球员看球赛的时候关心两队的控球率，教练的战略意图，球员的战术发挥等等
  • 质量控制（QC）
    • 过程组：监控；对象：Result结果； 目标：合格；工具技术：检查
    • 比如普通球迷看球赛的时候只关心他自己喜欢的球员有没有上场
• 面向X设计（DFX）
  • 英文名称Design for X
  • 设计时充分考虑
    • 好加工、好装配、好品控、好搬运、好收纳、好回收、好维护......
• 质量管理工具
  • 根本原因分析
    • 质量出现了问题，追根溯源，总能找到问题的根本原因
    • 石川图
      • 又叫鱼骨图，因果图
  • 直方图
    • 好的质量管理
      • • 基本符合正态分布
        • 数据全部在规格以内
        • 均值和规格的中心一致
        • 规格线位于标准差4倍的位置
    • 不好的质量管理
      • 双侧无余量型
        • • 产品范围与规格正好一致。因为没有余量，令人担心， 工序稍有变化，就会超出规格，所以有必要减小偏差
      • 余量过富裕型
        • • 工序能力太富裕。如不是规格太宽松，应适当放宽工序能力指数以降低成本
      • 平均值偏离型
        • • 平均值过于偏左。为降低不良率，应调整工序中心使之接近规格中心
  • 散点图
    • 通过变量之间的相关性来分析质量问题产生的原因
  • 帕累托图
    • 意大利经济学家Pareto发明的
    • 二八原理
      • 百分之八十的问题是百分之二十的原因所造成的
    • 帕累托图的原理就是将缺陷按原因归类后排序（缺陷从多到少），然后画出缺陷累计曲线，少数原因造成的缺陷已占到总缺陷数量的大部分。帮助项目经理集中精力针对少数原因就能解决大部分缺陷
  • 核对单
    • 将影响质量的因素列一个清单，检查了质量的就打一个√
    • 避免遗漏
  • 检查表（计数表）
    • 检查了一次，就记个数，进行累加求和
  • 控制图
    • • 在上下规格线内侧再画个控制线
      • 规格线是上下4倍标准差
      • 控制线是上下3倍标准差
    • 三种情况下必须停工找原因，解决了之后再继续干
      • • 连续七个点都在均值一侧
        • 连续七个点呈单调上升或单调下降的趋势
        • 存在控制线之外的点，即便在规格线之内
  • 层别法（数据分层法）
    • 人机料法环
      • Man人
      • Machine机器设备
      • Material材料
      • Method方法
      • Environment环境
  • 工具总结
    • 鱼骨追原因
    • 检查集数据
    • 直方显分布
    • 控制找异常
    • 帕累托重点
    • 散点看相关
    • 层别作解析
• 质量管理的发展历程
  • 工匠自检
  • 专职质检
  • 质量控制（QC）
  • 质量保证（QA）
  • 设计优化（DFX）
  • 全面质量管理（TQM）
• 质量管理观念的改变
  • 以前的观念
    • 定义：好，优，美；制度：缺陷减少成本增加； 标准：合格；测量：检验指标；重点：检查、测试
  • 现在的观念
    • 定义：与要求一致；制度：缺陷减少成本降低； 标准：零缺陷；测量：质量成本COQ；重点：设计、预防
• 控制质量工具
  • 过程决策程序图（PDPC）
• 控制质量
  • 主要作用
    • 识别过程低效或产品质量低劣的原因， 建议并/或采取相应措施消除这些原因
    • 确认项目的可交付成果及工作满足主要相关方的既定需求，足以进行最终验收
• 质量管理的发展趋势
  • 客户满意
    • 代表人物：朱兰
  • 持续改进
    • 代表人物：爱德华·戴明
    • 质量界的诺贝尔奖：戴明奖
    • 核心思想：戴明环（PDCA）
      • Plan计划
      • Do实施
      • Check检查
      • Action行动
    • 六西格玛
      • 期望值往前往后各6个标准差的面积为99.99966%
      • 保障率>=99.99966%
      • 缺陷率<百万分之3.4
    • Lean 精益
    • 精益六西格玛
  • 管理层的责任
    • 戴明说：员工只须对15%的问题负责，另外85%归咎于制度流程
  • 与供应商持续合作，互利共赢
• 质量成本（COQ）
  • 一致性成本（预防）
    • 预防成本（打造某种高质量产品）
      • 培训
      • 文件过程
      • 设备
      • 完成时间
    • 评估成本（评估质量）
      • 测试
      • 破坏性试验损失
      • 检查
  • 非一致性成本（纠正）
    • 内部失败成本（项目中发现的失败）
      • 返工
      • 报废
    • 外部失败成本（客户发现的失败）
      • 债务
      • 保修工作
      • 失去业务
• 质量管理相关代表人物
  • 爱德华·戴明
    • 戴明环（PDCA）持续改进
  • 田口玄一
    • "品质工程"奠基人
    • 质量偏离目标值越大，损失越大
  • 石川馨
    • 质量圈子之父（QCC）
    • 写了一本《质量控制》
    • 因果图（鱼骨图），也叫石川图
  • 克劳斯比
    • 被称为"零缺陷之父"
    • 第一次就把工作做对总是较便宜的
    • 质量产生于预防，而不是评估
    • 质量成本是以"不符合要求的代价"衡量的

项目资源管理

• 资源管理过程
  • 规划资源管理
  • 估算活动资源
  • 获取资源
  • 建设团队
  • 管理团队
  • 控制资源
• 权力矩阵
• 资源分解结构（RBS）
• 项目经理的管理风格
  • 在项目的不同阶段需要不同的风格
    • 形成阶段
      • 指令型
        • 直接、明确、清晰
        • 告诉团队每个人他们的职责所在
    • 震荡阶段
      • 影响型
        • 引导、斡旋、调解
        • 用自己的影响力，感召力去解决团队的冲突
    • 规范阶段
      • 参与型
        • 帮助、参与、促进
        • 团队需要帮助的时候伸出援手
    • 表现阶段
      • 授权型
        • 信任、授权、支持
        • 能让大家自己决策的就自己决策
• 人力资源的经典理论
  • X-Y理论
    • X假设所有一切都是负面的，Y假设所有一切都是正面的
  • 需求层次理论
    • 马斯洛提出来的， 人的需求有五个层次，由低到高依次为
      • 生存需求
        • 空气/水/实物
      • 安全需求
        • 安全/次序/自由
      • 社会需求
        • 爱情/友情/归属
      • 尊重需求
        • 自尊/成就/责任
      • 自我实现需求
        • 不讲回报/心甘情愿
  • 双因素理论
    • 赫茨伯格提出来的， 他把影响员工的因素分成了两类
      • 保健因素
        • 也叫必要因素，必须满足的条件
        • 比如工资、福利、制度等等
        • 基本没有激励作用但必须满足
        • 满足了不会更满意，但是不满足必定不满意
      • 激励因素
        • 比如成就、赏识、挑战性的工作、成长和发展的机会等等
        • 满足了肯定更满意，不满足也未必不满意
  • 期望理论
    • 维克托·弗鲁姆提出来的， 必须满足三个条件，才能让员工满意
      • 努力-绩效
        • 你给员工设定的目标他通过努力可以达到
      • 绩效-奖赏
        • 绩效达标可以获得奖赏
      • 奖赏-吸引
        • 潜在结果或奖赏有吸引力
• 敏捷场景下的项目团队
  • 有效团队
    • 具有共同的目标
    • 喜欢一起工作，互相帮助
    • 凝聚力强，彼此信任
    • 总能按计划达成目标
    • 分工明确，优势互补
    • 顺畅的沟通，主动分享
    • 1+1>2
  • 无效团队
    • 每个人对目标的理解不一致
    • 彼此排斥，单打独斗
    • 职责不清，专业重复或缺位
    • 冲突和不良的竞争
    • 沟通障碍，没有效率的会议
    • 挫折、无谓的返工
    • 1+1<2
  • 团队绩效评价
    • 针对：人：项目团队；标准：团队有效性； 过程组：执行；方法（例）：回顾会议
  • 项目绩效评价
    • 针对：事：项目进度、成本等指标；标准：计划吻合度； 过程组：监控；方法（例）：挣值分析
• RACI矩阵
  • R=负责 A=问责 C=咨询 I=通知
• 预分派资源
  • 比如这个人是技术骨干，项目团队没他不行， 这个人就是预分派资源，一定要在项目团队里才行
• 虚拟团队
  • 由跨地区、跨组织的成员通过通讯和信息技术联结和协同工作的团队
• 谈判
  • 项目经理需要很强大的谈判能力去和职能部门要人，搭建自己的项目团队
• 资源的获取
  • • 明星队友
      • 能力很强，价值观也很正
    • 野狗队友
      • 能力很强，价值观不正
    • 狗队友
      • 能力一般，价值观不正
    • 兔子队友
      • 能力一般，价值观很正
• 塔克曼阶梯理论
  • 把团队从建设到形成分成了五个阶段
    • 形成
    • 震荡
    • 规范
    • 表现/成熟
    • 遣散
• 冲突管理
  • WAR ROOM
    • 又叫作战室、集中办公、紧密矩阵
• 冲突解决方法
  • 强迫/命令
    • 上级强制命令听他的
  • 撤退/回避
    • 先搁置下冲突，回避下
  • 缓和/包容
    • 一方包容另一方，容忍了
  • 合作/解决
    • 双方去寻找一个双赢的解决方案
  • 妥协/调解
    • 双方各让一步
• 控制资源
  • 人员遣散计划
    • 好处
      • 控制成本
      • 提升士气
      • 降低风险
    • 项目经理要提前想好人员遣散计划，将团队人员回归职能部门

项目沟通管理

• 有效沟通
  • 以正确的形式、在正确的时间把信息提供给正确的受众，并且使信息产生正确的影响
• 沟通管理过程
  • 规划沟通管理
  • 管理沟通
  • 监督沟通
• 沟通管理定义
  • 为确保项目信息及时且恰当地规划、收集、生成、发布、 存储、检索、管理、控制、监督和最终处置所需的各个过程
• 过滤
  • 指大量信息在自上而下或自下而上的沟通过程中损失掉的现象
• 影响沟通的障碍
  • 信息过载
    • 指很短的时间内传递的信息量过大
  • 缺少知识
    • 沟通双方有一方没有知识储备
  • 文化差异
    • 沟通双方的文化差异
  • 分散注意力的环境因素
    • 比如周边环境过于嘈杂
  • 有害的态度
    • 一方对另一方带有有色眼镜
  • 情绪
    • 一方存在情绪不当
  • 不懂专业或者技术术语
    • 双方的知识背景不一样，聊不到一块
  • 沟通渠道过多
    • 相互之间传达信息的人过多
  • 选择性认知
    • 一方只听自己愿意听和想听的话
• 沟通障碍的原因
  • 不同的干系人对项目目标的理解不同
  • 人力、设备、材料等资源的竞争
  • 人员之间的个人冲突
  • 对变化的抵制（如新技术、新流程）
• 沟通的技巧
  • 简化运用语言
  • 视觉辅助手段
  • 积极倾听
  • 有效的反馈
  • 情绪控制
• 沟通的方式
  • 交互式沟通
    • 双方或者多方一言一句交流
      • 会议
      • 电话
      • 即时通讯
      • 视频会议
  • 推式沟通
    • 群发邮件
    • 群发短信
    • 发布公告
  • 拉式沟通
    • 下载
    • 订阅
    • 关注
    • 知识库
• 会议管理的学问
  • 准备并发布会议议程，包含会议目标
  • 在规定的时间开始和结束
  • 确保适当参与者受邀并出席
  • 切题
  • 处理会议中的期望、问题和冲突
  • 记录所有行动及其责任人
• 沟通的方式
  • 内部-外部
  • 正式-非正式
  • 官方-非官方
  • 书面-口头
  • 垂直-水平
    • 垂直是上下级的沟通
    • 水平是同级之间的沟通
  • 言语-体语
• 乔哈里窗
  • 由Joseph Luft和Harry Ingram在20世纪50年代提出
  • 被称为“自我意识的发现-反馈模型”
  • 建议
    • 适当地开放自己的隐秘区，把小秘密告诉对方，这样对方也会把 小秘密告诉自己，两个人的开放区也就越来越大，而未知区就越来越小了
• 书面沟通的5c原则
  • 正确的语法和拼写
  • 简洁的表述和无多余字
  • 清楚的目的和表述（适合读者需要）
  • 连贯的思维逻辑
  • 受控的语句和想法承接
• 规划沟通管理需要注意的点
  • 规划沟通需要考虑
    • 谁需要什么信息和谁有权接触这些信息
    • 他们什么时候需要信息
    • 信息应存储在什么地方
    • 信息应以什么形式存储
    • 如何检索这些信息
    • 是否需要考虑时差、语言障碍和跨文化因素等
  • 沟通漏斗
    • 100%
      • 你想说的
    • 80%
      • 你表达的
    • 60%
      • 他听到的
    • 40%
      • 他听懂的
    • 20%
      • 他做到的
• 沟通路径
  • 两个人之间算1条沟通路径
  • n个人之间的沟通路径为Cn2=nx(n-1)/2

项目风险管理

• 风险管理过程
  • 规划风险管理
  • 识别风险
  • 实施定性风险分析
  • 实施定量风险分析
  • 规划风险应对
  • 实施风险应对
  • 监督风险
• 风险敞口
  • 未加保护的风险，也称“风险暴露”
  • 在某个项目、项目集或项目组合中，针对任一特定对象， 而适时作出的对所有风险的潜在影响的综合评估
• 风险类别
  • 变异性风险
    • 黑天鹅事件
    • 剧情反转
    • 屌丝逆袭
    • 没按套路出牌
  • 模糊性风险
    • 需求不了解
    • 未来看不清
    • 规律搞不懂
    • 趋势猜不透
• 风险定性分析
  • 风险概率和影响定义
  • 风险概率和影响矩阵
• 风险定量分析
  • 模拟
    • 蒙特卡洛法
      • 蒙特卡洛是法国南部的一个全世界倒数第二小的国家摩纳哥的城市，是欧洲著名的赌城
  • 敏感性分析（龙卷风图）
  • 决策树
  • 影响图
    • 影响图是由结点和有向弧组成的无环路的有向图，其中，结点 代表所研究问题中的主要变量，有向弧表示变量间的各种相互关系
• 主题
• 风险和资源的关系
  • • 可以自动权变（不需要走变更程序）的情况
      • 人命关天，无暇请示上级
      • 有充足的理由证明来不及请示汇报
    • 不管是走应急计划，弹回计划还是走权变措施，都要先走整体变更控制程序
• 风险与项目生命周期
• 项目风险分类
  • 对风险是否了解
    • 已知风险
    • 未知风险
  • 按风险的作用范围
    • 内部风险
    • 外部风险
  • 按是否可以通过保险来转移
    • 商业风险
      • 比如创业这种，不能通过保险来转移风险的
    • 可保险风险
      • 可以通过买保险的形式来转移风险
• 选择风险应对策略时的影响因素
• 风险应对策略
  • 负面风险
    • 规避
      • 改变计划，换条路
    • 转移
      • 买保险
      • 外包出去
    • 减轻
      • 降低风险发生的概率
        • 比如打疫苗
      • 减小风险的影响
  • 正面风险（也叫机会）
    • 开拓
      • 想尽办法拥抱他
      • 努力将发生概率提升到100%
    • 提高（增强）
      • 扩大他给我带来的好处
      • 提高发生概率，但是不要求100%
    • 分享
      • 自己搞不定，和别人合作
  • 不管正面还是负面，接受（认命了）！
  • 不管正面还是负面，上报（交给管理层）！
• 风险应对工具
  • 应急计划（PLANB）
    • 事先制定的风险应对计划，以便在风险发生或出现 某些规定情况（风险触发器）时采用，是风险主应急计划
    • 应对的是已知风险
  • 弹回计划（保底计划）
    • 一般针对严重风险的备用的应急计划。在主应急计划不起作用时才启用
  • 权变措施
    • 是针对以往未曾识别或被动接受的、目前正在发生的风险， 而紧急采取的、原来没计划过的应急措施
    • 要经整体变更控制过程综合评估
    • 应对的是未知风险
  • 举例
    • 原计划：出国
    • 应急计划：考研
    • 弹回计划：找工作
    • 权变措施：送外卖
• 整合式风险管理
  • 项目风险
    • 项目经理负责
  • 项目集风险
    • 项目集经理负责
  • 项目组合风险
    • 项目组合经理负责
  • 组织风险
    • 企业老板负责
• 相关方的风险态度
  • 取决因素
    • 对风险的承受力
    • 相关方的偏好
• 识别风险的方法
  • 头脑风暴法（诸葛亮会议）
  • 德尔菲法（背靠背评估法）
    • 相关专家匿名参与。对专家的答卷进行归纳，发还给专家 做进一步评论。这个过程重复几轮后，就可能取得一致意见
    • 德尔菲技术有减轻数据的偏倚，防止任何个人对结果产生不恰当的影响
  • 根本原因分析（瑞士奶酪原理）
  • 核对单分析
  • 假设分析
  • 系统流程图
  • 专家判断
    • 注意专家的偏见
      • 可以通过德尔菲法来避免
    • 重视专家的直觉
  • 假设条件和制约因素分析
    • 假设条件：不确定，经验推断
      • 比如有可行的技术方案、有成熟的产品组件、 不会有其他突发工作、客户不会改需求、团队成员都能加班
    • 制约因素：已确定，客观存在
      • 比如只有6个人、只给50万、只剩30天、不可外包、数据保密
  • SWOT分析
    • 优势（Strengths）、劣势（Weaknesses） 机会（Opportunities）、威胁（Threats）
  • 提示清单
    • 识别单个项目风险
  • 战略框架
    • 识别整体项目风险
      • 从政治、经济、社会、技术、法律、环境等方面去分析
      • 从技术、环境、商业贸易、运营、政治方面去分析
      • 从多变的、不确定的、复杂的、模棱两可去分析（VUCA）
  • 层级图（气泡图）
    • 紧迫性、邻近性、潜伏期、可管理性、可控性、 可监测性、连通性、战略影响力、密切度

项目采购管理

• 采购管理的过程
  • 规划采购管理
  • 实施采购
  • 控制采购
• 采购领域的趋势
  • 建筑信息模型BIM
  • 国际标准采购合同范本
    • FIDIC国际咨询工程师联合会
    • AIA美国建筑师学会
    • ICE英国土木工程师学会
    • World Bank世界银行
• 敏捷场景下的采购管理
  • 通过主要服务协议（MSA）来管辖整体协作关系， 用附录或补充文件记录适应型的工作内容
• 采购合同类型
  • 总价类型
    • 固定总价合同
      • 英文名称FFP:Firm Fixed Price/Lump Sum
      • 合同的价格固定死了，不管乙方实际花销多少，甲方支付的都是这个数， 乙方实际成本超支了，乙方自己贴，乙方节约了，也算是乙方自己赚了的
      • 适用于甲乙双方对于项目的范围很清楚，也不会有太大的分歧，项目本身也比较简单
    • 总价加激励费
      • 英文名称FPIF:Fixed Price Plus Incentive Fee
      • 成本按预算控制另加约定费用，如成本超支或节约， 按约定的比例分担或分享，并设置天花板价格
      • 天花板价格是买方向卖方支付的最高价格
    • 总价加经济价格调整
      • 英文名称FP-EPA:Fixed Price-Economic Price Adjustment
      • 合同总价可以根据物价变动等因素调整
    • 适用于范围确定，需求明确的情况下
  • 成本补偿类型
    • 成本+固定费
      • 英文名称CPFF:Cost Plus Fixed Fee
      • 成本实报实销，按约定的固定数额支付费用
    • 成本+激励费
      • 英文名称CPIF:Cost Plus Incentive Fee
      • 成本按预算控制另加约定费用，如成本超支或节约，按约定的比例分担或分享
      • 对比总价加激励费合同类型，成本+激励费合同没有设置天花板价格
      • 对比成本+奖励费，成本+激励费的激励费是有公式可以算出来的
    • 成本+奖励费
      • 英文名称CPAF:Cost Plus Award Fee
      • 成本实报实销，甲方根据乙方表现给予奖励
      • 对比成本+激励费，成本+奖励费的奖励费是无法计算出来的，奖励费 是完全看甲方的心情来的，所以只要能算出来费用的都是成本+激励费
    • 适用范围可能变化，有变更需求的情况下
  • 工料合同T&M
    • 适用于不复杂的项目，要干的活相对来说比较简单，没有什么太大的 不确定性和变化，但是所需要的人工和材料的用量不好预测或者预测太麻烦
    • 适用范围无法确定的情况下
• 投标人会议&采购谈判
  • 投标人会议
    • 作为发包方，把所有具备资格，有条件来投标的投标方都召集来开一个投标人会议
    • 这个投标人会议上，投标人要澄清下这次招标过程是合法有效的， 公平公开的，不存在什么猫腻，不存在什么灰色地带等等
    • 投标人会议主要是为了申明甲方招标过程的合法合规和有效，免除一些不必要的责任
    • 召开时间：投标前；邀请参与方：所有符合条件的投标方；要澄清的内容：招标文件
  • 采购谈判
    • 在合同签署之前，对合同内容加以澄清，以取得一致意见
    • 包括责任、变更的权限、使用的条款和法律、技术和商务要求、 所有权、合同融资、技术解决方案、总体进度计划、付款以及价格等
    • 召开时间：中标后，签合同前；邀请参与方：中标方；要澄清的内容：合同
• 采购审计
  • 检查采购的执行过程是和采购管理计划当中定义的 这些规则流程是否一致，不一致的话就是不合规
  • 采购审计关心的就是合规，但是他并不在意具体的结果。比如说采购管理计划当中要求这个采购必须招标，那我们就要检查你是否严格地遵守了招标的流程和招标的规则。至于哪家中标了，最后又是以多少金额中的标，这些其实不是采购审计关心的问题
• 采购合同的结束形式
  • 成功完成
    • 甲乙双方的关系保持很好，并且也完成了合同的条款
  • 变更补偿
    • 甲乙双方的关系破裂，但是完成了合同的条款
  • 仲裁诉讼
    • 甲乙双方的关系破裂，并且也没完成合同的条款
  • 协商终止
    • 甲乙双方的关系保持很好，但是没有完成合同的条款，被迫协商终止合作
• 采购管理中的责任分析
  • 项目经理
    • 项目需求
  • 技术经理
    • 技术规范
  • 采购经理
    • 采购文件
• 项目收尾
  • 合同收尾
    • 定义：与供应商或客户完成交接，结清账目；发生时间：合同结束时； 经验总结：采购审计；审批者：买方（甲方）的采购管理员向卖方（乙方）签发书面确认； 交接对象：与外部客户交接；
  • 行政收尾
    • 定义：企业内部项目收尾程序；发生时间：项目或每个阶段结束时； 经验总结：经验教训总结；审批者：发起人或管理层向项目经理签发书面确认； 交接对象：与公司内部交接
  • 先后顺序：先与外部客户交接，再跟公司内部交接，也就是先合同收尾，再行政收尾
• 索赔管理
  • 甲乙双方签了合同之后，由于甲方或者乙方没有按照合同来履行自己的责任和 义务，那么就有可能给对方造成了损失或者增加了成本，那么对方就要求你来补偿
• 采购合同争议解决方式
  • 谈判
    • 甲乙双方自己谈判解决争议
  • 替代争议解决ADR
    • 甲乙双方找第三方来解决争议
  • 仲裁
  • 诉讼
• 自制外购分析
  • 需要分析下WBS的每个工作包是自己干还是外包给其他公司干
  • 自制的原因
    • 自制成本低
    • 保证充足供应
    • 无合适的供应商
    • 利用过剩劳动力
    • 获得供应的主动性
    • 排除供应商之间的勾结
    • 保护专利设计或商业机密
    • 保证质量
    • 维持组织的规模或能力
  • 外购的原因
    • 外购成本低
    • 降低库存压力
    • 保留供应商的许诺
    • 生产能力不足
    • 获得技术或管理能力
    • 获得供应的灵活性和可替代性
    • 产品受到专利或商业机密的保护
    • 保证质量
    • 享受配套的售后服务
• 供方选择分析
• 独立估算
  • 发包人事先找专业人士或第三方专业的机构算一下这部分工作应该花多少钱， 这个数就是标底价，通常是只有发包人自己知道，是保密的。发包人也可以 利用这个标底价来做一些修改，比如增加一个百分比，然后公开出去，这个数 就是拦标价。超过拦标价的投标都是废标
  • 独立估算有助于发包人控制成本，控制风险
• 合同类型与风险分担
  • 总价合同
    • 项目范围：明确；不确定性：低；风险分担：乙方
  • 成本补偿合同
    • 项目范围：不明确；不确定性：中；风险分担：甲乙双方
• 采购文件
  • 招标文件（采购部门负责）
    • 信息邀请书RFI
      • 甲方找寻能干这活的乙方，乙方需要提供他能干成这活的一些基本信息
    • 报价邀请书RFQ
      • 在RFI基础上，乙方还需要增加一个报价
    • 建议邀请书RFP
      • 在RFQ基础上，乙方还需要拿出他对于干成这活的一套方案
  • （采购）工作说明书SOW（项目经理负责）
    • 英文名称Statement of Work
    • 甲方撰写的关于乙方如何做这活的一些相关信息
  • 工作大纲TOR（项目经理负责）
    • 甲方撰写的关于工作的范围，工作的性质等的一些信息
• 采购策略之交付方法
  • 设计-招标-建造DBB（Design-Bid-Build）
    • 甲方自己负责设计-招标-建造的工作
  • 总承包（EPC）
    • 设计，采购，建造都统一交给一个总承包方
  • 特许经营
    • 甲方一定是政府
    • 建设-运营-移交BOT（Build-Operation-Transfer）
      • 比如政府要建高速公路，但是没有钱，叫来企业帮忙出钱来建。 建好之后，政府不用向企业支付建造费用，而是特许企业运营 高速公路五十年，这五十年的高速过路费的收入都给企业
    • 建设-移交BT（Build-Transfer）
      • 比如政府要搞商品房，但是没有钱，叫来企业帮忙出钱来建，建好之后，政府还是没有钱给企业，政府就把经济适用房卖给企业以此来抵企业为政府建造的商品房的成本
    • PPP（Public-Private-Partnership）
      • 政府和企业一起合资，政府出小头，企业出大头

项目相关方管理

• 相关方管理的过程
  • 识别相关方
  • 规划相关方参与
  • 管理相关方参与
  • 监督相关方参与
• 相关方管理的考虑点
  • 谁是你的相关方？
  • 他们有什么期望？
  • 他们的影响有多大？
  • 怎么调动他们的积极性？
  • 如何与他们沟通？
  • 怎么解决利益冲突？
• 相关方分析
  • 权力利益方格
    • 基于相关方的职权级别（权力）、对项目成果的关心程度（利益）、对项目成果的影响能力（影响），或改变项目计划或执行的能力，每一种方格都可用于对相关方进行分类
    • 权力高，利益高
      • 重点管理（紧密关注）
    • 权力高，利益低
      • 令其满意
    • 权利低，利益高
      • 随时告知
    • 权力低，利益低
      • 随时关注
  • 相关方立方体
    • 利益、权力、态度三个维度
  • 凸显模型
    • • 潜伏型
        • 他如果想参与，那么影响力很大
      • 随意型
      • 矫情型
      • 权贵型
      • 危险型
      • 从众型
      • 统治型
    • • 蓝色代表已经具有的属性
      • 灰色代表未具有的属性，但如果满足其上面 的条件，就会立刻变成蓝色，变成具备这个属性
• 相关方的类型
  • 受项目影响的相关方
  • 按距离由近及远
    • 内部
    • 本地
    • 国内
    • 国际
  • 项目团队
  • 职能经理
  • 客户/投资人
  • 供应商/分包商
• 相关方登记册
• 相关方参与程度评估矩阵
  • 不知晓
    • 对项目和潜在影响不知晓
  • 抵制
    • 知晓项目和潜在影响，抵制变革
  • 中立
    • 知晓项目，既不支持，也不反对
  • 支持
    • 知晓项目和潜在影响，支持变革
  • 领导
    • 知晓项目和潜在影响，积极致力于保证项目成功

敏捷专项

• 敏捷的洋葱圈
• 敏捷宣言
  • 敏捷软件开发宣言 我们一直在实践中探寻更好的软件开发方法， 身体力行的同时也帮助他人。由此我们建立了如下价值观：
  • 个体和互动 高于 流程和工具
  • 工作的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划
  • 也就是说，尽管右项有其价值，我们更重视左项的价值
• 敏捷原则
  • 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
  • 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化
  • 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期
  • 业务人员和开发人员必须相互合作，项目中的每一天都不例外
  • 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标
  • 不论团队内外，传递信息效果最好效率也是最高的方式是面对面的交谈
  • 可工作的软件是进度的首要度量标准
  • 敏捷过程倡导可持续开发
  • 责任人、开发人员和用户要能够共同维持其步调稳定延续
  • 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强
  • 以简洁为本，它是极力减少不必要工作量的艺术
  • 最好的架构、需求和设计出自自组织团队
  • 团队定期地反思如何能提高成效，并依此调整自身的举止表现
• 迭代待办事项列表
  • 迭代完成的需求列表
  • 产品待办事项列表的子集，只记录当前迭代的工作
  • 将用户故事拆分成任务，团队成员主动领取任务
  • 团队成员有共同的迭代目标，为交付可工作的成果而努力
  • 团队成员可以添加、删减或者更改迭代中的任务
  • 迭代列表中的任务进行了估算，剩余工作量的估计每天需要更新
• 每日站会
  • 鸡和猪都可以参加，但是只有猪可以发言
    • PO、SM、开发团队都是猪
    • 除了以上这三个角色之外的所有人都是鸡
    • 因为猪是全程参与项目的，鸡是半参与
  • 这个活动是用来做每日承诺的，而不是讨论会议
• 迭代评审会议
  • 和外部交互的会议
  • 原则上是规划会议时间的一半
  • 输出的是一份修订的产品待办事项列表
  • 在迭代最后倒数第二个去执行，最后一个是迭代回顾会
  • 为了和利益相关方的步调一致
• 迭代回顾会议
  • 除站会外时间最短的活动
  • 在迭代最后执行
  • 这个活动书上写的与会者是开发团队，PO，SM，利益相关方整个团队
  • 但建议真的要开这个会议的时候，只有开发团队 和SM参与，其他人别来，因为其他人几乎不会有输出的
  • 回顾内容
    • 开发人员的代码质量
    • 对总结的问题进行反馈后一定要有行动项，下个迭代要逐步改善
    • 哪些工作良好（应该继续保持）
    • 哪些做得不好（应该停止）
    • 哪些可以改进（就被按优先排序的改进的行动达成共识）
• 实施敏捷
  • 如何评估组织敏捷变革是否就绪
    • 某些组织的特征可能更容易支持跨部门协作、持续学习和内部过程演变等敏捷原则。
    • 这些变革友好型特征的示例包括
      • 管理层的变革意愿
      • 组织在员工认知、审核和评估方式上做出改变的意愿
      • 集中或分散项目、项目集和项目组合管理职能
      • 专注于短期预算和指标而不是长期目标
      • 人才管理成熟度和能力
  • 组织结构对敏捷环境的影响
    • 组织结构会严重影响其转向新信息或 转变市场需求的能力，以下是主要特征
      • 地理
        • 地理分散的项目组织可能会在各种项目中发现阻碍工作进展的一些挑战
      • 职能结构
        • 有些组织按照高度项目型、矩阵型或高度职能型的方式构建。 具有高度职能结构的项目可能会在组织内部协作方面遇到很大阻力
      • 项目可交付成果的大小
        • 缩小项目可交付成果将会激励部门之间更频繁的交流， 由此带来更频繁的交互以及组织内部更快速的价值流动
      • 项目人员分配
        • 另一种方法是在各个部门中抽出一个人，将其临时完全分配到最高优先级项目
      • 重采购型组织
        • 有些组织选择主要通过供应商实施项目。尽管项目目标可能非常明确，供应商 也有责任监管自己的财务状况。但是，供应商完成其义务并退出合约后，相关 项目知识也将随之带走。这就会限制持续灵活性和速度所需的内部能力
  • 如何与供应商共赢
    • 多层结构
      • 通过将合同中的更多变化因素隔离到单独的文档中，将会简化修改工作并提高灵活性
    • 强调价值交付
      • 里程碑和支付项目可以根据价值驱动可交付成果来构建，以增强项目敏捷性
    • 总价增量
      • 项目可以将范围分解为总价微型可交付成果（例如用户 故事），而不是将整个项目范围和预算锁定到单个协议中
    • 固定时间和材料
      • 将整体预算限制为固定数量，允许客户在最初未计划的项目中纳入新的观点和创新。 如果客户需要纳入新的观点，则必须管理给定能力，用新的工作来替代原有工作
    • 累进的时间和材料
      • 共担财务风险法。如果在合同期限之前交付，则可对供应商的 高效率进行奖励。相反，如果供应商延迟交付，则将扣除一定费用
    • 提前取消方案
      • 如果敏捷供应商在仅完成一半范围时便可交付足够的价值， 且客户不再需要另外一半范围，则不必支付这部分费用
    • 动态范围方案
      • 对于具有固定预算的合同，供应商可为客户提供在项目 特定点改变项目范围的方案。客户可调整功能以适应该能力
    • 团队扩充
      • 大多数协作合同方法是将供应商服务直接嵌入客户组织中。通过资助团队 而不是特定范围，可以保留客户自行确定需要完成工作这方面策略的权力
        • 其实就是外包，也就是供应商外派人员到客户驻场支持
  • 敏捷PMO特点和职责
    • 特点
      • 价值驱动型
        • 所有项目都应在合适的时间为合适的受众提供合适的价值
      • 面向创新型
        • 为了在基于价值的章程下加速发展，PMO可能需要强制执行某些解决方案或方法
      • 多学科型
        • 为了支持特定项目需求，PMO还需要熟悉项目管理本身 以外的其他一些能力，因为不同的项目要求不同的能力
    • 职责
      • 制定和实施标准
        • 提供用户故事、测试案例、累积流图等模版， 提供敏捷工具并培训支持小组了解迭代开发概念
      • 通过培训和指导发展人才
        • 协调敏捷培训课程、教练和导师以帮助员工过渡到敏捷思维模式并升级其技能
      • 多项目管理
        • 通过不同项目交流协调敏捷团队。考虑分享进度、问题、回顾性发现和改进实验等内容
      • 促进组织学习
        • 收集项目进度信息并获取、存储和记录回顾性发现成果
      • 管理相关方
        • 提供产品负责人培训，指导验收测试以及评估方法， 并提供系统反馈。宣扬主题专家（SME）对项目的重要性
      • 招聘、筛选和评估项目领导
        • 制定敏捷实践者访谈指南
      • 执行专业化项目任务
        • 培训和提供回顾促进者，与敏捷项目问题解决者订立协议，并提供导师和教练
  • 项目经理在敏捷环境中的角色——仆人式领导
    • 从事敏捷项目工作时，项目经理的角色就会从 团队的中心转变成为团队和管理人员提供服务
    • 在敏捷环境中，项目经理充当仆人式领导，其工作重点转变为 引导需要帮助的人，促进团队的合作，保持与相关方的需要一致
    • 作为仆人式领导，项目经理要鼓励将责任分配给 团队成员，分配给那些掌握完成任务所需知识的人
      • 其实就是鼓励团队成员承担更多的职责
    • 仆人式领导的职责
      • 仆人式领导的促进作用
      • 仆人式领导消除组织障碍
      • 仆人式领导为他人贡献铺路
    • 仆人式领导的职责实践
      • 教育相关方，使其了解为什么要敏捷以及如何敏捷
      • 通过指导、鼓励和帮助为团队提供支持
      • 通过技术项目管理活动，如量化风险分析来帮助团队
      • 庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用
  • 敏捷团队的特征
    • 专门人员
      • 专心致志，提高工作效率
      • 少于十人的小型团队
    • 跨职能团队成员
      • 作为一个独立团队交付完成的价值
      • 频繁开发与交付
      • 为完成任务，整合所有工作活动
      • 从团队内部和外部提供反馈
    • 集中办公或有能力应对办公地点不同带来的任何挑战
      • 改善沟通
      • 提供团队动力
      • 知识共享
      • 降低学习成本
      • 能够致力于相互合作
    • 由通才和专家组成的混合团队
      • 专家提供专门技能，通才提供从事不同工作的灵活性
      • 团队具有专业能力，往往成为通才型专家，他们既有专长又有多种技能经验
    • 稳定的工作环境
      • 彼此依赖实现交付
      • 对工作方法相互认同
      • 简化团队成本核算
      • 知识资本的保留和发展
  • 敏捷常用衡量工具
    • 燃尽图
    • 燃起图
  • 单团队敏捷实践
    • 看板
    • 极限编程（XP）
      • 一种基于频繁交付周期的软件开发方法
    • 水晶
      • 一种方法论家族，旨在根据项目规模（项目中涉及的人员数量） 以及项目的关键性来量化并提供方法严格程度选择
    • Scrumban
      • 一种敏捷方法，最初设计为Scrum到看板之间的过渡方法
    • 功能驱动开发（FDD）
      • 开发目的是满足大型软件开发项目的特定需求
    • 动态系统开发方法（DSDM）
      • 因强调制约因素驱动交付而著称。该框架从一开始便可设置成本、 质量和时间，然后利用正式的范围优先级来满足这些制约因素的要求
    • 敏捷统一过程（AgileUP）
      • 软件项目中统一过程（UP）的分支。其目的在于在七个主要 因素之间执行更多迭代的周期，并在正式交付之前纳入相关反馈
  • 多团队敏捷实践
    • Scrum of Scrums（SoS）
      • 也称为“meta Scrum”，是由两个或多个Scrum团队而不是一个大型Scrum团队所使用的一种技术，其中一个团队包含三到九名成员来协调其工作。每个团队的代表会与其他团队代表定期召开会议，可能是每日例会，但通常是一周两次或三次
      • 每日例会的执行方式类似于Scrum的每日站会，其中代表将报告已完成的工作、 下一步工作设置、任何当前障碍以及可能会阻碍其他团队的潜在未来障碍。 其目标是确保团队协调工作并清楚障碍，以优化所有团队的效率
    • 大规模敏捷框架SAFe
      • 专注于在项目组合、项目集和团队层详细设定实践、角色和 活动，强调围绕专注于向客户提供持续价值的价值流来组织企业
    • 大规模敏捷开发LeSS
      • 一种以扩展Scrum方法为共同目标来组织多个开发团队的框架。 其核心组织原则是尽可能保留传统单个团队Scrum模型的元素
    • 企业Scrum
      • 一种旨在通过更整体性组织层而不是单个产品开发层来应用Scrum方法的框架
    • 规范敏捷DA
      • 一种在综合模型中整合多种敏捷最佳实践的过程决策框架。DA旨在平衡 专注范围过于狭窄（如Scrum）或细节过于规范（如AgileUP）的流行方法
• 生命周期
  • STACE矩阵
  • 四种生命周期特征
  • 如何选择合适的生命周期
    • 没有哪个生命周期能够完美地适用于所有项目
    • 相反，每个项目都能在连续区间内找到一个点，根据其背景特征，实现最佳平衡
• 常见的敏捷实践
• 产品负责人
  • 客户代表
  • 定义所有产品功能
  • 决定产品发布的内容以及日期
  • 对产品的投入产出负责
  • 根据市场变化对需要开发的功能排列优先顺序
  • 合理的调整产品功能和迭代顺序
  • 认同或者拒绝迭代的交付
  • 确保开发团队知道产品待办事项列表
• 产品愿景（电梯演讲）
  • 为了【目标客户】，他们的【需要和机会】，这个【产品名称】， 是一个【产品类型】，它可以【关键优点和使用理由】， 而不像【同类竞争者】，我们产品的【差异化声明】
• 产品梳理会
  • 待办事项列表梳理会
  • 增删改查用户故事
  • 估算规模
    • 估算-相对概念
    • 敏捷估算基本上都建议使用相对估算法，也就是通过一个基线， 其他被估算的事物与基线进行对比，尽可能不使用绝对估算来进行计算
    • 基线选择相对较小，而不是绝对小的
    • 类比估算使用在相似的任务上，可用来复制基线
  • 故事优先级排序
    • 根据价值来分析优先级
      • 交付成本
      • 延迟成本
        • 因为没有做这件事而造成的损失有多大
      • ROI
    • 排序技术
      • MoSCow技术
        • Must Have必须有
          • 60%
        • Should Have应该有
          • 20%
        • Could Have可以有
          • 20%
        • Won't Have不应该有
      • Kano模型
        • 基于用户兴奋点或满意度来设定需求
          • 门槛级
            • 没有这个功能万万不行
          • 线性或性能要求
          • 愉悦要求
          • 淡漠
        • 如果不做这个功能，用户的满意度或兴奋点会是多少
      • 相对量级
      • 权重分析
        • 将所有成功的收获和制约因素均进行罗列
        • 分析每一项影响的大小和范围
        • 重点关注做带来什么收益、风险、问题，不做带来什么收益、风险、问题
        • 每一个都打个分
        • 基于得分高低获取优先级
  • 拆解用户故事
  • 可以邀请利益相关者来进行参与和评审
  • 可以有技术相关的讨论
• 产品增量
  • 交付物
  • 团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付
  • 每次交付的用户故事必须符合验收条件
  • 每次交付的增量成果必须处于可用状态，而不管 PO是否决定发布这个用户故事（交付和上线）
• 敏捷团队管理
  • 敏捷变更
    • 每个迭代里尽量不发生变更
    • 每个迭代之间可以发生变更
      • 人员变更
      • 需求变更
      • 环境变更
      • ……
  • 团队组建
    • 形成（指导型）、震荡（教练型）、规范（支持型）、成熟（授权型）
  • 团队领导
  • 服务式领导
    • 帮助团队>命令团队
    • 移除障碍>创建阻碍
    • 保护团队>干扰团队
  • 敏捷创建的是自组织团队，所以管理基于团队，不基于任务，团队应该在一起
• 用户故事
  • 作为【用户角色】，我想要【活动】，以便于【原因/价值】
  • 3c原则
    • Card卡片
      • 用户故事建议写在卡片上
    • Conversation交谈
      • PO和团队互相交谈，自组织决策
    • Confirmation确认
      • 确认验收标准
• Scrum Master（SM）
  • 项目早期SM和PM（项目经理）相对统一
    • 制定规则
    • 管理期望
    • 管理相关方
    • 制定沟通策略
    • 管理承诺等
  • 项目执行起来则SM和PM进行切割（SM不做决策，PM做决策）
  • 鼓励言论自由
  • 保证仪式
  • 团队有问题，优先内部讨论解决
  • 保护团队一个整体
• 开发团队
  • 自主选择
  • 全职能
  • 跨团队本身不进行解决
  • 决策在团队内
  • 平级
• 精益与看板体系
  • 看板
    • 这是用来进行透明的，对于管理干系人的希望有促进作用
    • 比如燃尽图、燃起图、看板或任务板、风险看板等
  • Kanban系统
    • Kanban系统是一个体系化的内容，它来自于风险。基于风险制造的 一些经验，罗列沉淀出来的适用于软硬件甚至制造行业的方法论
    • Kanban六大核心实践
      • 工作流程可视化
        • Kanban有设计、开发、测试等流程
      • 限制在制品数量
      • 度量和管理流动
      • 显示化规则
      • 建立反馈环路
      • 在协作及实验中改进
    • Kanban没有时间箱的概念
  • 极限编程
    • 重点实践
      • 持续集成
      • TDD
        • 测试驱动开发
      • 结对编程
        • 老带新
        • 系统复制
        • 攻坚难题
    • 代码集体所有权、小型发布
• 探测（Spike）
  • 敏捷中使用的一种技术，一般情况下只用来判断可行性的， 所有不确定的地方：风险、技术、商业模式等
• 产品待办事项列表
  • 排了序的需求池
  • 产品需求的列表
  • 包含业务需求、技术需求、NFR等
    • NFR是Non-Function-Requirements非功能性需求，也可以唤作性能需求
    • 技术需求包括但不限于：技术优化、技术方案调研
    • 还有培训呀，学习呀等等这些都可以放在产品待办事项列表里
  • 理想情况下，每一个待完成的工作都将对客户产生价值
  • PO对该列表进行优先级排序
  • 每个迭代开始前，优先级排序还需要再度修正
  • 待办事项列表中的条目以用户故事的形式呈现
  • 符合的原则
    • 适当的详细程度Detailed
    • 被估算的Estimated
    • 涌现的Emergent
    • 排了优先级的Prioritized
• 迭代规划会议
  • 分成两个阶段
    • 第一个阶段
      • 选取用户故事，确定迭代目标
        • PO与团队一起从产品待办事项列表中选择待完成的用户故事
    • 第二个阶段
      • 拆分任务，创建迭代待办事项列表
        • 团队拆分和确认任务，给出工作量估算
• DOD（完成的定义）
  • 核心就是做到什么样就算完成了
  • 可以通过流程或者本身交付物来进行限定
• 团队速率
  • 固定时间内团队完成任务的规模
  • 通常是单次迭代
  • 团队速率不是越大越好，而是越稳定越好
  • 跨团队比较不成立，但可以跨迭代比较，前提是统一基准
• Scrum体系（3355）
  • 3种角色
    • 产品负责人Product Owner
    • Scrum Master
    • 开发团队Dev Team
  • 3种工件
    • 产品待办事项列表Product Backlog
    • 迭代待办事项列表Sprint Backlog
    • 产品增量Product Increment
  • 5种仪式
    • 迭代Sprint
      • 其他四种的合称
    • 迭代计划会Sprint Plan
      • 迭代里第一个开的会议
    • 每日站会Daily standup meeting
      • 迭代每天都要开的会议，第二个开的会议
    • 迭代评审会Sprint Review
      • 第三个开的会议
    • 迭代回顾会Retrospective
      • 第四个开的会议
    • 产品梳理会
      • 不放在迭代里，但是有这么一个会，一般是在规划会议前开始
  • 5种价值观
    • 勇气Courage
    • 开放Open
    • 专注Focus
    • 承诺Commitment
    • 尊重Respect