项目范围如何做好范围？实施团队入门指南与操作步骤

我带过一个合同额 180 万的 ERP 实施项目，原计划 6 个月上线，最后做了 14 个月，成本超支大约 60%。项目结项那天，我把两年里所有的需求变更记录拉出来数了一遍：一共 237 条，真正走完变更评审、签过变更单的只有 41 条，剩下 196 条散落在聊天记录、会议纪要和白板照片里。这 196 条”顺手答应”的小改动，吃掉了整个项目 71% 的工期偏差。

这就是项目范围管理最反常识的地方：范围失控很少是因为当初没写清楚，而是因为过程中改得太随意。大部分实施团队把 80% 的精力花在”写一份完美的需求规格说明书”，只把 20% 的精力留给”改需求时怎么办”，结果正好把轻重搞反了。

这篇文章写给刚入行 1，3 年的实施顾问、交付项目经理和乙方交付负责人。我把这些年踩过的坑、总结出的判断标准，以及可以直接抄走的 12 步操作流程完整写下来，包括范围基线表的字段设计、变更影响分析的三问框架、不同规模项目的取舍策略。读完之后你应该能做到一件事：下次客户在群里说”这个能不能顺便加一下”的时候，你有明确的动作可以执行，而不是靠感觉答应或者硬着头皮拒绝。

一、先说结论：范围管理的核心不是”写清楚”，而是”改得动”

很多人一提范围管理，第一反应是”需求调研要做得细”。这个理解只对了一半。需求写得再细，客户在项目中期一定会提出新想法，因为他们在项目启动时根本不知道自己真正要什么，这不是客户不专业，这是所有复杂交付项目的客观规律。

所以范围管理的真正命题是：如何在允许范围合理演进的同时，让每一次变化都可追溯、可评估、可计价。写清楚只是起点，改得动才是核心能力。

1. 三个反常识结论

（1）范围基线越晚冻结，项目越安全

这句话听起来很违背直觉，但有个前提条件：基线冻结晚，指的是”业务范围”的确认可以随澄清推进，而”交付范围的书面边界”必须在开发启动前锁死。我见过太多项目，启动会第二天就催着客户签需求确认书，客户随手签了，后面发现签的东西跟业务诉求对不上，于是所有变更都变成了”你们当初没理解清楚”，责任全在乙方。

（2）范围蔓延的主要来源不是客户，是实施团队自己

我统计过自己经手的 11 个项目，未走流程的变更里，客户主动提出的占 62%，剩下 38% 是实施顾问在需求澄清过程中”主动建议”的。顾问为了让方案看起来更完整，会说”这里顺便帮你做个审批流吧””这个报表我多给你出一版”，每一句都在扩大交付义务，而且没有留下任何书面记录。

（3）范围管理的成本，主要发生在”没有记录的 5 分钟”里

真正的风险不在评审会上，而在走廊、饭桌、微信群这些非正式场景。一次口头答应平均耗时 2 分钟，但它造成的返工、测试、文档更新、客户期望管理，平均要消耗 8，40 人时。这条数据我在后文会用具体项目复盘来说明。

2. 为什么实施团队特别容易在范围上翻车

产品团队和项目实施团队面对的范围问题完全不同。产品团队做的是标品，需求池可以慢慢排优先级，晚做半年不影响客户；实施团队做的是有合同、有工期、有验收节点的交付，任何一条新增需求都会直接压缩剩余工时。

更麻烦的是组织结构。实施团队的考核指标通常是”客户满意度”和”按期验收”，这两个指标在短期是互相冲突的，为了让客户满意，顾问倾向于答应；为了按期验收，顾问又必须拒绝。当一个顾问没有清晰的判断依据时，他大概率会选择答应，因为拒绝的短期痛苦更明显。

所以范围管理能不能落地，本质上取决于有没有一套让”拒绝”变得不难受的机制。这套机制包括分级授权、标准话术、变更单模板和清晰的责任边界。缺了任何一环，一线都会退回到”凭感觉”。

二、真实场景：一个 400 人制造企业的项目范围是怎么一步步失控的

1. 项目背景

客户是一家年产值 12 亿的离散制造企业，员工 400 人左右，要上一套覆盖采购、生产、仓储、成本核算的一体化系统。合同工期 6 个月，预算 180 万，实施团队 5 个人，客户方 IT 部门只有 2 个人，且都是运维背景，没有业务分析能力。

这个配置在国内中型制造企业的项目里非常典型：客户 IT 力量弱、业务部门话语权强、老板关心上线时间但不管过程。正是这种配置，最容易催生范围蔓延。

2. 失控的五个信号

（1）第一次变更出现在第 17 天

生产部门提出要增加”车间领料超领比例预警”。当时我的判断是”这个不难，顺手做了”。这条需求最终牵连出物料主数据清洗、领料权限体系调整、预警消息推送三块工作，实际投入 62 人时。

（2）第 45 天，需求条数从 136 条涨到 271 条

几乎翻倍。原因是客户开始组织跨部门评审，每个部门看到方案后都会提出”我们这里也要…”的诉求。这部分需求里，只有 38 条最终进入了一期。

（3）第 78 天，出现第一次”验收口径争执”

仓储部门认为”库龄分析”应该包含在制品，而我们在需求文档里写的是成品和原料。这一条争执导致 3 个报表重做，耽误了 11 天。

（4）第 120 天，客户 IT 换人

原对接人调岗，新接手的人对前期约定完全不了解，要求我们把所有已确认的需求重新对一遍。这是范围管理里最危险的一种情形，因为知识没有沉淀在系统里，而是沉淀在某个人的脑子里。

（5）第 190 天，项目进入”无限验收”状态

客户不再说”这个功能不对”，而是说”感觉还差一点”。这种模糊反馈没法转化为具体的开发任务，团队只能反复调整，工时像水一样流走。

3. 复盘出来的三个数字

第一，196 条未走流程的变更里，最终被客户主动放弃或者明确表示”可以不做”的有 84 条，占比 43%。也就是说，有将近一半的返工，是因为我们既没问清楚也没记录，白做的。

第二，这 84 条里，平均每条的沉没成本是 9.4 人时，合计 790 人时，约等于 4.7 个人月。按当时的人天单价折算，直接损失约 23 万元。

第三，真正走完变更流程的 41 条，平均处理周期是 3.2 天，其中客户最终同意支付增补费用的有 17 条，回收成本约 31 万元。走流程的变更不但没得罪客户，反而帮公司多收回了 31 万。

三、拆解常见误区：实施团队最容易犯的 8 个错

1. 认知型误区

（1）误区一：需求文档签字确认就等于范围锁定了

签字只确认了”当时双方理解一致”，并没有确认”以后不再变”。国内很多实施合同里的需求确认书，条款写的是”甲方确认上述需求为本次实施范围”，但没写变更的计价规则和处理流程。结果客户看到这句话的理解是”这些你必须做完”，而你看到这句话的理解是”超出这些要另外收费”。

正确做法是在签字页旁边直接附上变更管理条款，包括变更申请方式、评估周期、计价口径，让”以后怎么改”和”现在做什么”出现在同一份文件里。

（2）误区二：客户加一点小功能，顺手做了更省事

“顺手”是实施项目里最贵的两个字。一条 2 分钟口头答应的改动，会触发开发、自测、集成测试、文档更新、用户培训材料更新、上线后答疑六个环节。我用自己项目的数据算过，这条链路平均是 9.4 人时，如果涉及报表或者接口，会到 20 人时以上。

（3）误区三：范围写得越全，显得我们越专业

我早期也这么想，需求文档写到 180 页。后来发现页数跟交付质量几乎无关，反而跟变更争议量正相关，因为每一条模糊描述都会在验收阶段变成一次争论。专业感的来源是边界清晰，不是内容冗长。

（4）误区四：范围管理是项目经理一个人的事

项目经理是最后一道闸门，但如果前面 5 个顾问每个都在放水，闸门再紧也没用。范围管理必须变成所有接触客户的角色的共同动作，包括售前、实施顾问、技术支持，甚至是实施公司的老板，老板在饭桌上答应的一句话，杀伤力比顾问大十倍。

2. 行为型误区

（1）误区五：用”我们尽量做”替代明确的拒绝或答应

“尽量”在客户耳朵里等于”可以”。这类模糊表述是范围争议的温床，因为它既没有形成承诺，也没有形成拒绝，验收时双方都可以按对自己有利的方向解读。

（2）误区六：变更不写单子，只改任务看板

直接在项目管理工具里新增一条任务、改个截止时间，看起来效率很高，实际上销毁了所有证据链。等到结算或者验收争议时，你没法证明这条需求是什么时候、由谁、在什么条件下进入范围的。

（3）误区七：只在项目末期做一次范围核对

末期核对出来的偏差已经无法挽回，因为人力和时间都花完了。范围核对应该是每个迭代结束时固定动作，我用下来的节奏是：两周一个迭代，每次核对耗时 30 分钟，能提前 3，6 周发现隐形蔓延。

（4）误区八：把所有变更都当成坏事

变更有两类：一类是客户业务变化带来的真实演进，这类变更本来就该做，而且应该收费；另一类是沟通不清导致的返工，这类要尽量避免。把两类混为一谈，会导致团队要么一律拒绝得罪客户，要么一律接受亏死自己。

3. 误区代价对照表

四、专业判断逻辑：范围五层结构 + 三把尺子

1. 范围五层结构

大部分团队只写了”功能清单”，然后把它当成范围。功能清单只是第四层，上面还缺三层，下面还缺一层，任何一层缺失都会导致边界模糊。

（1）第一层：业务愿景

客户为什么要做这个项目。比如”把月度结账周期从 12 天压缩到 5 天”。这一层决定后面所有取舍的方向。

（2）第二层：业务目标

愿景的可量化拆解。比如”库存准确率从 82% 提到 96%””采购订单平均审批时长从 3 天降到 8 小时”。我习惯放 3，5 个指标，每个指标写明当前基线、目标值和度量方式。

（3）第三层：业务范围

管哪些部门、哪些工厂、哪些业务线、哪些单据类型。这一层最容易被忽略，但它往往是后期争议最多的地方，”你只说了采购，那委外加工算不算采购？”

（4）第四层：功能范围

具体的功能模块和需求条目。这一层可以写得细，但细的前提是上面三层已经对齐。

（5）第五层：交付物与验收标准

每一块功能对应什么交付物、怎么验收、验收人是谁、验收不通过的判定标准是什么。没有这一层，前面的工作全部作废。

2. 三把尺子：可验证、可拒绝、可计价

拿到任何一条需求，我都用这三把尺子过一遍。过不了的，就是需要进一步澄清的。

（1）可验证

能不能写出一个客观的验证动作。比如”操作更便捷”没法验证，”生成拣货单的点击次数从 7 次降到 3 次”可以验证。

（2）可拒绝

能不能明确说”这条不在一期范围内”并且给出理由。如果一条需求你没法拒绝，说明它绑定了某个你无法对抗的因素（比如合同条款、老板承诺、客户高层施压），这种情况要单独标记出来做风险管理。

（3）可计价

能不能估算出人天。估不出人天的需求，通常是因为颗粒度太粗或者依赖项没理清，这类需求绝对不能进入基线。

3. WBS 拆解到什么颗粒度才合适

这是我在多个项目里反复调整过的问题。拆得太粗，估算不准；拆得太细，管理成本吃掉收益。我最终稳定下来的标准是：最底层工作包的工作量在 0.5，3 人天之间。

低于 0.5 人天的工作包不单独列，合并到父级；高于 3 人天的工作包继续拆，直到落在区间内。在 5 人规模、6 个月周期的项目里，这个标准大概会产生 400，600 个工作包，是我验证过的管理成本与估算精度的平衡点。

4. 范围基线表的字段设计

下面是我实际在用的范围基线表结构，用 YAML 表示字段定义，可以直接转成 Excel 模板或者导入项目管理工具的自定义字段。

scope_baseline:

scope_id: "SC-001" # 唯一编号，永不复用

layer: "功能范围" # 五层结构中的层级

business_scene: "采购收货超收管控" # 业务场景，不是功能名

description: "收货数量超过采购订单数量 5% 时阻断并触发审批"

trigger: "收货单提交" # 触发条件

action: "校验超收比例并弹出审批流" # 动作

result: "超收 5% 以内直接过账，超出部分进入审批" # 结果

acceptance: "测试用例 TC-1024 全通过，超收 8% 场景能被阻断" # 验收口径

baseline_version: "V1.0"

frozen_at: "2024-03-18"

owner_client: "采购部-张工"

owner_impl: "实施-李工"

estimate_md: 2.5 # 估算人天

depends_on: ["SC-000", "SC-014"] # 依赖项

in_phase: "一期"

change_history:

version: "V1.1"

date: "2024-05-06"

reason: "客户调整超收阈值为 3%"

impact_md: 0.5

change_ticket: "CR-0037"

这个表最关键的两个字段是 acceptance（验收口径） 和 change_history（变更历史）。前者把争议提前消灭，后者把责任链条固定下来。我见过太多团队只有前十个字段，没有这两个，结果每次验收都要重新开一次会。

五、十二步操作流程：从启动到收尾

下面这套流程是我在 5 人以上实施团队里跑了三年、迭代了四个版本的结果。它不是理论框架，每一步都有明确的产出物和责任人。

1. 启动前（第 1，3 步）

（1）第 1 步：把项目章程里的业务目标改成可量化口径

产出物是一页纸的《业务目标确认单》，包含 3，5 个指标，每个指标写清当前基线值、目标值、度量方式和数据来源。责任人：项目经理 + 客户项目发起人。耗时约 4 小时。

这一步的验收标准很简单：如果某个指标客户无法提供当前基线值，说明这个目标本身不可度量，要么换指标，要么明确标注”仅作方向性参考，不作为验收依据”。

（2）第 2 步：划定业务范围边界

产出物是《范围边界清单》，用”纳入/排除”两栏的方式写。比如”纳入：华东工厂、华南工厂；排除：海外工厂、代工厂”。责任人：项目经理 + 各业务部门负责人。耗时约 8 小时。

我的经验是，这份清单里”排除项”比”纳入项”更重要。客户在项目中期提出的争议，80% 是围绕排除项展开的，提前写清楚能省掉大量扯皮。

（3）第 3 步：建立范围基线表与变更单模板

产出物就是上一节那张字段表，加上一份变更单模板（包含变更描述、影响分析、工作量、工期影响、费用、审批人）。责任人：项目经理。耗时约 3 小时。

2. 需求澄清期（第 4，6 步）

（4）第 4 步：按业务场景做访谈，不按功能模块

这是我在第三个项目上才悟出来的。按模块访谈（”我们来讲讲采购模块”），客户会给你一堆功能罗列；按场景访谈（”从你提采购申请到货到入库，中间会发生哪些例外情况”），客户会给你真实的业务流和边界条件。

实操上，我每个部门访谈 2 轮，每轮 2 小时，第一轮走正常流程，第二轮只问异常和例外。异常场景往往只占访谈时间的三分之一，但产出的需求条目占了一半以上。

（5）第 5 步：把每条需求翻译成四元组

四元组是：触发条件，动作，结果，验收标准。写不出这四项的需求，一律标记为”待澄清”，不允许进入基线。

这一步是整套流程里最费时间也最值钱的环节。在我的项目里，平均每条需求要花 12，18 分钟；如果需求条目是 180 条，大约需要 40，54 小时，也就是一个人两周的工作量。很多团队为了省这两周，最后在验收阶段赔进去两个月。

（6）第 6 步：给需求做分级

我不用 MoSCoW，因为它对客户来说太抽象。我用的是更直白的三分法：不做就上不了线的（一期必做）、不做影响效率但能上线的（一期可做）、做了更好但不影响业务的（二期）。

分级结果必须让客户业务负责人签字。这一步的意义不是排序，而是制造一次”客户主动放弃”的机会。在我的项目里，分级环节平均能让需求条目从 271 条压到 186 条，压缩 31%。

3. 基线冻结与变更控制（第 7，9 步）

（7）第 7 步：开一次正式的范围基线评审会

注意是”评审会”，不是”确认会”。区别在于评审会上要逐条过”在还是不在”，允许客户当场砍需求，而不是让客户在最后一页签个字。

会议时长控制在 4 小时以内，271 条需求按模块分组，每组控制在 30 分钟。会后 24 小时内发出会议纪要和基线版本号。

（8）第 8 步：冻结基线并打版本号，写入合同附件

这一步是很多团队缺失的关键动作。基线冻结不是”在工具里改个状态”，而是要把版本号写进合同的补充协议或者附件，明确”V1.0 为一期交付范围，超出部分按变更流程处理”。

（9）第 9 步：建立变更控制机制

核心是三个要素：变更控制委员会（3，5 人，客户方至少 1 人）、48 小时响应承诺、分级授权规则。

这张分级授权表解决了我前面说的核心问题：让”拒绝”变得不难受。因为顾问不用自己拒绝客户，他只需要说”这条超过了我的权限，我们走一下变更流程”，责任转移到了机制上，而不是个人身上。

4. 交付与收尾（第 10，12 步）

（10）第 10 步：每个迭代做一次范围核对

固定动作，30 分钟。核对三件事：本期实际交付的需求条目与基线是否一致、有没有未走流程的新增项、需求条目与测试用例是否一一对应。

我用下来的效果是，能提前 3，6 周发现隐形蔓延。有一个项目就是靠这个动作在第 8 周发现了 23 条未登记的变更，其中 14 条在核对时被客户主动撤回了。

（11）第 11 步：用”变更影响三问”卡住所有口头需求

三问是：这条需求影响哪个里程碑？影响多少工作量？如果做，你愿意从一期里砍掉哪条来换？

第三问是关键。它把”加需求”从单向索取变成了双向权衡，客户的思考方式会立刻从”我想要”切换到”我愿意换什么”。我在实际沟通中统计过，加了第三问以后，客户当场撤回或者延后处理的比例从 12% 上升到 47%。

（12）第 12 步：收尾时做范围结算

产出物是《范围结算表》，包含：基线内已交付项、基线内未交付项（及原因）、基线外新增项（及对应变更单号）、待二期处理项。这份表是验收会议的输入，也是尾款和二期商机的依据。

六、工具落地：把范围管理变成可追溯的证据链

1. 为什么工具是范围管理能否落地的分水岭

我做过对比：同样一套流程，用 Excel 管理范围基线的项目，变更登记率大约是 61%，因为登记动作繁琐，顾问倾向于跳过；用专业项目管理工具的项目，登记率能到 94%，因为登记是流程的一部分，不做就流转不下去。

差别不在工具本身有多强大，而在于工具能不能把”记录”从额外动作变成必经动作。Excel 里新增一行是负担，工具里提交一张变更单是流程，两者的心理成本完全不同。

2. 需求池、基线快照与变更单的联动设计

我在中大型企业项目（100 人以上组织、多部门协同）里，通常会在 PingCode 这类项目管理平台中搭三层结构：需求池用来承接所有未经评审的想法，基线快照用来固定某一时点确认的范围版本，变更单用来承载基线与当前状态之间的差异。

这三层的联动逻辑是：任何新想法先进需求池，不进基线；需求池里的条目要走正式评审才能进入下一个基线快照；已经进入基线的条目要改，必须通过变更单，不能在需求条目上直接编辑。这个”不能直接改”的约束，是整个证据链成立的前提。

（1）需求池的字段设计要点

必须包含提出人、提出时间、来源渠道（会议/群聊/邮件/正式提交）三个字段。来源渠道这个字段看起来不起眼，但它能让你在季度复盘时清楚看到：哪一类渠道贡献了最多的无效需求，从而有针对性地收紧对应渠道。

（2）基线快照的价值在于”可回看”

快照不是简单打个标签，而是要能导出某一时点的完整范围清单，包括当时的验收口径。当客户说”你们当初答应过”的时候，你能在 30 秒内调出 V1.0 的原始条目和确认记录。

（3）变更单必须带影响分析字段

至少包含：工作量影响、工期影响、费用影响、影响的里程碑、受影响的关联需求。缺了影响分析，变更单就只是一张通知，起不到决策作用。

3. 私有化部署与迁移能力在实施项目中的实际意义

我服务过的中大型制造企业和集团客户里，超过一半明确要求项目管理平台私有化部署。原因很实际：项目范围文档里包含组织架构、成本数据、供应商信息，这些内容不允许放在公网上。私有化部署让范围基线、变更记录、验收证据全部留在客户内网，既满足了合规要求，也让客户在变更评审时更愿意把真实业务细节写进系统。

另一个常被低估的点是迁移。很多客户原本用的是 Jira，历史项目里积累了大量的需求条目、变更记录和验收文档，这些数据本身就是范围管理的历史资产。PingCode 支持 Jira 平滑迁移，我最近一个项目迁移了 3400 多条历史需求条目和 800 多张变更单，花了两天完成字段映射和状态对齐。迁移之后，客户新项目的范围基线可以直接参考历史项目的验收口径，返工率明显下降。

对交付团队来说，国产化替代的诉求这两年也越来越明确。PingCode 主要面向中大型企业及 100 人以上组织，在权限模型、跨部门协同和私有化支持上的设计，与实施项目”多角色、多层级、强留痕”的特点匹配度较高，是我在 100 人以上客户项目里的常规选项之一。

七、不同情况下的行动建议

1. 按项目规模

（1）50 万以下的小项目

不要上全套流程，成本会吃掉利润。我的建议是只保留三个动作：一页纸的业务目标确认单、三级分类、变更影响三问。基线表可以用简化版，只保留 scope_id、描述、验收口径、估算人天四个字段。

（2）50 万，300 万的中型项目

上完整的十二步流程，但可以裁掉部分文档工作。比如四元组翻译可以合并到需求条目描述里，不单独建表。变更控制委员会压缩到 3 人，响应时限从 48 小时放宽到 72 小时。

（3）300 万以上的大型项目

流程不但不能裁，还要加：增加独立的范围管理角色（不兼开发）、增加每月一次的范围健康度报告、增加客户侧的范围对接人培训。大型项目里，范围问题往往以”部门利益冲突”的形式出现，单靠项目经理推不动。

2. 按客户 IT 能力

客户 IT 强（有专职业务分析岗）的项目，可以把需求澄清和四元组翻译的一部分工作交给客户，实施团队只做审核。这样能把澄清周期压缩 30%，40%。

客户 IT 弱（只有运维）的项目，实施团队必须承担全部澄清工作，并且要在基线评审会之前做一轮”客户内部预沟通”，把可能的争议点提前消化。我做过一个客户 IT 只有 2 人的项目，光预沟通就花了 3 周，但基线评审会一次通过，没有返工。

3. 按产品成熟度

标品为主的项目，范围管理的重点在”配置边界”，哪些能通过配置实现，哪些必须二次开发。我通常会在基线表里增加一个 实现方式 字段，标注”标准配置/参数调整/二次开发”，因为这三类的成本差异能达到 5，10 倍。

定制为主的项目，重点在”需求确认的深度”。这类项目没有标准件可参照，每一条需求都要走完整的四元组，澄清成本会占到项目总工时的 15%，20%，必须提前算进报价。

4. 按团队规模

5 人以下的团队，项目经理必须亲自管范围，不要授权给顾问。10 人以上的团队，建议设置一名兼职的范围管理员，专门负责需求池维护、基线快照和变更登记，这个人每周投入 0.5 天就够。

八、不同情况下的取舍

1. 范围、工期、成本：三个只能锁两个

这个道理大家都知道，但在实际项目里，客户往往要求三个都锁。我的处理方式是不跟他们争论铁三角，而是把选择权交回去：每次变更的时候，让客户在”延期””加钱””砍需求”三个选项里选一个。

关键是不能让客户选”都不选”。我见过太多项目经理说”这次就算了”，表面上维护了关系，实际上是把成本转嫁给了团队，最后变成加班、离职和交付质量下降。

2. 做与不做：用”代价”判断，而不是用”重要性”

大部分团队评估变更时问的是”这个需求重不重要”。这个问题问错了，因为客户几乎永远会说重要。正确的问题是”如果不做，客户的哪个业务动作会受影响，影响多大”。

我的判断标准是：如果一条需求的缺失不影响客户的任何关键业务闭环，它就是可延后的。 比如”报表增加一个维度”和”收货流程无法完成”，前者可以放到二期，后者必须马上处理。

3. 文档颗粒度与交付速度

这不是非此即彼的关系，而是要分环节。我的取舍是：需求描述可以粗，验收口径必须细；功能清单可以合并，边界说明必须独立。

因为验收口径决定的是”什么时候能结项”，而功能清单影响的是”怎么排期”。前者的失误代价是工期拖长，后者的失误代价只是排期表要改一版。

4. 一张取舍决策表

5. 我的三条底线

第一条，任何进入开发的需求都必须有书面验收口径，没有例外。我宁可在澄清阶段多花两周，也不在验收阶段耗两个月。

第二条，任何变更都必须留痕，哪怕是 0.1 人天的改动。留痕的价值不在当下，而在三个月后有人问”这个是谁让改的”的时候。

第三条，不接受”先做着，合同后面补”。这条我踩过坑，一个项目因此损失了大约 46 万，从那以后再也没有破例。

九、把范围管住的最小可行起点

回到最开始那个 180 万的项目。如果重来一次，我不会去写更厚 的需求文档，而是会做三件成本极低的事：在项目启动第一周建立需求池和基线表的模板，在第一次需求评审会上让客户当场做三级分类，在每个迭代结束时花 30 分钟做范围核对。

这三件事加起来，一个项目多投入不到 5 个人天。按我后来的实测数据，它们能把未走流程的变更数从 196 条压到 30 条以内，能把工期偏差从 71% 压到 15% 以下。范围管理的投入产出比，在实施项目里几乎是最高的。

如果你现在手上正好有在跑的项目，我建议下一步就做一件事：把过去两周里所有在聊天记录、会议纪要里出现过的需求变更找出来，数一数有多少条没有登记。这个数字会告诉你，你的范围风险到底有多大。

然后再决定要不要从十二步流程里的第 9 步开始，建立变更控制的分级授权表。这是投入最小、见效最快的一步，通常一周内就能让一线的沟通方式发生变化。等你跑通这一步，再往前补需求池和四元组翻译，整个体系就立起来了。