第15章 交付闭环
前三部分分别解决了需求、资源和成本。现在进入真正的产品交付：不是「做出来」，而是让一个结果被验证、被验收、被付款。本章把第01章公式二展开成一套可执行闭环。第16章会继续讲 MVP 与质量底线。
15.1 结论先行：交付不是做完，而是四环闭合
交付闭环只有四个词：范围、实现、验证、验收。
text
交付闭环 = 范围 → 实现 → 验证 → 验收这不是口号，是一条硬流程。缺「范围」，你不知道做什么；缺「实现」，你没有结果；缺「验证」，你不知道对不对；缺「验收」，你拿不到确认和钱。
铁律：做完不等于交付，验收才等于交付。
15.2 四环是什么：输入、输出与验收
| 环节 | 输入 | 输出 | 通过标准 |
|---|---|---|---|
| 范围 | 需求文档 | 范围清单/非目标 | 对方确认 |
| 实现 | 范围清单 | 可运行产物 | 核心路径跑通 |
| 验证 | 验收标准 | 测试记录/截图/报告 | 标准逐条通过 |
| 验收 | 验证记录 | 确认/付款/上线 | 对方书面确认 |
交付闭环不是线性的死流程，它有反馈：验证不过回实现，验收不过回范围或变更。
text
范围 ──→ 实现 ──→ 验证 ──→ 验收
↑ │ │ │
└──变更────┴──修复──┴──确认──┘15.3 范围：验收标准先于实现
范围不是一句「做个网站」。范围要包含：核心目标、必须功能、非目标、验收标准。
text
范围确认最小模板
项目目标：
必须交付：
明确不做：
验收标准：
变更规则：
付款节点：如果没有验收标准，你实现时只能猜；客户验收时也只能凭感觉。凭感觉就会扯皮。
15.4 实现：只实现被确认的范围
实现阶段最容易被「顺手做一下」污染。客户顺手提，你顺手做，最后项目范围爆炸。
铁律：任何未写进范围的功能，都不是优化，是变更。
实现阶段的动作：
- 按范围拆任务。
- 每完成一项就对应一条验收标准。
- 遇到新增要求，进入变更流程，不直接做。
15.5 验证：你先替客户验一遍
验证不是等客户发现 bug。你要在交付前自己跑一遍验收标准。
text
验证记录模板
验收项：
测试步骤：
预期结果：
实际结果：
证据：截图/日志/链接
结论：通过 / 未通过验证的目标是让验收变成确认，而不是让客户当测试员。
15.6 验收：闭环的商业终点
验收必须留下记录：邮件、聊天确认、表单、付款截图、上线链接。没有记录，就没有闭环。
| 验收方式 | 适用场景 | 风险 |
|---|---|---|
| 聊天确认 | 小项目 | 容易丢失 |
| 验收单 | 中等项目 | 需要客户配合 |
| 里程碑付款 | 分阶段项目 | 要提前约定 |
| 上线确认 | 网站/系统 | 上线不等于满意 |
15.7 实战：交付闭环看板
text
项目名称：
[范围]
- [ ] 需求文档确认
- [ ] 非目标确认
- [ ] 验收标准确认
[实现]
- [ ] 核心功能1
- [ ] 核心功能2
- [ ] 部署/交付环境
[验证]
- [ ] 验收项1通过
- [ ] 验收项2通过
- [ ] 失败项已修复
[验收]
- [ ] 客户确认
- [ ] 尾款/上线/归档
- [ ] 复盘沉淀资产验证标准：看板四列没有未完成项，项目才算交付完成。
15.8 失败边界：四种断环
死法一：范围漂移
客户不断加功能，你不断做。对抗：任何新增都写进变更单。
死法二：实现主义
只顾写代码，不顾验收。对抗：每项任务必须绑定验收标准。
死法三：只测 happy path
只测最顺利路径，真实用户一用就崩。对抗：至少覆盖正常、异常、空数据三类路径。
死法四：不做验收
交付后不确认，尾款拖延。对抗：上线/交付必须绑定验收确认。
红线边界
生产环境、客户数据、付款节点、合同范围，不能口头改。必须留记录。
15.9 小结 / 核心心法
交付闭环的目的，不是让你显得专业，而是让项目不烂尾、结果可验证、收入可确认。
- 交付闭环由范围、实现、验证、验收四环组成。
- 验收标准必须先于实现。
- 验证是你先替客户跑一遍。
- 验收必须留下记录。
执行清单：
- [ ] 项目是否有范围清单？
- [ ] 每个功能是否绑定验收标准？
- [ ] 交付前是否自己验证？
- [ ] 是否拿到验收确认？
上一章：第14章 成本与预算 下一章：第16章 MVP 与质量底线