需求评审就写验收标准
每个需求至少写一条可核对的完成标准，写在需求单里而不是另存文档。为什么放在需求单：分开存放，开发时没人看，验收时才翻出来，往往已经对不上。做法是评审时由使用方口述标准，记录人当场写入，双方确认后生效。
开发自检
提交前按验收单自检一遍，附证据链接，未做的项写明原因。怎么做：自检不追求全过，而是让缺口提前暴露；技术负责人抽查自检记录，发现长期空白的项目，回到需求阶段重谈标准，而不是等到验收时再争吵谁理解错了。
交付前走验收单
交付前一天完成验收单填写与签字，留出整改时间。为什么提前：当天验收等于没有整改窗口，只能二选一通过或延期。做法是把验收单拆成必检项与抽检项，必检项不过不交付，抽检项可在观察期内补齐并注明责任人。
每月抽审一次
每月抽两个已验收项目，回看证据是否完整、标准是否被临时放宽。为什么抽审：验收一旦松一次，后面每次都会被引用为例外。做法是由不参与该项目的人抽审，结论写进月度质量记录，作为下个月的改进依据。
把验收记录变成资产
验收标准与证据归档，成为同类项目的模板与培训材料。边界：归档记录只用于质量与维护，不用于个人考核，否则填写人会倾向美化证据，反而失去参考价值，也会污染后续项目的标准制定。
适用与不适用
适合谁
- 有多个项目并行、验收质量参差的团队
- 交付前经常加班补材料的产品与工程团队
- 想把质量要求前置到需求阶段的管理者
不适合谁
- 只做一次性交付、不准备复用的项目组
- 没有固定评审流程、也不愿补记录的组织
典型场景
一家软件公司的交付团队把验收标准写进需求单，开发提交前自检并附截图，交付前一天走验收单。质量负责人每月抽两个项目回看证据，发现一个项目的标准被临时放宽，于是在月度会上把这类情况列为必检项；三个月后，交付当天的争议明显减少，返工也集中到开发阶段。
可执行步骤
- 需求评审时由使用方口述完成标准，记录人当场写入需求单。双方确认后才进入开发。标准至少要有一条可核对的描述。
- 开发提交前按验收单自检，附证据链接与未完成原因。技术负责人抽查自检记录。长期空白的需求回到评审阶段重谈。
- 交付前一天完成验收单填写与签字。必检项不通过不交付。抽检项写明观察期与补齐时间。
- 每月抽两个已验收项目回看证据与标准执行情况。由不参与该项目的人抽审。结论写进月度质量记录。
- 把验收标准与证据归档，整理成同类项目的模板。培训新人时直接用作案例。归档只用于质量与维护。
常见坑
- 验收标准只写在邮件里，开发时没人看。交付时才发现理解不一致，只能返工。把标准放进需求单，是最低成本的对齐方式。
- 自检记录长期空白，技术负责人也不抽查。缺口全留到交付前，整改时间被压缩。抽查不必频繁，但要让团队知道会被看。
- 验收单当天才填，没有整改窗口。结果是带病通过或整体延期。提前一天走单，是给双方留余地，而不是拖延。
自检与验收清单
- 需求单里是否写了可核对的完成标准与不做的部分
- 开发提交前是否自检并附证据链接与未完成原因
- 交付前一天是否完成验收单签字并留出整改时间
- 每月是否抽审两个项目，结论是否写进质量记录
- 验收材料是否归档，并用作同类项目的模板与培训案例
常见问题
小团队也要每月抽审吗
可以简化为一季度一次、抽一个项目。抽审的意义在于让标准被真正执行，而不是增加报表；小团队由负责人自己看两份材料、问两个问题即可，关键是形成会被检查的预期。
验收标准写太细会不会影响效率
只写关键项就不会。把数据准确、权限边界、可用性三项写细，其余用可接受范围描述；标准过细会让评审时间变长，过粗等于没写，取中的做法是先写三条再逐步补。
和客户验收冲突怎么办
先按合同与客户确认的标准执行，内部标准作为补充。若内部标准更严，提前与客户沟通说明理由；若客户标准更松，也不要在未确认的情况下自行放宽，避免后续维护责任不清。