BLOG

控制项目范围的方法有哪些？

不知道大家在工作中有没有遇到过类似情况：需求总是不能很好的得到买方的认可，或者是各个团队之间对需求的理解都不能达成一致，再或者是项目范围总是在变，导致了项目不能够按时交付？

上面这些情况，很多团队都遇到过，特别是软件项目的乙方团队，那更是深受其苦。

同样，参与过软件开发各种角色的我也屡次深陷其中。根据项目管理三角理论，项目的范围、成本与质量相互制约。如果不能在项目中使用合理的手段和方法去确定项目范围，不能在项目过程中有效的控制范围，不能让项目范围在各相关方之间达成一致，那么会对项目造成严重的伤害。

当一群人同时向你提需求……

说到这个话题，不知道大家还记不记得在领导力第13讲的时候，我给大家分享的那个指导相关方的案例，这里我再帮大家简单回顾一下：

案例背景

这个项目是给一个区的几个小学做家校系统。因为当时涉及的需求方众多，所以在获取项目范围的时候，也遇到了难以想象的困难。甚至，在很多个关键需求上，有几方表达的观点是冲突的。

不仅如此，需求收集的战线拉的也特别长，消耗了大量的时间。经历了各种波折，最终勉强收集了一个基本涵盖了所有相关方诉求的一份需求文件，虽然根据这份文件签订了合同和开发协议。

但是，在项目过程中，不断有新的需求或变更提出，而且被表述为是必要的修改。我与项目团队对此也感觉到非常苦恼。

做不包含在合同范围中的事情，肯定会影响项目的进度和质量；不做呢，就不能获得客户的验收，陷入左右为难的局面。相信这也是众多的乙方项目经理经常遇到的情况，那作为项目经理，我应该怎么办呢？

控制范围的具体方法

在PMBOK中对管理项目范围的表述是：

一个系统的、由几个过程组成的管理过程。

在这个过程中，我们对项目范围首先要做的是规划范围管理，以定义《范围管理计划》来记录如何定义、确认和控制项目和产品范围；然后就是要收集需求。在刚才的案例中，我们在收集需求的过程中是相当吃力的，也耗费了大量的精力。

那如何避免这种情况的发生呢，其实我们可以通过一些方法和手段，来确定和管理众多相关方想在项目中实现什么目的。

这里涉及到的方法工具众多有很多，也有近几年才刚发展出来的，比如说用户故事等比较能够适应当前复杂需求环境的工具和方法。

这些方法灵活程度很高，作为项目经理应该能在不同的方法中选择一个合适的，就能获取到项目的真正需求。

接下来是定义范围的过程，根据收集上来的需求，去制定项目和产品的详细描述，并且能够定义这些产品或者成果的验收标准。从上面的案例来说，我们做的事情就是将收集上来的需求整理成册，并定义了什么叫“完成”，根据这些需求文件签订了合同和开发协议。

接着，我们要做的事情是很容易被忽略但也是极其重要的，那就是创建WBS，WBS也叫工作分解结构，WBS在项目中起到的作用在于，通过把项目的范围分解到较小的工作包，并形成一定的层次结构。使项目的范围易于维护，便于对项目的交付内容提供框架，以及便于对交付过程进行跟踪。

最后就是确认范围，也就是对项目可交付成果的最终验收，这一步一般是有甲方来做的。

学会“拥抱变化”

当然了在整个的范围管理过程中，有一个极为关键的活动是必不可少的，那就是控制范围。通常我们会将控制范围理解成，在项目进行中要对项目的范围做一个限制，甚至试图去取得客户的承诺，尽量保持稳定性。

其实不然，控制范围的真实意义在于：

让项目范围的变更及时被识别到，而且要用正确的方法去处理这些变更的发生。回到刚才那个案例中，我们在项目过程中就会收到许多变更的要求，且被告知都是必要的。

但是其实是不是必要的这件事，是需要评估和调查的，然后要执行一个固定的变更流程才能在项目中执行。有必要的时候，还要对项目的其他内容，比如说合同，做一些变更才能够执行。

其实作为项目经理，应该在前期收集需求的时候就告知客户做变更的程序和方法，也作为一种交流和沟通的手段，让客户与项目团队能够在一定的程度上尽量在同一个标准下开展工作。

另外，在项目进行的过程中，尽可能多的与用户做演示和交流，及早的发现项目范围的变化。对于项目团队来说，用尽量小的可运行产品甚至原型去与客户进行确认需求，也是业界中最佳实践的一种，这样有利于将变更的成本和对项目的影响降到最低。

经常有人讲，当今的软件会在市场的作用下频繁的变化需求，所以，软件团队要学会“拥抱变化”。

其实拥抱变化不等于范围蔓延，作为项目经理，在多变的需求环境中，要有意识的去管理需求变更对团队产生的影响，而不是阻止或者放任需求的变化。而且，在项目团队中，要尽早的识别这种变化，越早识别对项目的健康越有利，另外，在研发领域也尽量用灵活的框架，使变更的代价降到最小。

关于如何规划和管理范围的案例分享就到这里，希望各位听众能有所感悟，理解范围管理在项目中的重要性和实践思路，以便今后更加顺利的完成项目工作。

今日要点

▼ 项目范围控制的关键步骤有哪些？

1、首先要做的是记录如何定义、确认和控制项目和产品范围。

2、接下来采用不同方法来收集项目需求。

3、根据收集上来的需求制定项目和产品的详细描述，并且能够定义这些产品或者成果的验收标准。

4、创建工作分解结构（WBS），把项目的范围分解到较小的工作包，并形成一定的层次结构。使项目的范围易于维护以及便于对交付过程进行跟踪。

5、最后就是确认范围，也就是对项目可交付成果的最终验收。