范围蔓延：原因、示例及预防方法

什么是范围蔓延？

范围蔓延 是指项目的产品范围或项目范围在时间、成本和资源没有相应调整的情况下不受控制地扩大。它发生在范围商定之后又添加了新的功能、交付物或任务，但没有人评估其影响、正式批准或更新计划以反映这些变化的时候。

PMI 在其术语表中几乎使用完全相同的表述，这也是一个有用的检验标准：如果增加了工作，而 范围基准、进度和预算却没有改变，那就是出现了范围蔓延。

区分两种范围很有帮助。 产品范围 是指您所构建事物的特性和功能，例如带有搜索和结账功能的网站。 项目范围 是指交付它所需的工作：设计、构建、测试、培训和上线。范围蔓延可能影响其中任何一种。客户要求增加在线聊天功能扩大了产品范围；发起人要求团队同时迁移十年的存档数据则扩大了项目范围。

“蔓延”一词很关键。单个大的变更通常会引起注意和讨论。范围蔓延则是许多小变更，每一个看起来都微不足道，不值得走正式流程：多一份报告、多一轮修改、对登录页面的快速调整。单独看它们似乎无害；加在一起却可能多出几周的工作量。

这种情况也很常见。PMI 的 2018 年 *Pulse of the Profession*（职业脉搏）报告发现，在过去 12 个月内完成的项目中，有 52% 经历过范围蔓延，而五年前这一比例为 43%。

我们关于 项目范围 的指南解释了如何一开始就正确定义范围。

范围蔓延与范围变更、镀金和功能蔓延

并非每一次范围变化都是范围蔓延。项目在推进中不断学习，能增加价值的已批准变更是良好项目管理的一部分。区别在于是否受控。

镀金 是一种源自团队内部的范围蔓延。它通常出于好意，但会消耗时间和预算、增加风险，并可能在客户从未要求的地方引入缺陷。 功能蔓延 是产品开发领域对同一模式的称呼，关注的是产品而不是项目。

范围蔓延的原因是什么？

范围蔓延几乎总是有不止一个原因。以下是最常见的几种。

范围和需求不清晰

如果 范围说明书 含糊不清（“一个现代化的网站”“改进的报告”），几乎任何请求都可以被说成属于范围之内。缺失或写得松散的 需求 和验收标准留下了解释空间，而这些空间往往会被额外的工作填满。

没有正式的变更控制

如果没有明确的 变更控制 流程，就没有一种公认的方式来表达“可以，这是它的代价”。请求要么被悄悄接受，要么被尴尬地拒绝，而那些被悄悄接受的请求就变成了范围蔓延。

相关方绕过项目经理

通过邮件、聊天或会议直接发给设计师或开发人员的请求绕过了项目经理。团队成员想要帮忙，就把工作做了，而计划对此一无所知。

镀金和良好的初衷

团队有时会添加功能或进行润色来给客户留下深刻印象。这感觉像是优质服务，但它占用了计划中没有包含的时间，还可能为未来的项目设定期望。

长周期项目和不断变化的业务需求

项目运行的时间越长，其周围的业务变化就越大：新法规、新竞争对手、新领导层。其中一些变化是合理的，但需要经过评估，而不是被默默吸收。

发起人支持不力和商业压力

不参与权衡决策的发起人会让项目经理在拒绝请求时缺乏后盾。在客户项目中，担心惹恼客户（或者采用固定总价合同，但 工作说明书含糊不清）会让人倾向于默默接受请求，而不是提出来讨论。

范围蔓延示例

以下示例展示了范围蔓延在不同类型项目中的表现。在每个案例中，最初的请求都是合理的；问题在于它从未根据时间和成本进行评估。

实例详解：小请求如何积少成多

设想一个上线日期固定的 12 周网站项目。在六周内，客户提出了五项“小”要求，每一项都是非正式同意的：

• 增加一个落地页（3 天）。
• 增加一个与其邮件平台对接的新闻通讯订阅功能（2 天）。
• 第三轮首页设计修改（3 天）。
• 定制 Cookie 横幅（1 天）。
• 导入 40 篇旧博客文章（4 天）。

这些单独看来都无关紧要，但加在一起，12 周的计划就多出了 13 个工作日，将近三周。进度和预算没有任何变化，于是团队加班加点，测试被缩短，上线要么推迟，要么带着缺陷上线。

现在让同样的请求走一遍变更控制流程。每项请求都被记录下来，影响得到展示，由客户做出选择：落地页和新闻通讯订阅获得批准，延期一周并追加预算；博客导入移至第二阶段；额外一轮设计修改替换掉一个优先级较低的页面。项目仍然在增长，但这是有意为之的增长。

范围蔓延的影响

范围蔓延之所以危害项目，是因为 三重制约：范围、时间和成本是相互关联的。如果范围扩大而另外两者不变，就必然有其他方面做出让步，通常是质量或团队。

• 进度延误： 额外的工作会推迟里程碑，而关键路径往往首当其冲。
• 预算超支： 更多的工作量、更多的材料和更多的供应商成本，却没有预算来支付。
• 质量下降： 为了保住截止日期，测试、评审和文档被压缩。
• 团队倦怠： 人们为没有出现在任何计划中的工作延长工作时间，这会损害士气。
• 信任受损： 当日期推迟时，相关方会感到意外，尽管那些增项正是他们提出的。
• 收益推迟： 项目的核心价值比本可以的时间更晚到达用户手中。
• 报告失真： 进度百分比变得毫无意义，因为基准不再反映实际工作。

在商业项目中还有额外的代价：无法计费的工作。默默承受范围蔓延的代理机构和咨询公司，在每个发生范围蔓延的项目上都会损失利润。

范围蔓延的预警信号

范围蔓延越早发现越容易处理。请留意以下信号：

• 看板或工时记录中出现的任务并未列入 工作分解结构.
• 请求通过邮件、聊天或会议提出，而不是通过商定的受理渠道。
• 您听到诸如“顺便做一下”“应该只需要五分钟”或“我们以为那是包含在内的”之类的话。
• 工作开始后，验收标准被改写。
• 团队在加班，但进度计划却没有任何变化。
• 交付物连续数周处于“快完成了”的状态。
• 燃起图上的范围线不断上升，或者待办事项列表的增长速度超过团队的交付速度。
• 对于本已很清楚的任务，实际工作量远远超出估算。
• 未参与规划的相关方在项目后期开始左右解决方案。

如何预防范围蔓延

预防的关键主要在于清晰地商定范围，并事先商定如何处理变更。以下步骤适用于任何规模的传统项目和混合型项目。

1. 商定清晰的目标。 在 项目章程 中写下可衡量的目标，这样每个请求都可以对照目标进行检验：它是否有助于实现目标？
2. 妥善收集需求。 让将要使用成果的人参与进来，而不仅仅是付费的人，并记录 需求 及其优先级。
3. 编写包含排除项的范围说明书。 列出哪些在范围内，同样重要的是，列出哪些在范围外。排除项可以避免出现“我们以为那是包含在内的”这类对话。
4. 分解工作。 创建 工作分解结构 以及 WBS 词典，使完整范围清晰可见，并让每个 可交付成果 都有定义。
5. 定义验收标准。 为每项交付物商定如何判断其已完成。悄悄改动验收标准是最不易察觉的范围蔓延形式之一。
6. 获得签核并确立基准。 请发起人或客户批准范围说明书、WBS 和 WBS 词典。三者共同构成范围基准，您将以此衡量变更。
7. 在需要之前就建立变更控制。 商定请求如何记录、由谁评估、由谁批准以及如何更新计划。小型项目的流程应保持轻量。
8. 建立单一的受理渠道。 请相关方将所有请求发给项目经理或通过请求表单提交，并请团队礼貌地将通过非正式渠道提出的请求转交过去。
9. 定期沟通。 保持稳定的 状态报告 和评审节奏，让相关方看到进展并感到自己的意见被听取，从而减少非正式请求。
10. 在合同中写入变更条款。 在客户项目中，工作说明书应说明如何提出变更、如何定价和批准。

​ 项目范围模板 涵盖目标、交付物、范围内、范围外、验收标准、制约因素和假设，相当于把上述大部分基础工作汇集在一份文件中。

变更控制是这份清单中最重要的一项控制措施。

范围蔓延发生时如何管理

即使计划周密的项目也会收到新请求。目的不是拒绝变更，而是让每一项变更都清晰可见、深思熟虑。

应对新请求的分步方法

1. 同意之前先暂停。 感谢对方，并表示您会研究其影响。避免当场答应或拒绝。
2. 记录下来。 将请求记录在变更日志或 变更请求模板中：要求什么、由谁提出以及为什么。
3. 对照基准进行检查。 它是真正的新需求，还是已被现有需求或验收标准所涵盖？
4. 评估影响。 估算其对进度、成本、资源、质量和风险的影响。让将要做这项工作的人参与评估。
5. 准备选项。 提供切实可行的选择，而不是单一答案（见下表）。
6. 由合适的人做出决定。 由发起人、客户或变更控制委员会做决定，而不是由接到请求的团队成员做决定。
7. 更新计划。 如果获得批准，更新范围说明书、WBS、进度计划、预算和风险登记册，然后重新确立基准。
8. 沟通结果。 告诉请求人、团队和其他相关方所做的决定及其带来的变化。

如何对相关方说“不”（或者说“可以，但是……”）

直接拒绝可能会损害关系，尤其是与客户和高层相关方的关系。通常更好的做法是展示其中的权衡，让决策者自己选择：

让对话围绕项目目标而非个人偏好展开，并将结果书面记录下来。我们关于 相关方管理 的指南介绍了如何与不同类型的相关方进行此类对话。

敏捷项目中的范围蔓延

敏捷方法预期范围会发生变化。这并不意味着敏捷团队对范围蔓延免疫，而是意味着变更的处理方式不同。

在 Scrum 中，所有已知工作都放在 产品待办事项列表中，由 产品负责人 排序。根据 2020 版《Scrum 指南》，在冲刺期间不做任何会危及冲刺目标的变更，随着了解的深入，可以与产品负责人澄清和重新协商范围。因此，新想法进入待办事项列表，而不是直接交给开发人员，如果足够有价值，就会在 冲刺计划会 时被拉入未来的冲刺。

每次迭代的时间和成本通常是固定的，范围才是变量。敏捷中的范围蔓延与传统项目中的表现不同：

• 相关方要求开发人员把工作偷偷塞进当前冲刺。
• 由于冲刺中途拉入了计划外的工作，冲刺目标屡屡未能达成。
• 待办事项列表不断增长却不排序、不梳理，因此没有任何事项被降低优先级。
• 发布日期和完整的功能清单都被视为固定不变。
• “完成”的含义悄然改变，因为没有共同的 完成的定义.

带有单独范围线的燃起图可以让这一点一目了然：如果范围线的上升速度和已完成工作线一样快，发布日期就永远不会到来。跟踪速度在这方面也有帮助；请参阅我们的指南： 敏捷速度图.

有助于控制范围的工具和模板

控制范围并不需要专业软件，但有几份文件可以让工作容易得多：

• 项目范围模板：目标、交付物、包含项、排除项、验收标准、制约因素和假设。
• 变更请求模板：变更请求表和变更日志，记录对范围、进度和成本的影响。
• WBS 模板：WBS 编码、层级、交付物、负责人、工作量和成本。
• RAID 日志模板：风险、假设、问题和依赖关系，包括范围所依赖的假设。
• 业务需求文档模板：在构建之前商定的需求和优先级。

当请求来自很多人时，项目管理软件会很有帮助。请求表单、审批工作流和可见的基准可以减少通过非正式渠道进行的工作。我们排名第一的工具 Wrike非常适合希望在多个项目中使用结构化请求表单和审批流程的团队；其他工具在这方面也表现不错，详见我们的 项目管理软件排名 。

应避免的常见错误

• 把所有变更都视为坏事。 拒绝每一个请求会让相关方感到沮丧，并可能导致项目交付一个没人需要的东西。要控制变更，而不是阻止变更。
• 接受口头批准。 如果没有书面记录，日后大家的记忆就会各不相同。
• 忽视小变更。 上面的实例说明了未经记录的小请求如何变成数周的工作。
• 遗漏排除项。 没有范围外清单的范围说明书会招致各种想当然的假设。
• 任由团队镀金。 肯定其初衷，但将额外的想法转为变更请求或放入待办事项列表。
• 批准变更却不重新确立基准。 如果计划没有更新，进展报告就会产生误导。
• 流程过于繁重。 为一天的变更填写十页的表格，只会促使人们绕过流程。请根据变更的规模调整流程。

要全面了解变更控制与组织变革的区别，请阅读 变革管理与变更控制.

本主题的免费模板

浏览所有模板

常见问题