曾经，小皮追女孩的时候，被拒绝了。那是小皮第一次追女孩。被她拒绝以后，她和小皮说，我要的是平平淡淡的茉莉清茶，而你总是给我过于甜的茉莉蜜茶，你给我的，不是我要的。小皮听到此时，痛心疾首！

还是小皮对女神的需求不了解，早知道女神喜欢茉莉清茶，小皮就直接在茉莉蜜茶的基础上兑点水就好了~

需求不明确的锅！

今天，这篇文章献给那些即将要追女神的，和已经在追女神的，和即将要追男神的，和已经在追男神的亲们，通过这篇范围管理，来看看应当如何把控范围！

范围管理

首先我们来明确一下什么是项目范围管理。

所谓范围，指的是项目中应包括什么、不包括什么。范围管理，就是确保项目做且制作成功完成项目所需的全部工作。

这也是项目管理中最难也是最重要的问题之一。

图1 项目的范围

项目范围管理分为以下几个过程：

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

其中，前四个过程都是属于规划过程组。后两个属于监控过程组。可见，在项目范围管理中，规划是很重要的，也是我们执行项目的先决条件之一。

规划范围管理

规划范围管理属于规划过程组。规划范围管理，做的就是规划。其作用是在整个项目中对如何管理范围提供指南和方向。

图2 规划范围管理

规划范围管理的输出就是范围管理计划和需求管理计划。（这里有一个小tip。在每一个知识领域中，凡是涉及到规范XX管理的过程，基本上输出都会有XX管理计划。）

范围管理计划

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划要将用于下列工作的管理过程做出规定：

• 制定项目范围说明书
• 根据详细项目范围说明书创建WBS
• 确定如何审批和维护范围基准
• 正式验收已完成的项目可交付成果

根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。

需求管理计划

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。根据《从业者商业分析：实践指南》，有些组织称之为“商业分析计划”。需求管理计划的主要内容包括（但不限于）：

• 如何规划、跟踪和报告各种需求活动
• 配置管理活动
• 需求优先级排序过程
• 测量指标及使用这些指标的理由
• 反映哪些需求属性将被列入跟踪矩阵的跟踪结构

收集需求

图3 收集需求

曾经，追女孩的时候，小皮被拒绝了。就是吃了没有收集需求的亏。所以收集需求是很有用的过程。

我们根据之前产出的一些计划，通过多种工具技术，产出需求文件和需求跟踪矩阵。

需求文件

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

这里我们把需求列出以下类别，包括:

• 业务需求
• 相关方需求
• 解决方案需求
• 过度和就绪需求（描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求）
• 项目需求
• 质量需求
• …

需求跟踪矩阵

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。

跟踪需求包括（但不限于）：

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

如果需求不明确，那么有可能出现如下图这样的情况…

定义范围

定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。

图4 定义范围

项目范围说明书

这里主要来说明一下项目范围说明书。

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。

项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括以下内容：

• 产品范围描述
• 可交付成果
• 验收标准
• 项目的除外责任（比如天灾）

创建WBS

WBS（Work Breakdown Structure）其实就是工作分解结构，是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。这个过程的主要作用是，为所要交付的内容提供架构，它仅开展一次或仅在项目的预定义点开展。

图5 创建WBS

范围基准

范围基准是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。

一旦成为了基准，必须走变更控制程序才可以变更！这点需要注意。

确认范围

确认范围是正式验收已完成项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。这个过程应根据需要，在整个项目期间定期开展。

图6 确认范围

控制范围

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。这个过程的主要作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。

图7 控制范围

对于控制范围来讲，有两种比较典型的超出范围之外的情况。

一种是镀金。另一种是范围潜变。

镀金，也就是画蛇添足的意思。明明这个产品没有这个功能，做产品的人非要硬加上去一个功能，如果反馈好，需求方满意还好，但如果一旦需求方不满意，那将是费时费力不讨好的事情。

范围潜变，就是指范围在不知不觉中就发生了改变。比如需求方和产品经理关系很好，当需求方有需求的时候，直接就和产品经理说了，也没有走变更等程序，那么这种需求积少成多，或造成目标范围和实际范围的不一致，这时也就是范围控制失败了。

总结

在项目范围管理的时候，我们需要做的就是根据规划范围管理产出的计划，收集项目的需求，定义项目的范围，根据项目的范围创建工作分解结构，确认范围以及控制范围。

在控制范围时，可以有以下几种做法：

• 提高用户的投入程度：确保项目信息（项目章程/计划/范围基准/）在组织中很容易获得；团队中有用户参与；定期会议；定期交付一些成果；保持有效沟通

• 减少不完整和不断变化的需求：遵循需求管理过程；制作原型；建立需求管理数据库；遵循变更控制流程；与相关方共同验证范围

• 利用软件辅助项目范围管理：使用各种专业化软件来支持项目范围管理