范围边界管理指南：项目经理如何做好项目范围，制度设计全流程

我做过一个挺典型的复盘：一个 6 个月周期的企业系统交付项目，立项时范围说明书 11 页，验收时需求清单变成了 43 页。项目经理每周加班，团队天天救火，客户还觉得"你们做得不够"。最后算下来，原始基线之外新增的功能点占总工作量的 38%，但没有一条走完了完整的变更审批流程，全是通过周会口头确认、微信群里一句"这个也帮忙加一下"推进的。

问题不在执行。这个团队的技术能力没问题，加班也够狠。真正失控的地方，是范围边界从头到尾就没有被定义成"可执行的制度"，只被当成了一份文档。文档会被搁置，制度不会。这就是我这几年做项目治理咨询时反复验证的判断：范围管理的核心不是需求管理能力，而是制度设计能力。

这篇文章我想把这件事讲透：范围边界到底包含哪几层，制度要从启动到收尾铺哪几道闸门，项目经理手上应该拿哪几个工具，以及当领导口头加需求、客户说"顺便做一下"的时候，具体怎么接。中间我会用 PingCode 在 100 人以上组织的真实落地方式做参照，因为范围制度最后一定要落在工具上，否则就是纸面制度。

一、核心结论：范围失控是制度问题，不是沟通问题

先把结论放在最前面，后面所有内容都是为这个结论做论证。

范围边界管理不是"把需求写清楚"，而是设计一套让变更"有门禁、有路径、有记录、有代价"的治理机制。需求文档只是这套机制的一个输入物，它本身不产生约束力。约束力来自四件事：谁有权批准、什么条件必须上会、变更的代价怎么计算、越权变更的后果是什么。

我见过太多项目经理把 80% 的精力放在"跟各方沟通协调"上，结果越沟通越失控。原因很简单：没有制度的沟通，本质是逐次谈判，每一次谈判都可能在削减边界。你今天答应加一个小功能，明天的参照标准就变成了"上次都能加，这次为什么不行"。

反过来我也见过做得好的团队。他们的共同特征不是需求更稳定，也不是客户更讲理，而是：范围基线被正式确认过一次、变更通道只有一条、超过某个工作量阈值的变更必须由发起人签字确认排期影响。这些团队的范围蔓延依然存在，但每次都"看得见、算得清、有人担责"。

这就是我所说的制度型项目经理和救火型项目经理的分水岭：救火型项目经理的成就感来自"我又搞定了一个需求"；制度型项目经理的成就感来自"这个需求被正确地评估、记录和决策了"。

二、背景与真实场景：边界是怎么一点点被吃掉的

先还原一个真实过程。这是我在一家制造企业信息化项目里观察到的完整链路，从失控到重新收边，前后花了 5 个月。

1. 启动阶段：所有人对"范围"的理解都不一样

项目启动会上，业务方负责人讲的是"我们要一个能支撑未来三年业务增长的数字化平台"。这句话在商务层面很漂亮，但作为范围描述它等于什么都没说。

IT 负责人理解的是"先把 OA 和审批流打通"；财务代表理解的是"要能出对账报表"；一线主管期待的是"手机上能直接审批"；而项目发起人关心的是"年底汇报时能拿出来的成果"。

四方坐在一起开了三次会，每次都说"没问题，都理解了"，但没有一个人写出过"本次项目不做什么"。这是后来所有争议的根源。

2. 执行阶段：每一次"顺便"都在重画边界

项目进入第 3 个月，第一次周会上，业务方副总说了一句："既然审批流都打通了，那顺便把采购申请也接进来吧，逻辑差不多。"

项目经理当场没拒绝。原因很现实：一是拒绝副总需要勇气和政治资本，二是"逻辑差不多"听起来工作量确实不大，三是合同里写了"乙方应配合甲方合理的需求调整"。

结果这个"顺便"牵出了供应商主数据对接、采购权限矩阵、历史数据迁移三块内容，多花了 21 人天。

更麻烦的是，这次妥协建立了先例。后面三个月，"顺便"出现了 14 次。项目组逐渐形成了一种默认认知：范围是可以随时被追加的，只要说得出理由。

3. 收尾阶段：验收标准变成了全新的战场

到验收阶段，真正的灾难发生了。甲方拿出了一份 43 页的需求清单，其中很多条目在立项时根本不存在。乙方说这些是新增需求，甲方说"这些都是当初说好的"。

双方都拿不出证据。因为整个项目没有一条正式的变更记录，没有一次正式的基线冻结，也没有一份双方签字的范围确认书。最后这个项目靠商务让步收场，乙方少收了尾款，甲方多等了 4 个月。

4. 我重新收边时做了什么

接手这个烂摊子之后，我没有立刻去争"哪些是新增"。我先做了一件更基础的事：把"当前实际应该交付的内容"和"曾经讨论过的内容"分开成两份清单。

第一份是边界内清单，只保留原始合同和首批确认的需求条目；第二份是待议清单，把所有新增诉求列进去，每一条都标注提出时间、提出人、预估工作量、影响的里程碑。

然后把第二份清单交给发起人，不是让他决定"做还是不做"，而是让他看到：如果全做，交付日期要往后推 3 个月；如果只做优先级前 5 条，需要追加预算并且砍掉原计划中的报表模块。

这个动作的效果远超预期。当成本被翻译成"砍掉什么"和"推迟多久"时，绝大多数高层会主动收回一部分诉求。边界失控常常不是因为高层想突破边界，而是因为他们从没看到突破边界的完整代价。

三、常见误区：关于范围管理的六个错误认知

下面这六条，是我在咨询和复盘里见到频率最高的错误认知。每一条我都会说明它错在哪，以及正确的做法是什么。

1. 误区一：把需求文档当成范围基线

需求文档记录的是"用户想要什么"，范围基线定义的是"项目承诺交付什么、不交付什么、按什么标准验收"。

这两者的差别巨大。需求文档可以是 200 条，范围基线可能只包含其中 120 条，另外 80 条是"本期不做，进入后续版本池"。没有"不做清单"的范围定义，等于没有范围定义。

2. 误区二：认为范围蔓延和镀金是一回事

不是。两者机制完全不同，治理手段也不同。

• 范围蔓延是被动增加：来自外部（客户、领导、其他部门），项目经理往往是被要求的。
• 镀金是主动增加：来自团队内部，开发者觉得"这个功能做得再漂亮一点会更好"、"顺手加个导出吧"。

蔓延要治的是审批通道，镀金要治的是团队认知和验收标准。用同一套方法处理这两件事，往往两头都不见效。

3. 误区三：以为"拥抱变化"就意味着不设边界

敏捷宣言里那句"响应变化重于遵循计划"被引用得太多，也被误解得太深。它说的是"计划要能调整"，不是"不要计划"。

敏捷项目的范围管理通过产品待办列表和迭代承诺实现，边界在迭代级别是硬的，在发布级别是软的。没有边界的敏捷不是敏捷，是无序。

4. 误区四：把变更控制等同于"一刀切拒绝"

很多项目管理新人一听变更控制，第一反应是"我就说不行"。这是典型的把制度用成墙。

真正有效的变更控制是分级的：小变更走快速通道当天批，中等变更走影响评估后 3 天内决策，重大变更上变更控制委员会。制度的目标不是挡住变更，而是让每一类变更走对它该走的路径。

5. 误区五：以为范围管理是项目经理一个人的事

这是最隐蔽也最致命的误区。项目经理没有权力单独定义边界，也没有权力单独批准重大变更。这两件事都必须有发起人或授权层级的背书。

如果项目经理手上的范围说明书没有发起人签字，那它在冲突发生时基本没有效力。

6. 误区六：认为范围稳定度无法度量

可以度量，而且必须度量。否则你无法证明制度有效，也无法向管理层解释为什么要投入治理成本。

我常用的四个观察口径：变更请求数量与分布、需求稳定度（基线确认后变动条数占比）、返工率、验收一次通过率。这四个指标不需要精确基准值，纵向对比自身历史数据就足以说明问题。

四、专业判断逻辑：范围边界的四层结构

要把边界讲清楚，我建议先把它拆成四层。很多项目之所以边界模糊，是因为四个层次混在一起谈，谈着谈着就变成了"需求讨论会"。

1. 交付边界：做什么、不做什么、做到什么程度

交付边界的核心不是"列出交付物"，而是三个动作同时完成：交付物清单、排除项清单、质量与验收口径。

其中排除项清单最容易被省略，也最有价值。我通常要求项目至少写出 10 条"本期明确不做"的内容，写不出来的，说明前期调研根本没做透。

验收口径指的是"做到什么程度算完成"。同样是"支持报表导出"，是支持 Excel 导出还是 PDF？是单表导出还是多表合并？导出 1 万行和 100 万行的技术方案完全不同。这些必须在交付边界阶段说清楚。

2. 需求边界：原始需求、基线需求、变更需求

需求边界管的是需求的"身份"。一条需求从提出到交付，至少要经历三个状态标签。

• 原始需求：提出但未评估、未承诺的需求，进入池子等待评审。
• 基线需求：已评估、已排期、已确认纳入本次交付范围的需求。
• 变更需求：基线确认之后提出或修改的需求，必须走变更流程。

这里最容易含糊的是"澄清"和"变更"的界限。我的判断原则是：如果变化不改变交付物清单、不改变工作量估算、不改变验收标准，属于澄清；只要任意一项发生变化，就是变更。

3. 责任边界：谁提、谁审、谁批、谁验收

责任边界是最容易被忽略的一层，但在执行期的破坏力最大。因为范围争议的本质往往不是"要不要做"，而是"谁说了算"。

我建议在项目启动阶段就明确四类角色：需求提出方、需求评审方、变更审批方、验收确认方。注意，这四个角色不一定由四拨人担任，但必须各自明确到人和位置。

特别要处理的一种情况是：越权口头变更。发起人之外的高层在会议上直接向团队下达需求，是范围失控最常见的引爆点。处理方式不是硬顶，而是建立一条规则：任何口头提出的需求，由项目经理在 24 小时内形成书面影响分析，回传提出人和发起人确认，未确认的不进入排期。

4. 变更边界：什么能变、何时变、代价谁承担

变更边界要回答三个问题。第一，"什么类型的变化可以进入变更流程"；第二，"什么时间窗口允许变更"；第三，"变更产生的成本、工期影响由谁承担"。

第三个问题最难，也最重要。如果变更的代价永远由交付方内部消化，那审批环节就会变成走过场。变更代价必须同等地作用在提出方身上：要么调整排期，要么削减其他需求，要么追加资源。三选一，不能全都不选。

五、制度设计全流程：从启动到收尾的六道闸门

把四层边界落到制度上，我习惯用"六道闸门"来组织。每道闸门对应项目生命周期的一个阶段，有明确的输入、动作和输出物。

1. 第一道闸门：启动阶段的治理章程与发起人授权

这道闸门解决的是"制度有没有权力来源"的问题。没有它，后面所有流程都是项目经理自娱自乐。

输出物：范围治理章程（1-2 页），必须包含四项内容：项目目标与成功标准；发起人及其在范围决策中的角色；重大变更的决策层级；范围争议的升级路径。

这份文件必须由发起人签署。我见过太多项目跳过这一步，结果是每次范围争议都要临时找领导，效率极低，且结果不可预测。

2. 第二道闸门：规划阶段的范围说明书、WBS 与验收标准

这道闸门解决"交付什么"的问题。三个文件各有分工。

三者的关系是：范围说明书说"要什么"，WBS 说"怎么拆"，验收标准说"怎么算做完"。三者必须一一对应，任何一项交付物在 WBS 里找不到工作包，或在验收标准里找不到判据，这个交付物就不该出现在范围说明书里。

3. 第三道闸门：基线确认与版本冻结

这道闸门是整条链路的转折点。基线一旦确认，后续所有变化都从"讨论"变成"变更"。

具体动作包括：组织一次正式的基线评审会，各方对范围说明书、WBS、验收标准逐项确认；确认后打版本号（如 V1.0）并归档；明确宣布自此之后的需求变化进入变更流程。

这里我要强调一个细节：基线冻结不等于范围不变，而是范围变化需要成本。很多项目经理不敢做基线确认，怕被说"不灵活"，其实恰恰相反，基线确认之后项目经理反而更有主动权，因为他手上有了判断变更的依据。

4. 第四道闸门：执行阶段的变更申请、影响分析与分级审批

这是制度运行最频繁的一道闸门。核心是三件事：变更单要有什么字段、影响分析要覆盖哪些维度、什么级别的变更走什么审批路径。

变更单我要求至少包含：变更编号、提出人、提出日期、变更内容描述、变更原因、影响评估、优先级、审批结论。没有"变更原因"字段的变更单是不合格的，因为原因决定了它是否可以通过其他方式满足。

影响分析要覆盖四个维度：工作量影响、进度影响、成本影响、对其他需求的影响。前三个是常规的，第四个最容易被忽略，加一个功能可能挤掉原计划中的另一个功能，这个连锁反应必须写出来。

分级审批的设计见下表，这是我用得最顺的一套划分。

这套分级的价值在于让 80% 的变更不必等领导，同时保证真正有影响的变更一定被看见。一刀切全部上会，会导致决策拥堵；全部下放，会导致边界形同虚设。

5. 第五道闸门：监控阶段的蔓延信号识别

这道闸门解决"什么时候该介入"的问题。范围失控从来不是突然发生的，而是有一系列前置信号。

我常用的五个信号，任意出现两个就该启动范围健康度检查。

1. 需求池增长速度连续两周超过开发完成速度。
2. 迭代承诺完成率连续两个迭代低于 80%。
3. 出现"这个需求之前确认过的吧"这类对话频次上升。
4. 测试阶段发现的缺陷中，相当比例来自未评审的需求。
5. 团队成员开始抱怨"不知道到底要做多少"。

特别说明第 5 条。这是最可靠的定性信号。当团队无法说出"这次要交付什么"的时候，边界事实上已经不存在了。

6. 第六道闸门：收尾阶段的验收、移交与归档

这道闸门把项目经验转化为组织资产。三个动作不能省。

第一，依据基线 V1.0 加上所有批准的变更单进行验收，而不是依据"最后一份需求文档"。这个顺序很关键，因为变更单才是合法的范围扩展凭证。

第二，把未完成的需求、遗留问题、变更历史完整移交给运维或后续版本团队。

第三，复盘并沉淀模板。范围说明书模板、变更单模板、分级审批矩阵、验收检查表，这四份东西如果每次都重新做，制度就永远停留在个人能力层面。

六、项目经理的四个关键工具（含 PingCode 落地方式）

制度讲完，回到项目经理手上的具体工具。这四个工具我在不同规模的项目里都跑过，下面同时说明制度层面的设计，以及在 PingCode 这类平台上的落地方式。

1. 工具一：范围边界画布

一页纸，六个区块：做什么、不做什么、谁负责、怎么验收、怎么变更、争议找谁。

画布的价值在于把抽象的范围讨论压缩到一页纸内，任何一方看完都能说出边界在哪。我通常要求这份画布贴在项目协同空间首页，新加入项目的人先看它。

在 PingCode 里，这个画布可以直接用富文本页面固定在项目概览中，并挂接需求、迭代、工作项的实时状态，让画布不是静态文档，而是能跳转到真实数据的入口。这对 100 人以上、跨部门协作的组织尤其重要，因为成员流动性高，静态文档很快过期。

2. 工具二：变更控制流程与权限矩阵

把前面那张分级审批表变成可执行的流程。关键设计有三点。

• 流程单一入口：所有变更只能通过一个渠道提交，其他渠道（微信群、会议口头）一律不进入排期。
• 权限硬编码：不同级别变更自动路由到对应审批人，不靠项目经理人工判断转派。
• 状态全程留痕：从提交、评估、审批到实施、验证，每一步都有时间戳和操作人。

这三点在 PingCode 里可以通过需求变更工作流、自定义审批节点和字段权限组合实现。我在一个 300 人规模的客户项目里做过对比：流程搬到平台之前，变更平均闭环时间 6.5 天且 23% 的变更查不到完整记录；搬到平台之后，平均闭环 2.8 天，记录完整率接近 100%。

这里补一句关于平台选择的实际考虑。中大型企业、尤其是 100 人以上的组织，往往对数据主权、流程定制深度和迁移成本有硬要求。PingCode 支持私有化部署，支持从 Jira 平滑迁移，是国内团队做国产替代时比较常见的选择。范围治理这类强依赖流程和权限的能力，恰恰是私有化部署和深度定制的价值最能体现的地方。

3. 工具三：变更控制委员会 / 决策会机制

很多项目设立了这个委员会，但运行得很糟。问题通常出在会议节奏和议题筛选上。

我的建议是：固定节奏（双周或每月一次）、议题前置（提前 3 天发出议程和影响分析）、默认通过（未在会前提出的异议视为同意）。这三条能大幅提升决策效率。

参会人不宜过多。发起人、业务代表、技术负责人、项目经理，四方足够。人越多，越容易变成表态会而不是决策会。

每次会议必须有决议记录，每条决议包含：变更编号、决议结论、附加条件、责任人、完成时限。这份记录就是后续验收和结算的依据。

4. 工具四：边界看板与沟通模板

边界需要持续被看见，否则三个月后大家又会忘掉。我通常用三种沟通载体。

这三种载体的内容不要互相复制。看板给执行层看"当下要做什么"，周报给决策层看"这周边界动了多少"，月报给治理层看"趋势是否健康"。层级不同，关注点不同。

七、高频冲突场景与应对策略

制度设计得再好，也要面对真人场景。下面四个是我遇到频率最高的，逐个给出应对思路。

1. 场景一：领导在会议上口头加需求

这是最常见也最敏感的场景。硬顶会得罪人，直接答应会破坏制度。

我的做法是三步。第一步，当场不拒绝也不承诺，回应"这个需求我记下了，我评估一下对当前里程碑的影响，明天给您一个方案"。第二步，24 小时内出具书面影响分析，写清工作量、进度影响、需要牺牲的其他需求。第三步，把选择权交回给提出人：可以加，但需要相应调整排期或范围，请确认选哪一项。

这个做法的关键在于把"要不要做"的问题转化成"用什么换"的问题。绝大多数的口头需求在这一步会自然收敛，因为提出人并不想承担调整排期的责任。

如果提出人是发起人且明确要求无条件加入，那就按重大变更走流程，同时更新基线。制度不是用来对抗权力的，而是用来记录和传导代价的。

2. 场景二：客户说"这个顺便做一下"

客户说"顺便"，通常是因为他看不到工作量。项目经理的任务是把"顺便"翻译成范围变更。

我常用的句式是："这个功能我们可以做，它大概需要 X 人天，会影响 Y 这个里程碑大约 Z 天。您看是调整交付时间，还是从当前的 A 功能里替换掉？"

注意，这句话里没有任何拒绝的意味，只是提供选项。客户讨厌的不是"要加钱"，而是"被含糊地拖着"。把代价说清楚，反而更容易推进。

3. 场景三：团队主动镀金

镀金的动机通常是好的，开发者想把东西做好。但它的危害不小：一是增加未被评估的工作量，二是引入未经测试的风险，三是可能偏离真实验收标准。

我的处理方式不是批评，而是建立两条规则。第一，验收标准以外的功能增强，一律进入后续版本池，不在当前迭代做。第二，代码评审时把"超出需求范围的实现"作为明确关注点，让镀金在评审环节被发现，而不是在交付时被发现。

4. 场景四：多部门之间责任模糊

跨部门项目里，最常见的争议是"这块到底谁负责"。范围边界在这里体现为责任边界。

解决方案是责任矩阵。列出所有交付物和关键任务，逐项标注四类角色：负责执行（R）、最终批准（A）、需要咨询（C）、需要知会（I）。

这里有个实操细节：每一项交付物有且只能有一个 A（最终批准人）。出现两个 A，就等于没有 A，争议必然发生。我在做治理审查时，第一件事就是看责任矩阵里有没有一项存在两个 A。

八、不同情况下的行动建议与取舍

制度和工具都不是通用的。下面按项目类型说明应该怎么调整，以及必须放弃什么。

1. 预测型项目：把基线做硬

外包交付、系统集成、合规类项目属于这一类。范围变更直接关联合同和结算，因此基线必须做硬。

建议动作：范围说明书、WBS、验收标准三者齐备并签字；所有变更必须书面；重大变更与合同补充协议挂钩；变更单作为结算依据归档。

必须放弃的：敏捷式的高频范围调整。这类项目如果强行做迭代式范围漂移，最终会陷入结算争议。

2. 敏捷或混合型项目：把迭代做硬，把发布做软

产品研发、内部平台建设多属于这一类。这类项目需要一个能容纳变化的框架，但框架内部仍需硬边界。

建议动作：迭代级别的范围承诺视为硬边界，中途插入需求必须替换掉同等规模的其他需求；发布级别的范围视为软边界，允许按优先级动态调整；产品待办列表保持单一入口和排序透明。

必须放弃的：试图在每次迭代中都做完美的影响分析。迭代周期短，这套流程会拖垮节奏。取而代之的是"替换原则"，要加一条，先砍一条。

3. 跨部门内部项目：把责任边界做硬

这类项目最常见的问题不是需求变化，而是责任推诿。范围本身往往稳定，卡点在协同。

建议动作：责任矩阵先行，每项交付物单一批准人；建立跨部门范围协调机制，由发起人层级的角色主持；变更单中增加"受影响部门确认"字段。

必须放弃的：指望靠项目经理的个人协调能力解决跨部门争议。这在两人冲突里有效，在四方以上冲突里无效，而且会快速消耗项目经理的信用。

4. 三个必须做的取舍判断

面对具体决策时，我通常用下面三个问题快速判断。

1. 这个变化影响的是交付物，还是实现方式？只影响实现方式的，不必上升到变更流程，但需记录。影响交付物的，必须走流程。
2. 代价能不能被量化？不能量化的代价，在谈判中等于不存在。哪怕只给出"约 3 人天、影响里程碑 2 天"这样的粗估，也远胜于"会有影响"。
3. 这次让步会不会建立先例？如果会，那么即使当前成本很小，也应该走完整流程。制度被破坏，往往不是因为大事，而是因为一次次"这次就算了"。

九、30/60/90 天落地路线图

如果从零开始推行范围制度，我建议按 90 天分三段推进。不要试图一次性把所有制度文件都建起来，那样大概率会流产。

1. 第 1-30 天：建立最小可用的边界

目标只有一个：让当前项目有一份被确认过的边界。

• 产出范围边界画布（一页纸），包含做什么、不做什么、谁负责、怎么变更。
• 整理当前所有需求，划分为基线内和待议两份清单。
• 把待议清单连同影响分析提交发起人，完成第一次裁量。
• 明确变更提交的单一入口。

这一阶段的成功标准是：团队能明确说出"这次要交付什么，不交付什么"。

2. 第 31-60 天：跑通变更流程

目标是让变更从一个概念变成一套日常动作。

• 上线变更单模板和分级审批矩阵。
• 完成至少 10 次变更的完整闭环，包括提交、评估、审批、实施、验证。
• 召开第一次变更决策会，形成决议记录。
• 把流程搬到项目协同平台，实现权限路由和状态留痕。

这一阶段最容易失败的地方是流程太重，导致团队绕开它。如果发现变更单填写时间超过 15 分钟，就要考虑精简字段。

3. 第 61-90 天：用数据固化制度

目标是把制度从"依赖项目经理推动"变成"依赖数据和机制自运行"。

• 建立范围健康度月度报告，固定四个指标：变更数量、需求稳定度、返工率、验收一次通过率。
• 复盘这三个月所有被绕过的流程环节，分析原因并修补。
• 沉淀四份模板：范围说明书、变更单、分级审批矩阵、验收检查表。
• 向管理层汇报制度运行效果，争取正式纳入项目管理规范。

这一阶段的核心不是指标多漂亮，而是这套东西能不能在项目经理换人之后继续运转。能，才算制度化成功。

十、我的核心判断与下一步行动

回到最开始那个把 11 页范围说明书做成 43 页需求清单的项目。它最终失败的原因，不是团队不努力，也不是客户太难缠，而是从头到尾没有任何一个时刻，有人正式宣布过"边界在哪里"。

我做了这么多项目治理，最核心的一个判断是：边界不是墙，而是门。墙是拒绝变化，门是让变化有入口、有规则、有记录、有决策。把范围管理做成墙的项目经理，会被指责为僵化；把范围管理做成门的项目经理，会获得信任，因为所有人都知道变化怎么进来、代价怎么算、结果谁负责。

如果你现在正被范围问题困扰，我建议不要先去争论"这个需求该不该做"。先做三件事。

第一件，把当前所有需求分成两份清单：基线内和待议。这一步不需要任何人配合，你自己就能做，而且做完之后你会第一次看清失控的规模。

第二件，为待议清单里的每一条加上工作量估算和里程碑影响。不需要精确，粗估也可以，但必须量化。这一步做完，你才有资格去和发起人谈。

第三件，和发起人开一次 30 分钟的会，只讨论一个问题：待议清单里哪些进入本期，代价是什么。这次会的产出，就是你的第一版边界基线。

做完这三件事，你就已经有了制度的雏形。接下来要做的，是把它变成流程、搬到平台上、用数据维护，也就是前面说的六道闸门、四个工具和 90 天路线。

范围管理的能力，从来不是把需求管得多死，而是让每一次边界的移动都发生在明处。