研发交付验收要回答的是“这次交付是否按约定完成、能否确认接收”。可执行的主线是：定标准—备证据—逐项核验—处置差异—签署确认—归档追溯。适用前提是验收范围、通过标准和证据要求已在交付前与需求方确认；范围之外的内容、项目整体结项和上线后的价值评估不在本文展开。
要点总览（TL;DR）
- 研发交付验收按“定标准—备证据—逐项核验—处置差异—签署确认—归档追溯”六步推进，验收方案须在交付前与需求方确认。
- 验收项按功能、性能、兼容、文档、部署分类，每项写明通过标准、证据要求和提交人，避免现场临时补材料。
- 单项判定分通过、有条件通过、不通过；不通过项按缺陷、范围变更、标准理解不一致三类分别走修复复验、变更评审、双方澄清。
- 验收结论由需求方与交付方共同签署，写明范围、结论、遗留项、签署人和日期，并与需求、版本、缺陷记录关联归档。
- 验收结束的判断标准是：验收项全部有结论、遗留项已登记并有责任人和期限、结论完成签署、证据与结论已关联归档。
验收前先定清楚：范围、标准与证据要求
验收现场最容易出现的分歧，是双方对“验什么、怎样算通过、拿什么证明”理解不同。把这些内容提前写进验收方案，并请需求方确认，后续核验才有统一口径。验收方案应在交付前完成确认，最迟不晚于交付方提交证据包之前。
验收范围要同时写明纳入项和排除项。纳入项按需求条目或交付模块列出；排除项写清本次不验收的内容，例如后续迭代功能、依赖外部系统的联调部分、由客户侧完成的数据初始化。范围写清楚，核验时就不会把新提出的期望临时算进本次交付。
验收项按类别拆开，每类给出可判断的通过标准：
| 验收类别 | 通过标准示例 | 证据要求 | 责任人 |
|---|---|---|---|
| 功能 | 验收范围内需求条目全部实现，关键路径操作结果符合需求描述 | 需求条目对照说明、功能演示记录或操作截图 | 交付方研发负责人 |
| 性能 | 在约定数据量和并发条件下达到约定指标 | 性能测试报告，注明测试环境与数据口径 | 测试与质量角色 |
| 兼容 | 约定的浏览器、终端或接口版本下功能可用 | 兼容性测试记录及覆盖清单 | 测试与质量角色 |
| 文档 | 部署说明、操作手册、接口说明齐全且与交付版本一致 | 文档清单及版本号 | 交付方研发负责人 |
| 部署 | 按部署说明可在目标环境完成安装启动，回滚步骤可执行 | 部署验证记录、回滚演练记录 | 交付方研发负责人 |
每一项验收都要指定证据类型和提交人。证据要求写到“谁提交、什么形式、对应哪个版本”，避免验收当天临时补材料。验收方案确认后如有调整，按变更方式记录，不口头修改。
交付方要提交哪些材料
交付方在验收前提交一套完整的证据包，验收方才能按清单核对，而不是在现场边看边找。证据包由交付方研发负责人组织准备，测试与质量角色提供测试相关材料，提交时附一份材料清单。
- 版本与构建产物标识：本次交付的版本号、构建编号、制品存放位置，确保验收对象唯一可识别，避免拿错包。
- 测试报告与缺陷清单：测试范围、执行结果、通过率；缺陷清单列明已修复项和遗留项，遗留项附处置意见，说明影响范围、规避方式和计划关闭时间。
- 部署与回滚说明：目标环境要求、安装步骤、配置项、验证方法，以及回滚触发条件和回滚步骤。
- 需求变更记录与影响说明：交付周期内发生的需求变更、变更评审结论，以及对验收范围和测试范围的影响。
证据包提交后由验收方做一次完整性检查：材料缺失或版本对不上的，先补齐再进入核验，避免核验中途反复中断。
逐项核验怎么做：核验顺序与判定规则
核验按“需求项—证据—结论”的顺序推进：先确认该验收项对应的需求描述，再核对交付方提交的证据是否覆盖该项，最后由验收方给出单项结论。顺序固定，可以减少先看演示再回头找依据造成的遗漏。
单项判定分三种：
- 通过：证据完整，结果符合通过标准，无遗留问题。
- 有条件通过：主体功能符合标准，存在不影响本次接收的遗留项，已登记责任人和关闭期限。
- 不通过：结果不符合通过标准，或证据不足以支撑结论。
判定为不通过时，要当场归类差异，后续处置路径不同：属于实现与需求不符的记为缺陷；属于验收范围需要调整的记为范围变更；属于双方对标准解释不同的记为理解不一致。归类写进记录，不停留在口头争论。
核验记录建议按统一字段登记，便于汇总和追溯：
| 字段 | 填写要求 |
|---|---|
| 验收项 | 对应需求条目编号或验收方案中的条目名称 |
| 证据 | 引用的报告、记录或演示材料及其版本 |
| 结论 | 通过、有条件通过或不通过 |
| 问题 | 差异描述及归类（缺陷、范围变更、标准理解不一致） |
| 责任人 | 该问题的跟进人及计划完成时间 |
核验记录逐项填写、当场确认，验收结束后作为签署结论的附件。记录分散在个人笔记或聊天记录里，后续追溯时很难还原判定依据。
差异怎么处置：修复、变更与澄清三条路径
未通过项按归类走三条路径，每条路径都要有明确的回流方式，验收才不会卡在争议上。
缺陷类：由交付方研发负责人排期修复，修复完成后提交新的构建版本和针对性测试记录，触发复验。复验只针对原不通过项及其关联影响范围，复验通过后更新该项结论。复验的触发条件是修复版本已提交且证据齐全，不以口头“已改好”为准。
变更类：由提出方提交变更说明，走变更评审，评审结论明确是否纳入本次验收范围。纳入的更新验收方案和验收项，不纳入的记入后续版本计划，并在验收结论中注明。范围变更不通过验收现场临时协商解决。
澄清类：由需求方与交付方共同确认标准的解释，形成书面澄清记录，明确按哪种理解判定，并同步更新验收方案中的对应描述。澄清只解决标准歧义，不改变已确认的需求内容。
有条件通过的遗留项单独登记，形成差异处置台账：
| 问题类型 | 处置路径 | 责任人 | 关闭条件 |
|---|---|---|---|
| 缺陷 | 修复后复验 | 交付方研发负责人 | 复验通过并更新结论 |
| 范围变更 | 变更评审 | 提出方与项目协调人 | 评审结论落定并更新验收范围 |
| 标准理解不一致 | 双方澄清 | 需求方与交付方 | 书面澄清记录确认 |
| 遗留项 | 登记跟踪 | 指定跟进人 | 在约定期限内关闭并验证 |
签署确认与追溯归档
全部验收项有结论后，由需求方与交付方共同签署验收结论。结论内容至少包括：验收范围、各项结论汇总、遗留项清单及关闭期限、签署人和签署日期。有条件通过的，要在结论中写明条件，避免后续对“是否已验收”产生不同说法。
验收结论需要与需求条目、交付版本、缺陷记录建立关联。这样后续出现问题时，可以从版本查到对应的验收结论和证据，也能从遗留项查到关闭情况。ONES 在 ALM 研发管理方案中围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，便于定位影响范围。把验收项、证据和结论挂到对应的需求与版本上，追溯时不必再跨多个表格人工比对。
归档材料包括：验收方案及确认记录、交付证据包、逐项核验记录、差异处置台账、验收结论签署件、澄清与变更记录。归档位置统一指定，并在验收结论中注明存放路径。遗留项到期未关闭的，由跟进人发起复验或延期申请，复验结论同样归档，形成完整闭环。
角色分工与各自交付物
验收涉及多方，按角色明确职责和交付物，可以减少“以为对方在跟”的情况。以下分工适用于常规研发交付，团队规模较小时可由一人兼多个角色，但职责要写清楚。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求方/业务验收人 | 确认验收范围与通过标准，参与核验并给出单项结论，签署验收结论 | 验收方案确认记录、核验结论、签署件 |
| 交付方/研发负责人 | 组织证据包准备，处理缺陷修复与复验提交，说明变更影响 | 版本与构建标识、部署与回滚说明、修复记录 |
| 测试与质量角色 | 提供测试报告与缺陷清单，执行性能、兼容等专项验证，参与差异归类 | 测试报告、缺陷清单及遗留项处置意见 |
| 项目或交付管理角色 | 协调验收排期，维护核验记录和差异处置台账，跟踪遗留项关闭，组织归档 | 核验记录表、处置台账、归档清单 |
角色之间有两处交接要特别明确：证据包由交付方提交、验收方做完整性检查；差异处置台账由项目协调人维护、责任人按期限关闭。交接点写进验收方案，验收当天按约定执行。
一个完整示例：从验收方案到签署
以下为演示情景，用于说明步骤如何串联，不代表真实项目数据。
某内部系统的一次版本交付，验收范围包括订单查询、报表导出和权限配置三个模块，排除项为对接第三方物流接口的联调。验收方案在交付前一周由需求方确认，功能项按需求条目逐条核验，性能项约定在测试环境按既定数据量验证，部署项要求提供回滚演练记录。
交付方提交证据包：版本号与构建编号、测试报告、缺陷清单（含两项遗留缺陷及处置意见）、部署与回滚说明、一次需求变更记录（报表导出字段调整，已经评审纳入本次范围）。核验按需求项逐条进行，订单查询和权限配置全部通过；报表导出因字段调整后的格式与需求描述不一致，判定不通过，归类为缺陷；性能项证据缺少测试环境说明，判定不通过，归类为标准理解不一致。
处置阶段，交付方修复报表导出问题并提交新构建，复验通过；性能项由双方澄清测试环境口径后补充报告，复验通过。两项遗留缺陷登记为有条件通过，责任人和关闭期限写入台账。最终验收结论写明范围、各项结论、遗留项和签署日期，由需求方与交付方共同签署，证据与结论关联到对应需求和版本后归档。
完成检查：验收是否真正结束
签署完成不等于验收收尾到位。用下面这份清单逐项核对，全部满足才可判定本次交付验收结束。
- 验收范围内的每个验收项都有明确结论，没有空白项或“待定”。
- 不通过项已按缺陷、范围变更、标准理解不一致归类，并完成修复复验、变更评审或书面澄清。
- 有条件通过的遗留项已登记，每项都有责任人和关闭期限。
- 验收结论已由需求方与交付方签署，内容包含范围、结论、遗留项、签署人和日期。
- 验收结论与需求条目、交付版本、缺陷记录已建立关联。
- 验收方案、证据包、核验记录、处置台账和签署件已按统一位置归档，路径可查。
- 遗留项关闭的复验触发方式已约定，到期未关闭时有跟进机制。
清单中任何一项不满足，验收就仍处于未完成状态，需要由项目协调人明确后续动作和完成时间。
常见问题
验收方案已经确认，交付过程中需求又变了，验收范围怎么处理？
需求变化时先走变更评审，评审结论明确是否纳入本次验收范围。纳入的，同步更新验收方案中的验收项、通过标准和证据要求，并通知验收方按新口径核验；不纳入的，记入后续版本计划，在验收结论中注明，避免后续对“是否已验收”产生不同说法。范围调整以书面记录为准，不在验收现场临时协商。
遗留缺陷不影响本次接收，可以判为有条件通过吗？
可以，但需要同时满足几个条件：主体功能符合通过标准；遗留项已评估影响范围，有规避方式；每项遗留项登记了责任人和关闭期限；处置意见写进验收结论。若遗留项涉及关键路径或存在数据风险，应判为不通过，修复后复验。有条件通过的条件要写清楚，后续按期限跟踪关闭。
验收方和交付方对通过标准理解不一致，僵持不下怎么办？
把这类差异归为标准理解不一致，由需求方与交付方共同确认标准的解释，形成书面澄清记录，明确按哪种理解判定，并同步更新验收方案中的对应描述。澄清只解决标准歧义，不改变已确认的需求内容。若澄清后发现需要调整需求，则转为变更流程处理。
验收结论和证据怎么关联，后续追溯时从哪里查？
验收结论要挂到对应的需求条目和交付版本上，核验记录、差异处置台账作为结论附件一并归档，缺陷记录与验收项建立对应关系。这样后续出现问题时，可以从版本查到验收结论和证据，也能从遗留项查到关闭情况。ONES 在 ALM 研发管理方案中围绕需求、基线、版本和变更建立统一管理对象，测试用例、缺陷、版本和发布过程可以关联到需求链路中，便于定位影响范围。
团队规模小，验收角色可以由一人兼任吗？
可以。常规分工中的需求方、交付方、测试与质量和项目协调角色，在团队较小时可由一人兼多个角色，但职责和交付物要写清楚，尤其是两处交接：证据包由交付方提交、验收方做完整性检查；差异处置台账由协调人维护、责任人按期限关闭。兼任时建议在验收方案中注明每个角色的实际承担人。
