软考高级信息系统项目管理师系列之：项目范围管理

一、范围管理概述

1.项目范围需要做以下三个方面

• 明确项目边界，即明确哪些工作是包括在项目范围之内的，哪写工作是不包括在项目范围之内的。
• 对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做。对不包括在项目范围内的额外工作说"不"，杜绝额外工作。
• 防止项目范围发生蔓延，范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。

2.产品范围与项目范围

• 产品范围是指产品或者服务所应该包含的功能。项目范围是指为了能够交付产品，项目所必须做的工作。
• 产品范围是项目范围的基础，产品范围的定义是产品要求的描述。项目范围的定义是产生项目管理计划的基础。
• 项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。
• 判断项目范围是否完成，要以范围基准来衡量。产品范围是否完成，根据产品是否满足了产品描述来判断。
• 产品范围描述是项目范围说明书的重要组成部分。因此，产品范围变更后，首先受到影响的是项目的范围。

3.范围管理的过程

项目范围管理主要是通过：

• 规划范围管理
• 收集需求
• 定义范围
• 创建WBS
• 确认范围
• 控制范围

六个过程来实现。

二、规划范围管理

规划过程组

1.定义

• 规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中对如何管理范围提供指南和方向。

2.输入

• 项目范围管理计划
• 项目章程
• 事业环境因素
• 组织过程资产

3.工具与技术

• 专家判断
• 会议

4.输出

• 范围管理计划
• 需求管理计划

三、范围管理计划

1.定义

• 范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入

2.内容

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

3.特点

• 项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。
• 根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。

四、需求管理计划

1.定义

• 需求管理计划在整个项目生命周期内如何分析、记录和管理需求

2.内容

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

3.特点

• 需求管理贯穿于整个过程，最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。
• 还要建立需求跟踪能力链确保所有用户需求都被正确的应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

五、收集需求

1.需求分类

• 业务需求：整个组织的高层级需要。
• 干系人需求：干系人或干系人群体的需要
• 过度需求：从当前状态过渡到将来状态所需的临时能力，例如数据转换和培训需求。
• 质量需求：用于确认项目可交付成果的成功完成，确认其他项目需求实现的任何条件或标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。

2.输入

• 范围管理计划
• 需求管理计划
• 干系人管理计划
• 项目章程
• 干系人登记册

3.工具与技术

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

焦点小组：

• 将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更加热烈。
• 焦点小组是一种群体访谈而非一对一访谈，可以有6～10个被访谈者参加。针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的意见。

引导式研讨会：

• 通过邀请主要的跨职能干系人一起参加会议。引导式研讨会对产品需求进行集中讨论与定义。
• 研讨会上快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见
• 该技术的另一个好处是，能够比单项会议更快地发现和解决问题。

群体创新技术：

• 群体创新技术是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
• 头脑风暴：各抒己见
• 名义小组技术：通过投票来排列最有用的创意，以便进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。
• 德尔菲技术：可以防止个人的观点被不正确的放大。
• 概念/思维导图：是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
• 亲和图：针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。
• 多标准决策分析：借助决策矩阵，用系统分析方法建立诸如风险水平、不稳定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。

群体决策技术：

• 定义：群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
• 一致同意：所有人都同意某个行动方案。
• 大多数原则：获得群体中50%以上的人的支持，就能做出决策，参与决策的人数定为奇数。防止因平局而无法达成决策。
• 相对多数原则：根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。
• 独裁：由某一个人为群体做出决策。

原型法：

• 原型法是一种根据干系人初步需求，利用产品开发工具，快速地建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速开发的方法。

标杆对照：

• 标杆对照将实际或计划的做法与其他类似组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据，标杆对照所采用的类似组织可以是内部组织，也可以是外部组织。

系统交互图：

• 系统交互图是对产品范围的可视化描述，显示系统与参与者之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。

文件分析：

• 文件分析就是通过分析现有文档，识别与需求相关的信息来挖掘需求。可供分析的文档很多，包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。

4.输出

• 需求文件
• 需求跟踪矩阵

需求文件：需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
内容不限于：

• 业务需求
• 干系人需求
• 解决方案需求
• 项目需求
• 过度需求
• 与需求有关的假设条件、依赖关系和制约因素

需求跟踪矩阵：

• 需求管理：需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
• 需求跟踪：可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规划、系统组件，以及帮助文件等。
• 每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是检查需求文件中的每个需求是否能在后继工作产品中找到对应点。反向跟踪是指检查设计文档、产品构件、测试文档等。工作成果是否都能在需求文件中找到出处。

五类需求可跟踪：

• 需求跟踪矩阵：

• 表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵，需求跟踪矩阵是将产品需求从其中来源连接到能满足需求的可交付成果的一种表格。

• 应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。

六、范围定义

1.定义

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

2.输入

• 范围管理计划
• 项目章程
• 需求文件
• 组织过程资产

3.工具与技术

• 专家判断
• 产品分析：产品分析说一种有效的工具。针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。
• 备选方案生成：备选方案生成是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。
• 引导式研讨会

4.输出

• 项目范围说明书
• 项目文件更新

七、项目范围说明书

1.定义

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

2.内容

• 产品范围描述
• 验收标准：定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。
• 可交付成果
• 项目的除外责任：通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理干系人的期望。
• 制约因素：列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素。
• 假设条件。

3.作用

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

八、创建WBS

1.定义

• 创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。

2.WBS

• 里程碑：里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线。
• 工作包：工作包是位于WBS每条分支最底层的可交付成果获项目工作组成部分，工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。工作包的大小需要遵循8/80原则。
• 控制账户：管理控制点。是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户。项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现纠正偏差。
• 规划包：规划包是指在控制账户之下，工作内容已知但伤缺详细进度活动的WBS组成部分。是在控制账户之下、工作包之上的WBS要素是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。
• WBS词典：制作WBS的过程中，要给WBS的每个部分赋予一个账户编码标志符，是成本、进度和资源使用信息汇总的层次结构。需要生存一些配套的文件，这些文件需要和WBS配套使用，称为WBS词典。WBS词典也称为WBS词汇表，是描述WBS各组成部分的文件。

3.输入

• 范围管理计划
• 项目范围说明书
• 需求文件
• 事业环境因素
• 组织过程资产

4.工具和技术

• 分解
• 专家判断

5.输出

• 范围基准
• 项目文件更新

6.分解的步骤

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

7.分解的原则

• 功能或者技术原则：在创建WBS时，需要考虑将不同人员的工作分开。
• 组织结构：对于职能型的项目组织而言，WBS也要适应项目的组织结构形式
• 系统或者子系统：总的系统划分为几个主要的子系统，然后对每个字系统再进行分解。

8.WBS分层方式

• 将项目生命周期的各阶段作为分解的第二层
• 主要可交付成果作为分解的第二层
• 子项目作为分解的第二层

生命周期作为第二层：

可交付成果作为第二层：

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

9.表示形式

表示形式：树型结构和表格形式

树型结构：

• 优点：树型结构图的WBS层次清晰、直观性和结构性强
• 缺点：但不容易修改，对大的、复杂的项目很难表示出项目的全貌

表格形式：

• 优点：能够反映出项目所有的工作要素
• 缺点：表格形式的直观性比较差

10.分解注意事项

• WBS必须是面向可交付成果的。项目的目标是提供产品或服务，仅仅是一连串特别的活动。
• WBS必须符合项目的范围。WBS必须包括，也仅包括了完成项目的可交付成果的活动。
• WBS的底层应该支持计划和控制。WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
• WBS中的元素必须有人负责，而且只由一个负责，尽管实际上可能需要多个人参与。
• WBS的指导。作为指导而不是原则，WBS应控制在4～6层。大项目可以超过6层。
• WBS应包括项目管理工作，也要包括分包出去的工作。
• WBS的编制需要所有项目干系人的参与，需要项目团队成员的参与。
• WBS并非是一成不变的，在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。

11.WBS用途与作用

• 明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。
• 清楚地定义项目的边界。
• 为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源。
• 针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
• 为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准
• 将项目工作和项目的财务账目联系起来
• 确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。WBS可以使用图形化6的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际情况进行调节和控制。
• 有助于防治需求蔓延。

九、确定范围

1.定义

• 确认范围是正式验收项目已完成的可交付成果的过程。确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。
• 确定范围应该贯穿项目的始终

2.输入

• 项目管理计划
• 需求文件
• 需求跟踪矩阵
• 确认的可交付成果
• 工作绩效数据

3.工具与技术

• 检查：审查、评审、审计、走查、巡检、测试等。
• 群体决策

4.输出

• 验收的可交付成果
• 变更请求
• 工作绩效信息
• 项目文件更新

5.步骤

• 确定需要进行范围确认的时间
• 识别范围确认需要哪些投入
• 确定范围正式被接受的标准和要素
• 确定范围确认会议的组织步骤
• 组织范围确认会议

6.范围确认检查6个方面的问题

• 可交付成果是否是确定的、可确认的
• 每个可交付成果是否有明确的里程碑，里程碑式否有明确的、可辨别的事件
• 是否有明确的质量标准
• 审核和承诺是否有清晰的表达。
• 项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。
• 项目范围的风险是否太高，管理层是否能够降低可遇见的风险发生时对项目的冲击。