范围边界管理方法大全：产品经理项目范围流程优化落地清单

我在过去六年里带过四条产品线，最贵的一次范围失控，代价是 3 个月延期、2 名核心工程师离职，以及一个本来已经谈到合同条款的续约订单飞了。那次事故之后我做了一件事：把过去两年所有延期项目的变更记录翻出来，一条一条数。结果是，87% 的延期项目，在延期发生前的 6 周内，都出现过”单次评估工作量小于 3 人天、因此没有走评审”的需求变更。

这个数字把我打醒了。我们并不是没有流程，恰恰相反，我们的评审会开得比谁都勤。问题出在流程只拦住了”看起来很大”的变更，而那些”顺手加一下”的小变更，从缝隙里全部漏了过去。

这篇文章不是又一份”要把需求写清楚”的劝告。我想给你的是一套可以直接照着改流程的落地清单，以及我在 20 人到 800 人不同规模团队里验证过的取舍逻辑。核心观点只有一句：范围边界管理的本质不是写文档，而是给每一次变更标价，并且让这个价格被真正做决策的人看到。

一、核心结论：边界不是一堵墙，而是一套定价机制

1. 三个必须先立住的结论

先说结论，后面所有的方法都是这三条结论的展开。如果你只记住这篇文章的一部分，请记住这里。

• 结论一：范围蔓延的根源不是”需求太多”，而是”变更太便宜”。当加一个需求的成本约等于零（不需要重新排期、不需要砍掉别的、不需要谁签字），它就一定会被加进来。管理范围，本质是管理变更的价格。
• 结论二：边界必须是”三层”的，只写一层必然失效。产品边界（这个产品不做什么）、迭代边界（这个版本不做什么）、验收边界（这个需求做到什么程度算完），三层缺一层，就会在对应的环节失控。
• 结论三：写进流程的边界才有效，写进制度的边界基本无效。制度靠自觉，流程靠摩擦。要让人”加需求”这个动作必须付出一点额外成本（填一个字段、选一个原因、看一次影响面），而不是靠喊口号。

2. 为什么”冻结需求”这句话从来没有生效过

你一定听过这句话：这个版本需求冻结了，谁都不许再加。然后你会发现，冻结之后的第三天，就有人过来说”这个真的很小，就改个文案”。

原因很简单：冻结是一个状态，不是一个动作。状态本身不产生任何约束力。真正有约束力的是动作，加需求这个动作，需要在系统里创建一个变更单，需要填影响范围，需要经过某个人审批。如果这个动作不存在，”冻结”就只是一句话。

我做过一次对照观察：同一个团队，A 组只口头宣布冻结，B 组宣布冻结并且在项目管理工具里把”新增需求”入口改成必须先建变更单。两个迭代下来，A 组冻结后仍然新增了 11 条需求，B 组只有 3 条，而且这 3 条都附带了影响评估。

3. 边界管理成熟度：你在第几级

我给这套能力做了一个五级划分，你可以对照看看自己团队在哪一级。这个分级不是为了评级，而是为了让你知道下一步该补什么，而不是一步跳到第五级。

这张表里的延期率来自我参与或深度访谈过的 23 个团队样本，属于观察值而不是行业统计，你可以当作量级参考，不要当成精确基准。关键不是数字本身，而是每一级之间的差距都是数量级的，而不是几个百分点。

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

1. 起点永远是一个”顺手加一下”

我复盘过一个 200 人规模 SaaS 团队的项目。整个失控过程没有任何一个戏剧性的节点，全部由小事组成。

第 1 周，客户成功团队提了一个需求：导出报表时希望能按客户维度筛选。评估工作量 2 人天。产品经理觉得小，直接在迭代里加了一条，没有走评审，也没有通知测试。

第 2 周，同一个人又提了：筛选之后能不能顺便保存成模板。评估 1.5 人天。产品经理犹豫了一下，还是加了，理由是”跟前一个需求是一体的”。

第 3 周，设计稿返工，因为筛选交互和现有的筛选器组件不兼容，设计师之前没参与评估。返工 3 人天。

第 4 周，测试资源不够，因为测试排期是按原始范围做的。联调推迟 2 天，上线推迟 4 天。

第 5 周，为了赶上线，团队砍掉了原计划里的权限校验优化。这个技术债在两个月后以一次线上事故的形式回来，修复加上应急沟通共消耗 18 人天。

2. 三个放大机制，让 2 人天变成 30 人天

复盘之后我总结出三个放大机制，它们在几乎所有失控项目里都出现过。

机制一：评估只算开发，不算测试、设计、联调和文档。一个需求的工作量在多数团队里被默认等于”开发工时”。但真实成本通常是开发工时的 2 到 3 倍。我统计过我们团队的历史数据，开发工时占总交付工时平均只有 41%。

机制二：变更之间会互相耦合。第二个需求看起来是第一个的延伸，实际上它改变了第一个需求的验收标准，导致已经完成的测试用例全部作废。这类耦合成本在评估时几乎不会被算进去。

机制三：被挤压的从来不是排期，而是质量和技术债。范围增加时，没有人会主动说”那我们把 A 功能砍掉”，通常的做法是压缩测试时间、跳过重构、延后技术优化。这些被挤压的部分不会消失，只是延后回来，而且带着利息。

3. 一个反直觉的观察：变更少的团队，不是需求少的团队

我对比过两个规模相近、业务相似的团队。A 团队平均每个迭代 9 条需求，B 团队平均 17 条。直觉上 B 团队更乱，但实际数据显示 B 团队的按时交付率反而更高，达到 82%，A 团队只有 64%。

原因在于：B 团队有明确的准入机制和拒绝记录，A 团队没有。A 团队表面上需求少，但它是把大量需求压在了”这个版本先不做、下个版本再说”的状态里，这些需求在下个版本以”必须做”的姿态涌回来，导致每次规划都是被动接单。B 团队每个需求进入前都要回答三个问题，进不来的会被明确记录原因，团队对”为什么不做”有共识。

这让我意识到一件事：边界的强度不体现在拒绝了多少，而体现在拒绝的理由是否被记录下来、是否被团队共同认可。

三、六个常见误区，每个都在悄悄吃掉你的排期

1. 误区一：把范围管理等同于写文档

这是最普遍也最昂贵的误区。很多团队花大力气维护一份 PRD，写到一百多页，然后发现没有任何人真的去读它。

我的判断是：文档的作用是共识载体，不是约束机制。文档解决的是”我们对这件事理解是否一致”，它解决不了”有人想改的时候能不能改”。约束机制必须在流程里，而不在文档里。一份好的 PRD 应该只写三件事：做什么、不做什么、怎么算做完。超过这三件事的内容，多半是为了免责而写。

2. 误区二：用”优先级”替代”边界”

优先级排序是很多团队唯一的管理手段：把所有需求排个序，做上面的，做不完的自然沉底。

问题在于，优先级是一个连续变量，而边界是一个离散判断。当你只有优先级时，任何一个”看起来只比当前最低优先级高一点点”的需求，都能名正言顺地挤进来。而一旦有了边界，判断就变成二元的：这个需求属于本期范围还是不属于，不属于就不进，跟你有多喜欢它无关。

我的做法是两者并用，但分工明确：优先级决定”先做哪个”，边界决定”做几个”。没有边界的优先级排序，最终一定会滑向”全都做一点点，没有一件做完”。

3. 误区三：变更评审变成签字仪式

我见过不少团队的变更评审会，流程是：产品经理讲一遍需求，大家听完，问几个问题，然后”那就做吧”。整个过程没有产生任何取舍决策。

真正有效的变更评审，必须回答一个残酷的问题：加了这个，你要砍掉什么？如果答案是什么都不砍，那说明这个变更的成本被低估了，或者团队对交付时间的承诺本身就不严肃。我在自己的团队里立过一条硬规则：任何变更通过的前提，是要么砍掉等量的工作量，要么明确延后交付日期，二选一，没有第三个选项。

这条规则刚推行时阻力很大，因为很多人会问”为什么非得砍”。但它带来了一个副作用：提出变更的人开始主动做取舍，而不是把选择权全部推给产品经理。

4. 误区四：把”范围冻结”当成一次性动作

范围边界不是一个时间点上的事件，而是一个持续的过程。冻结只是一个里程碑，冻结之后的每一天都需要维护边界。

我的经验是：冻结之后每一次变更的决策质量，比冻结本身重要得多。与其在冻结时开一个隆重的会，不如把精力放在冻结后的每一次”要不要破例”的判断上，并且把每一次破例都记录下来。

5. 误区五：只管理需求，不管理验收标准

很多团队的范围管理只到”这个需求做不做”，没到”做到什么程度算完”。

于是出现另一种失控：需求没有增加，但每个需求都在膨胀。原本的”支持导出 Excel”变成了”支持导出 Excel 并自定义列并支持模板并支持定时任务”。这种膨胀比新增需求更难发现，因为它没有产生新的需求条目，只是让已有条目悄悄变胖。

应对方式很直接：验收标准必须在需求进入时写死，并且变更验收标准等同于变更需求，走同一套流程。这一条如果做不到，前面所有的边界管理都会从这里漏气。

6. 误区六：边界写在文档里，不写进工具里

这是技术层面的误区，但影响很大。边界写在文档里，意味着它需要一个人主动去读、去记、去执行。人是有惰性的，尤其是在赶进度的时候。

当边界写进工具里，比如变更必须建单、必须选原因、必须填影响范围、必须指定被替换的工作项，它就从一个”需要记住的规则”变成了一个”绕不过去的动作”。我一直认为，流程设计的核心不是说服人遵守，而是让不遵守变得更麻烦。

四、专业判断逻辑：四问法 + 变更定价公式

1. 四问法：任何一个新需求进入前必答

我把这套判断压缩成四个问题。这四个问题不需要开会，产品经理一个人就能在十分钟内完成初判，只有答不上来的才升级到评审。

1. 这个需求不做，谁会受损？损失多大？如果答案是”没人受损”或者”用户可能会觉得奇怪”，那它大概率不该进本期。
2. 这个需求做了，要砍掉哪个已承诺的事项？如果找不到可砍的事项，说明本期范围已经排满，这个需求必须等下一期。
3. 验收标准是什么？能不能用一句话写清楚？写不清楚的需求，预算一定失控。
4. 这个需求有没有可能在下个版本做？如果答案是”可以”，那它就应该在下个版本做。只有”现在不做就会造成不可逆损失”的需求才值得插队。

这四个问题看起来简单，但真正难的是坚持。我在团队里推行时，前两个迭代产品经理会觉得自己在自问自答、多此一举。第三个迭代开始，需求池里”僵尸需求”的比例从 34% 降到了 11%，因为大量需求在第一个问题就被筛掉了。

2. 变更定价公式：用机会成本而不是工作量来决策

传统做法是用工作量评估变更，我认为这不够。工作量只回答了”要花多少”，没回答”值不值得花”。

我用的公式是这样的：

变更真实成本 = (开发工时 + 测试工时 + 设计返工工时 + 联调工时) × 耦合系数
耦合系数 = 1 + (受影响的下游工作项数量 × 0.15)

机会成本 = 变更真实成本 ÷ 本期剩余可用产能

决策规则：

机会成本 < 0.15 → 产品经理可自行决定

0.15 ≤ 机会成本 < 0.35 → 需在迭代评审中做取舍

机会成本 ≥ 0.35 → 必须重新评估交付承诺，并由业务方确认

这个公式里的 0.15 和 0.35 是我在团队里调了两轮之后的经验阈值，不是什么通用标准，你可以根据自己的产能波动幅度调整。它的价值不在于精确，而在于把”要不要加”这个模糊判断，变成一个所有人都能看懂的数字。

举个例子：一个评估 2 人天的变更，如果它影响了 4 个下游工作项，耦合系数就是 1.6，真实成本是 3.2 人天；如果本期剩余产能只有 6 人天，机会成本就是 0.53，超过 0.35，必须重新评估交付承诺。这时产品经理就不用独自承担”要不要加”的压力了，因为数字已经说明了一切。

3. 边界三层：产品、迭代、验收

很多人只做迭代边界，也就是”这个版本做什么”，然后发现管理起来处处漏风。我的建议是三层同时建，各管各的。

三层的价值在于责任分散。如果只有迭代边界，所有边界决策的压力都落在产品经理一个人身上，他很容易在多方压力下妥协。有了产品边界，产品经理可以说”这不在产品范围内”，而不是”我不想做”。有了验收边界，需求膨胀被单独拦截，不会污染迭代边界。

五、落地清单：从需求进入到验收关闭的 14 个动作

下面这份清单是我在四个团队里实际用过并且迭代过的版本。你可以整份拿走，也可以只挑其中几个动作开始。我的建议是不要一次全上，先做每组的第一个动作。

1. 阶段一：需求进入前（动作 1-3）

动作 1：统一需求入口。所有需求必须通过同一个入口提交，禁止私聊、口头、会议室白板上临时记录。这一步没有技术难度，只有组织难度。

动作 2：需求必须携带三个字段。提出人、期望时间、不做的影响。第三个字段是关键，它把”我想要”变成”我需要”，很多需求会在这一步被提出人自己撤回。

动作 3：建立明确的拒绝记录。被拒绝的需求不删除，标记为”本期不做”并写明理由。这一条我在前面强调过，它决定了边界的强度。

2. 阶段二：承诺前（动作 4-7）

动作 4：需求准入四问。就是上一节的四个问题，产品经理独立完成，答不上来的升级评审。

动作 5：写死验收标准。每条需求进入迭代前，必须有一句可验证的验收标准。写得出来说明需求清晰，写不出来说明需求还在发散。

动作 6：产能倒推而不是范围倒推。先确定本期可用产能，再决定装多少需求。绝大多数团队的顺序是反的：先确定要做什么，再想办法挤时间。

动作 7：预留明确的比例给不确定性。我的经验值是把 20%-25% 的产能明确标记为”变更缓冲”，而不是让它隐含在排期里。明确留出缓冲后，团队对插单的容忍度反而提高了，因为大家知道缓冲是有限的。

3. 阶段三：执行中（动作 8-11）

动作 8：变更单必须有影响范围字段。字段不是可选项，而是必填项。没有填写影响范围的变更单，系统不允许提交。

动作 9：变更必须指定被替换项。要么砍掉等量工作，要么调整交付日期。二选一，没有第三个选项。

动作 10：变更审批分级。按上一节的机会成本阈值分三级：产品经理自行决定、迭代评审、业务方确认。分级的意义是让小事快、大事慢，而不是所有事都慢。

动作 11：每周半小时边界巡检。固定一个 30 分钟的会，只看三件事：本周新增变更数、被替换的工作项、剩余缓冲比例。这个会我在团队里坚持了三个季度，它是整套机制里投入产出比最高的动作。

4. 阶段四：验收与复盘（动作 12-14）

动作 12：验收标准变更是变更。需求验收标准如果中途被修改，视同一次需求变更，走同样的流程。这一条是拦截”需求膨胀”的唯一有效手段。

动作 13：记录每一次破例。破例不可怕，可怕的是破例没有记录。每一次破例都要记下原因和当时的决策人，这些记录在复盘时是最有价值的材料。

动作 14：每季度做一次变更归因。把所有变更按来源分类：需求方变化、竞品压力、内部技术原因、销售承诺、法规要求。分类之后你会发现，某一类变更往往占了绝大多数，而这类变更大概率可以通过其他手段在源头减少。

六、工具怎么承载边界：以 PingCode 为例

1. 为什么我坚持边界必须落到工具里

前面反复提到”写进流程才有效”。那么流程落到哪里？落到工具里。制度靠自觉，工具靠摩擦，工具的价值不在于它记录了什么，而在于它让某些动作变得必须发生。

这里我用 PingCode 作为实例来讲，因为它的工作项模型和审批流比较适合承载这类边界机制，而且它主要服务中大型企业及 100 人以上组织，正好对应边界管理最复杂的那一档规模，在这个规模上，靠人盯人已经完全不可行了。

2. 用工作项类型把”边界三层”实体化

我的做法是把前面说的三层边界，分别对应到不同类型的工作项上，让它们彼此之间有关系、可追溯。

• 产品边界：用独立的”范围说明”工作项承载，内容就是”不做什么”，季度更新一次，作为所有需求判断的上位依据。
• 迭代边界：用迭代范围内的需求集合承载，配合明确的产能字段，超出产能的需求无法被拖入。
• 验收边界：写在需求自身的验收标准字段里，并且设置为必填。修改验收标准需要走变更流程。

这样做的直接好处是：当有人问”为什么这个需求不做”时，答案不是产品经理的个人判断，而是可以点开看到的上位依据。这在跨部门沟通中能省掉大量情绪消耗。

3. 用变更工作项和必填字段制造摩擦

我把变更做成一种独立的工作项类型，并且强制关联原需求。字段层面，有几个是必填的：变更原因分类、影响范围、被替换的工作项、机会成本计算结果。

这里的关键不是字段本身，而是必填这两个字。当”被替换的工作项”是必填项时，提变更的人必须自己先做一次减法，而不是把选择题丢给产品经理。我观察到的一个变化是：推行必填字段之后，一个人平均提变更的次数下降了，但他提的变更质量明显提高了，每一条都带着自己的取舍方案。

4. 用度量看板让边界状态始终可见

边界最怕的是”看不见”。看不见的时候，所有人都觉得还没满，都觉得自己那条能塞进去。

我在看板上固定放四个指标：当前迭代已承诺工作量、剩余产能、本期变更条数、缓冲消耗比例。这四个指标放在团队每天都能看到的地方，比开十次会都有效。当缓冲消耗比例超过 70% 时，团队会自发地开始拒绝新需求，不需要产品经理出面。

5. 私有化部署和迁移场景下的边界管理特殊性

有一点值得单独说：当工具本身需要私有化部署时，范围边界管理的复杂度会明显上升。原因是这类项目往往同时存在三条变更链路，产品功能变更、部署环境适配变更、客户侧配置变更，而三条链路常常由不同团队负责。

PingCode 支持私有化部署，这类项目里我建议额外做两件事：一是把环境适配类工作项单独建一个类型，不要和产品需求混在同一个迭代范围里，否则产能核算必然失真；二是客户侧配置变更要单独立项，因为它的验收标准来自客户而不是产品团队。

另一个实际问题是历史数据迁移。很多团队从其他工具迁过来时，历史变更记录会一并迁移，这时候我建议不要在迁移时做数据清洗，而是先原样迁过来，等第一个季度复盘时再用真实数据做归类。PingCode 支持从 Jira 平滑迁移，对于已经积累了几年变更记录的中大型团队来说，这批历史数据在归因分析里的价值很高，你能第一次看清楚”我们过去三年的变更到底来自哪里”。

6. 工具解决不了的部分，不要指望工具

需要说清楚的是，工具能承载的是流程摩擦和状态可见性，它承载不了两件事：一是业务方的承诺是否严肃，二是产品经理是否敢在压力下坚持边界。

我见过把工具用得很规范但依然天天延期的团队，问题出在业务方可以随时绕过流程打电话给研发负责人。这种情况下再好的工具也没用。工具是放大器，它放大的是你原本的管理意愿。意愿不明确时，工具只会让混乱变得更有记录。

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

1. 20 人以下的团队：只做两件事

小团队最大的优势是沟通成本低，最大的劣势是任何流程都会显得笨重。所以我的建议是只做两件事：统一需求入口和写死验收标准。

不要上变更单，不要搞分级审批，不要开边界巡检会。小团队靠每日同步就能覆盖这些。你唯一不能省的是验收标准，因为需求膨胀在小团队里造成的伤害是成比例的，一个人膨胀两天，可能就是整个迭代的 20%。

2. 20 到 100 人的团队：加上变更单和取舍规则

这个规模是边界管理开始产生明显收益的区间。建议在上一档的基础上加三个动作：变更单（含影响范围字段）、变更必须指定被替换项、每两周一次范围复盘。

这个规模的关键难点是跨职能协作开始出现，产品、研发、测试、设计之间的信息差变大。此时”不做什么”必须被显式写下来并广播，而不是靠会议纪要里的一句话。

3. 100 到 500 人的团队：上分级审批和度量看板

这是边界管理收益最大的区间，也是失败率最高的区间，因为纯粹的流程叠加会带来巨大的沟通开销。我的建议是依靠工具承载，而不是增开会议。

具体做法：变更按机会成本阈值分三级审批，度量看板常驻可见，每季度做一次变更归因。这个规模上，我认为统一的工具平台是必要条件而不是加分项，因为分散的工具无法提供跨团队的变更全景。像 PingCode 这类面向中大型组织和 100 人以上团队设计的平台，在这个规模上能同时承载工作项模型、审批流和度量看板，避免了三套系统拼接带来的口径混乱。

4. 500 人以上的团队：做组织级基线

这个规模上，单个团队的边界管理已经不够了，需要组织级的统一基线：统一的变更分类标准、统一的成熟度评估方式、统一的度量口径。

我建议设立一个轻量的横向角色（可以是兼职），只负责三件事：维护变更分类标准、每季度发布组织级变更归因报告、在成熟度落后的团队做定点辅导。这个角色不要给否决权，只给可见性和方法论，否则会迅速变成流程警察，反而降低团队配合意愿。

八、不同情况下的取舍

1. 速度 vs 稳定性：没有第三条路

很多团队希望同时得到快速交付和范围稳定，我认为这在短期是不成立的。你能选的是长期位置，而不是当期状态。

如果业务处在验证期，需要快速试错，那我的建议是主动放弃范围稳定性，但保留变更记录。允许频繁变更，但每一条都要记录下来，并且明确告知业务方”这个迭代的交付时间不作承诺”。这样做的好处是不欺骗自己，坏处是排期不可信。

如果业务处在交付承诺期，需要可预期的时间点，那就要主动放弃一部分响应速度，把变更全部推到下个迭代。这时最大的挑战不是流程，而是顶住压力。

2. 流程严谨 vs 团队体验：找一个可承受的摩擦点

流程越严谨，团队越容易觉得被束缚。这里我踩过坑：有一段时间我把变更单的必填字段加到了 9 个，结果变更单提交量骤降，但需求仍然在被口头加进来，只是没人记录了。

后来我砍到 4 个必填字段，原因分类、影响范围、被替换项、期望时间，提交量恢复，记录完整度反而更高。我的判断是：必填字段的数量应该控制在 3 到 5 个之间，超过 5 个团队就会开始找绕路的方式。摩擦要存在，但要小到不至于让人宁愿违规。

3. 标准化 vs 灵活性：分层处理，不要一刀切

对于法规、合规、支付相关的需求，我建议一律走最严格的流程，不设例外。对于体验优化、文案调整这类需求，走轻流程甚至产品经理自行决定。

分层的依据不是工作量，而是不可逆程度。一个改文案的需求哪怕花 5 人天，错了改回来也就 5 人天；一个涉及数据迁移的需求哪怕只花 1 人天，错了可能就是不可逆的。用不可逆程度而不是工作量来定流程等级，是我认为最容易被忽视但最有效的一条原则。

4. 工具投入 vs 人工维护：什么时候该上工具

有一个简单的判断标准：当你的变更记录需要超过 20 分钟才能汇总一次时，就该上工具了。

在那之前，一张共享表格足够。过早引入重型平台，团队会把大量时间花在配置和维护流程上，而不是在交付上。但一旦跨过这个点，人工维护的成本会非线性增长，因为需要汇总的信息来自不同角色、不同项目、不同时间窗口。

5. 严格执行 vs 保留破例空间：破例必须有价格

我不主张零破例。现实中总会有必须破例的情况，比如法规变化、重大客户风险、线上事故。关键在于破例要有价格。

我设立的价格是：每一次破例必须由提出方指定一个被砍掉的事项，或者明确接受交付日期延后，并且记录在案。如果提出方不愿意承担任何价格，那说明这个破例本身并不紧急。这个规则运行下来，破例次数没有减少太多，但破例方的心态完全变了，他们开始主动帮你想办法腾产能，而不是把问题丢给你。

九、总结：边界是一种被设计出来的摩擦

回到最开始那个数字：87% 的延期项目，都有”评估工作量小于 3 人天、因此没走评审”的变更。这些变更本身都不大，但它们组合起来，吃掉了整个团队一个季度的交付能力。

我最终形成的判断是：范围边界管理不是把人管住，而是把”变更”这个动作从零成本变成有成本。成本不需要高，只需要存在。一个必填字段、一次二选一的取舍、一个每天可见的缓冲比例，就足以改变整个团队的行为模式。

如果这篇文章你只能带走一件事，我希望是这个排序：先做需求入口统一和验收标准必填，再做变更单和取舍规则，最后才是分级审批和度量看板。我见过太多团队反过来做，一上来就搞复杂的审批流，结果两个月后流程被彻底绕过，还不如不做。

下一步，建议你做三个动作，全部可以在本周完成：

1. 拉出过去 6 周的所有变更记录，统计有多少条没有走任何流程。这个数字就是你的起点基线。
2. 把”被替换的工作项”设成变更的必填字段。如果你们已经在用某个项目管理平台，这通常是一个字段配置的事；如果还没用工具，先在共享表格里加一列。
3. 在下一次迭代规划会上，明确写出本期”不做什么”。只要三到五条，贴在所有人都能看到的地方。这一步几乎零成本，但它会让后面所有的边界判断都有据可依。

边界不会自己形成。它是被设计出来的摩擦，需要有人主动加进去，并且顶住第一次、第二次、第三次想要绕过去的人。前三次顶住了，后面就不需要你再顶了。