软考 - 高项复习 - 笔记2：范围管理

阿申申Cindy
1,957 阅读11分钟

笔记专栏：软考-高级-信息系统项目管理-复习笔记

更新了一下整篇行文结构，和后面的章节保持统一，加入更多的个人理解的口水话吧，免得和常规的教材太一致了

项目范围管理

通俗的来说，范围管理，也就是需要在执行项目前，就要确认好需求，确认好项目的范围和边界，从而避免最后的各种延期、交付物内容等风险。

简单的来说，也就是为了解决“项目做什么”的问题

所以本章节的核心关键，就是如何做好需求和分析，创建WBS、构建范围基准

但是如何确认好需求以及项目生命周期的全流程跟踪这件事，就需要一开始做好管理计划，然后不停地和用户（干系人）聊需求、确认需求、分析需求，然后开始把user story这些进行拆解分析，创建WBS，也就是范围基准。最后还需要把范围基准和可交付物进行比对确认，才能提交验收。

所以，这里讨论的关键词就是：需求、范围、WBS/WBS词典

1. 规划范围管理

[In]： 项目管理计划、项目章程、事业环境因素、组织过程资产

[Out]： 范围管理计划、需求管理计划

[Tech]： 专家判断、会议

1. 过程说明

每一个管理领域的开始，几乎都是规划这个领域的管理计划。

范围管理是对项目范围和需求进行管理，所以输入的依据就是项目管理计划和项目章程，根据实际需求，会产生两个计划，一个是范围管理计划，一个是需求管理计划。

怎么记忆呢，就是在项目的一开始，我们需要去跟用户谈需求，但是在那之前，我们要先拿出来一个收集需求的计划，但这个计划在这个几乎一无所有的阶段，也就只有项目管理计划和项目章程可以参考（作为输入）

产出的东西呢，要注意，有个单独的需求管理计划，这个是特别针对于收集需求进行定制的

2. 知识点说明

  1. 范围管理计划内容：
  • 如何制修订项目范围说明书
  • 如何根据项目范围说明书创建WBS
  • 如何维护和批准WBS
  • 如何确认和正式验收已完成的可交付成果
  • 如何处理项目范围说明书变更

全员参与！讲述的是如何进行整个范围管理！！在后续的过程中均有参与！！

所以内容记忆可以根据整个范围管理过程来推理~

  1. 需求管理计划内容：
  • 明确需求（贯穿整个过程，最基本的任务）
  • 建立需求基线（使项目管理团队和用户能达成共识）
  • 建立需求跟踪能力联系链（确保执行过程中，需求能被正确使用）
  • 控制影响范围
  • 始终保持产品与需求的一致性

和下一个“收集需求”的过程紧密相关，重点是要和用户达成共识，并且对需求进行跟踪

2. ITO说明

2.1 输入Input

  • 项目管理计划、项目章程、事业环境因素、组织过程资产
  • 记忆方式：准备规划收集、分析、确认需求这个阶段，并没有太多其他的过程的产物可以用来参考，所以只有项目管理计划和项目章程可以作为输入

2. 收集需求

[In]： 范围管理计划、需求管理计划、干系人管理计划、干系人登记册、项目章程

[Out]： 需求文件、需求跟踪矩阵

[Tech]： 访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析

1. 过程说明

根据上一个过程，产生了“需求管理计划”可知，现在需要开始进行需求的收集

由于需求和干系人（也就是我们的客户、甲方、用户）紧密相关，所以肯定需要经过大量的各种会议或者调研方式，同干系人进行了解和确认。所以输入部分除了范围管理计划和需求管理计划以外，还有干系人管理计划和干系人登记册。

根据需求管理计划内容，收集完需求后，产出的就应该是描述清楚需求的需求文件，和执行过程跟踪需求情况的需求跟踪矩阵

本过程的各种Tech也是十分关键，需要知道群体创新技术和群体决策技术分别有哪些内容，和大致区别。

知识点说明

  1. 需求文件：描述各种单一需求将如何满足项目相关业务需求。主要内容包含了业务需求、干系人需求、解决方案需求、过渡需求、项目需求、与需求有关假设条件、依赖关系、制约因素等等。

  2. 需求跟踪矩阵：（要知道图大概长什么样子）将单个需求和其他元素间的依赖关系和逻辑联系，建立跟踪。

  3. 需求分类:

  • 业务需求：整个组织高层级需要（实施原因）
  • 干系人需求：干系人群体需要
  • 解决方案需求：必须具备的特性、功能、特征
  • 过渡需求： 从“当前”到“将来”所需的临时能力
  1. 常用技术：重要
  • 访谈：与干系人直接交谈，预设和即兴问题（1:1,1:n）
  • 焦点小组：主持人、选定干系人、互动讨论（1:n）
  • 引导式研讨会：主要干系人集中讨论，达成一致意见
  • 群体创新技术：
    1. 头脑风暴：收集创意，追求创意数量，不一定要达成某种结论，发散性讨论
    1. 名义小组：头脑风暴 + 投票排序
    1. 思维导图：mindmap，寻找创意间的共性与差异，可以激发新创意
    1. 亲和图：创意 + 分组，有助于构建WBS
    1. 多标准决策分析：多标准 + 权重 + 评估 + 排序
    1. 德菲尔技术：专家 + 匿名 + 多轮 + 消除偏见（流程比较复杂）
  • 群体决策技术：
    1. 一致同意
    1. 大多数原则
    1. 相对多数原则
    1. 独裁
    1. 问卷调查
    1. 观察
    1. 原型法
    1. 标杆对照

3. 定义范围

[In]： 范围管理计划、项目章程、需求文件、组织过程资产

[Out]： 范围说明书、项目文件更新

[Tech]： 专家判断、产品分析、备选方案生成、引导式研讨会

1. 过程说明

定义范围，可以理解为，要确认范围的边界，以尽量避免后期的项目蔓延、范围蔓延这些情况。也就是为了产生范围说明书，以作为分解WBS的前提。

简单的来说，本过程，是明确收集的需求属于项目范围内

2. 知识点说明

  1. 范围说明书
  • 产品范围描述
  • 验收标准
  • 可交付成果
  • 项目的除外责任
  • 制约因素
  • 假设条件

范围说明书的核心，就是产品的范围描述等内容，详细记载了范围的内容

  1. 产品分析：对将产品作为可交付成果的项目有效

  2. 备选方案生成：指定尽可能多的潜在可选方案（这些备选方案，会在进度管理-估算活动资源的时候，进行分析）

  3. 引导式研讨会：很多专家、干系人集中在一起讨论，达成一致意见

  4. 专家判断

4. 创建WBS

[In]： 范围管理计划、范围说明书、需求文件、事业环境因素、组织过程资产

[Out]： 范围基准、项目文件更新

[Tech]： 分解、专家判断

1. 过程说明

WBS可以理解为需求/任务的分解结构，便于后期安排项目中的任务，而且是层层分解的。

本过程，是在之前的需求文件、范围说明书的基础上，为了便于后续的项目实施，所以进行了层层分解，构建了WBS。也就是“范围基准”（项目管理计划中的三大基准之一）

既然如此，那么所用的技术肯定就是“分解技术”

2. 知识点说明

1. WBS

  1. 全员参与、自上而下逐级分解

  2. 表现形式：

  • 树形：层次清晰，适合小项目
  • 表格型：反映全体要素，适合大项目
  1. 工作包：
  • 位于WBS的最底层
  • 非常具体，便于完整分派给不同的人/组织单元
  1. 控制账户：
  • 管理控制的节点，包含了多个工作包
  • 可以是工作包，也可以比工作包高一级
  1. 规划包：
  • 属于控制账户之下，工作内容已知，但是详细进度缺失的特殊的工作包
  1. WBS词典：
  • 对于WBS中每个元素的详细描述

2. WBS分解

  1. 分解原则：
  • 功能或技术原则（根据不同的人员或情况进行拆分）
  • 组织结构
  • 系统/子系统
  1. 分解方法：
  • 第二层：生命周期各阶段；第三层：产品和可交付成果
  • 第二层：主要可交付成果
  • 整合外包：卖方还需要编写外包部分的WBS

3 创建WBS的过程

  1. 识别工作：识别和分析可交付成果和相关工作
  2. 确定编排：确定WBS结构和编排方法
  3. 逐级分解：自上而下逐级分解
  4. 标识编码：为WBS组件制定和分配标识编码
  5. 核实成果：核实可交付成果分解程度是否恰当

4. 创建WBS需要注意的事项：

  1. 面向可交付成果进行分解
  2. 符合项目范围
  3. 支持计划和控制
  4. 元素由单人负责
  5. 一般分解为4~6层
  6. 包括项目管理、分包内容
  7. 编制需要全员参与
  8. 并非一直不变（完成编制后，仍可能需要修改）

5. 确认范围

[In]： 范围管理计划、需求文件、需求跟踪矩阵、核实的可交付成果、工作绩效数据

[Out]： 验收的可交付成果、变更请求、工作绩效信息、项目文件更新

[Tech]： 检查、群体决策技术

1. 过程说明

确认范围的关键点在于，要将可交付成果，和范围基准（也就是需求）进行比对核实查验，从而获得“验收的可交付成果”

这里需要和“定义范围”过程进行区分，可以理解为一个是事前，一个是事后的两个过程

还需要对“核实产品”和“确认范围”进行区分，两针针对的内容是不一样的，一个是针对产品，一个针对的是可交付成果

还需要对比“确认范围”和“项目收尾”的区别

2. 知识点说明

  1. 需求文件：来自于“收集需求”过程产出

  2. 需求跟踪矩阵：来自于“收集需求”过程产出，用于在执行过程中追踪需求的执行情况

  3. 核实的可交付成果：用于在本过程中和需求进行比对分析，判断是否符合验收标准

  4. 验收的可交付成果：核实的可交付成果通过比对审核，确认可以验收了

  5. 变更请求：比对查验过程中，可能会提出新的变更请求，这个时候又要回去走变更控制流程

  6. 核实产品与确认范围

  • 核实产品：针对产品是否完成，是在项目结束时，由客户/发起人进行验证，强调产品的完整性
  • 确认范围：针对可交付成果，是在阶段末，由客户/发起人进行验收，强调的是可交付成果
  1. 确认范围与项目收尾
  • 确认范围：强调可交付成果，且该过程属于监控过程，贯穿项目始终
  • 项目收尾：验收时强调产品本身，存在于项目结束的阶段
  1. 确认范围步骤
    1. 确认进行范围确认的时间
    1. 确认投入（识别投入）
    1. 确认接受标准和要素
    1. 确认会议组织步骤
    1. 组织确认会议

6. 控制范围

[In]： 项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据、组织过程资产

[Out]： 工作绩效信息、变更请求、项目管理计划更新、项目文件更新、组织过程资产更新

[Tech]： 偏差分析

1. 过程说明

控制范围过程是监督项目和产品的范围状态，管理范围基准的变更

在控制XX过程中，往往存在着绩效数据变为绩效报告、有新的变更请求、管理计划/文件/组织过程资产更新的结果

2. 知识点说明

  1. 造成项目范围变更的原因：外部环境发生变化（范围蔓延）

  2. 范围变更控制的工作（重要）

  • 影响导致范围变更的因素，尽可能使这些因素超有利方向发展
  • 判断范围变更是否已发生
  • 范围变更时，管理实际变更，确保按变更控制过程进行处理
avatar
文章
阅读
粉丝