需求蔓延怎么防：签字确认 + 变更单

接项目的人几乎都遇到过同一类事：谈的时候说好了一个范围，做到一半，需求一点点长出来。等交付的时候，你干了三倍的活，收了原来的钱，客户还觉得“这不都是当时说过的吗”。

这篇文章讲怎么防。先说结论：需求蔓延不是人品问题，是流程问题。 它发生的原因，是你们聊过的内容从来没有变成一份可以对照的基线。

防蔓延的核心动作只有两个：开工前把范围写成能验收的样子，开工后所有增量走变更单。 听起来不新鲜，但真正能省下钱的，是这两件事的写法。

先看需求是怎么长出来的

需求蔓延很少是客户某天突然拍桌子说“再给我加十个功能”。它通常是这么发生的：

• 开会时顺口提一句：“这里能不能再显示个统计？” 你点了头，觉得不难
• 验收时补一句：“我说的是要能按周看，不是按月。” 你之前没问，现在只能改
• 上线前加一句：“下个月要做活动，这个流程得支持一下。” 时间已经不够了

这三种情况的共同点是：提议的时候没有成本，做的时候全是你的时间。 你说的每一句“应该不难”，都在为后面的加价埋下伏笔 —— 因为等到真的不难变难了，你已经不好再开口谈钱。

所以防蔓延的关键不是学会说“不”，而是让每次增量都自动带上一张价格标签。 客户不傻，他看到“这个改动会多三天工期、多一笔费用”，自然会重新掂量。

第一步：把范围写成“能验收的句子”

很多项目从一开始就注定要吵，因为范围写得太粗。看看这句：

做一个预约系统，支持微信登录、在线预约、后台管理。

这句话里有四个概念：“预约系统”“微信登录”“在线预约”“后台管理” —— 每一个都能有两种以上的理解。你说的是“用户选时间提交就算预约”，客户想的是“要能改时间、能取消、能提醒、能查历史记录”。

同样是这句话，写细一点就变成这样：

用户用微信登录后，可以选择日期和时段提交预约；同一时段有人预约后，该时段自动不可选；提交成功后，用户凭手机号在后台可查到自己的预约记录。

差别在哪？后者包含了谁、在什么场景、做什么、看到什么结果。这四样凑齐了，范围才是可验收的。

我现在的习惯是：每一条需求都按“谁在什么情况下做什么，做完看到什么”来写。 写不出来的条目，说明我自己还没想清楚，那就先别写进范围，标成“待确认”。

这一步做完，范围里会多出一批“待确认”项。这是好事 —— 它们暴露的正是将来最容易吵架的地方。

第二步：把范围外的东西明确排除

只写“要做什么”是不够的，还要写清楚“不做什么”。前面那篇讲报价的文章里提过，排除项是报价里最保命的一栏，在需求管理里同样成立。

排除项的作用是把默认值反过来。没有排除项的时候，客户的默认是“你觉得这些都该做”；写了排除项，默认就变成“这些不在这一期”。

常见的排除项包括：

• 数据迁移和历史数据清洗（最容易低估的一块）
• 与第三方系统的对接（对方的接口什么时候给、稳定不稳定，都不由你控制）
• 移动端 / 小程序端（如果这期只做后台）
• 多语言、多币种、多组织这类“要不要支持”的开关
• 培训、文档、后续维护的时间范围

排除项不用写得多漂亮，就一句“以下不包含在本次范围内：……”。这一句话，能挡掉的返工比你想的多。

第三步：确认，要留下“确认过”的证据

范围写好了，还要让客户看一遍并且确认。这一步经常被跳过，因为它显得不信任对方，尤其熟人项目。

但这里有个现实：出问题的往往正是“都这么熟了”。 熟人项目不写文档，靠“你懂我懂”，最后一方记得的和另一方记得的不一样，谁也没法说对方错。

我的做法很简单：范围写好后发出去，明确说“这一版是我按我们聊的整理的，请你看一遍，没问题我就按这个开做”。 对方回一句“可以”，这段对话本身就是确认记录。

不需要签字盖章那么正式。要的是“文字”这个动作 —— 有文字，双方才有共同参照；没有文字，等于什么都没定。

第四步：所有增量走变更单

前面的都做到，也只是把范围定清楚了。真正防蔓延的是这一条：范围外的新需求，不进原来的范围，进变更单。

变更单不需要复杂，四个字段就够：

字段	写什么
变更内容	这次要加/改什么，按“能验收的句子”写
影响工期	多几天，什么时候能交付
影响费用	加多少，或者替换掉原来哪条
影响依赖	会不会影响其他功能、上线时间、第三方配合

这里最关键的是**“影响”两个字**。加一个“能不能显示统计”的需求，不要只答“可以”。要答：“可以，这会多两天工期，费用加多少；如果你希望不加钱，我们可以换掉原范围里的 X。”

把选择权交回给客户，远比直接答应或者直接拒绝好。客户要么接受多花的时间和钱，要么主动砍掉别的东西 —— 两种结果你都吃不了亏。

第五步：口头确认，48 小时内回执

现实里，客户大概率不会每次都正式提变更单，更多是在群里、在电话里顺口一提。

对这种口头需求，我的规矩是：聊完之后 48 小时内，用文字回一句确认。 写清“我理解你要的是……，这属于新的范围，我可以做，但会影响工期/费用，你确认的话我就排进去”。

这条规矩有三个作用：

• 把模糊的口头内容，固定成一段可以回看的文字
• 给客户一个反悔的机会 —— 很多需求他听你说清成本之后，自己就不提了
• 万一将来争执，这段文字就是依据

48 小时是个大概的数，意思是“趁记忆还清楚就落文字”，别拖到对方也想不起来当时说了什么。

第六步：上线前冻结，新需求进下一期

需求蔓延最集中的爆发点，是上线前。这时候客户最容易提“再加一点”，因为改动看起来最小 —— 但其实每一处改动都要重测，风险比开发阶段还高。

我现在的做法是：定一个版本冻结时间，冻结之后不再接任何新需求，一律进下一期。 冻结时明确说：“这一版我们先把已经确认的交付掉，你新提的这些我记下来，放到下一阶段评估。”

客户一般能接受这个说法，因为你要的是把已经做好的东西先稳定地交出去，而不是拒绝他。这比“先做着看”要负责任得多。

什么时候不用这么麻烦

这套流程是给“有明确交付、要验收”的项目准备的。有两种情况可以简化：

• 几千块的小单、几天做完：写清楚做什么、多少钱、什么时候交就够，上变更单反而把小事做重
• 按人天或按月结算的持续合作：合作方式本身就是按时间计费，多做的工时会体现在账单里，不需要每个需求都走变更单

但无论哪种情况，“范围要写下来”这一步不要省。 简化的是流程，不是基线。

小结

需求蔓延防不住，多半是因为没有基线：聊过的都是口头，谁记得谁的版本。把流程补上就两步 —— 开工前把范围写成能验收的句子并留一份确认记录，开工后所有增量走变更单。

再加两条纪律：口头需求 48 小时内落文字，上线版本到点就冻结。这四条做到，你会发现“加个功能”从一句话变成了一个决策，而决策是会算成本的。