项目范围范围教程：项目经理实操方法，避坑指南

项目范围范围教程：项目经理实操方法，避坑指南

我带过一个合同额 180 人天的 ERP 实施项目，最后交付结束的工时是 320 人天。多出来的 140 人天里，没有一天是因为技术攻克不了，全部来自一句话式的临时需求、口头化的验收标准，以及一份从没写过"不做什么"的范围说明书。那次项目让我彻底改变了做法：项目范围管理不是画一张 WBS 图，而是给每一次范围变化标上价格。

这篇内容不讲教材定义，讲的是我自己复盘 20 多个交付项目后总结出的一套可执行方法：怎么在一页纸内写清楚边界，怎么冻结基线，怎么用三级阈值裁决变更，怎么识别范围蔓延和范围镀金的早期信号，以及在不同合同类型、不同组织权限下该做什么取舍。文中所有数字，凡涉及具体项目的，都来自我的项目复盘记录；凡涉及行业推断的，我会明确标注为示意数据。

一、先给结论：范围失控不是执行力问题，是边界设计问题

大多数项目经理在范围问题上都会经历同一个阶段：把范围失控归因于"客户太能改""老板拍脑袋""研发不配合"。这个归因方式很安全，但没用，因为它指向的是你无法改变的东西。换个角度看，范围失控几乎总是三个可被你控制的设计缺陷造成的。

1. 结论一：变更之所以失控，是因为变更没有价格

需求方之所以敢随手加需求，是因为加需求的即时成本是零。他不需要签字，不需要说明预算来源，不需要解释要砍掉什么。只要"加需求"这个动作不产生任何可见代价，它就一定会被反复使用。

范围管理的核心动作不是"拒绝变更"，而是"让每一次变更都带上价格标签"，多少人天、影响哪个里程碑、替换掉哪项原定工作。一旦价格被摆到桌面上，至少一半的临时需求会自己消失，因为提出需求的人也不愿意承担砍掉其他功能的压力。

2. 结论二：项目范围管理的第一交付物是"不做什么"

我做过统计，在我经手的项目里，验收阶段的争议有七成以上指向同一类问题：某项工作到底在不在本次范围内。这类争议在启动阶段往往被一句"这个后面再说"轻轻带过。

所以在我的模板里，范围说明书的第一页永远有一块固定内容叫"本次不包含"，并且要求写得比"包含"更具体。写"不包含第三方系统对接"是无效的，要写成"不包含与 XX 供应商 WMS 系统的接口开发、联调与上线支持，如需支持另行评估工作量"。

3. 结论三：范围争议的胜负，在启动后前三周就决定了

很多人以为范围管理是执行期的活儿，其实决定性的动作发生在启动阶段。启动阶段你手里有最大的谈判筹码，项目还没投入，客户还愿意配合，老板还愿意听你讲风险。一旦进入执行中后期，你的筹码会迅速衰减：沉没成本已经产生，进度压力已经上来，任何"这个不在范围内"的说法都会被理解成推卸责任。

下面这张图是我复盘一个 180 人天项目时的工时膨胀拆解，它很直观地说明了"价格不可见"的代价。

这张图的关键信息不是 320 这个数字，而是结构：未经登记的临时需求一项就占了全部膨胀量的 41%。而这一项恰恰是最容易治理的，它不需要重新谈判合同，只需要一张变更登记表和一个"不登记不排期"的规则。

二、范围是怎么一步步涨上去的：一个 180 人天项目的完整复盘

抽象的方法论容易记住，但很难执行。我把一个失败项目的完整过程摊开讲，你能看到失控从来不是一次性发生，而是四个不起眼的节点串起来的。

1. 项目背景与初始约定

项目是给一家年产值 8 亿左右的制造企业做生产与库存模块的实施。合同约定的范围是：标准模块配置、三个报表定制、一次历史库存数据迁移、上线后两个月内的问题支持。合同附件里有一份 6 页的需求清单，写得相当粗，比如"支持多仓库库存查询"这一条，没有说明仓库层级、查询维度、并发要求。

启动会上，客户方的信息部负责人说了一句我后来反复想起的话："细则我们边做边对，先把框架搭起来。"我当时的处理方式是口头确认了主要模块，没有坚持把清单细化到可验收粒度，也没有写除外责任。

2. 从 180 到 320 的四个关键节点

第一个节点，启动后第 9 天。客户的生产部提出，希望库存查询能按车间维度看，因为他们的领料是按车间走的。这个需求听起来是查询条件加一项，实际牵扯到组织架构建模和权限体系调整。我评估为 6 人天，但因为没有变更流程，我在周会上直接答应了，理由是"避免影响客户关系"。

第二个节点，上线前四周。客户财务部提出，库存结存数据要和财务系统对上，需要开发对账报表。这已经超出原合同范围。这一次我意识到了问题，但选择"先做，商务后补"。结果是商务一直没补，交付照做，工作量照增。

第三个节点，UAT 阶段。验收标准第一次被正式讨论。客户提出，凡是查询类报表都要支持导出 Excel，并且导出格式要和现有系统一致。原合同对此没有任何约定。整改花了 24 人天。

第四个节点，上线后。项目组为提升使用体验，主动做了移动端审批的适配优化，18 人天，客户从未要求，也未计入合同。这是典型的范围镀金。

下面这张图展示变更数量与累计延期之间的时间关系，可以看清"变更密集期"往往出现在什么阶段。

3. 事后归因：三张当时没写的表

项目结束后我做了完整复盘，发现如果当时只有三样东西，结果会完全不同。第一是一页纸范围说明书，特别是"除外责任"部分；第二是变更登记表，把所有口头需求变成有编号、有评估、有决策的记录；第三是验收标准确认单，在开发启动前让关键干系人书面确认验收口径。

这三样东西加起来不到两小时的工作量，对应的却是 140 人天的差额。这也是我后来在所有项目里强制推行"启动三件套"的原因。

下面这张帕累托图来自我对 23 个项目的问题记录统计，可以看清哪几类原因贡献了大部分返工。

三、拆解六个常见误区

在讲具体方法之前，得先把几个流传很广但会误导执行的说法拆掉。这些说法单独看都没错，放进真实项目里就会让判断走偏。

1. 误区一：范围就是需求清单

需求清单回答的是"要什么"，范围回答的是"交付到什么程度算完成"。同一句"支持多仓库库存查询"，在没有说明仓库层级、并发量、响应时间、权限粒度的情况下，它只是一句愿望，不是范围。范围必须是可验收的表述。

我通常这样判断一条范围描述是否合格：把它交给一个没参加过需求会的测试人员，他能不能据此写出测试用例。如果写不出来，这条描述就还没到"范围"的粒度。

2. 误区二：基线冻结之后就不能改了

这是对新项目经理伤害最大的一个误解。基线的作用是提供比较基准，不是禁止变化。冻结基线的真实含义是：从此以后，任何偏离都要走流程、带价格、留痕迹。把基线理解成"不能变"，会导致两种糟糕行为，要么死扛着不改然后交付一个没人用的系统，要么偷偷改掉然后基线彻底失效。

3. 误区三：所有变更都必须上变更控制委员会

在很多中小项目里，正式变更控制委员会根本不存在，或者存在但一个月开一次会。如果强行要求所有变更都排队等会议，实际结果一定是绕过流程私下处理，流程变成摆设。

更现实的做法是做变更分级：小改动项目经理可直接决策并事后报备，中等改动由项目发起人和业务负责人双签，重大改动才升级到合同层面。分级阈值的具体设定我在第六章讲。

4. 误区四：WBS 拆得足够细就等于管住了范围

WBS 解决的是"工作分解"，不解决"范围边界"。我见过拆到四级、两百多个工作包的项目，照样在验收时扯皮，因为那些工作包描述的是任务，不是交付物，更没有任何一处写清楚什么不在范围内。拆得细只意味着你更清楚自己要做多少事，不意味着别人知道你不会做哪些事。

5. 误区五：范围蔓延和范围镀金是一回事

这两个概念经常被混用，但成因和对策完全不同。范围蔓延是外部需求不断渗入，责任在需求方和你的流程；范围镀金是团队自己主动增加未被要求的功能，责任在团队内部。前者靠变更控制解决，后者靠交付标准约束和团队激励调整解决。

关键在于定性归因：同一个多出来的功能，如果客户提过，是蔓延；如果客户没提、团队自己加的，是镀金。归错类会让你的对策完全失效。

6. 误区六：文档写全了，范围就不会跑偏

文档是必要条件，不是充分条件。我见过范围说明书写了 40 页的项目，照样失控，因为文档写完就进了共享盘，没有人读，也没有人在关键节点对照它做决策。范围文档的价值来自使用频率，不是来自篇幅。

所以我现在只推一页纸版本：一页能读完，才会有人读；有人读，才会在决策时被引用。

四、第一步：用一页纸范围说明书锁定边界

一页纸不是形式主义，而是对可执行性的筛选。当你被迫压缩到一页，你会自然放弃那些正确但无用的套话，只保留真正影响决策的信息。

1. 六要素的构成与写法

我用的模板固定包含六块：项目目标、交付物清单、范围边界、假设条件、除外责任、验收标准。顺序不能乱，因为它是按"回答疑问"的逻辑排列的：做什么、交什么、做到哪、凭什么前提、不做什么、怎么算完成。

2. 除外责任为什么是六要素里最重要的一块

因为它是唯一一块专门用来防止后期扯皮的内容，也是绝大多数模板会漏掉的一块。写除外责任有个技巧：不要凭想象写，而是从三个来源倒推。第一个来源是本次需求清单里被降级或砍掉的功能；第二个来源是客户在沟通中提到但本次不做的相关系统；第三个来源是团队内部讨论时有人提过、但被判定为超范围的想法。

把这三类内容全部写进除外责任，并且明确"如需支持，另行评估"。这一句话在后期能省掉的沟通成本，远超你的预期。

3. 验收标准必须在开发启动前对齐

验收标准后置是项目里最贵的错误之一。我的做法是在开发启动前专门开一次验收标准对齐会，参会人必须包括最终签字人和实际使用部门代表。会议输出一份验收清单，逐条写清验收项、验收方式、判定标准、数据量级和责任人。

这里有个容易忽略的细节：验收标准要写清楚在什么数据量级下验收。一个查询功能在 500 条测试数据下响应 0.5 秒，在 50 万条生产数据下可能是 15 秒。这个差异足以让验收从"通过"变成"不通过"。

下面这张雷达图对比了两类项目的范围说明书完整度评分，可以看出问题项目的短板集中在哪几个要素上。

五、第二步：冻结基线，让范围从"说法"变成可比较的版本

写完范围说明书只是有了边界描述，还需要把它变成可以被追踪、被比对的对象。这一步的关键词是"基线"，而基线成立的标志是你能随时回答一个问题：当前要做的事，和最初定的相比，多了什么、少了什么。

1. WBS 拆到可验收工作包为止

工作包停止拆分的判断标准不是层级数，而是它是否具备四个属性：有明确交付物、有唯一责任人、有验收条件、有工作量估算。缺任何一条就继续往下拆。

我见过太多 WBS 拆到"系统开发"这一层就停住的，这种工作包无法估算也无法验收。合格的写法应该像下面这样。

工作包编号：WP-03-02
工作包名称：库存对账报表开发

交付物：对账报表 1 张 + 取数逻辑说明文档 1 份

责任人：后端开发 A（主）/ 报表开发 B（支持）

验收条件：

1) 报表结果与财务系统月度结存差异率不高于 0.1%

2) 10 万条明细数据下生成时间不超过 30 秒

3) 支持按月、按仓库两个维度筛选并导出 Excel

工作量估算：8 人天（置信区间 7-10 人天）

前置依赖：仓库主数据清洗完成（WP-02-04）

2. 范围基准的三件套

基线不是一个文件，而是一组配套文件：范围说明书定义边界，WBS 分解交付，WBS 词典描述工作包细节。三者版本必须一致，任何一项单独更新都会让基线失效。

实践中我要求这三份文件共用同一个版本号，任何变更导致其中一项修改，三份文件同步升版。这样做的代价是变更时多做一点文书工作，收益是任何时候都能拿出一份自洽的范围基准。

3. 基线冻结会怎么开

基线冻结会不是走过场的形式会议，它要产出三个明确结果。第一，关键干系人书面确认范围边界和除外责任；第二，验收标准逐条确认无异议；第三，明确基线变更的唯一入口和审批路径。

会议有个细节很重要：确认动作要在会上当场完成，不要让干系人"回去看一下再签"。回去之后大概率就没有下文，而项目必须往下走，最后又变成默认同意。

冻结会之后，需求从提出到进入基线会经过一道筛选，这个过程本身就过滤掉了大量随意需求。

六、第三步：控制变更，让口头需求留下痕迹

基线冻结之后，变更控制就成了日常动作。这一章讲三件事：分级阈值怎么设，影响评估看哪几个维度，以及面对不同类型的需求方该用什么话术。

1. 变更分级：三级阈值

把所有变更都推到高层审批，流程会被绕过；全部由项目经理自己拍板，风险会失控。分级的意义在于让每类变更走到合适的决策层级，既不阻塞也不失控。下面是我在多数项目里使用的参考阈值。

阈值不是死的，要按项目规模和合同类型调整。一个 30 人天的小项目，把二级门槛设在 15 人天等于形同虚设；一个 2000 人天的大项目，把一级门槛设成 3 人天又会导致项目经理被琐事淹没。我的经验是按合同工作量的 1%-2% 设定一级门槛，5%-8% 设定二级门槛。

2. 影响评估的四维框架

评估变更不能只算开发工作量，那样会严重低估真实成本。我要求每次评估必须覆盖四个维度，缺一项就不进入决策环节。

• 工期影响：该变更增加多少人天，是否挤占关键路径，导致哪个里程碑顺延多少天。
• 成本影响：人力成本之外，是否涉及第三方采购、环境扩容、额外授权费用。
• 质量影响：是否引入新的测试范围，是否影响已通过的测试结论，需要回归测试哪些模块。
• 风险影响：是否引入新的技术不确定性、合规要求或跨系统依赖，失败概率和兜底方案是什么。

给出这四维之后，决策者拿到的不是"要不要做"，而是"做了之后要付出什么"。这个转变是范围管理能否落地的分水岭。

3. 三类话术：拒绝、延后、置换

项目经理常常卡在不会说话上。直接说"这个不在范围内"会让关系紧张，但全盘接受又会失控。我常用三种句式，区别在于给了对方什么选择。

拒绝型话术适用于完全超出合同且无法内部消化的情况。句式是：先确认对方诉求的合理性，再给出客观依据，最后给出正式路径。"这个需求我理解确实有业务价值。它超出了本次合同约定的交付范围，我们没有对应的工作量预算。如果要推进，我们走正式变更评估，我可以今天就把影响评估表发给你，你看什么时候方便确认。"

延后型话术适用于需求合理但不紧急的情况。"这个功能我记下来了，放在二期候选清单里。本次上线先保证核心流程跑通，二期立项时我们把它排在第一批。我会把这条写进本期遗留问题清单，你这边也能看到进度。"

置换型话术适用于对方坚持要在本期做的情况，核心是把"加"变成"换"。"可以做，工作量大概是 8 人天。这 8 人天要从本次范围内挪出来，目前能挪的是报表二和移动端适配，你倾向砍哪一个？或者我们同步调整上线时间。"

这三种话术的共同点是：不否定对方，但把成本显性化，让决策回到业务价值判断上。

七、避坑指南：六个预警信号与四张核心表

范围失控不会突然发生，它总是先发出信号。问题在于大多数信号都很不起眼，容易被当成正常的项目沟通。下面这六个信号，是我复盘后认为最值得提前干预的。

1. 六个早期预警信号

信号一：需求提出频率突然上升，但没人提预算。正常的业务需求会伴随优先级讨论，异常的需求潮只有"要"没有"舍"。

信号二：会议纪要里出现"待确认"项反复出现。同一个待确认项在三次会议里都挂着，说明责任人没定清楚，后期必然演变成争议。

信号三：验收标准在测试阶段被首次正式讨论。这说明验收标准从未前置，后面会进入被动整改。

信号四：团队开始主动说"顺便把 XX 也做了"。这是范围镀金的典型前兆，通常源自团队想做出更好产品的善意，但对交付没有帮助。

信号五：跨部门需求开始绕过对接人直接找你。这说明需求入口已经失守，后面的登记和评估都无从谈起。

信号六：变更登记表连续两周没有新增记录，但项目群里天天在讨论新需求。这条最危险，它意味着流程已经被绕过，你看到的数据和真实情况脱节。

2. 四张必须维护的表

方法最终要落到具体载体上，否则无法执行。我要求所有项目至少维护下面四张表，并且保持同期更新。

• 变更登记表：记录每一条范围变化的提出时间、提出人、内容描述、影响评估、决策结论、执行状态。
• 范围确认单：范围说明书和验收标准的逐条确认记录，含确认人、确认时间、确认方式。
• 验收清单：把验收标准拆成可勾选的条目，每条对应测试证据和责任人。
• 决策记录表：记录范围相关的关键决策，包括决策背景、备选方案、最终选择和理由。

变更登记表是四张表里性价比最高的。下面是一个我实际使用的字段结构，可以直接套用。

变更编号：CR-2024-017
提出日期：2024-05-13

提出人：生产部 王主管

变更内容：库存查询增加按班组维度筛选，并支持导出班组领料明细

原始需求来源：5 月 13 日生产协调会临时提出，无书面申请

【影响评估】

工期影响：+6 人天，不影响当前关键路径，里程碑 M2 无顺延

成本影响：无第三方采购，人力成本约 6 人天

质量影响：需回归查询模块 3 个既有用例，新增测试用例 5 条

风险影响：班组主数据需客户方提供，若数据缺失将影响排期

【决策】

变更级别：二级

决策人：项目经理 / 项目发起人 / 生产部负责人

决策结论：接受，同时将原定的报表二（预估 5 人天）延至二期

决策日期：2024-05-16

验证方式：验收清单新增第 14 项，由生产部王主管确认

3. 工具层的落地方式

表格用共享文档维护也能跑，但项目一多、参与人多，共享文档会出现版本混乱、评审记录缺失、变更与需求脱节的问题。我在中大型项目里更倾向用研发管理平台承载这套流程。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，需求池、迭代规划、里程碑、甘特图和工作项流转可以在同一套体系里打通。这对范围管理的价值在于三点。

一是需求池与基线的分离。所有新想法先进需求池，不直接进迭代。只有经过评估并被决策纳入本次交付的需求，才会进入当前迭代或里程碑，这在结构上避免了"讨论即承诺"。

二是变更痕迹可追溯。每个工作项的字段变更、状态流转、评审意见都有记录，月度和季度复盘时能还原出"这条需求是什么时候、由谁、基于什么理由加进来的"。这比事后回忆可靠得多。

三是验收与交付物对应。验收清单可以和具体工作项关联，避免出现清单上有、系统里没有，或者系统里有、没人确认的情况。

对还在用 Jira 的团队，迁移成本是常见的顾虑。PingCode 支持 Jira 平滑迁移，也支持私有化部署，对数据不出内网有硬性要求的企业来说，这是国产替代方案里比较务实的选择。我参与过一次从 Jira 迁移的项目，工作项、字段映射和迭代历史这类核心数据基本可以平移，真正需要重新设计的其实是流程配置本身，这恰好也是梳理范围管理流程的好时机。

需要说明的是，工具解决的是"记录和追溯"问题，不解决"判断和博弈"问题。阈值定多少、需求该不该接、话术怎么说，仍然取决于项目经理的判断。指望换一个平台就能管住范围，是把管理问题误当成工具问题。

八、验收与关闭：把范围真正关掉

范围管理的最后一环是关闭。很多项目上线之后就直接进入运维，范围正式关闭的动作被跳过，结果是半年后还有人拿着旧需求清单来找你加功能。

1. 验收标准回溯

验收不是从零开始写清单，而是回溯最初的验收标准，逐条核对。回溯时要做三件事：把初始验收标准与当前实际交付逐条对照；标注每条证据在哪里；对未完全满足的条目给出书面说明和处理方案。

这个动作的价值在于，它把"我觉得做完了"变成"按约定逐条确认做完了"。前者会引发争议，后者不会。

2. 范围关闭清单

关闭动作需要一份清单来保证完整。我用的清单包含五项：交付物清单已逐项移交、验收清单已全部确认、变更记录已归档、遗留问题已登记并明确处理方案、双方书面确认本次范围关闭。

最后一项最容易被省略，但它是防止后期扯皮的关键。没有这一步，你其实没有真正关闭范围，只是暂时没人来问。

3. 遗留问题的处理规则

遗留问题要分两类处理。一类属于本次范围内但未完成，这类必须给出明确完成时间和责任人；另一类属于本次范围外，这类要写清"转入后续评估"，不能含糊地写成"后续支持"。

区分这两类的意义在于费用归属。前者是交付方义务，后者是新增需求，混在一起写会导致后续所有工作都无法主张工作量。

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

上面讲的是通用框架，但真实项目里没有标准答案。同一个方法放在不同组织、不同合同结构下，效果差别很大。这一章讲三种常见情况下的取舍逻辑。

1. 强矩阵与弱矩阵，做法完全不同

强矩阵环境下，项目经理对资源有实际调配权，范围管理可以做得比较硬：范围不确认不开工，变更不评估不排期。因为你有资源抓手，硬规则能落地。

弱矩阵环境下，你既要对交付结果负责，又没有直接管理权限，硬规则的后果往往是自己被孤立，同时还背交付责任。这时候的取舍是：把硬规则换成书面共识。不追求"不确认就不开工"，而是追求"每一次口头同意都立刻转成书面记录并抄送关键人"。共识不需要权力支撑，只需要记录支撑。

还有一个弱矩阵下的实用技巧：把范围争议的裁决权推给业务负责人，而不是自己扛。你的角色是提供影响评估和备选方案，让业务负责人从业务价值角度做取舍。这样既避免了对抗，又让决策有了责任主体。

2. 固定总价合同与人天合同，关注点不同

固定总价合同下，范围边界直接等于利润边界，任何未经评估的增加都在消耗你的毛利。这类合同的范围管理必须前置，合同签订前就要把除外责任写到极致，执行期严格走三级变更分级。

人天合同下，范围增加的财务压力小，但真正的风险是项目无限延长、团队无法释放、客户满意度下降。这类合同管理的重点不是拒绝变更，而是控制变更节奏，把变更集中到固定窗口处理，避免每周都插入新需求导致节奏碎裂。

3. 敏捷迭代与阶段交付，基线定义不同

敏捷项目的范围基线不在功能清单，而在产品目标和迭代目标。你不需要冻结功能列表，但需要冻结每个迭代的目标和验收口径。迭代内插入新需求，本质上是打断迭代节奏，代价往往比多做一个功能更大。

阶段交付项目则相反，范围基线就是阶段交付物清单，变更必须走正式流程并重新基线化。判断标准很简单：如果范围变化会改变已承诺的交付时间或金额，就必须走正式变更；如果只改变实现顺序，可以在迭代内调整。

三种情况下的策略差异，可以放在同一组维度上比较，方便快速定位自己项目该往哪个方向调整。

十、行动清单：今天就能做的三件事

方法看完了，如果不能落到今天的具体动作上，大概率不会被执行。我建议从下面三件事开始，它们的共同点是启动成本低、当天能完成、效果可感知。

1. 今天就写一页纸范围说明，从"不做什么"开始写

不要从项目目标开始写，那部分最熟悉也最容易写空。先写除外责任，因为那是你最需要别人确认、也最容易漏掉的部分。写完除外责任再补边界和验收标准，目标放最后。

写完不要自己存着，当天发给关键干系人，请他们确认"哪一条你们有异议"。有异议的地方就是后期争议点，越早暴露越好。

2. 今天就建变更登记表，并且定下"不登记不排期"的规则

表的结构直接参考第六章的字段，先不用追求字段齐全，至少要有编号、提出人、内容、影响、决策五项。规则要公开说一次：所有需求无论大小，先进登记表，再进排期。

推行初期大概率会有人绕过你直接找开发。这时候的处理方式很重要，不要指责开发，而是把已经做的工作补录进登记表，并在周会上说明补录原因。坚持两到三周，规则就能立起来。

3. 本周内开一次基线确认会，当场完成确认动作

会议时间不用长，一小时足够。议程固定三项：逐条过除外责任、逐条过验收标准、明确变更审批路径。确认动作当场完成，会上没确认的条目单独标记并约定截止时间。

这三件事做完，你会发现变化不是立竿见影的，但一两周后会出现一个明显信号：提出需求的人开始先问"这个算不算在范围内"。

最后回到我最初那个 180 人天变成 320 人天的项目。真正的教训不是"客户太能改"，而是我当时没有意识到，项目经理对范围的责任，不是把门关死，而是给每一扇门都装上一个能看见价格的标牌。门可以开，但要有人知道开这扇门的代价是什么。当代价可见，绝大多数关于范围的争论会自己找到答案。

如果你现在手上正有一个范围已经有些模糊的项目，别急着重新谈判，先从写一份除外责任清单开始。那是最划算的一步。