承接上一篇《收产品输入》的需求签收环节。签收不代表范围锁定，如果只做核对表勾选、不做书面固化，项目中后期一定会出现范围蔓延、验收扯皮、UAT 翻车。
本文聚焦 PM 落地动作：把口头需求、零散交付、签收变更，统一收敛为可拆解、可测试、可验收的 《范围说明 V1》，解决「范围模糊、验收靠感觉、问题靠口头」的项目通病。
一、核心痛点：为什么验收总翻车？
中小团队常见场景：7～8 人项目组，产品对外对接需求，PM 对内控进度、质量、范围，兼任项目组长。
典型翻车链路：
签收核对表已勾 ✅ → 范围只写「优化体验、提升交互」→ WBS 只能写「开发80%」→ UAT 验收全是「不是我要的」。
根源只有一句话：
验收不能是主观感受，必须是可勾选、可核验的客观条目。
-
体验良好：里程碑永远绿，验收永远红，永远可以再优化
-
可测可勾：逐条通过/不通过，无歧义、无脑补、无追加范围
二、各角色分工（V1 定稿前置共识）
-
PM：牵头范围评审、控流程、定版本、锁争议、管变更
-
需求：主笔范围条文、Demo、场景描述
-
开发：梳理边界、依赖、接口、超章程内容
-
测试：校验可测性、整改模糊 AC、确认数据/环境/权限
变更分级沿用《执行骨架》，本文只讲 PM 落地交付标准与评审流程。
三、PM 本环节唯一核心产出：范围说明 V1
1、文档完整组成
一份定稿 V1 必须包含：
本期做啥（明确落地范围）
本期不做啥（硬性边界，防蔓延）
依赖与假设（环境/接口/数据前置）
Demo/原型属性（区分内部预览/客户可见、非最终交付）
开放问题（未决不进范围）
可测验收标准表 AC
多方确认栏（需求/测试/PM/发起人知悉）
2、联动规则：签收变更必须入 V1
签收环节产生的所有变更，必须写入 V1 或附链接，禁止定稿文档与签收记录无声不一致。
3、V1 定稿准入标准（缺一不可）
-
需求、测试已书面确认
-
本期不做内容完整、明确、无留白
-
所有 AC 可量化、可自测、可勾选
满足以上条件，才允许进入下一阶段「拆 WBS 与 DoD」。
补充规则：
-
已有 charter 范围也必须评审，不能只抄章程跳过会议
-
签收为 charter「待确认」状态，必须发起人书面定版后，才可标记 V1 定稿
四、标准范围评审会议（60～90min）
1、会前准备
对齐三份资料：签收记录 + charter + 产品交件
会前下发：V0 草案 + 空白验收表
会议目标：当场定 V1，不留 V0.9 过渡版
2、参会人员（必到）
需求、PM、开发/技术、测试
发起人会后邮件抄送知悉
3、会议固定流程（可直接照搬落地）
|
1 |
10′ |
对照签收记录，排查本期做/不做是否漏项 |
需求 |
|
2 |
20′ |
逐条需求转验收条目；明确 Demo 仅参考、非最终交付 |
需求+测试 |
|
3 |
15′ |
梳理依赖、接口、环境；超 charter 范围统一标红 |
开发 |
|
4 |
15′ |
明确数据/权限/边界；当场改写所有不可测 AC |
测试 |
|
5 |
10′ |
敲定本期不做清单；争议全部进开放问题，禁止口头扩范围 |
PM |
|
6 |
5′ |
定版本、确认人、后续变更提报规则 |
PM |
4、会后闭环（24h 内）
PM 发布正式 V1（范围+不做+验收表）
只收到不算确认：需求、测试必须明确回复「确认 V1」或列出修改项，才算书面闭环。
五、可直接复制：范围说明 V1 完整模板
【项目】……
【版本】V1
【日期】……
【基于】产品交接核对记录（日期：……）
一、本期做啥
1. ……
2. ……
二、本期不做（至少2～3条，对齐 charter/签收）
1. ……
2. ……
三、依赖与假设
– 系统/接口：……
– 环境/数据：……
– 假设条件：……
四、Demo / 原型
链接：……
属性：☐ 仅内部 ☐ 可给客户看（非最终交付）
五、开放问题（未决 ≠ 纳入范围）
六、验收标准 AC（可勾选、可自测）
|
AC-01 |
订单导出 |
列表支持导出 Excel |
文件可正常打开；列与范围一致；1万条数据5分钟内导出完成 |
UAT |
|
AC-02 |
…… |
…… |
……（可独立判断通过/不通过） |
内部 |
【确认】需求：… | PM：… | 测试：… | 发起人知悉：…
（超 charter、中大型变更：需发起人书面确认后，方可标记 V1 定稿）
六、PM 定稿四问（逐条自检）
每一条「本期做啥」是否都有对应 AC？
AC 中是否还有「待产品确定」模糊项？有则进开放问题，不默认入范围。
开发能否按 AC 编号拆解 DoD 任务？
测试不看用例，只看 AC 能否明确测什么？
产品坚持写「体验良好」等主观描述：PM 不妥协，直接升级发起人，要求改为可测语句。
七、需求变更分级与 PM 动作
变更链路：提出 → PM+需求评估 → 分级审批 → 更新 V1.x + 验收表 + WBS
|
小变更 |
不动里程碑、不动合同 |
组长+需求 |
更新 V1.x，完成确认 |
|
中变更 |
影响工期、工作量上涨 |
发起人 |
附影响说明，升级上报 |
|
大变更 |
涉及合同/报价/对外新承诺 |
项管会 |
严禁先干后批 |
PM 红线：
-
不许自判小变更绕过发起人
-
不许只改代码、不改范围文档
八、PM 必做 / 严禁 / 升级场景 & 漏洞对策
1、PM 必须做
-
签收四件套+变更全部落进 V1，有据可查
-
不可测 AC 当场整改、去主观化
-
超 charter 内容，必须发起人书面确认再定稿
-
开放问题明确负责人，超期标记阻塞
-
争议及时升级，不擅自兜底
2、PM 坚决不做
-
不为讨好客户删除「本期不做」
-
无测试参会不定验收标准
-
用 Demo 替代正式 AC 验收表
-
V1 未定稿就对外承诺里程碑
-
中大变更未批先开发
3、常见漏洞与对策
|
口头微调范围不用备案 |
所有微调一律更新 V1.x，走变更流程 |
|
AC 写了但依旧不可测 |
重写「通过标准」，删除所有形容词，只留量化结果 |
|
V0.9 过渡、后续补不做清单 |
不做清单不齐 = V1 未定稿，禁止进入迭代 |
|
仅 PM 签字确认 |
必须需求+测试书面确认，缺一不可 |
|
开放问题先做再说 |
未关闭问题不进范围、不进验收 |
|
评审后产品私自改口径 |
不认口头变更，必须走正式 V1.x 更新 |
九、省略本环节的直接后果
|
验收不做可测化 |
UAT 等于二次需求梳理，大面积返工 |
|
不写本期不做 |
范围持续口头膨胀，工期失控 |
|
未定稿 V1 就排 WBS |
任务只有「开发中」，无验收节点、无质量标准 |
|
Demo 不标交付属性 |
客户把原型当终版验收，纠纷不断 |
十、落地实操建议
时效门禁：签收完成后 3 个工作日内，完成评审、改 AC、发 V1、收书面确认。
验收分类：验收表备注列统一标注「内部验收 / UAT 验收」，一次性定死，杜绝后期扯皮。
结语
锁范围与验收的本质：把签收的模糊共识，改成纸面铁规则。
让验收 可勾、可测、可落地，让不做范围 写死、锁定、不蔓延。
V1 是 WBS 拆解的唯一合法输入，此处模糊，后续进度、质量、变更、返工一定会连环爆雷。
下一篇预告：《拆 WBS 与 DoD》
讲解：按 AC 编号拆任务、审查/联调/回归单独成行，让每一条验收标准都对应明确的交付完成定义。
标签：#项目管理 #需求管理 #范围管理 #验收规范 #PM落地方法论 #软件开发流程
