信息系统项目管理师—第五章 项目范围管理

范围管理

一、范围管理概述

1、项目范围管理需要做以下三方面工作：

（1）明确项目边界，明确那些再范围内，那些再范围外。
（2）确保所有该做的工作都做了，而且没有多做。对不在范围内的额外工作说“不”，杜绝做额外工作。
（3）防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。

2、产品范围与项目范围

（1）产品范围：

产品、服务或成果所具有的特性和功能。产品范围是否完成，以产品是否满足产品描述来判断，如软件产品是否完成，以软件需求规格说明书作为衡量标准。产品范围是项目范围的基础。

（2）项目范围：

是为了交付产品、项目所必须完成的工作。有时项目范围又成为工作范围。项目范围是否完成，以范围基准（项目范围说明书、WBS及字典）为衡量标准。

3、范围管理的重要性

（1）项目范围来自于项目目标，完成项目工作范围是为了实现项目目标。
（2）项目范围管理及控制的有效性，是衡量项目是否达到成功的一个必要标准。
（3）在项目中不断重申项目工作范围，是项目中实施控制管理的一个主要手段。
（4）项目范围管理可以详细、清楚地界定分工界面和责任。
（5）项目范围管理能确定项目边界，明确主要可交付成果，范围管理能提高对项目成本、进度和资源估算的标准性。
（6）项目范围管理影响到项目的成功，在实践中，范围蔓延时项目失败最常见的原因之一。

4、范围问题引起项目失败实例

范围没管好，时项目失败的主要因素之一。
原因：项目范围没有事先定义好，需求、事情没完没了的出现。
解决：重新梳理范围，制定里程碑清单。

5、项目范围管理过程

二、规划范围管理

规划范围管理：对如何定义、确认和控制项目范围的过程进行描述。

1、规划范围管理-输出

（1）范围管理计划内容

- 如何制定项目范围说明书。
- 如何根据范围说明书创建WBS。
- 如何维护和批准WBS。
- 如何确认和正式验收已完成的项目可交付成果。
- 如何处理项目范围说明书的变更。
- 对于WBS的编制只能可能又（但不限于）如下内容：
	- 确定WBS满足职能和项目的要求。
	- 检查WBS是否为所有的项目工作提供了逻辑细分。
	- 保证每一个特定的总成本等于下一个层次构成要素的成本和。
	- 从全面适应和连续角度来检查WBS。
	- 所有的工作职责需要分配到个人或组织单元。
实例：

（2）需求管理计划内容

需求管理计划是对项目的需求进行定义、确定、记载、核实管理和控制的行动指南。主要包括以下内容：
	- 如何规划、跟踪和汇报各种需求活动。
	- 需求管理需要使用的资源。
	- 培训计划。
	- 项目关系人参与需求管理的策略。
	- 判断项目范围与需求不一致的准则和纠正规程。
	- 需求跟踪结构，那些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。
	- 配置管理活动：如何启动产品、服务或成果的变更，如何分析其影响，如何进行跟踪和汇报，以及谁有权批准变更。

实例

三、收集需求

收集需求：为实现项目目标，明确并记录项目干系人的相关需求的过程 

1 收集需求–工具与技术

（1）访谈

- 访谈前准备：
	1、了解对象
	2、准备提纲
	3、让被访者上司安排
- 访谈时：
	1、两人去访谈。
	2、聆听非指导
	3、复述和确认
	4、引导描述事实，把握需求实质。
- 结束后
	1、感谢
	2、反馈

- 结构化访谈：事先准备好一系列问题，有针对进行。
- 非结构化访谈：列出一个粗略的想法
实际中常两者结合。

（2）焦点小组会议

预定的干系人和主题专家集中在一起互动式的讨论，比访谈更热烈。
1、集焦主题：收集主题
2、主持人引导：由主持人引导
3、多人互动式讨论
4、一般6-10人。

（3）引导式研讨会

跨职能、集中式讨论，比单项会议能更快的发现和解决问题。
- JAD：联合应用设计/开发，包含干系人+开发团队
- QFD：质量功能展开，包含客户声音（用户故事）

（4）群体创新技术

01、头脑风暴：

- 面对面、畅所欲言、相互启发，人数5-10人，时长1小时左右。
	- 原则：
		- 庭外判决原则：评判必须放到最后阶段
		- 各抒己见，自由鸣放；
		- 追求数量；
		- 探索取长补短和改进办法
	- 缺点：可能会屈服权威

02、名义小组技术

- 通过投票来排列最有用的创意；以便进行进一步的头脑风暴或优先排序，也可以先提出一些较大的创意类别，做为头脑风暴的基础。是头脑风暴法的深化应用，是更加结构化的头脑风暴法。 
- 过程：分多个名义小组，第个小组开展讨论——小组讨论结束后，主持人依次向每位参与者询问，请每人提出一个创意，可以很多轮——请全体参与者对所有创意进行评审和排序。
- 核心：头脑风暴+排序

03、德尔菲技术

- 关键词：背对背、匿名，以问卷方式多次征询专家意见
- 过程步骤：
	- （1）选择有相关经验的专家
	- （2）将信息分别提供给专家，请他们各自独立发表自己的意见，并写成书面材料
	- （3）主持人收集并综合专家们的意见后，将综合意见反馈给各位专家，请他们再次发表意见。如果分歧很大，可以开会集中讨论；否则主持人分头与专家联络
	- （4）如此反复多次，最后形成代表专家组意见的方案。
- 优点：
	- （1）能充分发挥各位专家的作用，集思广益，准确性高。
	- （2）减少数据及各方面的偏见。
	- （3）能把专家意见的分歧点表达出来，避免权威人士的意见影响他人的意见；
- 缺点：过程复杂、耗时。

04、思维导图

又称为心智图，是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。

05、亲和图

又称为 KJ 法，是针对某一问题，充分收集后，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。可针对某个问题，产生出可联成有组织的想法模式的各种创意，主要用来确定范围分解的结构，有助于 WBS 的制订。
核心：头脑风暴+归纳。

06、多标准决策

借助决策矩阵，采用多标准评估和排序方案。

（5）群体决策技术

- 一致同意；大多数原则（50%以上）；相对多数原则（超两个方案时）；独裁。

（6）问卷调查

问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。
问卷调查方法非常适用以下情况：
	- 受众多样化；
	- 需要快速完成调查；
	- 受访者地位位置分散；
	- 适合开展统计分析

（7）观察

- 观察也称为跟踪，直接查看个人在各自的环境中如何开展工作和实施流程（产品使用者难以或不愿说明需求时特别需要。可以挖掘隐藏需求）。

（8）原型法

- 在实际制造预期产品之前，先造出该产品的模型，并根据此征求对需求的早期反馈。

（9）标杆对照

- 与其他类似组织（内外部）的做法比较，识别最佳实践，形成改进意见（差异性分析）。

（10）系统交互图

- 系统交互图是对产品范围的可视化描述。显示系统与参与者的交互方式；系统间交互等，显示了业务系统的输入，输入提供者、业务系统的输出和输出接收者（如PDF、用例图）。

（11）文件分析

- 文档考古。分析现有文档，识别与需求相关的信息，来挖掘需求。

2 收集需求的输出

（1）需求文件

需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

需求文件可包括：业务需求、干系人需求（用户需求）、解决方案需求（功能和非功能）、项目需求（服务水平）、过渡需求、相关假设和约束。

实例：

（2）需求跟踪矩阵

需求跟踪矩阵是将产品需求从其来源连接到可交付成果的一种表格。有助于确保需求文件中被批准的每项需求在项目结束时能交付，还可以为管理产品范围变更提供框架。

样例：

(3) 需求跟踪

01 正向跟踪

正向跟踪是指检查需求文件中的每个需求是否都能在后续工作产品（成果）中找到对应点（以免需求被做漏、做偏）。

02 反向跟踪

反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处（是查需求源头，了解为什么要做这个需求，来源背景和原因是什么）。

四、 定义范围

1、定义范围的工具及技术–产品分析

- 产品分解
- 系统工程/系统分析
- 价值工程/价值分析
- 需求（功能）分析

产品分析与范围定义紧密相关，如软件产品，分为几个子系统？是不是有基础平台？等等。

2、定义范围的输出–范围说明书

（1）产品范围描述。逐步细化在项目章程和需求文件中所描述的产品、服务或成果的特征。 
（2）验收标准。定义可交付成果通过验收前必须满足的--系列条件，以及验收的过程。  
（3）可交付成果。可交付成果既包括组成项目产品或服务的各种结果，也包括各种辅助成果，例如，项目管理报告和文件。对可交付成果的描述可详可简。 
（4）项目的除外责任。通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围， 有助于管理干系人的期望。 
（5）制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素 
（6）假设条件。假设条件是指在制订计划时，不需验证即可视为正确、真实或确定的因素 
助记：产、验、可、除、制假
范围说明书的作用：确定范围、沟通基础、规划控制基础和变更基础

实例

五、创建WBS

1、创建WBS过程说明和作用

01 创建WBS做什么？

把项目可交付成果和项目工作分解为更小，更易于管理得组件。

02 WBS的作用

1、明确和准确说明项目范围；  明确范围。
2、清楚地定义项目边界；   定义边界。
3、为各独立单元分派人员，规定其职责，确定所需技能和资源；  分派人员。
4、提高估算的准确性；   估算准确。
5、为计划、预算、进度安排和费用控制奠定共同基础；   计划基础。
6、将项目工作和项目财务账目联系起来；   账目联系。
7、确定工作内容和工作顺序；   确定工作。
8、有助于防止范围蔓延；   防止蔓延。

2、相关重要概念

01 工作包

工作包是WBS的最低层组成部分。再工作包上可对其成本和进度进行可靠的估算、控制，便于完整分派给不同组织和个人。
特征：具体，能明确责任，逻辑上不能再分。
分解粒度： 8 -- 80 经验法则：工作包最小不小于8小时，最大不超过80小时。

02 控制账户

控制账户是一个管理控制点，再该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。控制账户设置在WBS中选定的管理节点上。每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。

03 规划包

规划包也是WBS组件，位于控制账户之下，工作内容已知，但详细的进度活动未知。规划包最终会分解成工作包。

3、工具及技术–分解

01 活动及步骤

02 分解结构形式

03 分解表现形式

04 分解注意事项：

（1）WBS 必须是面向可交付成果的。项目的目标是提供产品或服务，仅仅是一连串特别的活动。WBS 中的各项工作是为提供可交付的成果服务的。 
（2）WBS 必须符合项目的范围。WBS 必须包括，也仅包括为了完成项目的可交付成果的活动。100％原则（ 包含原则）认为，在 WBS 中，所有下一级的元素之和必须 100% 的代表上一级元素。如果 WBS 没有覆盖全部的项目可交付成果；那么最后提交的产品或服务是无法让用户满意的。 
（3）WBS 的底层应该支持计划和控制。 
（4）WBS 中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。这个规定又称为独立责任原则。 
（5）WBS 的指导。作为指导而不是原则，WBS 应控制在 4〜6 层。如果项目规模比较大，以至于 WBS 要超过
6 层，此时，可以使用项目分解结构将大项目分解成子项目 然后针对子项目来做 WBS。一个工作单元只能从属于某个上层单元，避免交叉从属（从属唯一）。  
（6）WBS 应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。 
（7）WBS 的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。 
（8）WBS 并非是一成不变的，在完成了 WBS 之后的工作中，仍然有可能需要对 WBS 进行修改。 

05 WBS样例

4、创建WBS的输出–范围基准

范围基准包括：已批准的项目范围说明书、WBS和WBS词典。只有走正式变更程序，才能变更范围基础。
WBS是范围说明书的进一步分解。它定义了整个项目的范围，不在WBS里的，则不属于项目范围，要增加，必须走变更。
WBS词典：工作单元的细节描述，可能包括：账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。

六、确认范围

1、确认范围步骤

确认范围步骤：
	01、 确定需要进行确认范围的时间。
	02、识别确认范围需要哪些投入。
	03、确定范围正式被接受的标准和要素。
	04、确定确认范围会议的组织步骤。
	05、组织确认范围会议。

2、确认范围检查的问题

确认范围需要检查的问题：
	01、可交付成果是可确认和核实的。
	02、每个交付成果是否有明确的里程碑。
	03、是否有明确的质量标准。
	04、审核或承诺是否表达清晰。
	05、项目范围是否覆盖了要完成的产品或服务。
	06、项目范围的风险是否太高，管理层是否能降低风险的影响。

3、确认范围与控制质量

确认范围与控制质量：
	01、确认范围强调可交付成果获得客户的接受。质量控制强调可交付成果的正确性，并符合具体质量要求（质量标准）。
	02、质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行。
	03、质量控制属内部检查，由质量部门实施；确认范围由外部干系人（如客户）验收。

4、确认范围与项目收尾

确认范围与项目收尾：
	01、确认范围强调的是核实与接受可交付成果（目的是验收），而项目收尾强调的是结束项目或阶段所要做的流程性工作（目的是结束和收尾）。
	02、确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果（验收成果），项目收尾强调验收产品（移交成果、归档、总结经验）。

5、确认范围的工具与技术及关注点

01 检查

检查也叫：审查、产品评审、走查、审计、巡检。包括测量、测试、检验等活动，判断结果是否符合要求和期望。

确认范围时干系人的关注点：
	01、管理层所关注的项目范围，是指范围对项目的进度、资金和资源的影响。
	02、客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务。
	03、项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，潜在风险解决方法。
	04、项目团队成员主要关注自己参与和负责的元素，检查自己的工作时间是否足够，是否有多项工作，是否有冲突。

七、控制范围

1、变更原因及工作

01、范围变更的原因

- 政府政策问题。
- 项目范围的计划编制不周密详细，有一定的错误或遗漏。
- 市场上出现了或是设计人员提出了新技术、新手段或新方案。
- 项目执行组织本身发生变化。
- 客户对项目、项目产品或服务的要求发生变化。

02、范围变更控制的工作

- 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。
- 判断范围变更是否已经发生。
- 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。

2、范围失控相关术语

范围蔓延：未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）。
镀金：特质团队成员擅自增加新工作或产品功能（未受控）。

最后

以上就是隐形高山为你收集整理的信息系统项目管理师---第五章 项目范围管理信息系统项目管理师—第五章 项目范围管理的全部内容，希望文章能够帮你解决信息系统项目管理师---第五章 项目范围管理信息系统项目管理师—第五章 项目范围管理所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。