项目验收要落到可执行的动作上，通常按“先定标准、再备证据、后走评审、最后移交归档”推进。本文面向项目整体结束或阶段转换时的验收，说明验收前准备什么、验收中如何逐项判定、验收后如何移交和归档，并给出角色分工与完成检查清单；单次软件交付的验收与追溯不在本文展开。
要点总览（TL;DR）
- 验收前先形成可执行的验收方案，写清验收范围与边界、可判断的通过标准、参与角色、日程和材料清单，作为后续判定的依据。
- 验收执行按提交申请与交付物清单、逐项核对记录偏差、偏差分类处置、形成结论、签字确认的顺序推进，结论分为通过、有条件通过和不通过。
- 项目负责人、验收方、质量或技术评审角色、项目管理办公室或上级各有对应交付物，分工要在方案中写明参与时点。
- 结论签字后还要完成成果移交确认、遗留问题登记与关闭验证、资料归档，并与项目收尾和复盘衔接。
- 判断验收是否闭环，可核对标准、证据、结论是否一一对应，结论是否签字并通知相关方，移交是否有接收确认，遗留项是否有责任人和时限。
验收前要准备什么：范围、标准与验收方案
验收能否顺利推进，很大程度上取决于启动前是否把“验什么、按什么判、谁来判、什么时候判”写清楚。准备阶段的核心产物是一份可执行的验收方案，它让验收从口头确认变成有依据的评审活动。
第一步是划定验收对象与边界。把本次纳入验收的成果逐项列出，例如已完成的业务模块、交付的文档、完成的培训或部署动作；同时写明哪些内容属于后续阶段、哪些属于单次交付验收，避免验收会上对“这次该不该验”产生分歧。边界写清楚，后续的标准和证据才有对应的落点。
第二步是把通过标准写成可判断的条件。常见的写法是按类别给出可核对的描述：功能类写明应实现的操作和预期结果；质量类写明可观测的指标或检查项；文档类写明应提交的文件及其必备内容；合规类写明需要满足的制度或约定要求。只写“满足要求”“达到预期”无法支撑判定，应替换为“某项检查通过”“某份文档齐备并包含某几项内容”这类可以给出是或否结论的表述。
第三步是确定验收方式与时点。会议评审适合需要多方共同确认结论的项目；现场检查适合成果以实体或环境状态呈现的情况；抽样测试适合成果数量多、逐项检查成本高的情况；书面确认适合范围清晰、分歧较小的场景。几种方式可以组合使用，但要在方案中写明每种方式覆盖哪些验收对象。
最后把上述内容汇总成验收方案，至少包含：验收范围与边界、通过标准、参与角色及各自职责、日程安排、所需材料清单。方案在验收启动前发给各方确认，确认后的版本作为后续判定的依据。方案形成后，准备阶段即告完成，可以进入执行环节。
验收执行步骤：从自检到评审结论
执行阶段按顺序推进，每个动作都有明确的输入和输出，最终形成一份有依据、有签字的验收结论。
提交验收申请与交付物清单。项目负责人依据验收方案整理交付物清单，逐项对应到验收对象，并附上自检记录。自检记录说明每项交付物对照标准做了哪些检查、结果如何、发现了什么问题及是否已处理。输入是验收方案和实际成果，输出是可被验收方直接核对的材料包。
逐项核对并记录偏差。验收方按标准对每项交付物给出符合或不符合的判断，把结果记入验收记录表。记录应写到具体条目，例如“某功能在指定场景下未返回预期结果”，而不是笼统写“部分功能存在问题”。符合项与偏差项分开列示，便于后续处置。
对偏差项分类处置。偏差项通常分三类：当场可以整改的，现场完成并复检；需要限期整改的，明确整改内容、责任人和完成时间；涉及范围或标准变化的，转入变更流程，由有权决定的一方确认后再调整验收安排。分类的目的是让每个偏差都有明确的下一步，而不是停留在问题清单上。
形成验收结论。依据核对结果给出三种结论之一：通过，即全部标准满足；有条件通过，即主要标准满足、遗留项在约定期限内完成整改；不通过，即存在影响交付的关键偏差。结论必须写明依据，指向具体的核对记录和偏差处置安排。
签字确认并明确后续责任。结论由验收方与项目负责人签字确认，同时写明遗留事项的责任人和时限。签字完成，执行阶段结束，验收记录表与结论文件成为后续移交和归档的输入。
角色与交付物分工：谁在验收中做什么
验收涉及多方，职责不清容易出现“材料没人整、结论没人签、问题没人跟”的情况。下表按角色列出主要职责和对应交付物，具体岗位名称可按组织实际调整。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 项目负责人 | 组织验收、整理并提交材料、牵头整改遗留项 | 验收申请、交付物清单、自检记录、整改计划 |
| 验收方/客户代表 | 对照标准逐项判定、签署验收结论 | 验收记录表中的核对意见、签字确认的结论文件 |
| 质量或技术评审角色 | 核查质量证据与技术符合性，给出专业判断 | 技术核查意见、质量问题清单 |
| 项目管理办公室或上级 | 监督流程执行、裁定争议、确认结论有效性 | 流程检查意见、争议裁定记录 |
分工确定后，建议在验收方案中一并写明每个角色的参与时点：谁在准备阶段提供标准，谁在执行阶段做判定，谁在结论后负责跟踪。角色与交付物一一对应，验收过程的责任链条才完整。
当验收涉及多个项目或需要长期留痕时，验收方案、自检记录、核对结果和结论文件往往分散在邮件、表格和聊天记录中，追溯成本较高。ONES 可以用工作项承载验收任务与遗留项、用文档承载验收方案和记录，让标准、证据与结论在同一处流转并保留版本，便于评审时对照和事后检索；具体配置方式可按团队现有流程设计。
验收后的移交、归档与遗留问题处理
结论签字并不等于验收结束，成果移交、遗留项关闭和资料归档完成后，验收才算真正收口。
成果移交。按交付物清单逐项移交，写明接收人、移交时点和确认方式。移交单上应有移交方与接收方的确认，涉及账号、环境、设备或文档位置的，注明具体位置和访问方式。移交完成的标志是接收方确认可以独立使用或接管该成果。
遗留问题登记与关闭。把有条件通过时约定的整改项和验收中记录的待办事项汇总成遗留问题清单，每项写明问题描述、责任人、关闭条件和时限。整改完成后由提出方或验收方验证，验证通过再关闭，避免清单长期挂起。
资料归档。归档范围至少包括验收方案、自检记录、验收记录表、结论文件、移交确认单以及验收期间的变更记录。归档时按项目或阶段建立目录，保证后续复盘、审计或同类项目参考时能够检索到。
与收尾和复盘衔接。验收结论是项目收尾的依据之一，复盘时可以回看验收中暴露的标准不清、证据不足或协作不畅等问题，把改进项带入后续项目的验收方案设计。
示例：一次中等规模项目的验收过程
以下为演示情景，用于说明完整走法，不代表任何具体组织的真实项目。
背景与范围。某团队完成一套内部业务系统的建设，进入项目验收。验收范围包括已上线的核心业务模块、配套操作手册和培训记录；性能压测和二期规划内容不在本次验收范围内，另行安排。
通过标准的写法。功能类写成“核心业务流程在测试环境中按操作手册步骤可完整走通，结果与预期一致”；文档类写成“操作手册覆盖全部上线模块，包含操作步骤和常见问题处理”；培训类写成“完成对使用方的培训并留存签到与培训材料”。每条标准都能给出符合或不符合的判断。
验收会上的核对记录。验收方按标准逐项核对，记录样式如下：
| 验收项 | 标准要点 | 核对结果 | 偏差说明 |
|---|---|---|---|
| 核心业务流程 | 按手册步骤可完整走通 | 符合 | — |
| 操作手册 | 覆盖全部上线模块 | 部分符合 | 两个辅助模块的操作说明缺失 |
| 培训记录 | 签到与材料齐备 | 符合 | — |
有条件通过与整改关闭。由于主要功能满足标准、文档存在局部缺失，验收结论为有条件通过，约定在十个工作日内补齐缺失模块的操作说明。项目负责人为整改责任人，验收方在材料提交后核对内容完整性并确认关闭。整改关闭后，移交单和结论文件一并归档，验收流程结束。
完成检查：验收是否真正结束
用下面这份清单逐项核对，全部满足即可认为验收闭环；存在未满足项时，按对应条目补做。
- 验收方案中的每条通过标准，都能在验收记录中找到对应的核对结果，标准、证据、结论三者一一对应。
- 验收结论已明确为通过、有条件通过或不通过，写明依据，并由验收方与项目负责人签字确认。
- 结论已通知到相关方，包括使用方、上级和相关协作团队。
- 成果移交已完成，移交单上有接收方确认，账号、环境或文档位置已交代清楚。
- 遗留问题清单中每项都有责任人和关闭时限，已完成的整改项经过验证后关闭。
- 验收方案、记录、结论、移交单和变更记录已按目录归档，后续能够检索到。
- 验收中暴露的问题已纳入复盘议题，形成可带入后续项目的改进项。
常见问题
验收会上出现意见分歧，结论定不下来怎么办？
先回到验收方案：分歧通常来自标准表述不够具体，或对某项偏差是否影响交付的判断不同。处理时把争议落到具体条目上，对照方案中的通过标准逐条确认事实，区分“标准本身有歧义”和“执行结果不符合标准”两种情况。前者由有权确认方案的一方补充或澄清标准，必要时转入变更流程；后者按偏差分类处置，能当场整改的现场复检，需要限期的写明责任人和时限。仍无法达成一致时，由项目管理办公室或上级按方案约定的裁定职责给出结论，并把裁定依据记入验收记录，避免结论悬空。
有条件通过和通过、不通过的区别是什么，后续处理有什么不同？
通过表示验收方案中的标准全部满足，可以直接进入移交和归档。有条件通过表示主要标准已满足，但存在不影响整体交付的遗留项，需要在约定期限内完成整改，验收方在整改完成后核对并确认关闭。不通过表示存在影响交付的关键偏差，需要整改后重新组织验收或调整验收安排。三者的差别体现在后续动作上：通过侧重移交，有条件通过侧重遗留项跟踪与关闭验证，不通过侧重整改和重新判定。结论类型要在结论文件中写明，并指向具体的核对记录。
验收范围里既有项目整体成果，也有单次软件交付内容，怎么划分？
按验收对象归属划分：属于项目整体结束或阶段转换的成果，纳入本文所述的验收方案统一组织；单次软件交付的验收与追溯按对应流程单独处理，不混入同一次验收结论。划分时在验收方案中逐项列出纳入本次验收的成果，并写明哪些内容属于后续阶段或单次交付验收。边界写清楚后，通过标准和证据才有对应落点，验收会上也不会对“这次该不该验”反复讨论。两类验收如果时间接近，可以共用部分材料，但结论和建议分开形成。
遗留问题一直没人关闭，验收还能算结束吗？
遗留问题清单中每项都要有责任人和关闭条件，整改完成后由提出方或验收方验证再关闭。如果清单长期挂起，说明关闭责任没有落实，验收处于未闭环状态。处理时可以按清单逐项确认当前状态：已完成的补做验证并关闭，逾期的重新明确责任人和时限，涉及范围变化的转入变更流程。完成检查清单中“遗留项是否有责任人和关闭时限”一项未满足时，应补做后再判断验收是否结束。把遗留项纳入项目收尾和复盘的跟踪范围，也有助于避免验收后无人跟进。
验收资料归档应该由谁负责，保存哪些内容？
归档责任通常在验收方案中约定，常见做法是由项目负责人整理提交、由项目管理办公室或指定角色核对完整性后归档。归档范围至少包括验收方案、自检记录、验收记录表、结论文件、移交确认单以及验收期间的变更记录，按项目或阶段建立目录，保证后续复盘、审计或同类项目参考时能够检索到。保存期限和审批层级属于组织制度性要求，各组织与行业规定不同，需按内部制度确认，不宜套用统一标准。
