信息系统项目管理 - 范围管理（划重点）

项目范围(Scope) 是为了达到项目目标，交付具有某种特质的产品和服务，项目所
规定要做的工作。项目范围管理就是要确定哪些工作是项目应该做的，哪些不应该包括
在项目中。项目范围是项目目标的更具体的表达。

概述

项目范围管理需要做三方面的工作：

1. 明确项目边界。
2. 对项目执行工作进行监控。
3. 防止项目范围发生蔓延。

产品范围与项目范围

产品范围是指产品或者服务应该包含的功能，项目范围是指为了能够交付产品，项目所必须的工作。

项目范围基准是经过批准的项目范围说明书、WBS、WBS字典。

判断项目是否完成，要以范围基准来衡量。而产品范围是否完成，则根据产品是否满足了产品描述来判断，例如，软件产品是否完成，需要根据软件需求规格说明书的要求判断。

注意：产品范围发生变化，并不意味着项目范围就会跟着变化。

项目范围的重要性

项目范围的管理及控制的有效性，是衡量项目是否达到成功的一个必要的标准。

在项目中不断的重申项目范围，有利于项目不偏离轨道，是项目实施控制管理的一个重要手段。

虽然人们对WBS的每一项工作的估算都存在误差，但这些误差可能相互抵消。

范围蔓延是项目失败最常见的原因之一。

范围管理的过程

“开局两张表”，对各个过程的进行了解释，并汇总了各个过程的输入、输出、工具与技术，之后不再重复整理。

项目范围管理各个过程

管理过程	所属过程组	解释
规划范围管理	规划过程组	编制范围管理计划，书面描述如何定义、确认和控制项目范围过程
收集需求		为实现项目目标而确定、记录并管理干系人的需求和需求的过程
定义范围		制定项目和产品详细的描述过程
创建WBS		将项目可交付成果和项目工作分解成较小的，更易于管理的组件的过程
确认范围	监控过程组	正式验收已完成的项目可交付成果的过程
控制范围		监督项目和产品的范围状态，管理范围基准变更的过程

项目范围管理过程中的输入、输出、工具与技术

管理过程	输入、输出、工具与技术
规划范围管理	输入	项目管理计划、项目章程、事业环境因素、组织过程资产
	输出	范围管理计划、需求管理计划
	工具与技术	专家判断、计划
收集需求	输入	范围管理计划、需求管理计划、干系人管理计划、项目章程、干系人登记册
	输出	需求文件、需求跟踪矩阵
	工具与技术	访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照法、系统交互图、文件分析
定义范围	输入	范围管理计划、项目章程、需求文件、组织过程资产
	输出	项目范围说明书、项目文件更新
	工具与技术	专家判断、产品分析、备选方案生成、引导式研讨会
创建WBS	输入	范围管理计划、项目范围说明书、需求文件、事业环境因素、组织过程资产
	输出	范围基准、项目文件更新
	工具与技术	分解、专家判断
确认范围	输入	项目管理计划、需求文件、需求跟踪矩阵、确认的可交付的成果、工作绩效数据
	输出	验收的可交付成果、变更请求、工作绩效信息、项目文件更新
	工具与技术	检查（审查、产品评审、审计、走查、巡检）、群体决策技术
控制范围	输入	项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据、组织过程资产
	输出	工作绩效信息、变更请求、项目管理计划更新、项目文件更新、组织过程资产更新
	工具与技术	偏差分析

规划范围管理

要对将用于下列工作的管理过程做出规定：

• 如何制定项目范围说明书
• 如何根据项目范围说明书创建WBS
• 如何维护和批准WBS
• 如何确认和验收已完成的项目可交付成果
• 如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联

需求是软件项目成功的核心之所在，它为其他许多技术和管理活动奠定了基础。在信息系统集成项目中，需求管理贯穿整个过程，它最基本的任务就是明确需求，并使项目团队和客户达成共识，即建立需求基线。另外，要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理计划主要包括以下内容：

1. 如何规划、跟踪和汇报各种需求活动。
2. 需求管理需要使用的资源。
3. 培训计划。
4. 项目干系人参与需求管理的策略。
5. 判断项目范围和需求不一致的准则和纠正规程。
6. 需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。
7. 配置管理活动。

收集需求

收集需求是为实现项目目标而确定、记录并管理干系人的需求和需求的过程，其作用是为定义和管理项目范围（包括产品范围）奠定基础。

需求分类：

1. 业务需求
2. 干系人需求
3. 解决方案需求
4. 过度需求（数据转换和培训需求）
5. 项目需求
6. 质量需求

工具和技术

• 访谈：其形式包括结构化和飞结构化两种。最有效的访谈是结合两种方法进行。
• 焦点小组：是一种群体访谈。
• 引导式研讨会：邀请主要的夸只能干系人一起参加会议
• 群体创新技术：头脑风暴（直接、质疑）、名义小组技术（排序）、德尔菲技术（背靠背）、概念/思维导图（心智图）、亲和图（核心是头脑风暴，根据结果找原因）、多标准决策分析
• 群体决策技术：为了达成某种期望结果而对多个未来行动方案进行评估。
• 问卷调查：缺点－双方未见面、不重视一张小小的表格、无法了解细节、回答者较少
• 观察：工作跟踪
• 原型法：干系人有机会体验最终产品的模型；渐进明细的理念
• 标杆对照
• 系统交互图：软件需求分析中的DFD、用例图
• 文件分析

软件需求规格说明书是一种典型的需求文件。

需求跟踪包含两层含义：

1. 项目执行过程中两个或者多个产品之间能够建立关系的程度，尤其是哪些具有前后关系或者主从关系的应用。
2. 项目产品中每个元素能够建立其存在理由的程度。

需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪。

五类需求可跟踪：如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。第五类联系链是需求文件之间的跟踪。

需求跟踪的内容：

• 业务需求、机会、目的和目标
• 项目目标
• 项目范围（WBS可交付成果）
• 产品设计
• 产品开发
• 测试策略和测试场景
• 高层级需求到详细需求

需求跟踪矩阵的典型属性：唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、已完成等）和状态日期。

定义范围

定义范围是制定项目或产品详细描述的过程，其主要作用是明确所收集的需求哪些将包含在项目范围内，哪些排除在项目范围外，从而明确产品、服务或成果的边界。

项目范围说明书的编制

工具与技术

• 产品分析：将高层级的产品描述转变为有形的可交付成果；价值工程、价值分析；价值工程是在产品开发设计阶段进行的价值与成本革新活动；此阶段以后持续的分析师降低成本的主要方法，就称为价值分析。
• 备选方案生成：头脑风暴、横向思维

项目范围说明书：对项目范围、主要可交付成果、假设条件和制约因素的描述；项目范围说明书记录了整个范围，包括项目范围和产品范围，详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。

范围说明书包括以下内容：

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

范围说明书的作用：

• 确定范围
• 沟通基础
• 规划和控制依据
• 变更基础
• 规划基础

创建WBS（工作分解结构）

创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要的作用是对对所要交付的内容提供一个结构化的视图。

WBS中的“工作”并不是指工作本身，而是指工作所导致的产品或可交付成果。

WBS层次：

• 里程碑
• 工作包：位于WBS每条分支最底层的可交付成果；8/80原则。
• 控制账户：一种管理控制点；一个控制账户包含若干个工作包，但一个工作包仅属于一个控制账户；通常在项目规划阶段就要确定项目的控制账户；如果项目出现了不利的局面，为了加强控制，项目管理团队可以临时决定下移控制账户。
• 规划包：在控制账户之下、工作包之上的WBS要素；暂时用来做计划的。
• WBS词典：也称WBS词汇；WBS词典比WBS包含的信息更多，因此作用更大。

分解：

创建WBS没有所谓的正确方式，可以使用白板、草图，或者使用比较专业的计算机软件。

创建WBS过程的工具和技术主要有分解和专家判断。

分解为工作包，要开展一下活动：

• 识别和分析可交付成果及相关工作
• 确定WBS的结构和编排方法
• 自上而下逐层细化分解
• 为WBS组件制定和分配标识编码
• 核实可交付成果分解的程度是恰当的

分解原则：

• 功能或技术原则
• 组织结构
• 系统或子系统

分解方式：

• 项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层
• 主要可交付成果作为第二层
• 项目团队以外的组织实施，卖方需要编制相应的合同WBS

工作过程：

WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。

编制高层工作分解结构 －> 分配管理层职责 －> 分解工作分解结构 —> 分配职责 —> 编写项目范围说明书 －> 审批工作分解结构 －> 批准的工作分解结构

WBS表现形式主要有分级的树形结构（组织结构图式）和表格形式（列表式）。

8项注意：

1. WBS必须是面向可交付成果的。
2. WBS必须符合项目的范围。
3. WBS的底层支持计划和控制。
4. WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。
5. WBS的指导。作为指导而不是原则，WBS应控制在4~6层。
6. WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
7. WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
8. WBS并非一成不变的。

8项作用：

1. 明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。
2. 清楚的定义项目边界，它提供了项目管理人员、项目产品或服务的用户、项目发起人、项目团队人员等一致认可的项目需要做的工作和不需要做的工作。
3. 为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源。
4. 针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
5. 为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。
6. 将项目工作和项目财务账目联系起来。
7. 确定工作内容和工作顺序。
8. 有助于防止需求蔓延。

确认范围

确认范围是正式验收项目已完成的可交付成果的过程。

验收测试是一种典型的确认范围的技术。

确认范围应该贯穿项目的始终。

干系人关注点：

• 管理层关注范围对项目进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。
• 客户主要关心的事产品的范围，关心项目的可交付成果是否足够完成产品或服务。
• 项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
• 项目团队成员主要关心项目范围中自己参与的元素和负责的元素，通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作又有冲突的地方。

确认范围与核实产品：

核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或者客户来验证；确认范围是针对项目可交付成果，由客户和发起人在阶段末确认验收的过程。

控制范围

控制范围主要作用是在整个项目期间保持对范围基准的维护。

范围变更的原因：

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

范围变更控制的工作：

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