研发项目整体验收前，材料准备的重点在于把范围、质量、交付和收尾四类证据备齐，并让每项都能在验收会上当场核对。本文面向项目经理、质量与测试负责人、交付负责人和验收方代表，给出一份可直接勾选的检查清单，说明每项材料的通过标准、证据形式、责任人和检查时点，并标出缺失即阻断验收的关键项。
要点总览（TL;DR）
- 研发项目整体验收前，材料按范围与目标、过程与质量、成果与交付、收尾管理四类备齐，每项写明通过标准、证据形式、责任人和检查时点。
- 通过标准要落到可观察事实：文件有或无、签字是否齐全、版本是否一致、缺陷状态是否为已关闭，避免“基本完成”这类无法核对的写法。
- 验收会前两周启动自查，验收会当天逐项核对证据；证据按阶段存放在统一目录，便于自查和会上出示。
- 范围基线缺失、关键与严重缺陷未闭环、交付物无签收、验收标准未逐条对照属于阻断项，缺失即不能通过验收。
- 验收完成需同时满足：全部阻断项通过、遗留问题有责任人和期限、验收结论由验收方代表签字确认。
谁在什么时点使用这份验收材料清单
这份清单服务于研发项目的整体收尾，即项目生命周期结束、成果移交或转入下一阶段之前的验收。它解决的是“材料是否齐、证据是否硬、责任是否清”的问题，与单次软件交付验收中的测试追溯、版本比对属于不同工作，后者不在本文展开。
使用时点建议分两段：验收会前两周启动自查，由项目经理牵头，各责任人按清单补齐材料；验收会当天逐项核对，对照证据给出“通过/不通过”结论并记录。提前两周的意义在于给缺陷闭环、签收补签、归档整理留出处理时间，避免会上才发现材料缺口。
| 角色 | 在清单中的职责 | 主要介入时点 |
|---|---|---|
| 项目经理 | 总协调，汇总清单、组织自查、主持验收会核对 | 验收前两周至验收会当天 |
| 质量/测试负责人 | 提供测试报告、缺陷闭环记录、配置与版本清单 | 验收前两周内完成证据整理 |
| 交付负责人 | 提供交付物清单、签收记录、部署上线与交接材料 | 验收前两周内完成签收与交接确认 |
| 验收方代表 | 对照验收标准逐项确认，签署验收结论 | 验收会当天 |
需要说明的是，不同组织的项目类型差异较大，纯研发预研项目与对外交付项目的材料侧重不同。清单中的检查项可按项目实际裁剪，但裁剪决定应记录在验收申请中，说明省略理由，避免会上临时争议。
验收前材料按四个阶段逐项自查
把材料按“范围与目标—过程与质量—成果与交付—收尾管理”四个阶段排列，对应项目从立项到收尾的证据链条。每个阶段给出检查项、通过标准、证据形式、责任人和检查时点，可直接作为自查表使用。
阶段一：范围与目标类材料
| 检查项 | 通过标准 | 证据形式 | 责任人 | 检查时点 |
|---|---|---|---|---|
| 项目立项书/任务书 | 文件存在，含项目目标、范围、主要交付物，已经批准 | 立项文档（含编号与版本） | 项目经理 | 验收前两周 |
| 需求与范围基线 | 基线版本已冻结，与立项范围可对应 | 需求文档基线版本、范围说明 | 项目经理/产品负责人 | 验收前两周 |
| 变更记录 | 所有范围变更均有记录、审批与影响说明 | 变更单、变更评审纪要 | 项目经理 | 验收前两周 |
阶段二：过程与质量类材料
| 检查项 | 通过标准 | 证据形式 | 责任人 | 检查时点 |
|---|---|---|---|---|
| 阶段评审记录 | 关键里程碑评审均有纪要，结论明确 | 评审纪要、评审结论页 | 项目经理 | 验收前两周 |
| 测试报告 | 报告含测试范围、结论，结论为通过 | 测试报告（含结论页） | 测试负责人 | 验收前两周 |
| 缺陷闭环记录 | 关键与严重缺陷状态均为已关闭，其余缺陷有处理结论 | 缺陷列表导出、状态统计 | 测试负责人 | 验收前一周 |
| 配置与版本清单 | 交付版本与配置项一一对应，版本号一致 | 配置清单、版本发布记录 | 测试/配置管理员 | 验收前一周 |
阶段三：成果与交付类材料
| 检查项 | 通过标准 | 证据形式 | 责任人 | 检查时点 |
|---|---|---|---|---|
| 交付物清单与签收 | 清单覆盖全部约定交付物，接收方已签字 | 交付物清单、签收单 | 交付负责人 | 验收前两周 |
| 部署与上线记录 | 生产环境部署有记录，上线时间与版本可查 | 部署记录、上线确认单 | 交付负责人 | 验收前一周 |
| 运维/用户交接材料 | 操作手册、运维说明已移交，接收人确认 | 交接清单、培训或移交记录 | 交付负责人 | 验收前一周 |
阶段四：收尾管理类材料
| 检查项 | 通过标准 | 证据形式 | 责任人 | 检查时点 |
|---|---|---|---|---|
| 验收申请与标准对照表 | 申请已提交，验收标准逐条有对应证据 | 验收申请单、标准对照表 | 项目经理 | 验收会前 |
| 遗留问题与风险清单 | 每项有描述、责任人、处理期限 | 遗留问题清单 | 项目经理 | 验收会前 |
| 成本与工时结算 | 实际成本与工时已统计，与预算对比有说明 | 结算表、工时统计 | 项目经理 | 验收会前 |
| 经验总结与归档清单 | 总结文档完成，归档目录与清单一致 | 总结文档、归档清单 | 项目经理 | 验收会后一周内 |
每项材料的通过标准怎么写才可核验
通过标准的作用是让核对人不必依赖主观判断就能给出结论。写法上应落到可观察事实：文件有或无、签字是否齐全、版本是否一致、缺陷状态是否为已关闭。凡是需要“感觉差不多”才能判断的表述，都应改写。
| 不可核验写法 | 可核验改写 |
|---|---|
| 测试工作基本完成 | 测试报告已出具，结论页标注“通过”，覆盖范围与需求基线一致 |
| 缺陷已处理得差不多 | 严重及以上缺陷状态全部为“已关闭”，一般缺陷均有处理结论和责任人 |
| 交付物已交给客户 | 交付物清单所列项目全部有接收方签字，签收日期在验收会之前 |
| 文档比较齐全 | 归档清单所列文档在文档库中均可检索到，编号与版本与清单一致 |
证据形式要与通过标准匹配：签字类看签收单和评审纪要，状态类看系统导出记录，版本类看配置清单与发布记录。责任人填写具体角色或姓名，避免写“相关同事”；检查时点写到“验收前两周”“验收会前”这样的节点，便于排期。对于跨团队项目，建议在标准中注明证据的存放位置，减少会上翻找的时间。
证据归档与责任人分工
材料齐不齐，取决于平时有没有按统一位置存放。建议在项目文档库或配置库中建立验收专用目录，按四个阶段设子文件夹，文件名带文档编号与版本号。这样自查时按目录逐项对照，验收会上按目录出示证据，核对结论也记录在同一目录的核对表中。
| 材料类别 | 归档位置 | 归档责任人 | 验收会举证方式 |
|---|---|---|---|
| 范围与目标类 | 项目文档库/01-范围与目标 | 项目经理 | 出示立项书、基线版本与变更单 |
| 过程与质量类 | 项目文档库/02-过程与质量 | 测试负责人 | 出示测试报告结论页与缺陷状态导出 |
| 成果与交付类 | 项目文档库/03-成果与交付 | 交付负责人 | 出示签收单、部署记录与交接清单 |
| 收尾管理类 | 项目文档库/04-收尾管理 | 项目经理 | 出示验收申请、标准对照表与遗留问题清单 |
当项目在ONES中管理时，需求、任务、测试与缺陷在同一套工作项中流转，验收所需的证据可以直接从系统中取用：需求池与工单构成需求—任务—测试—缺陷的闭环，测试计划、缺陷管理与报告生成支撑质量证据；流水线集成可提供构建与部署状态记录。效能管理会自动收录系统内日常流转的研发数据，形成交付效率、交付质量等维度的指标，项目经理在准备成本工时结算和完成情况说明时，可以引用这些客观数据，并按角色配置读写权限。对于需求明确、交付周期固定的项目，ONES的项目制管理方式强调里程碑和交付物控制，与本文按阶段核对材料的做法可以对应起来。需要说明的是，验收清单模板和收尾流程的专门功能以实际环境为准，上述能力用于承载材料流转与证据留存。
阻断项与验收完成条件
并非所有材料缺失都同等严重。把缺失即导致验收无法进行的项目单独标为阻断项，其余列为限期补齐项，可以让验收会聚焦在关键判断上，也避免因一份总结文档未定稿而拖延整个项目关闭。
| 类型 | 项目 | 处理方式 |
|---|---|---|
| 阻断项 | 范围基线缺失或与立项范围无法对应 | 补齐基线并完成确认后方可提交验收 |
| 阻断项 | 关键与严重缺陷未闭环 | 缺陷关闭或经批准转为遗留问题并明确责任人与期限 |
| 阻断项 | 交付物无签收 | 取得接收方签字，签收日期不晚于验收会 |
| 阻断项 | 验收标准未逐条对照 | 完成标准对照表，每条标准有对应证据 |
| 限期补齐项 | 经验总结未定稿 | 验收会后一周内提交 |
| 限期补齐项 | 部分归档材料未入库 | 验收会后两周内完成归档并通知项目经理 |
验收完成的判定条件可以归纳为三条：全部阻断项通过核对；遗留问题清单中每项都有责任人和处理期限，并经验收方确认；验收结论由验收方代表签字确认。三条同时满足，项目才进入正式收尾，后续的归档补齐按限期跟踪，不再影响验收结论本身。
常见问题
项目范围在收尾前又发生了一次变更，验收材料要怎么处理？
先确认这次变更是否走完了变更审批。若已审批，把变更单、评审纪要和影响说明补入范围与目标类材料，并更新需求与范围基线，使基线版本与立项范围能够对应；若变更尚未审批，应在验收会前完成审批，否则范围基线这一阻断项无法通过核对。
变更涉及交付物的，同步更新交付物清单，并确认新增或调整的部分已有接收方签收。变更记录与基线版本要能互相追溯，验收会上按变更单逐条说明影响范围。
关键缺陷在验收会前无法全部关闭，还能通过验收吗？
关键与严重缺陷未闭环属于阻断项，直接通过验收不合适。可行的处理是走遗留问题确认：对确实无法在会前关闭的缺陷，逐项说明原因、影响范围、责任人和处理期限，由验收方代表确认后转为遗留问题，并在遗留问题清单中登记。
转为遗留问题的缺陷需要有明确的处理计划，不能只写“后续修复”。验收结论中应注明这些遗留项，后续按期限跟踪关闭情况。
纯研发预研类项目，材料清单可以裁剪到什么程度？
预研项目通常没有对外交付物，成果与交付类材料中的签收单、部署上线记录可能不适用。裁剪时保留范围与目标、过程与质量、收尾管理三类中的核心项，例如立项书、范围基线、阶段评审记录、测试或验证结论、验收申请与标准对照表、经验总结。
裁剪决定要记录在验收申请中，写明省略了哪些检查项及理由，由验收方确认。这样既贴合项目实际，也避免验收会上对材料是否齐全产生争议。
验收会后补齐的归档材料，由谁跟踪、怎么确认完成？
限期补齐项由项目经理统一跟踪，归档责任人按清单在期限内把材料放入对应目录，并在核对表中标注完成日期。项目经理核对目录内容与归档清单一致后，通知验收方代表确认。
补齐情况建议在项目收尾记录中留痕，与验收结论分开记录，避免把会后补齐的材料误认为验收会当天的核对依据。
用ONES管理项目时，验收证据可以从哪些地方取？
当需求、任务、测试与缺陷在同一套工作项中流转时，需求池与工单构成需求—任务—测试—缺陷的闭环，测试计划、缺陷管理与报告生成可用于整理质量证据；流水线集成可提供构建与部署状态记录。效能管理会自动收录系统内日常流转的研发数据，形成交付效率、交付质量等维度的指标，可用于成本工时结算和完成情况说明，并支持按角色配置读写权限。
验收清单模板和收尾流程的专门功能以实际环境为准，上述能力主要用于承载材料流转与证据留存。
