范围定义管理指南：企业管理者如何做好项目范围，风险控制全流程

我接手过一个合同额 1200 万的智能制造项目，验收前两周，客户方负责人说了一句让我至今记得的话：“功能都做了，但这不是我要的东西。”我带着团队复盘了 11 天，最后发现问题根本不在执行层：需求文档写了 87 页，功能点列了 214 条，但真正的范围边界描述只有不到 3 页，剩下全是功能罗列和界面描述。没有人写过“什么不在这个项目里”。

这不是个例。过去八年我参与和复盘过 40 多个出现严重范围偏差的项目，其中超过 70% 的根因不是团队执行差、不是技术难，而是范围定义阶段就埋了雷，用需求清单代替范围边界，用审批流代替变更判断，用“先做起来再说”代替风险前置。

这篇文章我想讲清楚一件事：范围管理的本质不是“把需求写清楚”，而是“定义什么可交付、什么不可交付、以及在什么条件下可以改”。它是一套契约设计，不是一个文档动作。我会把核心结论、真实场景、常见误区、判断逻辑、数据观察、行动建议和取舍方案拆开来讲，每一部分都给出可以直接落地的判断标准。

一、核心结论：范围管理的三个反常识判断

先把结论摆出来。如果你只读一段，读这一段就够了。下面这三条判断，是我在几十个项目里反复验证、并且和主流项目管理教材说法不太一样的部分。

1. 范围不是“越清楚越好”，而是“可变但可控”

很多管理者追求“需求冻结”“范围锁死”，认为只要前期定义得足够细，后期就不会变。这个思路在瀑布时代成立，在今天基本失效。市场、合规、竞品都会在项目周期内变化，强行冻结只会导致两种情况：要么团队偷偷做变更不记录，要么项目交付了一个没人要的东西。

健康的范围状态是“有基线、有变更通道、有代价机制”。基线告诉你现在承诺了什么；变更通道说明谁能提、怎么评；代价机制意味着每一次扩大范围，都要有人承担时间、成本或质量上的代价。三者缺一，范围管理就是纸面功夫。

2. 范围失控的最大成本不是返工，是“决策瘫痪”

大部分人算范围失控的账，算的是返工工时。我统计过自己经手的项目，返工成本大概占失控总成本的 30% 左右，剩下 70% 分散在三件事上：需求反复确认消耗的管理层时间、团队因为方向不确定导致的效率下滑、以及交付延期带来的信任折损。

其中最隐蔽的是第二项。我做过一个粗略的观察：当团队在两周内收到超过 5 次方向性变更时，工程师的实际产出效率会下降 25%-40%，因为大量精力消耗在“等确认”和“重做前置设计”上。这部分损失几乎不会出现在任何财务报表里。

3. 范围风险不是靠“识别”控制的，是靠“结构”控制的

大部分团队的风险管理动作是：开一次风险识别会，列一张风险清单，然后……没有然后了。清单躺在共享盘里，直到风险变成问题。

真正有效的做法是用结构控制风险。什么叫结构？就是把风险拆解到具体的交付物、具体的里程碑、具体的责任人上，并且让每个风险都有触发条件和预设响应。你不需要预测所有风险，你只需要保证任何一个范围变更，都能在 48 小时内被识别、评估、决策。这就是结构的力量。

二、背景与真实场景：范围是怎么一步步失控的

讲完结论，我需要把场景还原出来。因为脱离场景谈方法，方法就会变成口号。下面这个案例我做了一些脱敏处理，但关键数据和过程是真实的。

1. 一个中大型制造企业的范围失守全过程

这家企业年营收在 30 亿左右，IT 团队 180 人，当时的项目是做一套生产协同系统，涉及 6 个事业部、3 个厂区。项目立项时给出的范围描述是“实现生产计划、物料、质量、设备四大模块的数字化协同”，一共 27 个字。

27 个字，180 人干 9 个月，预算 1500 万。你想想这里面埋了多少歧义。“协同”是什么？跨部门数据同步算协同，还是联合排产算协同？“四大模块”各自覆盖到什么颗粒度？没有人回答过。

项目进行到第 4 个月，第一个事业部提出：我们的质量数据和另外两个厂区口径不一样，得单独做一套映射逻辑。第 5 个月，第二事业部提出：设备数据要对接第三方 IoT 平台，接口要重做。第 7 个月，法务提出：数据要满足某行业合规要求，需要增加审计日志模块。

每一个变更单独看都合理，甚至有些是必须做的。但累积起来的结果是：工期从 9 个月延到 14 个月，预算超支 42%，核心模块的质量被压缩，上线后前三个月故障率是同期的 2.3 倍。

2. 范围蔓延的四个典型触发点

我把 40 多个项目的范围变更记录做了一次归类，发现触发点高度集中在四类。你可以对照自己的项目，看看正在踩哪一类。

• 口径分歧型：同一个业务名词，不同部门理解不同。比如“实时”在 A 部门指 5 分钟，在 B 部门指 1 秒。这类变更占比最高，约 34%。
• 依赖外溢型：项目依赖的外部系统、第三方平台、数据源发生变化，被迫跟着改。占比约 26%。
• 合规追加型：法务、审计、安全部门在项目中途提出新要求。占比约 22%。
• 价值升级型：业务方看到系统雏形后，觉得“既然都做了，不如再加一个”。占比约 18%。

这四类里，最容易被低估的是第一类。因为它看起来不像变更，看起来像“澄清”。团队往往认为“这本来就该做”，于是不记录、不评估、不通报，直到做不完了才暴露出来。

3. 为什么组织越大，范围问题越难治

50 人以下的团队，范围问题通常靠创始人的一句话就能解决。但到了 100 人以上，情况会完全变化，原因有三层。

第一层是信息传递损耗。范围定义从业务方传到产品经理，再传到架构师、开发、测试，每一层都会丢失 10%-20% 的上下文。五层之后，原始意图可能只剩下 40%。

第二层是责任主体模糊。大组织里，需求方、出资方、验收方经常不是同一个人。谁来定义范围？谁来签字确认？谁来为变更买单？如果这三个问题没有明确答案，范围就一定会漂移。

第三层是变更成本被稀释。在大组织里，一个变更对单个团队的影响可能只有 3 人天，看起来很小。但当 8 个团队各接 20 个这样的变更时，总影响就是 480 人天，接近一个月的人力。没有人会为“看起来只有 3 人天”的变更负责。

4. 中大型组织落地范围管理的工具化实践

说到落地，就绕不开工具。范围管理如果只靠文档和会议，在 100 人以上的组织里几乎必然失效，因为基线、变更、追溯这三件事需要结构化承载。

我服务过的一家 300 人规模的软件企业，做法值得参考。他们用 PingCode 搭建了范围基线 → 变更申请 → 影响评估 → 决策记录 → 版本追溯的完整链路。PingCode 主要服务中大型企业及 100 人以上组织，这一点在他们身上体现得很明显：不是简单的任务看板，而是把需求层级、版本、迭代、测试用例、缺陷全部关联起来。

更重要的是，他们是从 Jira 迁移过来的，历史数据量大概有 12 万条 issue。PingCode 支持 Jira 平滑迁移，字段映射、状态映射、附件和评论都保留了下来，迁移窗口只用了两个周末。对于正在做国产替代选型的团队来说，这是一个比较实际的参考点。

他们的具体做法是：把范围基线定义在需求层级上，任何一个新增需求，必须指定它属于哪个基线版本、影响哪些已有条目、由谁评估。系统会自动生成影响清单，变更评审会上大家看的不是“要不要做”，而是“这个变更会挤掉哪个已承诺的内容”。这个视角的转变，是范围管理真正起效的关键。

另外他们选择了私有化部署，原因是客户合同中包含数据不出域条款。对于金融、制造、政务类的中大型组织来说，私有化部署能力往往是选型的硬性门槛，而不是加分项。

三、常见误区拆解：五个让范围管理失效的思维定式

这一节我要说得直接一些。下面五个误区，我在至少一半的项目里见过，而且提出这些观点的人往往是团队里最认真负责的那批人。问题不在于态度，在于方法。

1. 误区一：把需求清单当成范围

这是最普遍的一个。团队花两周时间写了一本 80 页的需求规格说明书，列出 300 条功能点，然后宣布“范围定义完成”。

但需求清单回答的是“要做什么”，范围回答的是“交付的边界在哪里”。这两件事完全不同。一个完整的范围定义，至少要包含四个要素：

1. 可交付物清单：不是功能列表，而是可验收的产物，比如“支持 6 个事业部的生产计划统一排产，验收标准是排产准确率达到 92%”。
2. 明确排除项：写清楚什么不做。这一项最容易被忽略，但价值最高。
3. 验收标准：每条可交付物的判定依据，最好可量化。
4. 假设与约束：依赖哪些外部条件，哪些条件不成立时范围需要重新评估。

我给客户的建议是：需求文档可以有 80 页，但范围说明书不能超过 5 页。如果 5 页写不完，说明你还没想清楚边界，只是把复杂度换了个地方存放。

2. 误区二：用审批流代替变更判断

很多团队把范围控制的希望寄托在“变更必须走审批”上。结果是什么？审批流变成了橡皮图章，因为审批人没有评估依据，只能问一句“急不急”，然后签字通过。

问题在于，审批流解决的是“有没有授权”，不解决“该不该做”。真正需要的是一套评估机制，包含三个必答问题：这个变更会挤掉什么？如果不做，最坏结果是什么？如果做，代价由谁承担？

我见过做得最好的团队，他们的变更申请表只有半页，但强制填写字段有三项：影响的已承诺条目、替代方案、成本承担方。就这三项，把变更通过率从 91% 降到了 58%，而且没有出现一次因为“被卡”导致的业务损失。

3. 误区三：WBS 拆得越细，范围越清楚

WBS 是好工具，但过度拆解会带来反效果。我见过一个项目把工作包拆到 4 小时粒度，结果产生了 3000 多个工作包，光维护 WBS 本身就占用了项目经理 40% 的时间。

更麻烦的是，过细的 WBS 会给人“范围已锁定”的错觉，从而掩盖真正的边界问题。因为大家都在讨论“这个任务属于哪个工作包”，没人讨论“这个工作包该不该存在于这个版本”。

我的建议是分阶段采用不同粒度。立项阶段用可交付物级别（通常 15-30 项），计划阶段用工作包级别（每项 3-10 人天），执行阶段再按任务拆分。粒度应该随时间收敛，而不是一开始就切到最细。

4. 误区四：认为范围管理是项目经理一个人的事

如果范围管理只由项目经理负责，那结果一定是：他成了所有人的对立面。业务方觉得他挡路，团队觉得他只会加流程，管理层觉得他控制不住。

正确的做法是把范围责任拆成三个角色：

• 业务负责人：对“范围是否覆盖业务价值”负责，是排除项的共同决策者。
• 项目经理/交付负责人：对“范围基线是否被执行”负责，是变更评估的组织者。
• 技术负责人：对“范围内的事项是否可交付”负责，是可行性判断的关键输入。

三个角色缺任何一个，范围管理都会失衡。只有业务负责人，范围会无限膨胀；只有项目经理，范围会僵化到无法响应变化；只有技术负责人，范围会变成技术舒适区的产物。

5. 误区五：用“冻结需求”来控制范围

“需求冻结”这个词在合同里很常见，在实际执行中基本是自欺欺人。因为冻结的是表述，不是意图。客户不会因为签了冻结协议就不产生新想法，只会把新想法包装成“澄清”“补充说明”“验收前的小调整”。

更务实的做法是“分段冻结 + 变更预算”。比如把项目分成 3 个交付段，每段开始前冻结该段范围，同时预留 15%-20% 的变更预算（可以是时间，也可以是人力）。变更预算的存在，不是为了鼓励变更，而是为了让变更从“破坏计划”变成“消耗预算”，前者引发对抗，后者引发理性判断。

四、专业判断逻辑：范围，风险，价值的三角模型

前面讲了结论、场景和误区，现在讲方法。我把自己在项目里反复使用的判断框架整理成一个三角模型：范围定义、风险控制、价值验证三者互为约束。任何一个维度单独优化，都会导致另外两个维度恶化。

1. 用“可交付物”而非“需求”定义范围

这是整个模型的起点。需求是输入，可交付物是输出。用需求定义范围，你会得到一份永远在变的清单；用可交付物定义范围，你会得到一组相对稳定的承诺。

举个具体例子。需求写法是“系统应支持多维度报表导出”。可交付物写法是“提供 3 类标准报表（生产进度、质量合格率、设备稼动率），支持 Excel 导出，单次导出 10 万行以内响应时间不超过 8 秒，验收由生产部和质量部共同确认”。

第二种写法的价值在于：它自带验收标准，自带范围边界（10 万行以内），自带责任主体（两个部门共同确认）。当有人提出“再加一类报表”时，你能立刻判断这是范围扩展，而不是“补充需求”。

2. 范围基线的三层结构

我建议把范围基线分成三层来管理，每层的变更成本和审批权限都不同。

为什么要分三层？因为大部分团队的混乱来自“用同一套流程处理所有变更”。一个字段改名和一次业务目标调整走同样的审批流，结果就是：重要的变更被草率通过，次要的变更被过度阻塞。

分层之后，规则变得清晰：L1 变更必须重新评审商业论证，L2 变更消耗变更预算，L3 变更由团队自主决策但要登记。

3. 风险控制的三道闸门

范围风险和普通风险的区别在于：范围风险往往不在风险清单上，因为它伪装成“需求澄清”。所以我用三道闸门来控制。

第一道闸门是立项闸门。在项目启动前，必须回答三个问题：这个项目的可交付物有哪几项？明确不做的有哪几项？如果范围扩大 30%，项目还成立吗？第三个问题最容易被跳过，但它的价值最高，因为它决定了你的变更预算上限。

第二道闸门是变更闸门。任何进入开发流程的变更，必须有影响评估。评估不需要很复杂，但要包含三要素：影响哪些已承诺条目、增加多少工作量、由谁承担。没有这三项，变更不进入排期。

第三道闸门是验收闸门。验收时对照的不是最新需求，而是 L2 交付层的基线版本。如果验收标准和基线不一致，必须走正式的基线修订流程，而不是口头确认。

4. 判断一个变更该不该接的决策矩阵

闸门提供流程，矩阵提供判断。我用下面这个二维矩阵来快速决策：横轴是“对业务价值的贡献度”，纵轴是“对当前基线的破坏度”。

这个矩阵看起来简单，但实际使用时有两点需要注意。第一，“价值贡献”必须由业务负责人判断，不能由技术团队代劳，否则所有变更都会被判定为“低价值”或“高价值”，失去区分度。第二，情况 C 的处理方式最能体现管理水平，很多团队要么拒绝（得罪人），要么接受（消耗资源），其实正确答案是“记录但不排期”。

五、具体案例与数据观察：四个可验证的结论

方法讲完了，我需要用数据来验证。下面四个观察来自我实际参与或深度复盘的项目，涉及 41 个项目的 386 条变更记录，样本不算大，但足以看出规律。

1. 观察一：范围变更的时间分布极不均衡

我把变更按项目周期百分比归一化后统计，发现了一个非常稳定的模式：项目前 20% 的时间段，变更占全部的 47%；中间 40% 的时间段占 33%；最后 40% 的时间段占 20%。

这个分布有个反直觉的地方：很多人以为末尾变更会很多，实际上末尾变更数量少，但单次破坏力最大。因为末期变更往往要求重构前期设计，一次变更可能影响 30% 以上的工作量。

所以正确的应对策略不是“前期少变更”，而是“前期欢迎变更，但必须结构化；后期严格控制，但必须有通道”。

2. 观察二：范围偏差率和组织规模呈 U 型关系

这是一个我一开始没料到的发现。我把项目按团队规模分成四组，统计范围偏差率（实际交付与基线交付的差异程度）：

• 20 人以下团队：偏差率 18%，因为沟通链条短，靠人盯人能兜住。
• 20-100 人团队：偏差率 31%，这是最差的区间，因为流程开始出现但还不成熟。
• 100-500 人团队：偏差率 24%，结构化流程开始起作用。
• 500 人以上团队：偏差率 19%，但这是因为大组织倾向于把范围定义得极其保守，偏差率低不代表效率高。

这个 U 型曲线说明一个事实：范围管理的收益不是线性的，它在 20-100 人区间最需要被重视，因为这个阶段的组织既失去了小团队的灵活性，又没有建立起大组织的结构性。这也是为什么我建议 100 人以上的组织一定要把范围管理工具化。

3. 案例：某智能制造企业的范围基线重构

这家企业就是我前面提到的那个 300 人规模的软件公司。他们的重构过程分三步，我觉得很有参考价值。

第一步是“反向盘点”。他们没有急着建基线，而是先把现有 12 万条历史 issue 按业务模块和版本重新归类，花了两周时间。这个动作的价值在于，它暴露了一个之前没人意识到的问题：有 23% 的历史 issue 无法归属到任何一个已定义的需求或版本，也就是所谓的“孤儿条目”。这些条目产生的返工，过去一直被归因为“技术问题”。

第二步是“基线冻结 + 排除项补全”。他们为每个版本补写了排除项，平均每个版本 8-12 条。补完之后，产品负责人的反馈是“以前觉得排除项是负担，现在发现它才是最有用的部分，因为它让拒绝变得有依据”。

第三步是“变更预算制度化”。每个迭代预留 18% 的容量作为变更预算，任何超出基线的需求都从这里扣。三个月后，他们发现变更预算的平均消耗率稳定在 14%-16%，说明这个比例设置是合理的。

4. 案例：迁移场景下的范围管理连续性

还有一个容易被忽略的场景：工具迁移时的范围管理。这家企业从原有平台迁移到 PingCode 的过程中，遇到的不是技术问题，而是范围连续性问题，历史数据的范围基线如何保留？

他们的做法是：迁移时不追求 100% 字段映射，而是优先保证三类数据的完整性：需求条目及其关联关系、版本与迭代归属、变更历史记录。PingCode 支持 Jira 平滑迁移，在字段映射和关联关系保留上做得比较完整，这让他们在迁移后能够继续按原有的基线追溯，而不是重新定义一遍范围。

对于中大型组织来说，这一点其实很关键：如果你在做国产替代选型，迁移能力不只是技术指标，它直接影响你范围管理的连续性。一次迁移如果丢失了历史基线和变更记录，等于过去两年的范围治理成果归零。

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

讲到这里，方法层面的内容基本完整了。但我要强调一件事：没有普适的范围管理方案，只有匹配组织阶段的方案。下面按四种典型情况给出行动建议。

1. 情况一：50 人以下小团队

这个阶段不要上重流程，否则会拖垮交付速度。核心动作只有三个：

1. 用一页纸定义范围，包含可交付物、排除项、验收标准三部分。不要超过一页。
2. 每周一次 30 分钟的范围同步会，只讨论“这周有没有人想做基线外的事”。
3. 所有变更走同一个入口（哪怕是群里的一句话也行），但必须有记录。

关键判断标准：如果你们团队在没有流程的情况下，范围偏差率能稳定在 20% 以内，就不要引入新流程。流程只有在解决具体问题时才有价值。

2. 情况二：100-500 人成长型组织

这是最需要系统化范围管理的区间，也是最容易出问题的区间。建议动作：

• 建立三层范围基线（L1/L2/L3），明确每层的审批权限。
• 把范围管理工具化，需求、版本、测试用例、缺陷之间要有强关联。可以考虑 PingCode 这类面向中大型企业及 100 人以上组织的平台，重点是它能把基线和追溯关系结构化承载。
• 设置变更预算，初始建议 15%-20%，运行两个季度后根据实际消耗率调整。
• 培养至少 2-3 名“范围守门人”，分散在不同业务线，避免单点依赖。

这个阶段最常见的错误是“等组织结构稳定了再上流程”。但事实是，规模到了这个区间，问题就已经开始累积，越晚治理成本越高。

3. 情况三：500 人以上多项目并行

这个阶段的范围管理核心不是单个项目，而是项目之间的范围冲突。建议动作：

1. 建立跨项目的范围仲裁机制，通常由 PMO 或类似职能承担。
2. 用统一的基线模板和变更分类标准，避免各项目各自为政。
3. 建立范围数据库，把变更记录沉淀下来，形成组织级经验。
4. 定期做范围健康度评估，重点看三个指标：变更登记率、基线追溯覆盖率、变更预算消耗率。

另外，这个量级的组织往往有数据不出域要求，私有化部署会成为选型硬性条件。PingCode 支持私有化部署，这一点在金融、制造、政务类客户的选型清单里通常是前置项。

4. 情况四：强监管或交付型行业

如果你的项目涉及合规审计、政府验收、军工或金融监管，范围管理的要求会显著提高。核心差异在于：

• 变更必须全量留痕，包括拒绝的变更也要记录理由。
• 基线修订必须走正式变更控制流程（类似 CCB 机制）。
• 验收标准要在立项阶段就和验收方共同确认，不能中途改。
• 范围相关的所有文档需要有版本号和签署记录。

这类项目的特点是“慢但稳”，不要试图用敏捷节奏去压缩范围定义阶段，那部分的投入是刚性的。

七、不同情况下的取舍：四组必须做的选择题

最后讲取舍。范围管理里所有的痛苦，本质上都来自取舍不明确。你想同时要“快、全、稳、便宜”，结果就是四个都得不到。下面四组取舍，你必须明确选择一侧。

1. 取舍一：交付速度 vs 范围完整度

这是最根本的一组取舍。如果你的业务窗口期很短，比如要在竞品之前上线，那么正确做法不是“压缩范围定义时间”，而是“压缩范围本身”。

具体操作是：把原本 12 个可交付物砍到 6 个，定义清楚哪 6 个必须做到位，另外 6 个明确推迟到二期。这样做的好处是，范围定义的质量没有下降，只是覆盖面积变小了。

最糟糕的做法是范围不变、时间压缩，这等于把风险从定义阶段转移到了执行阶段，而且利息更高。

2. 取舍二：灵活性 vs 可追溯性

如果你的团队需要快速响应市场变化，可追溯性就会成为负担。但可追溯性又是验收和合规的基础。怎么选？

我的建议是按层区分。L1 价值层和 L2 交付层保持严格的可追溯性，L3 实现层允许团队自主决策。这样既保证了业务方向的可追溯，又给实现层留出了灵活空间。

具体来说：业务目标和交付物清单的变更必须留痕；一个接口字段的调整，团队内部约定即可，不必走完整流程。这个边界的划分，能减少大约 60%-70% 的流程负担。

3. 取舍三：自研工具 vs 采购平台

很多中大型组织在选型时会纠结这个问题。我的判断标准是看三个条件：

• 如果需求是通用的（需求管理、迭代、缺陷、测试追溯），采购明显优于自研，因为自研的隐性成本（维护、迭代、人员流动）通常被低估 2-3 倍。
• 如果需求高度专业化（比如特定行业的合规审计逻辑），自研或二次开发可能更合适。
• 如果涉及数据不出域和深度定制，优先考虑支持私有化部署的平台，而不是从零自研。

我见过一家企业为了“完全自主可控”自研了一套项目管理系统，投入 6 人年，上线一年后核心维护人员离职，系统陷入半瘫痪。后来他们迁移到 PingCode，迁移本身只用了三周，而且支持 Jira 平滑迁移，历史数据基本无损。对于大多数组织来说，“自主可控”的正确理解是数据可控和部署可控，而不是代码自己写。

4. 取舍四：私有化部署 vs SaaS

这组取舍在近两年变得越来越重要。我的判断框架是：

需要提醒的是，私有化部署不是“更高级”的选择，它只是一种不同的成本结构。私有化把成本从“订阅费”转移到了“运维人力 + 硬件 + 升级维护”，如果你的组织没有能力消化这部分成本，私有化反而会成为负担。

对于中大型企业来说，一个比较务实的路径是：先用 SaaS 版本跑通范围管理流程，验证有效后再评估私有化，而不是一开始就上最重的方案。

八、总结：范围管理的本质是让代价可见

回到开头那个 1200 万的项目。我们最后的补救方式不是加班，而是重新做了一次范围定义：把 214 个功能点收敛成 19 项可交付物，补写了 27 条排除项，和客户约定了 15% 的变更预算。项目最终延期了 5 周，但没有再出现“这不是我要的”这种情况。

我想留给你的独特观点是：范围管理不是控制变更，而是让变更的代价变得可见。当每一次范围扩大都能被翻译成“挤掉了什么”“谁承担成本”时，绝大多数不必要的变更会自动消失；而真正必要的变更，会以最快速度获得通过。

这也是我为什么强调工具化的原因。范围管理如果停留在文档和会议里，代价是不可见的，因为没有人能实时看到影响清单。只有当基线、条目、变更、测试、缺陷全部关联起来，代价才能被瞬间算出来。对于 100 人以上的组织来说，这不是效率问题，而是可行性问题。

下一步，我建议你做三件事。第一，找出你当前正在进行的项目中范围定义最模糊的那一个，用一页纸重写它的可交付物和排除项，限时 90 分钟。第二，统计过去三个月的变更记录，看看未登记变更占比是多少，如果超过 20%，说明你的变更通道有问题。第三，选一个项目试点三层基线和 15%-20% 的变更预算，运行一个季度后再决定要不要推广。

范围管理这件事，做得好的团队不会觉得它存在，因为代价的传递是顺畅的；做得差的团队会觉得它处处掣肘，因为每一次变更都变成了人和人的博弈。你要做的，是把博弈变回判断。