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

这是一篇关于高项第五章-项目范围管理的思维导图。从控制范围、确认范围等方面梳理，内容详实，结构清晰，逻辑严密，非常值得学习。

第五章-项目范围管理

• 5.1规划范围管理
  • 定义
    • 编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。
  • 两种范围
    • 项目范围
      • 工作
        • 明确项目边界
        • 对项目执行工作进行监控
        • 防止项目范围发生蔓延
      • 定义
        • 为了能交付产品，项目必须做的工作
        • 产生项目管理计划的基础
        • 范围基准是经过批准的项目范围说明书、WBS、WBS词典
    • 产品范围
      • 产品或服务应包含的范围
      • 是产品要求的描述，是项目范围的基础
      • 根据是否满足产品描述来判断产品范围是否完成
• 5.2收集需求
  • 定义
    • 为实现项目目标而确定、记录并管理干系人的需要和需求的过程
  • 分类
    • 业务需求
    • 干系人需求
    • 解决方案需求
      • 功能需求
      • 非功能需求
    • 过渡需求
    • 项目需求
    • 质量需求
  • 工具与技术
    • 访谈
    • 焦点小组
      • 将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更加热烈。焦点小组是一种群体访谈而非一对一访谈
    • 引导式研讨会
      • 通过邀请主要的跨职能干系人一起参加会议。引导式研讨会对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术
    • 群体创新技术
      • 头脑风暴
      • 名义小组
        • 投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序
      • 德尔菲技术
        • 匿名或背靠背的方式、预测过程几轮反馈，使专家的意见逐渐趋同
      • 概念/思维导图
      • 亲和图
        • 是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来
      • 多标准决策分析
    • 群体决策技术
      • 一致同意
      • 大多数
      • 子主题
    • 问卷调查
    • 观察
    • 原型法
    • 标杆对照
    • 系统交互图
    • 文件分析
  • 需求文件
    • 业务需求
    • 干系人需求
    • 解决方案需求
    • 项目需求
    • 过渡需求
    • 假设条件、依赖关系、制约因素
  • 需求跟踪
  • 需求管理
    • 包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态
    • 需求基线
      • 软件项目需求开发的结果应该有项目视图和范围文档、用例文档、软件需求规格说明及相关分析模型，经评审批准，这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。
    • 需求获取
      • 积极地和用户交流，获取用户需求并分析和修正，最后形成符合解决问题的用户需求，生成《用户需求说明书》
    • 需求分析
      • 对各种需求进行分析并抽象描述，建立一个可以指导系统的概念模型
    • 需求定义
      • 根据需求获取和需求分析的结果，定义准确的产品需求，生成《需求规格说明书》
    • 需求验证
• 5.3定义范围
  • 定义
    • 定义范围是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界
  • 工具与技术
    • 专家判断
    • 产品分析
    • 备选方案生成
    • 引导式研讨会
  • 项目范围说明书
    • 产品范围描述
    • 验收标准
      • 成本、进度、质量测量指标
    • 可交付成果
    • 项目的除外责任
    • 制约因素
    • 假设条件
    • 作用
      • 确定范围
      • 沟通基础
      • 规划和控制依据
      • 变更基础
      • 规划基础
• 5.4创建WBS
  • 定义
    • 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程
  • 里程碑
    • 标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线
  • 工作包
    • ≥8小时，≤80小时
  • 控制账户
    • 一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户
  • 规划包
    • 是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分
  • WBS词典
    • 包括账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息
  • 分解活动
    • 识别和分析可交付成果及相关工作
    • 确定WBS的结构和编排方法
    • 自上而下逐层细化分解
    • 为WBS组件制定和分配标识编码
    • 核实可交付成果分解的程度是恰当的
  • 8个注意方面
    • WBS必须是面向可交付成果的
    • WBS必须符合项目的范围
    • WBS的底层应该支持计划和控制
    • WBS中的元素必须有人负责，而且只由一个人负责
    • WBS的指导。作为指导而不是原则，WBS应控制在4~6层
    • WBS应包括项目管理工作，也要包括分包出去的工作
    • WBS的编制需要所有(主要)项目干系人的参与，需要项目团队成员的参与
    • WBS并非是一成不变的
• 5.5确认范围
  • 定义
    • 项目干系人对已完成的可交付成果进行正式验收的过程
  • 工具与技术
    • 检查
    • 群体决策技术
  • 步骤
    • 确定需要进行范围确认的时间
    • 识别范围确认需要哪些投入
    • 确定范围正式被接受的标准和要素
    • 确定范围确认会议的组织步骤
    • 组织范围确认会议
  • 与质量控制区别
    • 确认范围强调可交付成果的接受程度；质量控制强调可交付成果正确性；
    • 质量控制一般在确认范围前进行，也可同时；确认范围一般在阶段末；
    • 质量控制是内部检查；确认范围由项目干系人验收可交付成果；
  • 与收尾区别
    • 确认范围强调核实与接受可交付成果；收尾强调结束项目或阶段的流程性工作
    • 确认范围强调验收可交付成果；收尾强调验收产品
• 5.6控制范围
  • 控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。其主要作用是在整个项目期间保持对范围基准的维护
  • 主要工作
    • 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
    • 判断范围变更是否已经发生
    • 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理