第4章-计划 4.4 范围管理

范围蔓延从内部到外部都有可能发生。由于开发人员往往出于主动性，会把自己放置在用户的角度思考，会按照自己的想法臆想需求，往往就会出现范围蔓延，无端地增加了很多原本没有讨论过的需求；一些定制项目的硬件开发周期比较长，客户很可能在开发过程中随意地提出一些不合理的需求；有些老板和领导在开发过程中发现了新的价值点或者新的商业机会，也会忍不住提出新需求。

为了避免需求在开发过程中走样，我们需要进行“范围管理”。项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它指用以保证项目能按要求的范围完成所涉及的所有过程，包括确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理及范围核实等。项目范围是指产生项目产品所包括的所有工作及产生这些产品的过程。项目干系人必须在项目要产生什么样的产品方面达成共识，也要在如何生产这些产品方面达成一定的共识。

范围管理的目的是在项目开发过程中，避免出现范围蔓延。范围的蔓延，势必影响项目的质量、时间和成本。所以，我们需要制约项目的需求蔓延。制约一个项目需求蔓延，就是确定项目“约束条件”——需求、时间、成本、质量。

在需求一定的前提下，一个项目中这三个条件是相互影响、相互制约的。项目一开始确定的范围小，那么它需要完成的时间以及耗费的成本必然也小，反之亦然。
很多项目在开始时都会粗略地确定项目的需求、质量要求、时间以及成本，然而在项目进行到一定阶段之后，往往会变得让人感觉到不知道项目什么时候才能真正结束，要使项目结束到底还需要投入多少人力和物力，整个项目就好像一个无底洞，对项目的最后结束时间没人心里有底。
这种情况的出现对于公司的管理者来说是最不希望看到的，然而出现这样的情况并不罕见。造成这样的结果就是没有控制和管理好项目的范围。可见项目的三个约束条件中最主要的还是范围的影响。

1.范围管理的定义

范围管理是指收集和定义项目的需求，标识项目的交付和验收标准，通过变更控制和验收活动，确保交付满足项目要求。简单地说就是：范围是需求的集合。

2.范围管理与需求管理的区别

范围管理包含分析范围、定义和明确范围、控制范围、控制范围变更、验收范围。范围管理包含一系列子过程，用以确保项目包含且只包含达到项目成功所必须完成的工作，范围管理主要关注项目内容的定义和控制，即包括什么，不包括什么。

而需求管理是确保各方对需求的一致理解，管理和控制需求的变更，以及需求的跟踪。所以需求开发和管理的目的是通过调查与分析，获取用户需求并定义产品需求，还要确保各方对需求的一致理解，管理和控制需求变更，是需求的双向跟踪。而范围管理的目的是确保项目包含且仅仅包含项目所必须完成的工作。需求管理是对已批准的项目需求进行全生命周期的管理，过程包括定义需求管理、梳理需求管理流程、制订需求管理计划、管理需求和实施建议等，其主要的工作就是需求的变更管理。

范围管理过程包括范围计划编制、范围定义、创建工作分解结构、范围确认和范围控制。

3.需求管理和范围管理之间的联系

首先通过需求开发来获取项目的需求，在此基础上确定项目的范围，进行项目范围管理；其次需求的变更会引起项目范围的变更。

4.范围蔓延

范围蔓延是指项目在进行期间需求缓慢增加，超出原先的范围框架，造成质量、成本、进度等的失控。例如，未对时间和成本影响进行评估，增加额外的功能和服务。项目要严格控制范围变更，评估范围变更对进度、成本、质量的影响，防止项目失控。在目前快速迭代的时代，如何控制项目的蔓延，就是一个非常重要的课题。

类似小米早期手机软件的开发节奏，需要做到一周一版本的水平，其实是有相当大的难度。这里面需要对需求准确地把握，需要对任务的分配准确地把握，同时，在做的过程中应该杜绝范围蔓延。当然，这个过程中，需要管理者把控好版本节奏，合理地进行版本拆分，需要工程师持续努力和有责任心。硬件很难这样一周一版本地快速迭代，但是这种版本拆分、快速迭代的思维方式在硬件产品研发中是可以借鉴的。

由于认知能力的局限，项目范围在开始的时候有可能不清晰，需要不断细化和完善，在项目的进展过程中渐进明细。随着项目进展，项目信息越来越精确。在很多项目中，客户或者项目相关人在项目初期往往只能提出大概要什么，无法很具体地提出怎么做，那些需求的优先级和工作量也都无法评估。

不管是开发者，还是管理者，都应该有清醒的头脑，在项目开发过程中提醒自己，不要范围蔓延。特别是初创企业或团队，可以做的事情很多，可以讨论和发展的方向也很多，此时更要坚守核心价值的特性开发，不能范围蔓延，要有战略耐性，要耐得住寂寞，“脚踏实地，做挑战自我的长跑者”。

讲一则关于需求蔓延的故事。瓦萨王朝统治时期，瑞典是欧洲的强国之一。为了与劲敌丹麦、波兰对抗，称霸波罗的海，瑞典国王古斯塔夫二世·阿道夫要求建造一批新的战舰，并要求战舰航速要快、火力要强、装饰要华丽，因为这样才足以显示瓦萨王朝的权力、财富和战斗力。1626年初，作为其中最大的战舰，“瓦萨”号在国王的亲自监督下正式开始建造。国王总是有太多要求。在“瓦萨”号建造期间，他不断下令依照他的旨意改变设计和建造要求。在“瓦萨”号的骨架已经安装好的时候，他下令增加战舰的长度。1627年，国王得知了丹麦建成双层炮舰的消息，于是他又决定，为原计划修建单层炮舰的“瓦萨”号增加一个枪械甲板，把它改建成“双层”炮舰。这样一来，“瓦萨”号便拥有了双排共64门舰炮，全长达到了69米，成了当时装备最齐全、武装程度最高的战船。

1628年8月10日，离岸后还没来得及扬帆远航的“瓦萨”号在一阵大风浪过后开始倾斜，接着又慢慢恢复平衡，但随即再一次朝右舷倾斜。岸上的人们都惊得目瞪口呆。“瓦萨”号的下层甲板在慢慢进水，舰体开始晃动下沉。“瓦萨”号就在众目睽睽之下沉没了。

5.应对范围蔓延的办法

范围蔓延的主要现象是需求的随意增加和变更，很可能导致质量、成本、进度的变化。

第一，当需求变更被提出时，作为工程师应该清晰地评估出其对质量、成本、进度的影响。例如，如果提出增加某一个功能，那么我们需要清楚地评估因为这个功能开发所需要增加的工作量，与其耦合的模块需要增加的工作量及质量风险，增加的物料成本，总体导致的项目开发周期的顺延日期。

第二，需求、计划、成本、质量要求都应该在项目早期基线化。当需求被提出时，我们应该第一时间拿出《需求跟踪表》《项目计划》《成本核算表》等在项目早期已经归档的文档。已经归档的文档是我们讨论的“基线”。对“需求变更提出者”，表达出变更所需要付出的代价。

第三，我们在具体技术和项目的执行上应该做到比老板更专业，也就是说你所提出的变更带来的代价是评估得很准确的。这样在进行需求讨论的时候他才会听取你的意见，不然你的评估直接被挑战。项目最终还是要回归商业价值的收益，也就是说我们要权衡“需求变更”带来的收益和付出，老板和销售往往对商业价值的把控更准确，当我们提出准确的“需求变更的代价”之后，决策者很容易就可以得出“是否变更”的决策。这也是“用数据和事实说话”。

6.范围控制

控制范围，不是不让改需求，也不是完全抵触需求的增加和变更，而是保证范围的正确变更。对于可能的、合理的范围变更，应积极主动地分析是否存在价值，尽可能地创造条件让高价值的需求变更落地。在范围变更分析的时候，需要重点考虑对项目价值、项目策略、项目质量、项目周期、产品目标成本等的影响。变更之时，还需要考虑项目中需求的冗余、错误之处，新技术引入带来的风险导致的连锁需求变更。