立项时说要做一个客户管理系统，报价二十万，工期三个月。做到第四个月，功能清单比原来多了一半，价格没变，双方都不太高兴。
范围变大这件事，很少是一次性发生的，多数是一点一点加上去的，每次都觉得就加这么一点，回头看才发现加了很多。
一、范围是从三个地方漏出去的
第一个入口是需求阶段没划边界。功能清单写的是客户管理、合同管理、报表统计，这类描述没有边界，怎么解释都行。到了开发阶段，每个词都要展开成具体功能，展开的过程中自然就变多了。
第二个入口是过程里的顺带一提。评审会上有人说既然都做了客户管理，顺便把跟进记录也加进来吧。开发方想着不难就答应了，一答应就多了一个模块。
第三个入口是上线后的补充。用起来发现某个场景没覆盖，要补。这类补充往往是被动的，很难拒绝，但累积起来量很大。
二、把功能清单写到能数的程度
控制范围的第一道防线是清单要具体。不要写客户管理模块，要写新增客户、编辑客户、客户列表查询、客户导入、客户导出、客户合并。每一项都能数得清、估得出工时。
写具体之后还要标优先级。把功能分成必须做、应该做、可以延后三档。这个分档在后期扯皮时非常有用，因为范围要压缩的时候有依据可依，砍掉的是可以延后的那些，而不是临时拍脑袋决定砍哪个。
清单要双方签字确认。这句话看着形式主义，但它是后面所有变更讨论的基准。没有基准，讨论范围变大还是没变大就无从谈起。
三、变更要走评估，不能口头答应
范围蔓延最主要的技术原因是口头答应。会上说加个小功能，开发方顺口就应了，没人记下来，到后期才发现累计的工作量。
合理做法是任何超出确认清单的需求，都走一次简单评估。评估三件事，要多少工时、影响不影响原定工期、要不要调整费用。评估结果告诉提出方，由提出方决定是加进来还是延后。
这套流程的价值不在于卡人，而在于让需求方看到成本。很多时候，提出方知道一个小功能要三天工时、会让上线推迟一周，自己就会说那先不做了。看不到成本，需求提起来是没有负担的。
四、范围已经变大了怎么办
如果事情已经发生，回头看功能清单比原计划多了不少，有几个处理方式。
分期交付。把已经做完的、能独立运行的部分先上线，让业务先用起来产生价值，剩下的部分作为第二期。这样业务不会一直等着，开发方也能缓解工期压力。
等价替换。如果总的预算和工期不能变，那就总量不变，用新增的换掉一部分原计划中优先级低的功能。这是一个相对公平的交换，也容易谈成。
追加费用或者延长工期。这条最难谈但最直接。谈的时候要带上依据，把新增的功能清单和对应的工时摊开给对方看。有据可依的加价，比空口说做不完了要容易接受得多。