研发交付验收分工要解决的是：一次研发交付由谁准备材料、谁按标准核验、谁在上线后确认结果、谁接收服务，以及每一步留下什么记录。把角色、动作和证据对应起来，验收结论才能被追溯。本文聚焦单次交付的完成确认，项目整体收尾与产品使用效果评估不在讨论范围内。
要点总览（TL;DR）
- 分工从三件事起步：先划定本次交付清单的范围，再固定可判定的验收标准，最后把交付方、验收方、发布后验证方、服务接收方的职责写到人。
- 验收按五个阶段推进：交付准备、验收评审、缺陷与返工闭环、发布后验证、服务移交，每个阶段明确输入、动作、输出和完成标志。
- 每个角色都要产出可查记录：交付清单与证据包、验收记录与不通过项清单、验证结论、移交确认，结论要能对应到清单条目和证据。
- 验收结束后用完成检查清单核对分工本身：责任是否到人、结论是否有记录、不通过项是否闭环、遗留事项是否登记。
- 小团队可以一人兼多个角色，但每个角色的职责和应产出的记录仍需分别写清，兼岗不等于职责合并。
验收分工先定三件事：范围、标准与角色
安排人员之前，先把本次验收的边界划清楚。范围不清，验收方容易把“项目是否成功”与“本次交付是否完成”混在一起讨论，分工也会随之失焦。建议由交付方负责人和验收方负责人共同确认以下三项，形成一份范围与角色对照表，作为后续所有验收动作的依据。
第一，范围。明确本次交付清单包含哪些内容：完成了哪些工作项、随附哪些文档（设计说明、接口文档、部署手册、测试报告等）、交付哪些构建产物或安装包、是否包含服务内容（环境部署、数据初始化、培训、运维交接）。清单之外的项不进入本次验收，避免范围蔓延。
第二，标准。验收标准的来源通常有三类：需求中约定的验收条件、团队或组织的质量门禁（如缺陷密度、用例通过率、性能指标）、合同或内部约定中的交付要求。标准要写到可判定的程度，例如“核心流程用例全部通过”比“功能正常”更可执行。标准来源应在验收开始前固定，验收过程中不临时追加。
第三，角色。一次交付验收通常涉及四类角色：交付方负责准备交付清单与证据；验收方负责按标准逐项核验并给出结论；发布后验证方负责上线后的确认；服务接收方负责接收移交内容并反馈意见。小团队中一人可兼多个角色，但每个角色对应的职责要写清楚，兼岗不等于职责合并。
| 范围项 | 判定标准 | 责任角色 |
|---|---|---|
| 功能工作项 | 需求验收条件逐条满足，关联用例通过 | 交付方准备，验收方核验 |
| 交付文档 | 文档齐全、版本与交付物一致、内容可执行 | 交付方提交，验收方抽查 |
| 构建产物 | 版本号明确、构建记录可查、部署验证通过 | 交付方提供，发布后验证方确认 |
| 服务内容 | 移交清单逐项完成，接收方确认 | 交付方移交，服务接收方确认 |
需要说明的是，项目整体收尾（如结项评审、资源释放）和产品使用效果评估（如上线后的业务指标变化）属于另外的管理动作，不纳入本次验收分工，否则验收结论会因评价口径过多而难以收敛。
按阶段拆分验收动作与交付物
范围与角色确定后，把验收拆成五个阶段依次推进。每个阶段都明确输入、动作、输出和完成标志，负责人对号入座，验收就不会停留在“大家看一下”的层面。
阶段一：交付准备
输入是已完成的工作项、测试记录和相关文档。交付方负责人据此整理交付清单，逐项附上证据：工作项链接、用例执行记录、构建记录、文档版本。输出为待验收清单与证据包。完成标志是清单中每一项都能找到对应证据，且证据版本与待交付版本一致。证据缺失的项应标注原因，不带着空白进入评审。
阶段二：验收评审
输入是待验收清单与证据包。验收方按约定标准逐项核对，对每一项给出三种结论之一：通过、有条件通过、不通过。有条件通过需写明附加条件与完成时限；不通过需写明原因和判定依据。输出为验收记录与不通过项清单。完成标志是清单中每一项都有明确结论，没有“待定”项遗留。
阶段三：缺陷与返工闭环
输入是不通过项清单。交付方为每个不通过项指定修复责任人，修复完成后提交复验；验收方复验并回写状态。输出是更新后的验收记录，不通过项转为通过或维持不通过并说明原因。完成标志是所有不通过项均已关闭，或经双方确认转为遗留事项登记。状态回写要及时，避免验收记录与实际进度脱节。
阶段四：发布后验证
输入是发布计划与验证项清单。发布后验证责任人在上线环境中按验证项逐条确认，例如关键流程可用性、数据迁移结果、监控告警是否正常。输出为验证记录与验证结论。完成标志是全部验证项有明确结果，异常项已转入缺陷流程处理。
阶段五：服务移交
输入是移交清单，包括环境信息、账号权限、运维手册、遗留事项说明。交付方逐项移交，服务接收方逐项确认并给出接收意见。输出为移交确认记录与遗留事项登记表。完成标志是接收方确认接收，遗留事项已登记责任人与处理时限。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 交付准备 | 已完成工作项、测试记录、文档 | 整理清单、附证据 | 待验收清单与证据包 | 每项有对应证据 | 交付方负责人 |
| 验收评审 | 待验收清单与证据包 | 逐项核对、给出结论 | 验收记录、不通过项清单 | 每项有明确结论 | 验收方负责人 |
| 缺陷与返工 | 不通过项清单 | 修复、复验、回写状态 | 更新后的验收记录 | 不通过项关闭或转遗留 | 修复责任人、验收方 |
| 发布后验证 | 发布计划、验证项清单 | 上线环境逐项确认 | 验证记录与结论 | 验证项全部有结果 | 发布后验证责任人 |
| 服务移交 | 移交清单 | 逐项移交、接收确认 | 移交确认记录、遗留事项表 | 接收方确认接收 | 交付方、服务接收方 |
角色与交付物清单：谁签字、谁留证据
按阶段推进解决的是顺序问题，按角色梳理解决的是责任归属问题。每个角色在验收中既要完成动作，也要产出可查的记录，签字确认的对象是记录本身，而非口头认可。
- 交付方负责人：产出交付清单、证据包、遗留问题说明。对清单完整性和证据真实性负责，在提交验收前完成自检。
- 验收方负责人：产出验收记录、验收结论、不通过项清单。对判定依据与标准的一致性负责，结论需写明对应标准条目。
- 发布后验证责任人：产出验证记录与验证结论。对上线后确认的及时性和记录完整性负责。
- 服务接收方：产出移交确认与接收意见。对接收内容的完整性和后续运维可行性负责，接收意见中应包含遗留事项的处理约定。
追溯要求贯穿以上角色：验收结论要能对应到交付清单的具体条目，清单条目要能对应到证据（工作项、用例记录、构建记录、文档版本），证据要能对应到本次交付的版本。任何一环断开，后续复盘或审计时就难以还原当时的判定过程。实践中可以在验收记录中为每个条目保留清单编号、证据位置和结论三项信息，形成最小可追溯单元。
| 角色 | 核心职责 | 应产出记录 | 确认方式 |
|---|---|---|---|
| 交付方负责人 | 准备清单与证据、说明遗留问题 | 交付清单、证据包、遗留问题说明 | 提交前自检并署名 |
| 验收方负责人 | 按标准核验、给出结论 | 验收记录、不通过项清单 | 逐项结论署名 |
| 发布后验证责任人 | 上线后确认交付结果 | 验证记录与结论 | 验证完成后署名 |
| 服务接收方 | 接收移交、反馈意见 | 移交确认、接收意见 | 接收确认署名 |
当验收涉及较多工作项和文档时，记录分散在多个工具中会增加追溯成本。ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；同时把测试用例、缺陷、版本和发布过程关联到需求链路中，便于在验收时从清单条目定位到对应证据。对于需要把评审节点和交付物模板沉淀为可复用资产的团队，这类关联方式可以减少手工整理对照表的工作量。具体采用何种记录载体，仍应按团队现有工具链和合规要求确定。
示例：一次版本交付的验收分工
以下为演示情景，用于说明分工如何落地，不代表任何真实项目数据。
背景。某团队完成一次版本交付，内容包括三项功能改进、一份接口文档更新、一个安装包，以及向运维团队移交部署与监控配置。交付方负责人为研发组长，验收方负责人为测试负责人，发布后验证责任人为值班工程师，服务接收方为运维负责人。
交付准备。研发组长整理交付清单：三项功能各对应一个工作项和一组用例记录，接口文档标注版本号，安装包附构建记录。清单共六项，每项附证据位置。自检发现其中一项功能的用例记录缺少回归部分，补充执行后重新提交。
验收评审。测试负责人按需求验收条件逐项核对：两项功能通过，一项功能因边界场景未覆盖判定为不通过，接口文档与安装包通过。验收记录中写明不通过项对应的标准条目和原因，形成不通过项清单。
缺陷与返工。研发组长指定该功能的开发人员补充边界场景处理并提交复验，测试负责人复验通过后回写状态，验收记录更新为六项全部通过。
发布后验证与服务移交。值班工程师按验证项确认核心流程可用、监控告警正常，记录验证结论。随后研发组长向运维负责人移交环境信息、账号权限和运维手册，运维负责人逐项确认，将一项监控阈值调整登记为遗留事项，约定一周内处理。
追溯关系。本次验收中，每个清单条目都能对应到工作项、用例记录或构建记录，每条验收结论都能回溯到对应条目和标准，遗留事项单独登记并关联到移交记录。后续如需复盘，可从任一结论出发还原当时的证据与判定依据。
完成检查：验收分工是否到位
验收结束后，用以下清单核对分工本身是否完整。检查对象是分工机制，而非具体功能质量。
- 每个交付项都有明确的验收责任人和可判定的标准，没有“共同负责”的模糊项。
- 验收结论有书面记录，且能追溯到交付清单条目与对应证据。
- 不通过项均指定了修复责任人和复验安排，状态已回写。
- 发布后验证有指定责任人，验证项清单和验证结论齐全。
- 服务移交有指定接收人，接收确认已记录。
- 遗留事项已登记，包含责任人、处理时限和后续跟踪方式。
- 验收范围与标准在验收开始前已固定，过程中未临时追加范围外内容。
以上各项均可核对时，本次交付验收的分工基本到位。若出现某项无责任人、结论无记录或证据与清单对不上，应优先补齐该环节再宣告验收完成，避免把问题带入后续运维或下一版本。
常见问题
小团队人手有限，验收方可以由交付方成员兼任吗？
可以兼任，但要把职责分开写。常见做法是同一人承担交付准备和部分验收动作，此时验收记录中应注明该条目的核验人与交付准备人是否为同一人，并对关键条目安排另一名成员复核。涉及对外交付或合规要求的场景，验收结论最好由未参与交付的成员确认，减少自评自验带来的判定偏差。
验收过程中发现需求本身有遗漏，应该走验收流程还是变更流程？
先判断遗漏项是否属于本次交付范围。属于范围内的，按不通过项处理，由交付方修复后复验；属于范围外的新增内容，应转入变更流程评估，不临时塞进本次验收。验收标准在开始前已经固定，中途追加范围会让验收结论失去可比性，也会拉长验收周期。若遗漏项影响本次交付的核心目标，可由交付方与验收方共同确认后调整范围，并同步更新交付清单。
发布后验证发现问题，验收结论要回退吗？
视问题性质而定。如果问题属于本次交付内容的缺陷，应将对应清单条目的结论回退为不通过，转入缺陷与返工闭环，修复并复验后再更新结论；如果问题属于环境配置或使用方式差异，可在验证记录中说明并给出处理安排。无论哪种情况，验证记录都应保留原始结论和后续处理过程，便于追溯当时的判定依据。
服务移交时接收方对部分内容有异议，验收还能算完成吗？
可以把有异议的内容登记为遗留事项，明确责任人和处理时限，其余内容正常完成移交确认。验收完成的判定依据是移交清单逐项有结论、接收意见已记录、遗留事项已登记，而非所有事项当场无异议。若异议涉及核心运维能力且短期内无法解决，建议在移交确认中注明风险，并约定复核时间。
验收记录分散在多个工具里，怎么保证可追溯？
关键是建立最小可追溯单元：每个验收条目保留清单编号、证据位置和结论三项信息，证据位置指向具体的工作项、用例记录、构建记录或文档版本。记录载体可以分散，但对照关系要集中维护，例如在验收记录中统一登记证据位置。ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯，并把测试用例、缺陷、版本和发布过程关联到需求链路中，便于从清单条目定位到对应证据；具体记录载体仍应按团队现有工具链和合规要求确定。
