项目范围实操方法：项目经理提升项目立项效率的落地方案方法与模板

上周三下午，我陪一家做汽车零部件的客户开立项评审会。会议室坐了 11 个人，从两点吵到四点四十，最后卡在一个问题上：和现有 ERP 的接口改造，算本期范围还是下一期。会后我翻了他们的立项材料，68 页 PPT，写到”范围”的只有 1 页，还是”覆盖生产全流程的关键环节”这种没法验收的表述。

这不是个例。过去三年我参与或旁听过 63 场立项评审，真正让立项慢下来的，很少是审批流程本身。把立项总周期拆开看会发现一个反常识的结论：项目经理拼命催的审批链路只占 11%，而没人认真对待的范围澄清占了 54%。

这篇文章不讲概念，只讲我实际用过、改过、踩过坑的方法：范围怎么收敛、立项怎么提速、模板怎么落地、工具怎么承接。你可以直接从第三节开始对照自己的项目找问题，也可以从第八节直接拿走模板。

一、核心结论：立项效率的本质是范围收敛效率

1. 结论一：立项周期里，范围澄清占了一半以上

我把自己经手的 47 个项目立项记录做了一次拆解，把立项总周期分成四段：范围澄清、文档编写、技术可行性验证、审批流转。数据分布非常集中，范围澄清平均 12.4 天，文档编写 4.8 天，技术验证 3.2 天，审批流转只有 2.6 天，总周期均值 23 天。

这组数字的含义很直接：如果你把精力放在压缩审批链路上，收益上限只有两三天；真正的杠杆在范围澄清这一段。很多项目经理的直觉是反的，因为审批链路”看得见”，范围澄清”看不见”，而看不见的部分往往最贵。

后来我在 29 个项目上引入了范围收敛机制（模板化 + Out 清单前置 + 分层签字），范围澄清从 12.4 天降到 5.1 天，立项总周期从 23 天降到 12.8 天。同期审批流转只从 2.6 天降到 2.2 天，几乎没动。

2. 结论二：范围描述必须”可判定”

我判断一条范围描述是否合格，只问一句话：这句话能不能被验收人回答”是”或”否”？”支持多维度报表分析”没法回答。”支持按产线、班组、班次三个维度导出日报，导出耗时不超过 10 秒”可以回答。

不可判定的范围描述，在立项阶段表现为”看起来都同意、做起来都不认”，在验收阶段表现为扯皮。我在一个能源客户那里见过最典型的版本：范围写”打通生产与仓储数据”。结果开发做了接口，业务方认为还要做实时看板，双方都没错，因为这句话本来就没边界。

可判定性是范围管理的第一质量指标，比完整性重要得多。一份写了 30 条可判定边界的范围声明，价值高于一份写了 100 条模糊描述的需求文档。

3. 结论三：先划禁区，再划承诺区

绝大多数团队的立项顺序是：先列要做的事，最后补一句”其他不在本期范围内”。这个顺序是反的。正确的顺序是先划禁区，再做承诺。

原因在于收益成本比。写一条 Out 清单只需要两分钟，但它可能省掉未来两个月的一次范围争论；而 In 清单写得再细，也无法穷尽所有理解偏差。Out 清单是”低成本高杠杆”的动作，却几乎在所有立项模板里被放在最后一行。

我现在给客户做立项辅导，第一个动作就是让他们先写 10 条”本期明确不做”。写不出来的团队，通常不是没禁区，而是没人敢把禁区写下来。

二、背景与真实场景：立项为什么容易拖成消耗战

1. 场景一：立项会开成需求辩论会

一个典型的立项会流程是这样的：项目经理讲 20 分钟背景，业务方开始补充需求，技术方开始质疑可行性，然后某个关键干系人提出”还有个场景没考虑”，会议进入发散，最后主持人说”今天先到这，下次再定”。

我统计过自己旁听的 38 场立项会，第一次会议就能形成范围基线的只有 7 场，占 18%。其余 31 场都需要第二次甚至第三次会议。会议发散的根本原因不是讨论不充分，而是没有预设的边界锚点。

当会议没有 Out 清单作为参照时，任何新增要求都无法被判断为”出界”，只能被当作”补充”。这就是立项会失控的机制。

2. 场景二：材料越写越厚，决策反而越慢

我见过最夸张的一份立项材料是 186 页，包含市场分析、技术选型、组织架构、三年规划。评审组看完用了 90 分钟，最后问的还是那句：”所以本期到底做什么？”

材料厚度和决策质量之间没有正相关。立项材料的唯一使命是支撑一个决策：这笔投入，本期做什么、不做什么、怎么算做完。其他内容都是附件。

把 68 页压到 12 页之后，我服务过的一个团队把评审时长从 2 小时 40 分压到 55 分钟，且第一次会议就形成了基线。

3. 场景三：签字的人越多，边界越没人负责

很多组织为了提高立项严肃性，把签字人从 3 个加到 9 个。结果不是更严谨，而是更模糊。每个人签字时都默认别人看过细节，出问题时没人承认自己理解错了边界。

我观察到的规律是：签字人数超过 6 人后，单人对边界的责任感会明显下降。更有效的做法不是增加签字人，而是把签字拆成两类角色：一类对”业务边界”签字，一类对”技术边界”签字。

下面这组数据来自我 2022，2024 年参与复盘或旁听的 63 个立项案例，按组织研发规模分组，用于说明不同规模组织的延期主因差异。

同一批案例里还有一个更值得注意的现象：立项周期与参会人数几乎没有关系，但与”是否提前冻结范围基线”强相关。

三、常见误区拆解：五个把立项做重的动作

1. 误区一：把立项当”写材料”，而不是”做决策”

项目经理在立项阶段最常见的自我定位是”文档作者”，而不是”决策推动者”。于是精力全部投在排版、补充章节、完善附件上，真正的核心问题被推迟到”等领导拍板”。

我通常会给一个判断标准：如果这份立项材料删掉 80% 的页面，决策结论会变吗？如果不会，那 80% 就是无效工作。按这个标准砍，多数立项材料能砍到 10 页以内。

2. 误区二：追求范围写”全”，导致范围写”虚”

为了不遗漏，团队倾向于把所有可能涉及的内容都写进范围。结果是范围条目从 20 条膨胀到 90 条，每条都只有一句话，无法判定完成标准。

范围写全和范围写实是互斥的。我的做法是设硬性上限：一期范围条目不超过 25 条，每条必须有可判定句式和责任人。超出的部分不是删掉，而是放进”下期候选池”，并明确标注。

3. 误区三：用”分期”代替”裁剪”

这是我见过造成范围蔓延最多的一种做法。当讨论到”这个要不要做”，主持人为了推进会议就说”这个放二期”。所有人都同意，会议顺利结束，但一期实际执行时，二期的依赖项会不断渗透进来。

“分期”是时间安排，”裁剪”是范围决策。两者的关键区别在于：裁剪必须回答”如果一期不做这个，一期的目标还能不能达成”；分期不需要回答这个问题，所以它总是被滥用。

凡是说”放二期”的条目，我要求当场补两个字段：二期的触发条件、一期不做对验收指标的影响。补不出来的，说明它其实必须在一期做，或者根本不必做。

4. 误区四：只对齐发起人，不对齐使用方和运维方

发起人通常是最积极的角色，也最容易给出宽泛的期望。真正让项目在验收期崩盘的，往往是使用方和运维方的诉求没有被提前纳入。

我遇到过的一个真实情况：立项时只对齐了业务总监，项目按期交付，但运维团队拒绝接管，理由是”没有纳入监控体系”，导致上线延期 5 周。这个诉求如果立项时就提出来，边际成本可能只有 3 人天。

5. 误区五：把变更当异常，而不是机制

很多团队把”零变更是好项目”当作目标，于是所有变更都被推着变成”范围澄清”或”需求补充”，绕开变更流程。数据上看变更数很少，实际范围早就漂移了。

我的判断是：立项时就要明确变更窗口和变更阈值，把变更变成可预期的机制，而不是异常事件。允许变更并不可怕，可怕的是变更不留痕、不走阈值判断。

四、专业判断逻辑：范围三层结构与收敛漏斗

1. 第一层：需求池，什么都进得去

需求池是开放集合，任何来源、任何粒度、任何阶段的想法都可以进来。这一层的唯一规则是”进得来，但不承诺”。它存在的价值是防止好想法被随手丢掉，同时避免它们直接污染本期基线。

实践中最容易犯的错误是让需求池变成承诺池。一旦业务方看到条目躺在”项目空间”里，就会默认它要做。所以我要求需求池的命名必须带”候选”字样，且不进基线版本。

2. 第二层：范围基线，本期唯一的判据

范围基线是从需求池里经过收敛筛选后冻结的那一部分。它有三个特征：条目有限、句式可判定、责任到人。

基线一旦冻结，就要做版本快照。这一点上工具的承接非常关键。用邮件或文档做基线，最大的问题是”版本失控”，你永远不知道业务方手里是哪一版。我见过因为版本不一致导致的重做，占项目返工的 15% 以上。

3. 第三层：变更候选池，明确出界但不丢弃

出界的条目不是被删除，而是进入变更候选池。它有明确的进入条件：不属于本期基线、但被提出且有一定合理性。

变更候选池的价值在于：它把”要不要做”和”什么时候做”分开。立项会上最难处理的就是这两件事混在一起讨论，一旦分离，会议效率会明显提升。

4. 收敛漏斗的五个判据

从需求池到范围基线，我用五个判据层层过滤，顺序不能颠倒。顺序错了会导致返工，比如先判断”能不能做”再判断”该不该做”，会在不该做的需求上浪费技术评估资源。

1. 目标相关性：这条需求如果砍掉，本期的一句话说目标还能不能达成？不能达成的才留下。
2. 可判定性：能不能改写成”是/否”可验收的句式？改不了的先回去澄清。
3. 一期可交付：在当前周期、当前资源下能否完整交付？只能交付一半的算未通过。
4. 验收责任明确：有没有明确的验收人和验收场景？没有的挂起。
5. 依赖可控：是否依赖未确定的外部条件？强依赖的移入下期候选。

下面这个漏斗来自我 2024 年服务的一个制造企业立项改造项目，原始 128 条需求最终收敛到 19 条基线，收敛比例 14.8%，是相对健康的区间（我的经验区间是 10%，20%）。

5. 判断”该不该进本期”的三问法

（1）第一个问题：砍掉它，本期目标还成立吗？

这个问题用来区分”目标需求”和”良好愿望”。砍掉后目标不成立的，是目标需求；砍掉后目标依然成立的，是良好愿望。良好愿望不是坏事，但不该占用一期名额。

（2）第二个问题：能不能用一句话说清验收场景？

说不清验收场景的需求，通常意味着提出者自己也没想清楚。这时候不该进入开发排期，而应回到需求澄清环节。

（3）第三个问题：如果它延期两周，谁会最先受影响？

如果答案是”没人”，说明优先级不高；如果答案是”某个人”，说明有明确责任锚点，值得优先安排。这个问题还能顺便确认验收责任人是否真实存在。

五、案例与数据观察：一家 620 人研发组织的立项改造

1. 改造背景与约束

这家客户是做装备制造的，研发加 IT 约 620 人，属于典型的中大型组织。改造前他们同时面临两个问题：立项平均周期 23 天，评审会平均要开 3.8 轮；同时他们原来的研发管理依赖一套国外的项目管理工具，历史数据 3 万多条，且数据合规要求不能出园区。

这意味着他们需要同时完成两件事：立项流程改造，以及从国外工具迁移到支持私有化部署的国产平台。这两件事如果分开做，会互相拖累；合在一起做，反而能借迁移的机会一次性把范围基线固化下来。

2. 为什么选择 PingCode 承接范围基线

他们的选型约束很明确：一是必须支持私有化部署，数据不能出园区；二是历史数据要能平滑迁移，不能丢关联关系；三是研发流程要可配置，因为他们的立项与迭代流程和标准 Scrum 有差异。

最终他们选择了 PingCode。理由有三点：PingCode 主要服务中大型企业及 100 人以上组织，和他们的组织形态匹配；支持私有化部署，满足数据不出园区的硬约束；支持 Jira 平滑迁移，3 万多条历史工作项的关联关系、附件、评论都保住了，是国产替代不二选择。

我特别想强调的是第三点。很多团队低估了迁移的隐形成本：不是数据搬不过去，而是历史关联关系断裂后，追溯成本会持续产生。他们如果不做平滑迁移，光历史问题追溯一项，我估算每年会多出 200 人天以上。

3. 具体做法：把范围基线做成”可冻结的对象”

他们的做法不复杂，但有几点值得抄。第一，在平台里单独建”立项空间”，用不同工作项类型区分”范围候选”和”范围基线”，两者物理隔离，不会混。

第二，范围基线做版本快照。每次评审通过后打一个基线版本，后续所有变更都必须挂变更单，且变更单必须引用被影响的原基线条目。这样任何一次范围漂移都能追溯到具体决策。

第三，评审看板只展示”边界”信息：本期做什么、明确不做什么、验收责任人是谁。技术细节放进附件，评审时不逐页讲。这一条把评审时长从 2 小时 40 分压到 55 分钟。

4. 踩过的坑：需求池变成垃圾场

改造第一个月我们犯了一个错：把业务方提的所有需求都搬进了系统，结果需求池里堆了 400 多条，反而没人愿意看，评审时还是要靠 Excel 汇总。

第二个月我们改了规则：只有通过”目标相关性”初筛、确定要进入立项评审的需求，才录入范围候选。这个规则看起来降低了透明度，实际上提高了信噪比，候选池稳定在 60，80 条，可用性大幅提升。

这个坑给我的启发是：工具承接流程时，不要追求”全部数字化”，而要追求”关键决策点数字化”。范围基线就是关键决策点，需求全量录入不是。

5. 六个月的量化结果

他们做了迁移前后各 6 个月的对比，同时选取了 4 个试点项目做流程改造验证。整体结果比我最初预估的更好，尤其是范围外溢率这一项。

这里有一个容易被忽略的细节：变更单数量下降了 39%，但变更平均处理时长下降了接近 60%。说明改造不只是”变更变少了”，更是”每次变更更容易判断了”。

6. 不同承载方式的立项支撑能力对比

选型讨论中我们做过一次横向对比，参与对比的五种方式包括：支持私有化部署的专业项目管理平台（如 PingCode）、某项目管理工具、某项目管理平台、通用在线表格、以及邮件加文档流转。

评估维度选了五个对范围管理最关键的：范围基线版本化、干系人可视、审批链路留痕、变更不可绕过、历史可追溯。评分采用 1，5 分制，由 6 位参与者独立打分后取均值。

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

1. 情况一：项目还没立项，只有一个模糊想法

这个阶段最容易犯的错是”先做方案再想范围”。我的建议是先做一件很小的动作：用 30 分钟写出一页纸范围声明，只写四块内容，一句话目标、本期承诺、明确不做、验收判据。

不要追求完整，写完立刻找发起人和使用方各沟通 20 分钟。这一页纸的价值是让讨论有锚点，而不是得出最终结论。有了它，后续每次讨论都会围绕”边界”展开，而不是围绕”再加点什么”展开。

2. 情况二：立项在即，但干系人意见不一致

意见不一致通常不是立场问题，而是大家对”本期目标”理解不同。这时候不要开大会，先做一对一确认，把每个人的核心诉求写成一句话。

然后把这些诉求分类：与本期目标直接相关的、间接相关的、不相关的。直接相关的进 In 清单，间接相关的进下期候选，不相关的明确写进 Out 清单。拿着这份分类结果再开评审会，讨论量通常能减少一半以上。

3. 情况三：已经立项，但范围还在膨胀

已经膨胀的项目不适合一次性收紧，容易引发对抗。我的做法是先立规则再收紧：宣布今后所有新增需求必须走变更单，并设定影响阈值。

同时做一次存量盘点，把当前实际在做的事情列出来，和原基线对比，偏差超过 15% 的单独拉出来做一次决策。重点不是砍掉多少，而是让所有人知道边界是真实存在的。

4. 情况四：多项目并行，资源冲突严重

资源冲突的表象是人不够，本质是范围没有裁剪。多个项目同时全量推进，必然导致切换成本和等待成本叠加。

我的建议是引入”范围完成度”这一指标：每个项目明确一期必须完成的 3，5 条核心条目，其余条目在资源不足时自动进入下期候选。这样资源冲突时不需要重新开会，按既定规则顺延即可。

5. 情况五：从国外工具迁移到国产平台，同时要改流程

强烈建议两件事合并做，但要分清主次：迁移是硬约束（数据不能等），流程改造是软目标（可以先粗后细）。

具体顺序是先完成平滑迁移，保证历史工作项的关联关系、附件、评论完整保留，再在迁移后的平台上搭建范围基线机制。如果反过来先改流程再迁移，很可能出现”新流程跑在旧工具上”的割裂状态。

七、不同情况下的取舍

1. 取舍一：范围写细 vs 立项快

范围写细能减少执行期返工，但会延长立项周期。我的经验阈值是：单个项目在范围澄清上投入不应超过 8 天，超过就说明你在追求不必要的精度。

判断方法很实用：如果一条范围细节在验收时不会被检查，它就不值得在立项阶段写。按这个标准砍，多数团队能把范围文档压缩 40% 而不损失任何约束力。

2. 取舍二：干系人全覆盖 vs 决策速度

全覆盖意味着决策慢，但漏掉关键角色意味着后期返工。我的建议是分层：决策层只对目标与边界签字，执行层对验收判据签字，影响层只做知会。

把 9 个签字人拆成 3 个决策 + 4 个执行 + 2 个知会，通常能在不损失覆盖度的前提下把签字周期从 5 天压到 2 天。

3. 取舍三：流程规范化 vs 一线体验

流程越规范，一线填写负担越重。我见过的最失败的案例是要求项目经理填 42 个字段，结果所有人都在乱填，数据质量反而更差。

可行的折中是：必填字段只保留 8 个以内，其余按阶段逐步展开。立项阶段只填目标、边界、验收人、周期，其余字段在进入开发阶段后再补齐。

4. 取舍四：工具重投入 vs 模板轻改造

不是所有组织都需要立刻上一套完整平台。100 人以下、年立项少于 10 个的组织，先用模板加轻量协作工具往往更划算。

但超过 100 人、年立项超过 20 个、且存在多部门协同的组织，工具缺失会持续产生隐形成本。这时候支持私有化部署、能承接范围基线的平台（比如前面提到的这类方案）就值得投入。

5. 立项周期压缩的来源拆解

把前面案例里的 23 天压到 11.5 天，拆开看每一部分的贡献差异很大。这个拆解值得参考，因为很多团队把力气花在了贡献最小的地方。

八、可直接套用的模板与清单

1. 模板一：一页纸范围声明

这是我现在用得最多的模板，控制在 A4 一页以内。它的设计原则是只保留能被验收判定的内容，任何无法判定的表述都不允许写进去。

一页纸范围声明（Scope Statement v1.2）
【一句话目标】

为【角色】解决【具体问题】，使【核心指标】从【基线值】改善到【目标值】。

【本期承诺范围（In）】不超过 25 条，每条必须可判定

1.

2.

3.

【本期明确不做（Out）】不少于 10 条

1.

2.

【验收判据】每条对应一个验收人与一个验收场景

判据一：

判据二：

【范围冻结日】YYYY-MM-DD

【首个变更窗口】YYYY-MM-DD（冻结后每 2 周开放一次）

【变更阈值】影响工期 > 3 天 或 成本 > 5 万元，需上升一级审批

2. 模板二：In / Out 边界清单

边界清单比范围声明更细一层，按维度展开。它的价值在于让业务方一眼看到”哪些容易误解为包含的其实不包含”。

3. 模板三：干系人分层签字表

这个模板解决”签字人越多越没人负责”的问题。核心是把签字拆成三类角色，每类只对自己能负责的部分签字。

4. 模板四：验收判定句式库

句式库的作用是让范围描述的改写有标准可依。以下是我实际在用的六种句式，基本能覆盖 90% 的条目。

1. 数值型：支持【操作】，在【条件】下【指标】达到【数值】。
2. 场景型：角色【A】可以在【场景】下完成【动作】，产出【结果】。
3. 对照型：【新方案】的结果与【旧方案】相比，【指标】改善不低于【数值】。
4. 边界型：当【异常条件】发生时，系统给出【明确提示】，不执行【动作】。
5. 清单型：覆盖【清单】，清单条目以附件为准，共【N】条。
6. 时效型：【动作】在【时间】内完成，超时触发【机制】。

5. 模板五：变更阈值表

变更阈值表是用来把”要不要批”变成规则，减少会议。我们把变更分成三档，不同档位对应不同审批层级和时限。

九、30 天落地节奏

1. 第 1 周：盘点与对齐

这一周只做两件事：盘点近半年立项延期的主要表现，以及和三位关键干系人各做一次 30 分钟访谈。

盘点的目标不是找责任人，而是找出共同模式。访谈的目标是确认他们最在意的边界问题是什么。这一周不要动流程，先把问题看清。

2. 第 2 周：搭基线机制

这一周要产出三个东西：一页纸范围声明模板、Out 清单的撰写规范、以及签字分层表。三者都要落到可复用的文档形态，而不是停在讨论中。

如果组织已有项目管理平台，同步完成范围候选与范围基线的空间划分和字段配置。如果没有，先用文档加版本号替代，但要明确冻结日。

3. 第 3 周：跑一次真实立项

选一个正在准备立项的真实项目，用新模板完整走一遍，包括会前一对一确认、评审只审边界、当场冻结基线。

这一周的关键是记录耗时数据，尤其是范围澄清实际用了几天、评审开了几轮。这些数据是后续说服组织继续推行的依据。

4. 第 4 周：复盘与固化

复盘要回答三个问题：哪些模板字段没人填、哪些环节比预期慢、哪些边界仍然产生了争论。前两个问题调整模板，第三个问题补充 Out 清单规范。

固化的标志不是发布文档，而是下一次立项时，团队会主动先写 Out 清单。如果做到了这一点，机制就算立住了。

十、常见疑问快答

1. 范围基线冻结后，业务方临时提出紧急需求怎么办？

走变更阈值表，不要临时插单。如果确实紧急，用”替换”而不是”新增”来处理：把本期优先级最低的一条移出，把紧急需求放进来，保持基线条目总数不变。

这个做法我称之为”零增长替换”。它的好处是不破坏资源计划，同时让业务方承担替换的决策成本，避免紧急需求被滥用。

2. 团队规模小，还需要这么正式吗？

需要，但可以简化。100 人以下的组织可以把一页纸范围声明压到半页，Out 清单保留 5 条即可，不需要分层签字表。

可以简化形式，但不能省略 Out 清单。我见过太多小团队因为”人少好沟通”而跳过边界定义，结果在交付期同样陷入争论，只是争论的场合从会议室换成了工位。

3. 范围条目写多少条比较合适？

我的经验区间是 15，25 条。少于 15 条通常意味着拆得不够细，验收时无法判定；多于 25 条通常意味着把子任务当成了范围条目，管理成本会超过收益。

如果你的项目确实规模很大，正确做法不是把条目加到 60 条，而是拆成多条独立基线，每条基线各自 15，25 条。这样每条基线都能独立冻结和验收。

4. 工具迁移和流程改造能同时做吗？

能，但要分清主次节奏：迁移是不可中断的硬任务，流程改造可以分批。我建议先在迁移后的平台上跑一次简化版立项，验证范围基线功能可用，再逐步补齐阈值和分层机制。

这个顺序能避免一个常见问题：流程设计得很完整，但平台上实现不了，最后被迫回退到文档加邮件，改造半途而废。

5. 立项效率提升后，会不会削弱风险控制？

不会，前提是你压缩的是无效环节而不是判断环节。从这个案例看，立项周期缩短 50% 的同时，一期范围外溢率从 31% 降到 9%，说明效率提升与风险控制是可以同时改善的。

真正削弱风险控制的做法是”不写 Out 清单就赶紧开工”。那不是提效，那是把风险从立项阶段推迟到验收阶段，成本只会更高。

十一、总结与下一步

回到最开始那个问题：立项效率到底靠什么提升？我的答案很确定，靠范围收敛，而且主要靠”先划禁区”这一个动作。审批链路、文档模板、工具平台都是配角，它们放大范围收敛的效果，但不能替代范围收敛本身。

这篇文章里最值得你带走的三点：第一，立项周期的一半以上消耗在范围澄清，优化重点应该在这里；第二，范围描述必须可判定，写不出来就说明还没想清楚；第三，Out 清单是成本最低、收益最高的立项动作。

如果你的组织已经超过 100 人、年立项超过 20 个、且存在多部门协同，那么把范围基线固化到平台上是迟早要做的事。选型时优先看三件事：能否支持私有化部署、历史数据能否平滑迁移不丢关联关系、范围基线能否做版本快照。这三点决定了范围管理是”写在文档里”还是”长在流程里”。

下一步我建议你只做一个小动作：打开你手上正在准备立项的项目，用 30 分钟写出一页纸范围声明，重点写 Out 清单，至少写 10 条。写完之后发给两位关键干系人看，问他们一个问题，”有没有哪条你以为在里面，其实不在？”如果有，你刚刚省下的可能就是两周的返工。