第五章 项目范围管理 思维导图

这是一篇有关项目范围管理的思维导图，包含了项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。

第五章 项目范围管理

• 前言
  • 范围管理的目标
    • 1、要做什么
    • 2、只做什么
    • 不要少做，也不要多做。任何多做的事都是有成本的。
  • 范围管理包括
    • 产品范围
    • 项目范围
  • 范围管理的过程
    • 确保相关人员对要做哪些工作达成共识
  • 不同生命周期范围管理差别
  • 质量功能展开 QFD
• 一、规划范围管理
  • 输入
    • 项目章程
      • 项目章程记录了项目目的、项目概述、假设条件、制约因素，以及项目意图实现的高层级需求
    • 项目管理计划
      • 质量管理计划
        • 在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式
      • 项目生命周期描述
        • 项目生命周期定义了项目从开始到完成所经历的一系列阶段
      • 开发方法
        • 瀑布式
        • 迭代型
        • 适应型
        • 敏捷型
        • 混合型
    • 事业环境因素
      • 组织文化
      • 基础设施
      • 人事管理制度
      • 市场条件
    • 组织过程资产
      • 政策和程序
      • 历史信息和经验教训知识库
  • 工具技术
    • 专家判断
      • 就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：
        • 以往类似项目
        • 特定行业、学科和应用领域信息。
    • 数据分析
      • 备选方案分析
        • 本技术用于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。
    • 会议
  • 输出
    • 范围管理计划
      • 描述如何定义、制定、监督、控制和确认项目范围。要对下列工作的管理过程作出规定
        • 制定项目范围说明书
        • 根据详细项目范围说明书创建WBS
        • 确定如何审批和维护范围基准
        • 正式验收已完成的项目可交付成果
    • 需求管理计划
      • 描述如何分析、记录和管理项目和产品需求。主要内容包括不限于
        • 如何规划、跟踪和报告各种需求活动
        • 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；
        • 需求优先级排序过程
        • 测量指标以及使用这些指标的理由
        • 反映哪些需求属性将被列入跟踪矩阵的跟踪结构。
• 二、收集需求
  • 关于需求
  • 收集需求的工具和技术
    • 专家判断
    • 数据收集
      • 头脑风暴
      • 访谈
      • 焦点小组
        • 会议主题明确
      • 问卷调查
        • 面大 面广
      • 标杆对照
        • 和竞争对手 和行业龙头进行比较
    • 数据分析
    • 决策
      • 确定什么需求应该被满足，什么需求应该要求客户让步的过程
      • 工具
        • 投票
          • 投票人数单数
          • 三种方式
            • 1、一致同意
            • 2、大多数同意50%
            • 3、相对多数同意
        • 独裁
        • 多标准决策（MCDA）
    • 数据表现技术
      • • 对创意进行分组，以便进一步审查和分析
      • 思维导图
        • 把头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意
    • 人际关系与团队技能
      • 名义小组
        • 1、小组成员先不通气，独立思考
        • 2、各自轮流写下备选方案和意见
        • 3、轮流陈述自己的方案和意见
        • 4、小组成员对全部备选方案投票
        • 5、得票最得到备选方案入选
        • 6、当然，管理者仍有权否决这一方案
      • 观察法
      • 引导式研讨会
        • 比如专家会诊
        • 跨部门跨专业讨论 有主持人
    • 四种需求呈现的方式
      • 用户故事
        • 以固定的语法把客户的需求表述成统一的格式。以便于项目成员分析。识别它。
        • • 作为一个微信用户我希望微信不限制好友数量，以便于我只用一个微信号就可以了
      • 故事版
        • 用可视化剧本去确认需求
      • 系统交互图
        • 通过分析、解构现实当中的工作的模式和流程，最后产生一个我们的系统的开发需求。
      • 原型法 Prototype
        • 先做一个样品根客户进行需求确认
          • 样板间
          • 样机
          • 样板app
  • 输出
    • 需求文件
      • 描述各种单一需求将如何满足与项目相关的业务需求
      • 主要相关方认可后 可作为基准
    • 需求跟踪矩阵
      • 最大作用：能够把历史上曾经发生过跟需求有关的识别、记载、变化都能忠实地记录下来，以便于我们去跟踪管理。
• 三、定义范围
  • 总论
    • 由于收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。
  • 输入
    • 项目章程
    • 项目管理计划
      • 范围管理计划
    • 项目文件
      • 假设日志
      • 需求文件
      • 风险登记册
        • 风险登记册记载了可能影响项目范围的风险及其应对策略，例如缩小和改变项目范围，以规避或缓解风险。
    • 事业环境因素
      • 组织文化
      • 基础设施
      • 人事管理制度
      • 市场条件
    • 组织过程资产
      • 用于指定项目范围说明书的政策、程序和模板
      • 以往项目的项目档案
      • 以往阶段或项目的经验教训
  • 工具与技术
    • 专家判断
    • 数据分析
      • 备选方案分析
        • 用于评估实现项目章程中所述的需求和目标的各种方法。
    • 决策
      • 多标准决策分析
        • 借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。
    • 人际关系与团队技能
      • 引导
        • 在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业背景的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。
    • 产品分析
      • 把高层级的产品或服务描述转变成为有意义的可交付成果。
        • 产品分解
        • 需求分析
        • 系统分析
        • 系统工程
        • 价值分析
        • 价值工程
  • 输出
    • 项目范围说明书
      • 产品范围描述
        • 逐步细化，渐进明细
      • 可交付成果
        • 描述可详可略
      • 验收标准
        • 可交付成果通过验收前必须满足的一系列条件
      • 项目的除外责任
        • 识别排除在项目之外的内容。有助于管理相关方期望以及减少范围蔓延
      • 项目范围说明书与项目章程关系
        • 渐进明细的一个过程，章程是纲领，范围说明书是细节。
        • • 高层及需求
            • wbs中高层次的描述，细分前的需求 粗略的
    • 项目文件更新
      • 假设日志
        • 随同本过程识别出更多的假设条件或制约因素而更新假设日志
      • 需求文件
        • 可以通过增加或修改需求而更新需求文件
      • 需求跟踪矩阵
        • 随需求文件的更新而更新
      • 相关方登记册
        • 如果在本过程中收集到了新的相关方，则记录下来
• 四、创建WBS
  • 输入
    • 项目管理计划
      • 范围管理计划定义了如何根据项目范围说明书创建WBS
    • 项目文件
      • 项目范围说明书
      • 需求文件
    • 事业环境因素
      • 所在行业WBS标准
    • 组织过程资产
      • 用于创建WBS的政策、程序和模板
      • 以往项目的项目档案
      • 以往项目的经验教训
  • 工具与技术
    • 专家判断
      • 用征求具备类似项目知识或经验的个人或小组的意见
    • 分解
      • 分解是一种吧项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术
        • 识别和分析可交付成果及相关工作
        • 确定WBS的结构和编排方法
        • 自上而下逐层细化分解
        • 为WBS组成部分制定和分配标识编码
        • 合适可交付成果分解的程度是否恰当
  • 输出
    • 项目范围基准
      • 项目范围说明书
        • 包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
      • 工作分解结构WBS
        • WBS组件
          • 子项目
          • 控制账户
            • 选择一级工作包 作为账户分类方式
            • 一般与团队对应，一个团队一个账户
          • 工作包
            • 拆到很轻易就能知道这个工作需要的时间 资源 成本 的程度。这样一个单元就叫做工作包
            • wbs最低层次的单元
            • 项目经理最低管到工作包
          • 规划包
            • 做分解时无法评估的工作包暂时先定位规划包。
          • 活动
            • 工作包再细分叫活动
            • 对应 执行团队
          • 任务
            • 活动再分叫任务
            • 对应 个人
        • WBS是项目管理中最重要的工作，是其他工作的基础
          • 是基准的来源
            • 直接决定范围基准
            • 进度、成本基准是依据范围基准来的。
          • 是计划的基础
          • 工作的展现
          • 控制的依据
          • 团队的指南
      • WBS词典
        • 针对每个WBS组件，详细描述可交付成果活动和进度信息的文件。
        • 一个工作包对应一个表，所有表合在一起叫WBS词典
    • 项目文件更新
      • 假设日志
        • 随同本过程识别出更多的假设条件或制约因素而更新假设日志
      • 需求文件
        • 可以更新需求文件，以反映在本过程中提出并已被批准的变更
• 五、确认范围
  • 确认范围是正式验收已完成的项目可交付成果的过程。本过程的作用是使验收过程具有客观性，同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。本过程应根据需要在整个项目期间定期展开。
    • 注意交付前要检查
    • 跟客户确认的工作要积极，不要积攒。分批分期及时确认。
    • 每完成一部分交付成果，每到一个阶段及时让客户确认。
  • 输入
    • 项目管理计划
      • 范围管理计划
        • 定义了如何正确验收已经完成的可交付成果
      • 需求管理计划
        • 需求管理计划描述了如何确认项目需求
      • 范围基准
        • 用范围基准与实际结果比较，以确定是否有必要进行变更、采取纠正措施。
    • 项目文件
      • 经验教训登记册
        • 在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果
      • 质量报告
        • 内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前。需要查看所有这些内容。
          • 控制质量过程已经完成后的输出 是报告
      • 需求文件
        • 将需求与实际结果比较，已决定是否有必要进行变更、采取纠正措施或预防措施。
      • 需求跟踪矩阵
        • 需求跟踪矩阵含有与需求相关的信息，包括如何确认需求
    • 核实的可交付成果
      • 核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
    • 工作绩效数据
      • 工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。
  • 工具与技术
    • 检查
      • 检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
    • 决策
      • 投票
  • 输出
    • 验收的可交付成果
      • 符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或者发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。
    • 工作绩效信息
      • 通过工作绩效数据 得出工作绩效信息，例如哪些可交付成果已被验收，哪些未通过验收以及原因。这些信息应该备记录下来并传递给相关方。
    • 变更请求
      • 对已经完成但未通过正式验收的可交付成果及未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。变更请求应该由实施整体变更控制过程进行审查与处理。
    • 项目文件更新
      • 经验教训登记册
        • 更新经验教训登记册，以记录遇到的挑战、本应如何避免该挑战，以及良好的可交付成果验收方法。
      • 需求文件
        • 记录实际的验收结构，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已被放弃的情况。
      • 需求跟踪矩阵
        • 根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。
• 六、控制范围
  • 控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是，在整个项目期间保持对项目范围的维护，且需要在整个项目期间开展。
    • 控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。
    • 在变更发生时，也要采用控制范围过程来管理这些变更。
    • 控制范围过程应该与其他控制过程协调开展。
    • 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。
      • 如何防止范围蔓延
        • 方便的话尽量留开口，做出更改的可能。
        • 范围蔓延：指的是范围发生了改变但是没有经过整体变更控制程序，从而产生了不良的影响。
          • 范围镀金：
            • 镀金要谨慎 稳定
            • 主动
          • 范围爬行
            • 客户不断更改，
            • 被动
          • 都没有经过范围变更流程。
        • 如何避免
          • 镀金的原因
            • 1、讨好客户
            • 2、配置强迫症
              • 象牙筷子综合证
            • 3、秀才艺
            • 要避免
              • 增加的功能一定要绝对稳定否则就不增加
          • 范围爬行
            • 规范的变更流程是保护项目经理和项目团队的防火墙。
    • 变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。
  • 输入
    • 项目管理计划
      • 范围管理计划
        • 记录了如何控制项目和产品范围
      • 需求管理计划
        • 记录了如何管理项目需求
      • 变更管理计划
        • 定义了管理项目变更的过程
      • 配置管理计划
        • 定义了哪些是配置项，那些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
      • 范围基准
        • 用范围基准与实际结果作比较。以决定是否有必要进行变更、采取纠正措施或预防措施。
      • 绩效测量基准
        • 使用挣值分析时，将绩效测量基准与实际结果比较，已决定是否有必要进行变更、采取纠正措施或预防措施。
    • 项目文件经
      • 验教训登记册
      • 需求文件
        • 用于发现任何对商定的项目或产品范围的偏离
      • 需求跟踪矩阵
        • 需求跟踪矩阵有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
    • 工作绩效数据
      • 可能包括收到的变更请求数量、接受的变更请求的数量，以及核实、确认和完成的可交付成果的数量。
• RAM责任分配矩阵
  • 负责人有且只有一个