及早发现范围蔓延：好的样子与坏的样子
没有哪份项目计划写过「我们将悄悄多做百分之三十的工作而预算不变」。然而许多项目恰恰走到了这一步。范围蔓延几乎从不张扬，而是以一连串听起来合情合理的小添加出现——这里加个字段，那里加份报表，「反正你都在改代码了」。每一项都小得不值得争论，合在一起却拖垮了进度。能及早发现它的团队与发现不了的团队，差别很少在于才能，而在于蔓延累积之前所坚持的习惯。
它从何而来
范围蔓延滋生于「约定的内容」与「写下的内容」之间的缝隙。基线一旦含糊，每个请求都仿佛「本就在范围内」，拒绝便显得吹毛求疵。2021年初仍属常态的远程与混合办公让情况更糟：过去说完即忘的走廊对话，如今化作一条聊天消息，悄然变成一项承诺。对策不是僵化，而是让每一项添加都可见，使取舍成为一次决定，而非一场意外。
好的样子
范围基线是书面的、具体的、共享的——人人都能指出哪些在内、哪些在外。
每一项变更请求，无论多小，都在动工前连同其对时间、成本和风险的影响一并记录。
由指定的某人或委员会批准变更；走廊里随便谁说的「行」不算数。
团队能坦然地说「好主意——这是它的代价」，把范围变成一次看得见的取舍。
状态报告把原始范围与当前范围并列呈现，使偏移在伤害发生之前很久就让发起人一目了然。
坏的样子
范围只存在于人们脑中和几封过时的邮件里，于是「在范围内」就成了嗓门最大的相关方所认定的内容。
小请求被非正式地吸收，只为「让客户满意」，从不计入账。
变更控制纸面上有，却被当成官僚程序，凡是「很快」的事项一律跳过。
出问题的第一个征兆是错过的里程碑，随后人人都惊讶团队竟已落后。
没人说得清额外接下了多少工作，因为根本没人数过。
早期预警的习惯
及早发现蔓延，关键在于降低「察觉」的成本。你不需要一套沉重的流程，而需要一套迅捷的流程。当请求到来时，自律的应对是一段简短而中立的对话：
对照基线核实。 这究竟已在约定范围内，还是新增的？多数争执在双方一起重读基线后便烟消云散。
诚实地估量。 哪怕是粗略的估计——工时、风险、依赖关系——也能把一项看不见的人情变成看得见的成本。
把取舍摆上台面。 若把它纳入，又有什么要移出或顺延？把选择呈上，让发起人来承担。
记录决定。 一行日志——已请求、已估量、已批准或已搁置——就足以让全局在数月之内保持诚实。
若能持之以恒，每个请求只需几分钟，却能在收尾时省下数周。它还会改变与客户的关系。对范围说不既艰难，又损害信任；而说「可以，但代价在此」则尊重各方的时间，也让项目保持诚实。目标从不是把项目封冻在琥珀里——需求本就会正当地变化——而是确保每一次变更都是有人有意作出的选择，且代价尽收眼底。
如果你的项目总因谁也说不清的原因延期收尾，XNM 的项目群与项目交付咨询 可以帮你建立这套范围纪律，在蔓延拖垮进度之前将其拦下。