项目范围交付范围教程：跨部门团队最佳实践，避坑指南

去年我接手一个跨 5 个部门的交付项目，合同写的是 12 周上线，实际交付花了 19 周。多出来的 7 周里，真正写代码多花的只有 1 周，剩下 6 周全耗在一件事上：反复争论”这个功能到底算不算在范围里”。

更扎心的是复盘时的发现。项目启动会上，5 个部门负责人对”交付范围”的理解至少有 3 个版本：业务方理解的是”我提过的都算”，产品理解的是”PRD 里写了的算”，研发理解的是”排期表里的算”，测试理解的是”验收标准里有的算”。四方都没错，四方也都没对齐。

这就是跨部门项目最典型的失控方式，不是有人不努力，而是没有人把”范围”变成一个所有人都能指向同一个东西的定义。范围一旦变成各人脑子里的私有版本，交付就必然变成一场事后谈判。

接下来我会按七个部分讲清楚：核心结论、真实场景、常见误区、判断逻辑、案例与数据观察、行动建议、取舍。所有内容来自我 2019 年以来带过的项目和复盘记录，不是教科书上的定义复述。

一、核心结论：范围管理的本质是”变更决策权”的分配

先把结论摆在前面，后面所有内容都是围绕这几条展开的。如果你只记住一句话，记住这条：范围管理不是把需求写清楚，而是把”谁有权决定范围变了”这件事提前定清楚。

1. 范围失控的根因从来不是需求太多，而是决策权没有归属

我带过的项目里，需求数量翻倍的情况很常见，但真正把项目拖垮的，是需求翻倍之后没有人能拍板”这个做、那个不做”。所有人都可以提，没有人能拒。这种状态下，范围不是被扩大的，是被”默认接受”积累出来的。

一个健康的跨部门项目，应该在启动阶段就明确三件事：谁提需求、谁评估影响、谁最终决定砍还是加。三个角色可以是同一个人，也可以分属三个部门，但必须有名有姓，且写在文档里。

2. 交付范围必须可验证，否则它只是愿望清单

“系统要稳定”不是范围，”系统在 500 并发下 P95 响应时间小于 800 毫秒”才是范围。前者无法验收，后者可以跑压测。跨部门项目里最容易出现的就是这种”愿望型范围”，它的问题不在于模糊，而在于模糊的范围永远无法被判定为完成，因此永远无法结束。

3. 变更成本随阶段呈指数增长，且跨部门会再放大约 1.5 倍

业界比较公认的经验曲线是：需求阶段变更成本为 1，设计阶段约 3~5，开发阶段约 10，测试阶段约 20~50，上线后可达 100 以上。跨部门场景还要再叠加沟通链路成本，因为一次变更要重新对齐的干系人数量从 2~3 人涨到 8~15 人。

这意味着：把变更拦在需求阶段，收益是拦在开发阶段的 10 倍以上。这也是为什么我在所有项目里都会坚持在需求评审环节设置强制卡点，哪怕它看起来”拖慢了启动速度”。

4. 工具的价值不在”记录范围”，而在”让范围的每一次变化可追溯”

Excel 也能记录范围。但当项目有 6 个部门、80 多人、每月 30+ 次变更时，Excel 版本分裂的速度会超过任何人的维护能力。我见过最夸张的一次，同一个需求在 4 个 Excel 里有 4 种状态，最后靠翻聊天记录才还原出真相。

所以工具选型的判断标准很简单：能不能做到”任何一条范围条目，从提出到验收的全链路变更都有时间戳和操作人”。做不到这一点，工具就只是电子化的草稿纸。

5. 范围管理做得好的团队，交付速度反而更快

这是最反常识的一条。很多团队担心”严格管范围会拖慢交付”，但我的观测恰恰相反。下面这组数据来自我经手的 18 个跨部门交付项目的复盘，属于样本推演，不是行业统计，但趋势足够清晰。

二、背景与真实场景：跨部门项目的范围为什么总在交付前失控

要解决问题，先得看清问题长什么样。这一节我拆三个层面：失控是怎么发生的、范围本身有几层、跨部门为什么比单团队难得多。

1. 一次真实的交付事故复盘：需求没变，但范围变了

2023 年我参与过一个会员系统重构项目，涉及业务、产品、研发、测试、风控、客服 6 个部门。项目中期我做了一次范围偏差分析，结果很有意思：原始需求条目一条没删，但实际工作量比初始估算多了 63%。

多出来的工作量来自哪里？我一条条追下去，发现来源高度集中：

• 风控部门在开发中期提出”会员等级变更需要留痕审计”，这是合规硬要求，无法拒绝，新增 21 人天。
• 客服部门在联调阶段提出”工单要能直接看到会员历史等级”，因为旧系统有这个能力，新系统不能退步，新增 9 人天。
• 研发在实现时发现旧数据里有 4 种历史等级编码格式，兼容逻辑未在需求中体现，新增 14 人天。
• 测试在验收阶段提出”等级降级的边界场景未定义”，倒逼产品补了 6 个补充规则，新增 8 人天。

这四类来源里，只有第 3 类属于”估算不准”，其余三类本质上都是范围基线不完整，不是需求变了，而是需求从来就没有被完整地识别出来。

更关键的是，这 52 人天里，有 21 人天是在开发中期之后才被识别的，按变更成本曲线折算，实际损失接近 90 人天的等价工期。这就是那多出来的 7 周的主要来源。

2. 交付范围其实有四层，多数团队只对齐了最上面两层

我习惯把范围拆成四层来看，每一层的负责人、验证方式、变更频率都不同。混淆这四层，是跨部门扯皮的主要技术原因。

问题在于，绝大多数启动会只对齐了”业务范围”和”产品范围”，因为这两层是老板和业务方最关心的，讨论起来也最热闹。真正决定项目能不能按时交付的，恰恰是第三层和第四层，而这两层往往在启动会上一句”细节后面再对”就被跳过了。

3. 跨部门比单团队难，难在三个结构性差异

很多管理者把跨部门的难度理解为”沟通成本高”，这个理解太浅。我观察到的是三个结构性差异，它们无法靠”多开会”解决。

第一个差异是目标函数不同。研发团队的 KPI 可能是线上稳定性，业务团队的 KPI 是转化率，风控团队的 KPI 是零合规事故。同一个需求，三个团队的最优解完全不同。研发希望少改、业务希望快上、风控希望多留痕。这种冲突不是沟通问题，是激励结构问题，只能靠机制解决。

第二个差异是拒绝成本不对称。业务方拒绝一个需求，成本是”业务目标可能达不成”；研发拒绝一个需求，成本是”被质疑不配合”。这种不对称会让所有拒绝压力都转移到执行团队身上，最终表现为研发被迫承接超出容量 30%~50% 的工作量。

第三个差异是信息衰减速度。我做过一个粗略统计：在 5 个部门参与的链条上，一条需求经过 3 次转述后，关键约束条件的保留率大约只有 60%。这意味着如果交付范围依赖口头传递，它在到达最末端执行者手里时，已经是一份”残缺版”。

这三个差异共同解释了为什么跨部门项目必须依赖书面基线：不是为了追责，而是为了让每一层的约束在传递过程中不丢失。

三、拆解常见误区：七个看起来正确、实际致命的做法

下面这七个误区，都是我在项目评审和复盘里反复见到的。它们的共同特点是：听起来很专业，执行起来很省事，代价在交付前 4 周才集中爆发。

1. 误区一：把 WBS 当作交付范围

WBS 是工作分解结构，它回答的是”要做哪些活”，不回答”做到什么程度算完”。我见过太多项目把 WBS 三级节点打印出来当作范围基线，结果验收时发现：节点上写的是”会员等级管理模块开发”，但等级降级、等级互斥、等级历史追溯这些边界完全没有定义。

正确做法是：WBS 只做进度分解，范围基线必须独立成文，且每一条都带上验收口径。两者可以互相映射，但不能互相替代。

2. 误区二：口头确认等于达成一致

“会上大家都点头了”是我最不信任的一句话。真实情况往往是：会上信息密度极高，每个人只对自己部门相关的部分做了确认，对边界的部分选择了默认。

我的做法是：会议结束后 24 小时内发出书面范围确认，要求每个部门负责人回复”确认”或”有异议”，超过 48 小时未回复视为默认确认。这条规则的价值在于把”沉默”从模糊状态变成明确状态，你要么确认，要么提出异议，不能事后说”我当时没太理解”。

3. 误区三：把范围变更等同于加需求

范围变更其实有四种形态，加需求只是最容易被注意到的第一种：

1. 新增：本来没有，现在要加。
2. 裁剪：本来承诺了，现在要砍。
3. 降级：还做，但标准降低（比如原定支持 3 种角色权限，改为支持 1 种）。
4. 隐式变更：需求文字没变，但实现复杂度上升（比如发现历史数据格式不统一）。

第四种最危险，因为它不产生变更单，却实实在在消耗工期。我在项目里会强制要求研发在发现”实现复杂度显著高于估算”时，24 小时内发起一次范围复核，把它显性化。不显性化的复杂度，最后都会变成延期。

4. 误区四：用”尽量做”当承诺

“尽量做”是范围管理里最昂贵的一句话。它让提出方以为已经拿到了承诺，让执行方以为保留了退路，结果是双方在交付前的预期完全对不上。

我的规则很简单：范围条目只有三种状态，做、不做、待定（附决策截止日）。“尽量做”不在选项里。待定条目必须指定决策人和决策截止日期，到期未决策自动转为”不做”，并且这个自动转不做的规则要提前写进项目章程。

5. 误区五：验收标准留到测试阶段写

这是代价最高的一条。测试阶段才发现验收标准缺失，意味着任何补充都要走变更，而此时变更成本已经是需求阶段的 20 倍以上。

我的做法是：任何进入本期承诺范围的功能，在需求评审通过时必须同时产出可执行的验收口径。写不出验收口径的条目，不能进入承诺范围，只能留在待定池。这条规则在推行初期会显著降低”承诺数量”，但会显著提高”承诺兑现率”。

6. 误区六：把范围管理的责任全压在项目经理身上

项目经理没有业务决策权，也没有技术决策权。如果范围决策权全部压给他，结果就是所有变更加总到他这里，他只能要么全部接受（范围失控），要么全部拒绝（被投诉不配合）。

正确的结构是：项目经理负责流程与可视化，业务负责人负责优先级裁决，技术负责人负责可行性裁决。三者分开，项目经理才不会成为所有人的敌人。

在一个 100 人以上的组织中，这一点尤为关键，因为涉及的部门数量和利益方远超小团队，靠单点协调根本无法支撑。这也是我后来倾向于用系统化手段做范围可见性的直接原因。

7. 误区七：认为严格的范围管理会伤害团队士气

这个误区我在推行初期遇到过强烈的抵触。研发觉得”又要写文档”，业务觉得”又在设门槛”。但实际运行两个迭代之后，反馈会反过来：研发说终于知道自己不用做什么了，业务说终于知道什么时候能拿到东西了。

原因很简单：模糊的范围伤害的不仅是执行方，也伤害提出方的确定性。一个能被明确拒绝的团队，同时也是一个能被明确承诺的团队。

四、专业判断逻辑：五个可以直接落地的判断锚点

知道了误区，还需要一套判断方法。我把自己的判断逻辑收敛成五个锚点，每一个都可以在会议现场直接使用。

1. 可验证性锚点：这条范围能不能被第三方判定完成

我常用的测试叫”第三方判定法”：把这条范围描述念给一个完全没参与项目的人听，问他”如果你来验收，你能判断它做完了没有吗”。如果答案是”不能”，这条范围就不合格。

举两个对比：

• “系统支持会员等级变更” ， 第三方无法判定，不合格。
• “系统支持会员等级从 A 级变更为 B 级，变更后 3 秒内生效，变更记录保留 180 天且可导出 CSV，单账号每日变更上限 5 次” ， 第三方可以逐条判定，合格。

判断标准不是描述长短，而是能否被外部判定。有些很短的描述也能被判定，比如”登录接口 P95 响应小于 500 毫秒”，因为它有明确的量化口径。

2. 归属锚点：这件事如果出问题，谁来买单

每一条范围条目都应该能回答”谁为它的正确性负责”。如果答不上来，说明这条范围处在一个无主地带，它迟早会在交付前变成争议。

跨部门项目里常见的无主地带包括：跨系统接口的字段语义、旧数据迁移的清洗规则、权限模型的最终解释权、异常场景的兜底逻辑。这四类我在每个项目里都会单独拉一张表，逐条指定责任人。

3. 成本曲线锚点：现在改和两周后改，差多少

这是说服业务方最有效的一个锚点。当业务方在开发中期提出变更时，我不说”不行”，而是给他两个数字：现在改需要 6 人天，会影响 3 个下游任务，延期 4 天；如果纳入下个版本，成本是 2 人天，不产生延期。

把选择权交回去之后，绝大多数业务方会自己做出理性选择。抵抗变更的正确方式不是拒绝，而是把成本透明化。

4. 容量锚点：承诺量不能超过可用产能的 80%

这是我坚持最久的一条硬规则。团队的有效项目工时，通常只占总工时的 60%~70%，剩下的被会议、线上问题、临时支持、人员休假吃掉。如果按 100% 产能承诺范围，实际缺口会直接转化为延期。

我的做法是：承诺范围按团队总工时的 80% 排布，剩下 20% 作为变更缓冲。这个缓冲不是浪费，它是范围管理的减震器。没有缓冲的项目，任何一次小变更都会直接变成延期。

5. 工具锚点：范围条目能不能被追溯

最后一条是工具层面的判断。我会问三个问题：

1. 这条范围的当前状态，任何一个干系人能不能在 30 秒内查到？
2. 它的每一次状态变化，有没有时间戳和操作人？
3. 它和其他条目之间的依赖关系，是不是可见的？

三个问题都答”能”，说明工具达标。答不上来的，无论用的是 Excel 还是专业平台，本质上都只是记录工具，而非管理工具。后面第五节我会用具体平台举例说明这三个问题在实践中怎么落地。

五、案例与数据观察：100 人以上组织怎么把范围基线真正跑起来

前面讲的是方法，这一节讲落地。我以自己深度参与过的几个项目为例，涉及的组织规模都在 100 人以上，部门数量 5~9 个，项目周期 6~12 个月。这个规模的项目有个特点：范围基线不可能靠某个人的记忆维护，必须落到系统里。

1. 100 人以上组织的范围失控，有一个共同形态

我在 4 个百人以上组织里观察到的失控形态高度相似：范围条目分散在至少 3 个载体上（需求管理平台、即时通讯群、个人 Excel），没有任何一个载体是权威版本。这带来的直接后果是，每次范围争议都要花 2~4 小时做”事实还原”。

我的解法是设定”唯一权威源”原则：任何范围条目在系统里的状态就是唯一事实，聊天记录、个人表格、会议纪要都不作为依据。这条规则推行初期会很别扭，但一旦坚持两个月，团队会自发依赖系统状态，事实还原成本会降到接近零。

在这个环节，我实际使用过 PingCode。它在多项目、多部门并行场景下的范围管理有几个让我印象比较深的点：需求的层级结构与状态流转是配置化的，可以把”待定，评估中，已承诺，开发中，待验收，已验收”这套自定义状态直接做成工作流，并且每个状态变更都自动留痕。对于需要同时跑 10+ 个项目、涉及 6 个以上部门的组织，这种”状态即事实”的机制能显著降低协调成本。

2. 从既有平台迁移时，范围基线的重建比数据搬移更重要

我参与过一次从 Jira 迁移到 PingCode 的项目，组织规模约 300 人，涉及 7 个部门、40 多个历史项目。这次经历让我形成一个明确判断：迁移的难点从来不是数据搬运，而是范围语义的重建。

举个例子：在旧系统里，”已解决”这个状态在不同团队的含义完全不同。有的团队指”开发自测完成”，有的指”代码已合并”，有的指”测试通过”。迁移时如果直接映射状态名，会把这种语义混乱原封不动地带到新系统，甚至放大。

我们的处理方式是分三步走：

1. 先做状态语义对照，把每个团队对每个状态的实际含义写下来，形成映射表。
2. 重新定义一套组织级统一状态，各团队的特殊状态作为子状态挂在主状态之下。
3. 历史数据按语义映射迁移，而不是按名称映射。

PingCode 在支持 Jira 平滑迁移这块，提供了字段映射、工作流映射和历史数据处理的能力，配合上面这套方法论，我们最终把状态语义的统一率从迁移前的约 55% 提升到了 92%。迁移后的好处不只是干净，更实际的是：跨部门查一个需求的全链路状态，时间从平均 25 分钟降到了 3 分钟以内。

3. 私有化部署在什么情况下是范围管理的必要条件

这一点经常被忽略，但在某些行业里它直接决定项目能不能做。当交付范围涉及客户数据、身份信息、风控规则或受监管的业务逻辑时，数据不出内网往往是硬约束。

我参与过一个金融相关项目，客户的合规要求明确规定：所有涉及客户等级、交易行为的数据分析过程必须在自有网络内完成。这种情况下，任何 SaaS 形态的范围管理平台都进不来，只能考虑支持私有化部署的方案。PingCode 支持私有化部署，是我在国产替代选型中把它列为候选的原因之一。

但我要提醒一点：私有化不是免费的午餐。它会带来版本升级周期变长、运维人力投入、内部环境适配等问题。我的判断标准是看三条：数据合规是否强制、组织是否有基本运维能力、是否有明确的升级响应机制。三条都满足，私有化才是划算的。

4. 一个容易被忽视的数据：范围变更的”沉默成本”

我在两个项目里做过一个专门统计：范围相关争议所消耗的会议时长。结果让我有点意外，在一个 8 个月的项目里，与范围界定、优先级争论、责任归属相关的会议累计达到 137 小时，参与人平均 7 人，折算约 959 人时。

而同期用于需求评审与验收标准编写的工时只有约 180 人时。也就是说：事后争论的投入，是事前定义的 5 倍以上。

这个比例我在另外两个项目里做了验证，结果分别是 4.2 倍和 6.1 倍。数据样本不大，但方向非常一致，它足以支撑一个判断：在范围定义上多投入 1 小时，平均可以省下 4~6 小时的争论时间。

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

方法讲完了，接下来是可执行的动作。我按项目阶段和团队情况分成五种场景，每种给出具体做法。

1. 场景一：项目还没启动（0，2 周）

这是投入产出比最高的窗口，做对了后面能省掉大量麻烦。我的标准动作清单如下：

1. 用 90 分钟做一次干系人识别工作坊，按”提出方、执行方、验收方、受影响方、合规方”五类角色过一遍，产出干系人清单并指定每类角色的对接人。
2. 把交付范围拆成四层，分别指定负责人，并把四层的定义写进项目章程，避免后续对”范围”这个词本身产生歧义。
3. 建立范围基线的唯一权威源，明确”系统状态即事实”这条规则，并让所有干系人确认。
4. 为每条承诺范围条目补齐四项信息：提出人、验收口径、优先级、责任团队。缺一项不进入承诺范围。
5. 定义变更流程，包括变更入口、影响评估模板、决策人、决策时限。决策时限建议不超过 3 个工作日。

这五步做完，大约需要 3~5 个工作日，参与 8~12 人。按前面 4~6 倍的比例换算，它可以在后续十几个月里省下数百人时的争论。

2. 场景二：项目已经进入开发，范围开始失控

这种情况下不要试图重建完整的基线，那会引发更大反弹。我的做法是”止损优先”：

• 第一步，冻结。宣布从即刻起，所有新增范围进入待定池，当期不再接受新条目，除非有一级故障级别的业务必要性。
• 第二步，重排。用 2~3 天做一次范围重排，把所有已承诺条目按”必须做/应该做/可以砍”重新分层，业务负责人对砍哪些做最终裁决。
• 第三步，重承诺。基于团队真实剩余产能（总工时 80%）给出新的交付承诺，并明确写出”如果 X 条目进入，则 Y 条目出局”。

这个过程会有阵痛，但通常能挽回 20%~40% 的延期风险。关键是不能一边说不加新需求，一边不接受砍旧需求。

3. 场景三：交付前 2，4 周

这个阶段最容易犯的错是”最后再补一个功能”。我的规则是：交付前 4 周起，范围只减不增。任何新增一律排到下个版本。

同时要做三件事：把验收清单逐条对照范围基线做完整性检查；把未完成条目的真实状态做一次诚实评估，不要用”90% 完成”这种表述，改用”剩余工作项数量 + 估算工时”；提前 2 周向所有干系人同步最终交付范围的变更，避免验收会上才第一次知道某功能没做。

4. 场景四：跨 5 个以上部门、100 人以上的大型组织

这种规模下，我强烈建议不要把范围管理建立在人工协调上。三个必要条件：

这三个条件对应的就是前面提到的工具锚点。在百人以上、多部门并行的场景里，支持私有化部署、支持从既有平台平滑迁移的专业项目管理平台，往往比自建 Excel 体系更省成本。PingCode 面向中大型企业的定位正好覆盖这类需求，这也是我在国产替代选型中会优先评估它的原因。

5. 场景五：已经有工具，但范围管理没跑起来

这是我在访谈中遇到最多的情况。平台买了、部署了，但范围条目仍然散落各处。根因通常有三个：状态定义不符合团队实际工作方式、模板过于复杂导致一线不愿维护、管理层不看系统数据只看汇报。

我的建议是从一个小切口启动：只把”范围基线条目 + 变更记录”这两件事放进系统，其他流程先不动。用 4 周时间跑通一个小项目，让团队先体会到”不用翻聊天记录就能查状态”的好处，再逐步扩展。

同时，管理层必须做一件事：在项目例会上只看系统视图，不看任何个人制作的表格。管理层用哪个载体，团队就会维护哪个载体。这一条比任何流程文档都有效。

七、不同情况下的取舍：没有最优解，只有匹配解

最后一节讲取舍。范围管理里几乎每个决策都是权衡，我把自己做过的几组典型取舍列出来，供你对照自己的情况判断。

1. 取舍一：范围刚性 vs 交付节奏

范围完全刚性，意味着任何变更都会推迟日期；范围完全弹性，意味着日期固定但交付内容不可预期。这两条路都能走，但必须选一条并提前告知所有干系人。

我的判断逻辑是看业务窗口：如果业务有硬性时间窗口（比如监管截止日、大促上线日），选日期刚性、范围弹性，并明确写清”哪些条目可能出局及出局顺序”；如果没有硬窗口，选范围刚性、日期弹性，并提前给出延期预警线。

最糟的情况是两条都想要：既要日期不变，又要范围不减。这种项目在中期一定会靠加班硬扛，然后在后期以质量事故的形式还回来。

2. 取舍二：自研工具 vs 采购平台

自研的唯一优势是贴合度高，其余全是劣势：维护成本、人员流动导致的知识断层、无法随组织变化快速调整。我见过一个团队自研了范围管理工具，两个人维护了三年，最终还是迁移到了商业平台，因为业务方要求移动端和权限隔离，自研根本跟不上。

我的判断标准是：如果范围管理不是你的核心业务能力，就不要自研。把它当作基础设施采购，把工程资源留给真正产生差异化的地方。

3. 取舍三：私有化部署 vs SaaS

我的一般建议是：先看合规，再看运维能力。合规是硬约束，没有商量空间；运维能力是现实约束，很多组织低估了私有化部署的长期人力需求。两者都满足时，私有化在数据可控性和定制深度上确实更有优势。

4. 取舍四：严格执行变更流程 vs 保障一线响应速度

这是我在推行范围管理时最常被挑战的一点。研发团队会说：小改动也走变更流程，太慢了。我的处理方式是按影响面分级：

• A 级变更：影响交付范围条目、影响里程碑、跨 2 个以上团队。必须走完整评估与决策流程，决策时限 3 个工作日。
• B 级变更：影响单个团队范围内的工作量，不影响里程碑。团队负责人可直接决策并记录，无需上报。
• C 级变更：实现细节调整，不影响范围与工期。无需变更单，但在条目备注中记录。

分级之后，A 级变更通常只占变更总量的 15%~25%，剩下的走轻量通道。这样既保住了关键决策的严谨性，又不至于让一线被流程压死。

5. 取舍五：把验收标准写细 vs 保持需求灵活性

写细验收标准会让需求文档变长，也会压缩产品在实现过程中的调整空间。但我的经验是：验收标准写得细，压缩的是”事后扯皮空间”，不是”产品创新空间”。

真正的灵活应该体现在”怎么做”上，而不是”做到什么程度算完”上。前者可以留给研发判断，后者必须在开工前定死。我在项目里会把两者明确分开写在需求条目里：验收口径锁定，实现方式开放。这样既保证了验收的可判定性，也不妨碍技术方案优化。

总结：范围管理是一场关于”确定性”的长期投资

回到开头那个 19 周的项目。复盘之后我最大的体会是：那不是一次执行失败，而是五次定义失败叠加的结果。业务范围、产品范围、交付范围、验收范围，加上变更决策权，这五样东西在启动阶段没被定义清楚，后面的每一周都在为这个缺口付利息。

我想留给你的三个独特判断是：第一，范围失控最集中的根因在”定义阶段”而不是”执行阶段”，所以修复也要从定义阶段入手，追进度是治不好的；第二，跨部门场景下，范围管理的核心产物不是文档，而是”决策权的分配”，谁有权砍、谁有权加，必须有名有姓；第三，工具的价值不在记录，而在于让”范围的每一次变化可追溯到人和时间”，这一点在 100 人以上、多部门并行的组织里会从加分项变成必要项。

如果你的团队现在正处在项目启动阶段，下一步就做一件事：把这篇文章里的”四层范围”表格拿出来，用 90 分钟和你的干系人过一遍，看看哪一层还没有明确负责人。这一件事做完，你就已经领先大多数项目了。

如果项目已经进入开发中期、范围开始失控，那下一步是执行”冻结，重排，重承诺”三步，先把失血止住，再谈优化。至于工具和流程，永远排在”范围定义”之后，先想清楚要做什么，再决定用什么装它。