为了能做完项目，需要一个比较清晰的项目范围基准文件——《范围说明书》。项目的《范围说明书》的作用是详细记录项目可交付的成果，以及为提交这些可交付的成果而必须开展的工作。有了《范围说明书》，项目团队才能展开更详细的计划，才能评估变更请求是否为额外工作。
《范围说明书》中主要的内容之一是活动分解（Work Breakdown Structure，WBS），WBS将项目的“交付物”自顶向下逐层分解成易于管理的若干元素（这些元素组成一个树形图），结构化地定义了项目的工作范围。WBS每细分一层都是对项目元素更细致的描述，细分的元素称为工作细目，其中最底层的工作细目（树形图的叶节点）叫工作包。为了方便分层统计和识别，WBS中的每个元素都被指定一个唯一的标识符，并分层表示。
除了WBS，《范围说明书》还包括以下内容：
■前言。介绍编写《范围说明书》的主要内容、编写目的、适用范围和效力、生效和终止的条件及日期等内容。
■项目概述。说明项目要实现的主要业务功能；项目与现行系统和其他系统的关系；目标系统的硬件和软件结构等。
■产品范围。描述所提供的产品、服务和成果的特征，可以通过需求文件记录。
■项目范围。为完成项目目标而必须完成的工作；明确哪些内容不属于项目范围，有助于避免分歧。
■双方职责。对于双方需要配合完成的工作（如需求分析），要明确说明双方各自承担的工作内容和担负的责任。
■交付成果。交付成果包括组成项目的产品或服务的各种结果，也可以包括各种辅助成果，比如项目管理报告和文件，对于可交付的成果描述可详可简。
■验收标准和流程。定义已经完成的产品、服务或成果的验收过程和标准。
■项目的约束条件。是指与项目范围有关，且制约项目团队的约束条件。例如，预算限制、强制性的里程碑时点、政策法规、合同条款等。
■项目的假设条件。与项目相关的假设条件，以及万一不能成立而造成的可能结果。
■变更流程。明确规定项目发生变更时的处理流程，并对照组织结构说明最高的决策机构。(www.xing528.com)
按照上述的内容，小M整理了《范围说明书》，如图4-1所示。
实际上，与客户讨论和确认《范围说明书》确实比较费时间。但小M觉得，这项投入是非常值得的，哪怕是知道与客户有哪些分歧也很重要。范围核实的过程秉承了几个原则：
图4-1 范围说明书
■对于没有说清楚的，现在就进行澄清，或者至少记录下来这里有个问题。
■对于没有想清楚的，设定假设条件，比如目前的构想是什么，将来可能变化；或者，明确说明某个地方还需要进一步讨论。
■对于无法控制的外部政策等变化，在项目的制约条件中进行了列举。例如，说明某个模块是依据×××政策的标准开发的，如果政策发生了变化，则需要进行必要的变更分析。
■对于依赖的、无法控制的外部条件，在假设条件中进行列举，例如，系统期望用一个尚未发布的新的操作系统版本，那么假设条件就是这个操作系统能够按期发布。
■核实过程中，不但要确认范围，还要确认双方的分工和职责。
■不但确认交付成果，还要确认中间的过程文件。中间结果并不一定向客户提交，但却是一个工作完成的证据。
完成之后，小M召集各方面的人员，对《范围说明书》进行了重新的评审，确认之后小M心里踏实多了。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
