需求与范围

产品方向回答「做什么、为什么做」（见用户研究与需求洞察、需求分析与 PRD）；本篇从项目执行角度回答：一旦开始做，怎么界定「这次做多少、边界在哪、变了怎么办、怎样才算做完」。核心矛盾是——既要拥抱变化，又不能任范围失控。

项目范围 ≠ 产品范围

概念	含义	管控主体
产品范围	产品「应该具备」的功能集合	产品负责人长期演进
项目范围	本次交付承诺「要做」的功能 + 非功能 + 约束	项目经理/团队与干系人共担

范围蔓延（scope creep）大多不是新增需求本身，而是新增需求没有走流程、没有同步影响评估就混进了承诺。

范围界定：从目标到可执行

1. 先有验收目标，再有功能

每个项目范围都该能回答：「做完后，用什么客观标准判断成功？」——对应到功能层面，就是每条需求的验收标准（Given-When-Then 模板见PRD）。

2. 工作分解结构（WBS）

把交付物逐层拆到可估算、可指派、可验收的叶子任务：

层级	内容	粒度
L1	里程碑/交付物	可评审
L2	功能模块	可演示
L3	任务包	可估算（1~数天）

拆 WBS 三原则：100% 覆盖（没有遗漏项）、不重复（一项只归一个父级）、以交付物为导向（不写「研究研究」，写「产出一份架构方案」）。

3. 范围基线（Baseline）

里程碑节点把 WBS + 估算 + 排期一起冻结为范围基线。基线是变更管理的参照物：基线之后的一切改动都需走变更流程，而不是「顺手就加了」。

需求优先级：项目内的取舍

产品层面的排序方法（MoSCoW、WSJF 等）见需求分析与 PRD。项目层面补充两点：

1. 从「都想做」到「这轮做」：把优先级翻译成可承诺范围时，用「必须（Must）/ 应（Should）/ 可（Could）/ 不（Won't）」四类，Won't 是明确写出来的——不写清「这轮不做」，范围蔓延就会钻空子；
2. 成本意识进入排序：价值接近的两项，先做工期短、风险低的（见排期与进度的估算）；价值高但五年后才有用的，通常是干扰项。

变更管理：一套 4 步流程

步骤	动作	产出
1 提交	任何干系人提出变更请求（CR），写清背景与期望	变更请求单
2 评估	评估对范围、工期、成本、质量、风险的影响	影响分析表
3 决策	变更控制委员会（或 PO + 关键干系人）决定 接受 / 拒绝 / 延期	决策记录
4 落地	接受则更新基线并通知全员；拒绝则回复理由	基线 v2 + 通知

区分大小变更：UI 文案等小事走「快速通道」当天消化；牵动范围基线/关键路径的大变更才开评审会。让所有变更都挤同一流程，团队会绕过流程。

变更管理的产品形态是版本规划：一个大变更集中起来放进下个版本做，而不是在迭代中零散塞入——与 PRD 的版本范围口径对齐。

验收标准与完成定义（DoD）

层级	关注	示例
需求级	这条功能怎么算「对」	空态、异常态、权限态都覆盖（见交互与信息架构的状态设计）
迭代级（DoD）	功能怎么算「完成」	代码合入 + 测试通过 + 文档更新 + 可发布
项目级	阶段怎么算「交付」	验收目标达成 + 干系人确认

DoD 要成文、全员一致，并在评审时逐条核对。「代码写完了」但没测、没文档、没验证，只能算 80%。

常见坑速查

坑	表现	应对
验收标准模糊	评审时凭感觉「我觉得可以了」	写需求时就把 Given-When-Then 写完
变更不记账	口头答应改一点，月底发现承诺全乱	一切变更走 CR，哪怕最后只是记一笔
范围只增不减	加需求容易，删需求没人提	每轮评审问「为保交付，能砍什么」
镀金（Gold-plating）	开发者自行加「顺手优化」超出承诺	DoD 之外的新增都算变更，先问再改
100% 范围冻结	上线前禁止一切改动，反而拖垮质量	用快速通道兜底小改，评审会兜底大改

检查清单

• [ ] 项目范围与产品范围已区分，书面记录了本次承诺边界
• [ ] WBS 满足 100% 覆盖、不重复、可验收三原则
• [ ] 关键节点已冻结范围基线，基线版本有记录
• [ ] 变更流程已落地：模板、影响评估表、决策人、通知机制齐全
• [ ] Must/Should/Could/Won't 四类明确，Won't 有据可查
• [ ] 需求级 / 迭代级 / 项目级验收标准全部成文
• [ ] 每次评审按 DoD 逐条核对，而不凭感觉

相关：方法论与流程 · 排期与进度 · 需求分析见产品方向