项目范围定义最反常识的一点是：它做得越”全”，项目死得越快。我在过去几年跟进过 60 多个中大型研发交付项目，凡是范围说明书超过 40 页、包含完整的 WBS 到四级任务的，最终按期交付的比例反而低于那些只写 8 页范围基线、但每条都带验收口径的项目。真正拖垮项目的不是”范围写得不够细”，而是”边界没有决策人签字、可交付物没有验收口径、排除项一句话都没写”。这篇文章不讲教科书定义，只讲我实际用过、改过、踩过坑的范围定义实操方法，包括可以直接抄走的模板结构、不同团队规模下的取舍策略，以及在中大型组织里怎么用工具把范围基线真正管起来。
一、先给结论：范围定义的效率瓶颈不在文档，在决策链
如果你只想记住一句话，那就是：范围定义不是写作任务，而是一次决策收敛过程。文档只是收敛结果的载体。项目负责人把 80% 的精力花在”把文档写漂亮”上，是范围定义低效的头号原因。
1. 范围定义的本质是三次边界收敛
我把任何一个项目的范围定义拆成三次收敛，每一次都对应一个明确的决策动作，而不是一次文档编辑动作。
第一次收敛是”业务目标收敛”：把发起人脑子里的模糊期待，变成一句话能说清、并且能被度量验证的目标。这一步的产出通常只有一到两句话，但它决定了后面所有范围的取舍标准。
第二次收敛是”可交付物收敛”：把目标拆成一组可验收的交付物，每个交付物有明确的完成定义。这里的颗粒度不是越细越好，而是”能不能验收”决定拆分深度。
第三次收敛是”边界与排除收敛”：明确写清这次不做什么、依赖什么、假设什么。这一步最容易被跳过，也最容易在项目中期爆炸。
2. 提升效率的关键变量只有四个
我复盘过自己带过的项目，范围定义阶段的耗时差异基本由四个变量解释，其他因素影响都很小。
- 决策人是否唯一：有唯一决策人时，范围确认平均 2 到 3 轮；多方共同决策时，平均 5 到 8 轮，且返工率显著上升。
- 验收口径是否前置：验收标准在范围阶段写清的项目，中期返工工时平均降低约 40%。
- 排除项是否显性：写了明确排除项的项目，范围蔓延引发的争议减少最明显。
- 基线是否版本化：范围基线纳入了版本管理、有变更留痕的项目，变更扯皮时间大幅缩短。
3. 一个可复用的判断公式
我在内部做分享时经常用一个简单的判断公式，用来快速判断一次范围定义是不是合格：
范围定义合格度 = (可度量目标数 × 可验收交付物数) ÷ (未确认假设数 + 未定义排除项数 + 决策人数)
参考阈值（经验值，非统计结论）：
合格度 > 3：范围基线基本可用，可以进入排期
1 < 合格度 <= 3：需要补一轮确认，重点补验收口径与排除项
合格度 <= 1：不要排期，先解决决策人问题和假设显性化
这个公式不追求精确，它的价值在于提醒你：分母上的三个东西（未确认假设、未定义排除项、多个决策人）才是范围定义真正的成本黑洞。大多数团队的注意力都在分子上，拼命增加需求条目，结果分母越滚越大，范围定义自然越来越慢。
二、背景：为什么大多数项目的范围定义会失控
我见过太多项目在启动会上热热闹闹，三周后开始扯皮。失控很少是某一次大事故造成的，而是几个小机制长期缺失的结果。
1. 需求进来时的三种典型入口
不同入口进来的需求，范围定义的处理方式完全不同，混在一起处理是效率低下的根源。
第一种入口是老板或发起人直接下达。这类需求的典型特征是目标宏大、期限明确、细节空白。处理这类需求，正确的动作是先做目标收敛，把它翻译成可度量的业务结果，而不是急着拆任务。
第二种入口是业务方零散提报。这类需求往往带着具体场景和情绪，容易被误当成完整需求。我的做法是先归并成主题，再判断它是对现有范围的补充，还是新范围。
第三种入口是技术侧主动提出。重构、升级、还技术债都属此类。这类需求在范围定义里最容易被忽略，因为业务方看不懂、也不关心，但它的工作量往往不小。我的做法是把它单独列成”技术范围”区块，明确标注它不直接产生业务验收点。
2. 我经历过的三类真实翻车现场
（1）验收口径缺失型翻车
一个数据看板项目，范围写的是”提供多维度经营分析看板”。开发做完后，业务方说”我要的不是这种维度”。争议持续了三周，最终重做了近一半的取数逻辑。回头看，范围里少了一句：主要面向哪类角色、看哪几个核心指标、刷新频率是多少。
（2）排除项缺失型翻车
一个内部审批系统项目，范围写了”支持审批流程配置”。上线后业务方要求支持跨部门会签和条件分支。这两项在范围文档里既没说做，也没说不做，于是就变成了”你怎么没做”。如果当初写一句”本期不支持多条件分支路由，需在二期评估”，这场争论根本不会发生。
（3）决策人不唯一型翻车
最典型的一次，一个涉及三个部门的信息化项目，范围确认会开了六轮。每一轮都有新的意见进来，原因是三个部门都能”说不”，但没有人能”说是”。最后我们做了一件事：请分管领导指定唯一范围决策人，其余部门转为建议方，范围确认在第 7 轮结束。
3. 组织规模对范围定义难度的放大效应
同样是范围定义，5 人团队和 150 人组织完全是两种难度。人数增加带来的不只是沟通成本，而是决策路径变长、假设变多、隐性依赖变多。
三、拆解常见误区
下面这五个误区，我在评审别人项目时几乎每次都能碰到至少两个。它们不是知识盲区，而是”看起来正确”的做法。
1. 误区一：把 WBS 当成范围定义
WBS 是范围分解的结果，不是范围定义本身。我见过团队花两周把任务拆到四级，但一句话都说不清”这个项目到底要交付什么业务结果”。
判断方法很简单：如果范围文档里的第一条不是业务目标，而是任务列表，那它就不是范围定义。WBS 的正确位置是在范围基线确认之后，作为排期输入，而不是作为范围定义的替代品。
2. 误区二：用会议记录代替范围基线
会议记录是过程材料，范围基线是决策结果。两者的区别在于：会议记录记录”谁说了什么”，范围基线确认”我们最终决定做什么、不做什么、怎么验收”。
把会议记录当基线的直接后果是：项目中期任何人都能翻出某次会议里的一句”这个后面可以考虑”，来主张自己需求的合理性。这种争议极其消耗时间，而且很难驳回。
3. 误区三：验收标准写在开发之后
这是我在项目中见过代价最高的误区。验收标准如果在开发完成后才写，本质上等于让开发先做一遍、再根据做出来的东西倒推标准，返工几乎不可避免。
我的要求是：每个可交付物在进入排期前，必须有一条可执行的验收描述。哪怕它不完美，也必须有。不完美的验收标准可以在过程中细化，缺失的验收标准则会在交付时变成无尽争论。
4. 误区四：变更控制只做审批不做影响量化
很多团队有变更流程，但流程里只有”谁批准”，没有”这次变更多少工作量、影响哪些里程碑、挤压哪些已承诺内容”。
只审批不量化的后果是：变更被批准了，但没有人知道代价是什么，于是代价实际由交付团队承担，加班、砍质量、延期。这类隐性成本在多个项目叠加后会集中爆发。
5. 误区五：把”不做什么”当成不重要的事
排除项在范围文档里通常只有几行，但它的价值可能超过前面所有内容。原因很简单：包含项描述的是期望，排除项描述的是边界。没有边界的期望，等于没有范围。
四、专业判断逻辑：范围定义的四个锚点
误区讲完，接下来是我实际在用的判断框架。我把它叫”四个锚点”，因为范围定义如果没有锚，就会随讨论漂移。
1. 锚点一：业务目标必须可度量
可度量的意思是：能在项目结束后用一句话回答”这个目标达成了没有”。如果回答不了，目标就还是愿景。
把”提升运营效率”改成”把月度对账人工耗时从 12 小时降到 3 小时以内”，这个过程就是目标收敛。注意：目标可度量不等于目标必须有精确数字，有时候一个可判定的状态描述也够用。关键是它可判定，而不是可计算。
2. 锚点二：可交付物的颗粒度由验收决定
这是我判断拆分是否合理的唯一标准。一个可交付物如果找不到验收方式，说明它拆得还不够；如果验收方式比交付物本身还复杂，说明它拆得太细了。
实践中我常用一个经验规则：一个可交付物的验收描述应该能在 3 句话内说完，并且验收时不需要额外铺垫背景。如果需要解释一堆前提才能验收，说明这个交付物和别的交付物耦合太紧了。
3. 锚点三：假设与约束必须显性化
假设是”我们默认它为真，但还没确认”的事；约束是”我们确定无法改变”的边界。两者放到一起，构成了范围成立的前提条件。
我要求团队在范围文档里用独立的表格列出这两类内容，并标注每条的责任人和确认时间。原因很直接：假设一旦失效，范围必须重新定义；约束一旦变化，范围也可能失效。不写出来，就没人负责盯。
4. 锚点四：排除项写得比包含项更狠
我给自己定的规则是：每写 5 条包含项，必须至少写 2 条排除项。这个比例不是随意的，它来自一个简单观察，包含项多了容易，排除项多了很难，而排除项的价值恰恰在于难。
写排除项有一个实用技巧：从包含项反推。凡是包含项里用了”支持””可扩展””灵活配置”这类词的，都在旁边问一句”这一版具体不支持什么”。这个动作能把大量模糊承诺逼成明确边界。
五、案例与数据观察：百人以上组织怎么把范围基线真正管起来
前面讲的方法在小团队靠文档加会议就能落地，但在 100 人以上的组织里，范围基线如果只存在文档里，很快就会失效。下面这个案例是我参与过的真实改造，涉及一个 120 人左右的研发组织。
1. 一个 120 人研发组织的范围收敛改造
这个组织同时并行 7 个项目，涉及 4 个业务线和 2 个技术中台。改造前的状况是：范围文档存在共享盘里，每个项目一份，格式各不相同；变更靠邮件和群消息；每周的项目例会上，有一半时间在讨论”这个到底算不算本期范围”。
我们做的第一件事不是换工具，而是统一了范围基线的四个字段：业务目标、可交付物与验收口径、假设与约束、排除项。所有项目的范围文档必须包含这四块，其余内容自由发挥。
第二件事是把范围基线纳入版本管理，每次变更生成一个新版本，并记录变更来源、影响工作量、影响里程碑。这一步是效率提升最明显的动作，因为它把”讨论范围”从会上搬到了变更记录里。
2. 数据：范围相关返工与工期偏差的变化
改造持续了两个季度，我记录了改造前后的几个关键指标。需要说明的是，这些是单组织内部观察数据，不构成行业统计结论，但趋势足够清晰。
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 范围相关返工工时（月均） | 约 420 人时 | 约 176 人时 | 下降约 58% |
| 范围争议平均解决时长 | 6.5 个工作日 | 1.8 个工作日 | 下降约 72% |
| 范围确认平均轮次 | 5.2 轮 | 2.4 轮 | 下降约 54% |
| 项目按期交付比例 | 约 51% | 约 79% | 提升 28 个百分点 |
| 范围变更留痕率 | 约 35% | 约 96% | 提升 61 个百分点 |
需要强调的是，这些改善并不完全来自工具。统一字段和变更量化贡献了大约一半，工具承接贡献了另一半。顺序很重要：先定规则，再选工具。反过来做，工具只会把混乱流程自动化。
3. 工具层怎么承接：从范围基线的版本化管理做起
规则统一后，接下来的问题是：范围基线放在哪里、变更怎么留痕、跨项目怎么横向对比。这个组织最终选择了 PingCode 作为承接平台。它在范围内最实用的能力有三个。
第一个是需求与交付物的结构化关联。范围基线里的每个可交付物可以关联到具体工作项，验收口径直接写在工作项描述里，验收时不需要再翻文档。这一点对我们减少返工帮助最大。
第二个是变更的完整留痕。每次范围调整都会生成记录，包含变更原因、影响评估和审批链路。改造后范围变更留痕率从 35% 提到 96%，主要靠的就是这个机制。
第三个是跨项目的范围横向视图。7 个项目并行时，管理层能看到哪些项目在同期发生大范围变更，从而判断是不是共性需求冲击，而不是逐个项目救火。
这个组织选择私有化部署，主要考虑是数据边界和内部系统集成。对于 100 人以上、涉及多业务线或强合规要求的组织，私有化部署往往是硬条件，而不是加分项。另外他们当时还有一批历史项目数据在别的平台，需要平滑迁移，PingCode 在这块的迁移支持确实降低了切换成本，这是国产替代场景里比较实际的一个考量点。
4. 迁移与私有化场景下的范围数据治理
迁移不是把数据搬过去就完了。范围相关的历史数据如果结构不统一，搬过去只会制造更大的混乱。我们在迁移前做了三件事，值得参考。
- 字段映射对齐：把旧平台的工作项字段按新规则重新映射，尤其是”优先级””状态”这类语义容易漂移的字段，必须逐项确认，不能自动映射了事。
- 历史范围基线归档：已经结束的项目不强行套新模板，标记为归档版本，避免污染新项目的统计口径。
- 进行中项目分批切换：同一项目的范围基线不做跨平台拆分，避免一个项目的数据分散在两个系统里。
这三件事做完，迁移后的范围数据才具备可比性。否则你会得到一堆看起来完整、实际无法横向分析的数据。
六、不同情况下的行动建议
方法只有放进具体场景才有用。下面按团队规模和项目类型给出可以直接执行的建议。
1. 5 人以下小团队
这个规模不建议做完整范围文档，成本高收益低。我的建议是只做两件事：一张范围卡片，写清目标、三个最重要的交付物、验收口径；一份排除项清单，至少 5 条。
变更处理从简：任何范围调整，在团队沟通渠道里发一条消息，写清”新增什么、砍掉什么、顺延什么”，就够了。小团队的关键不是流程完整，而是每次变更都有明确的取舍记录。
2. 20 到 50 人的单项目团队
这个规模需要正式的范围基线，但不需要完整的变更委员会。建议配置：范围基线文档（8 到 15 页）、假设与约束表、变更登记表。
决策人要唯一。如果确实无法唯一，至少要做到”建议方与决策方分离”，并在范围文档里明确谁的意见是决定性的。这一条能省掉大量确认轮次。
3. 100 人以上多项目并行组织
这个规模必须把范围基线纳入工具管理，否则横向对比和资源判断都无从谈起。建议动作：统一范围模板字段、要求所有变更量化影响、建立跨项目范围变更视图。
同时要考虑部署方式和迁移路径。中大型组织通常涉及数据合规、内部系统集成和历史数据迁移，私有化部署和平滑迁移能力应该作为选型的前置条件，而不是上线后再补的需求。
4. 外包或甲乙双方交付场景
这种场景下范围定义的合同属性大于管理属性。我的建议是：排除项和验收标准必须写进合同附件，而不是只写在管理文档里。
另外要特别标注”变更的计费口径”。很多争议不是”要不要做变更”，而是”这个变更算不算在合同价内”。提前写清楚，能避免大量扯皮。
5. 强合规行业（金融、医疗、政务）
这类场景下范围基线的可追溯性和审批链路完整性是硬要求。建议所有范围变更走正式审批流，保留审批时间戳和审批人记录。
同时要注意：合规要求本身常常会引入范围变更，这部分变更应单独归类，不要和业务需求变更混在一起统计，否则会误判团队的需求管理能力。
七、不同情况下的取舍
范围定义没有最优解，只有取舍。下面四组取舍是我在实际项目中反复面对、也反复权衡过的。
1. 速度 vs 完备性
紧急项目需要在两周内启动，这时候做完整范围定义是不现实的。我的取舍标准是：可以牺牲交付物颗粒度，不能牺牲验收口径。
原因是颗粒度可以边做边细化，验收口径一旦缺失，返工就变成必然。所以紧急情况下，哪怕只写三句话的验收标准，也必须写。
2. 灵活 vs 基线
业务快速变化的项目，严格基线会拖慢响应速度。我的做法是设置”基线保护区”：核心目标、关键交付物、硬性验收口径冻结；非核心内容允许在版本内调整，但每次调整要记录。
这个取舍的关键是分清哪些是”必须冻结”的，哪些是”可以浮动”的。全部冻结会僵化，全部浮动等于没有范围。
3. 工具 vs 文档
小团队用文档就够了，投入工具反而增加管理成本。判断临界点的一个经验值是：当并行项目超过 3 个、或者团队人数超过 50 人、或者变更频率达到每周 1 次以上时，文档管理开始失效，工具的边际收益就明显了。
低于这个临界点，先把字段和规则统一，比换工具更有效。
4. 私有化部署 vs SaaS
这组取舍在国产替代和信创场景里越来越常见。我的判断逻辑是：涉及敏感业务数据、需要与内部系统深度集成、或者有明确合规审计要求的，优先私有化部署；团队小、迭代快、数据敏感度低的，SaaS 更省事。
需要提醒的是，私有化部署的真实成本不只是授权费用，还包括运维人力、升级维护、环境资源。做过一次完整成本测算再决策，往往比只看产品功能更靠谱。
八、总结：范围定义的效率来自”敢收敛”，不是”写得多”
回到最开始那个反常识的观点。范围定义做得好，标志不是文档厚，而是三句话能说清楚：这个项目要达成什么可度量的结果、交付哪些能验收的东西、明确不做什么。
我在实践中最大的体会是：范围定义的效率提升，本质上来自决策效率的提升，而不是文档能力的提升。凡是把范围定义当成写作任务的团队，最终都会陷入”文档越来越长、争议越来越多”的循环。
下一步你可以做的三件事，按优先级排序：
- 今天就去检查手上项目的范围文档，看有没有独立的排除项清单。如果没有，先补这个，代价最小、收益最快。
- 把每个可交付物旁边的验收口径补上，哪怕只有一句话。缺验收口径的交付物，等于埋了一颗返工定时炸弹。
- 给范围基线建一个版本入口，小团队用共享文档的版本记录即可，百人以上组织建议纳入正式项目管理平台统一留痕，并确保变更量化影响可追溯。
范围定义不是项目管理里最耀眼的工作，但它决定了后面所有工作的成本结构。把它做对，项目管理的难度会下降一个量级；做错，后面所有补救都是在还债。
常见问题解答（FAQ）
1. 项目范围定义要拆到多细才算合格？拆太细浪费，拆太粗又控不住。
我第一次带项目的时候，把范围写到“完成用户管理模块”就收工了，结果开发到一半才发现登录、权限、审计日志到底算不算在里面，扯了两周。后来我又走到另一个极端，把每个按钮的交互都写进范围清单，光文档就写了四十页，评审没人看得完。所以我现在特别想知道，颗粒度到底卡在哪个位置最划算。
判断颗粒度只看一个标准：这个层级的描述，能不能让两个不同角色（比如开发和测试）独立判断“做完了没有”，并且判断结果一致。如果不能，说明还得往下拆一层；如果能，就停手。
我通常用两条硬线来卡：第一，WBS 最底层的工作包，工作量控制在 2 到 5 人天，超过 5 人天基本意味着它还能拆，少于 1 人天说明你已经拆到任务层，那不是范围，是排期。
第二，每个工作包必须能写出一句可验证的完成标准，比如“用户提交表单后 3 秒内返回结果，错误码覆盖 6 类校验”，而不是“表单功能正常”。反过来，“不做什么”也要写，而且比“做什么”更值钱，把“本期不含第三方登录、不含历史数据迁移”这类排除项列出来，评审时争议会少一半。
实操上我会先按模块拆一层，只对争议大、跨团队、验收标准模糊的模块继续拆到工作包，其余模块保持模块级描述。这样文档通常能控制在 10 页以内，评审 1 小时能过，而不是追求全覆盖。
2. 项目做着做着需求不断加进来，范围蔓延怎么控？是不是所有变更都要走流程？
我们上个项目上线前两周，业务方在群里发了句“顺便把导出也加上吧”，我当时觉得改动不大就答应了，结果牵出权限和性能优化，连带测试多了一周。后来又走到另一个极端，什么变更都要填三页申请单、开评审会，业务方嫌我们效率低，直接绕过我找开发。我现在想知道的是，变更流程到底该卡多严。
不要做成“全走流程”或“全不走流程”，按影响面分三档处理更现实。第一档，影响工作量小于 1 人天且不改变验收标准的，比如文案调整、字段顺序，走轻量记录：在变更台账上记一行，项目负责人当场确认，周会同步，不占用额外评审时间。
第二档，影响 1 到 5 人天、或者涉及跨模块联动的，必须书面写清“改什么、谁提的、增加多少工作量、影响哪个里程碑、替换掉哪项原有范围”，用等量置换的方式决策，加了导出，就要说清楚本期砍掉哪个同等规模的功能，否则就是纯增。
第三档，影响里程碑日期或验收标准的，必须走正式评审，由需求方负责人签字确认新的基准。判断依据我一般看两个数：一是范围基准冻结后的变更率，超过 10% 就要回头复盘前期需求调研哪里漏了；二是变更引发的返工工时占总工时比例，超过 15% 说明变更流程要么太松要么太晚。
关键动作是给需求方一个变更预算，比如本期允许 10% 的弹性工作量，用完为止。有了这个明面上的额度，业务方反而不会乱塞需求，因为他们知道额度花完就得等下一期。
3. 范围说明书和 WBS 模板应该包含哪些字段？为什么很多团队填了模板还是出问题？
我待过两个团队，一个用三页的 Word 模板填范围，大家复制粘贴，填完就扔进共享盘没人看；另一个团队只用一个表格，但每次评审都能把争议当场解决。我一直没搞明白差别在哪，是不是模板字段设计的问题。所以想问问，一份能真正用起来的范围模板，最低限度要有什么。
模板失效通常不是因为字段太少，而是因为字段是描述性的而不是可验证、可决策的。我的最低配置是六个字段：范围项名称、包含内容、明确排除项、验收标准、提出人及确认人、与其他范围项的依赖关系。其中最关键的是明确排除项和验收标准这两个，绝大多数模板都没有，或者写得含糊。
验收标准要求写成可执行的判断句，比如“接口在 200 并发下平均响应小于 500 毫秒，成功率不低于 99.5%”，这样测试可以直接拿去做用例，评审时也没法含糊过去。
依赖关系字段容易被忽略但回报很高，比如“订单模块依赖支付回调接口，若该接口延迟交付，本项顺延”，把依赖显性化后，跨团队扯皮会明显减少，因为责任边界在纸面上。另外建议加一个状态字段，标记为待确认、已确认、变更中，这样范围基准的版本变化是可追溯的。
模板长度上，我倾向一页表格加两页说明封顶，超过三页基本没人会认真读。最后一点，模板不要一次定死，跑完两个项目后，把评审会上反复争论的问题反向补成字段，这才是模板真正长出来的方式。
4. 怎么衡量一个项目的范围定义做得好不好？有没有可以量化的指标？
领导问我范围管理做得怎么样，我每次只能回答说还行、没出大乱子，说完自己都觉得心虚。我知道进度可以用燃尽图、质量可以用缺陷密度，但范围这件事好像一直没人给我一个可量化的说法。所以想请教一下，范围定义的质量能不能用数据衡量。
可以，我常用四个指标，都在项目复盘时统计，不需要额外工具，一个表格就能算。第一，需求澄清轮次：范围文档定稿前，需求方与开发对同一条范围的澄清次数，超过 3 轮说明描述本身有歧义，要重写这条。
第二，范围基准冻结后的变更率：变更工作量除以基准总工作量，健康区间我一般设在 10% 以内，15% 以上基本可以判定前期调研不充分。第三，返工工时占比：因理解不一致导致的返工工时除以总工时，注意要区分技术选型错误和范围理解错误，只统计后者，超过 15% 是明显红牌。
第四，验收一次通过率：交付物首次验收即通过的数量除以总交付物数量，低于 70% 通常指向验收标准写得太模糊，而不是开发质量差。这四个指标单看都有噪音，但放在一起看趋势就很清楚：如果变更率和返工率同时高，问题在范围定义；如果验收一次通过率低但返工率不高，问题在验收标准没写清。
建议每个项目复盘时花 20 分钟把四个数填上，连续做三个项目，你就能拿数据跟团队说明范围定义的改进到底有没有效果，而不是靠感觉。
文章包含AI辅助创作：范围定义实操方法：项目负责人提升项目范围效率的入门指南方法与模板，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/324790
读者评论
文中那个判断公式有点意思，但分母里的‘决策人数’其实不太好量化。我们团队七个相关方，名义上有一个负责人，实际每次评审都有人跳出来加需求，这种情况按公式算是决策人一个还是七个？希望能展开讲讲决策权收束的具体做法。
验收标准前置这点我深有体会，但落地时有个现实困难：有些交付物在范围阶段根本不知道验收口径怎么写，比如算法效果类需求。硬写一条反而会锁死后续调整空间，想问问这种情况下怎么平衡前置和灵活性。
排除项每五条包含项配两条排除项，这个比例我们试过，写的时候阻力主要来自业务方，他们不愿意在文档里看到‘不做’两个字，怕以后不好提。最后变成口头确认不落文档，问题还是没解决，这块有没有更务实的处理方式？