衡量交付证据缺失风险，可以把“证据是否齐全、是否可追溯、是否被确认”拆成一组能逐项判断的检查项，为每项写明通过标准、证据形式和负责人。检查分交付前准备、交付评审、交付确认三个时点推进，任一阻断项未通过，本次交付即判定为证据不完整。
要点总览（TL;DR）
- 检查清单按交付前准备、交付评审、交付确认三个时点推进，分别由交付负责人、评审人和验收方使用，判定口径统一为通过、有条件通过、阻断三档。
- 检查项围绕证据清单对应关系、各环节产出归档、版本可定位、评审记录与意见闭环、双向追溯与验收确认展开，每项写明通过标准、证据形式和负责人。
- 通过标准写成有/无、齐全/缺失、可追溯/不可追溯这类可核验判断式，不合格项按检查项编号、缺失描述、补证责任人与期限记录，便于复检。
- 风险程度可用缺失率（未通过项数÷适用检查项总数）加分级计权折算，比较时限定在同类交付之间并保持权重口径稳定。
- 阻断项未通过不得放行；交付完成的条件是全部阻断项通过，非阻断项缺口已补证或经验收方书面接受。
谁在什么时点使用这份检查清单
这份清单服务于一次具体研发交付的完成确认，主要使用者是交付负责人、评审人和验收方。交付负责人负责准备证据并逐项自查，评审人依据清单判断证据是否充分，验收方在确认环节核对证据链并签署结论。三方使用同一份清单，可以避免各自按不同口径判断“证据够不够”。
检查分三个时点启动，每个时点的输出物不同：
| 使用角色 | 检查时点 | 主要动作 | 输出物 |
|---|---|---|---|
| 交付负责人 | 交付前准备 | 按清单逐项自查，补齐缺失证据 | 准备阶段检查表、缺口清单 |
| 评审人 | 交付评审 | 核对证据充分性，确认评审意见闭环 | 评审记录、评审结论 |
| 验收方 | 交付确认 | 核对追溯关系与确认记录，签署验收结论 | 验收确认记录 |
判定口径统一为三档：通过指该项证据齐全且符合通过标准；有条件通过指非阻断项存在缺口，已明确补证责任人与期限；阻断指阻断项未通过，本次交付不得放行。三档结论都要写入检查记录，不能只口头确认。
清单的边界需要说明：它判断的是某次交付的证据是否完整、可追溯，项目整体收尾的计划与资源安排属于项目收尾管理，产品上线后的使用效果与价值评估属于另一类验证工作，均不在本清单范围内。
交付前准备阶段的证据检查项
准备阶段的目标是带着完整证据进入评审，而不是把缺口留给评审人发现。交付负责人应在发起评审前完成下表自查，任一“否”都先补证再提交。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 级别 |
|---|---|---|---|---|
| 交付物清单与证据清单对应 | 每个交付物均有对应证据条目，无孤立交付物 | 对照表或清单文档 | 交付负责人 | 阻断 |
| 需求、设计、开发、测试产出归档 | 四个环节均有可打开的归档文件，版本为本次交付版本 | 文档库归档记录 | 各环节负责人 | 阻断 |
| 版本与构建记录可定位 | 能根据交付物定位到具体版本号与构建记录 | 版本记录、构建日志 | 开发负责人 | 阻断 |
| 遗留问题与已知限制书面记录 | 每条遗留问题有描述、影响范围与处置计划 | 问题清单文档 | 交付负责人 | 重要 |
| 证据文件命名与存放规范 | 文件名含交付物标识与版本，存放位置统一 | 目录结构截图或说明 | 交付负责人 | 一般 |
自查时建议逐项标注“有/无”，而不是凭印象打勾。发现缺失时，记录缺口内容、补证责任人和完成时间，补证完成后再更新检查表状态。
交付评审阶段的证据检查项
评审阶段判断的是证据是否足以支撑放行决定，重点在评审过程本身是否留下记录、意见是否闭环、结论是否书面化。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 级别 |
|---|---|---|---|---|
| 评审参与角色完整 | 需求、开发、测试、验收方均有代表参加，角色可识别 | 评审签到或参会记录 | 评审组织人 | 阻断 |
| 评审记录完整 | 评审时间、参与人、检查项结论均有记录 | 评审纪要文档 | 评审组织人 | 阻断 |
| 评审意见逐条闭环 | 每条意见有处理结论，状态为已关闭或有明确后续安排 | 意见跟踪表 | 各意见责任人 | 重要 |
| 关键交付物签署或确认 | 关键交付物有评审人或验收方签署记录 | 签署页、电子确认记录 | 验收方 | 阻断 |
| 测试报告与缺陷收敛 | 测试报告覆盖本次范围，阻断级缺陷为零，其余缺陷有处置结论 | 测试报告、缺陷列表 | 测试负责人 | 阻断 |
| 评审结论与放行条件书面化 | 结论明确为通过、有条件通过或阻断，并写明条件 | 评审结论文档 | 评审组织人 | 阻断 |
评审意见闭环是容易被忽略的一项。意见记录存在但状态长期停留在“处理中”，意味着证据链在评审环节断开，应按未闭环处理，不能以“已开会评审”代替闭环结论。
交付确认阶段的证据检查项
确认阶段核对的是证据链能否从交付物反向追溯到需求与任务，以及验收方是否留下明确的确认记录。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 级别 |
|---|---|---|---|---|
| 交付物与需求、任务双向追溯 | 每个交付物可追溯到来源需求与任务，需求也可定位到对应交付物 | 追溯关系表或系统关联记录 | 交付负责人 | 阻断 |
| 变更记录与影响范围说明 | 交付期内的变更均有记录，并说明对范围、测试的影响 | 变更单、影响分析说明 | 变更提出人 | 重要 |
| 缺陷与遗留问题处置结论 | 每条缺陷有修复或延期结论，遗留问题有验收方知悉记录 | 缺陷列表、处置结论 | 测试负责人 | 重要 |
| 验收方确认记录与时间 | 有验收方签署或确认记录，含确认时间与确认范围 | 验收确认单 | 验收方 | 阻断 |
| 证据存放位置可检索 | 证据集中存放，按交付物或版本可检索到 | 证据索引或目录说明 | 交付负责人 | 一般 |
双向追溯是确认阶段的核心检查项。只能从需求找到交付物、无法从交付物回到需求，说明存在来源不明的交付内容；反向缺失则说明部分需求没有对应交付证据。两个方向都要核对。
每项检查的通过标准与证据要求
检查项要能判断完成与否，通过标准应写成可核验的判断式，避免“基本完成”“大致齐全”这类无法复核的描述。常用写法有三类：有/无，用于判断记录是否存在；齐全/缺失，用于判断一组证据是否完整；可追溯/不可追溯，用于判断关联关系是否建立。
| 标准类型 | 写法示例 | 对应证据形式 | 判断方式 |
|---|---|---|---|
| 存在性 | 有评审记录且含参与人与结论 | 评审纪要文档 | 打开文档核对字段 |
| 完整性 | 交付物清单中每一项均有证据条目 | 对照表 | 逐行比对，统计缺失条目 |
| 可追溯性 | 交付物可定位到来源需求编号 | 关联记录或追溯表 | 抽查若干交付物反向查询 |
| 时效性 | 确认记录时间在交付确认时点之后 | 签署记录 | 核对时间字段 |
证据与检查项应一一对应，一条检查项对应一类可指认的证据，避免一条检查项挂多个模糊证据。不合格项的记录方式建议统一为：检查项编号、缺失描述、影响判断、补证责任人、补证期限、复检结果。这样复检时可以直接对照原记录判断是否补齐。
证据缺失风险的量化口径
只做“通过/不通过”判断，难以比较不同交付之间的缺失程度。可以把检查结果折算为缺失数量与缺失率，再按级别计权，得到一个可比较的风险分值。
基础口径是缺失率：缺失率 = 未通过检查项数 ÷ 适用检查项总数。适用检查项指本次交付实际涉及的条目，未涉及的条目不纳入分母，避免口径不一致导致结果失真。
分级计权可按阻断项、重要项、一般项分别赋权，例如阻断项计 5、重要项计 2、一般项计 1，加权缺失分 = Σ（未通过项数 × 对应权重）。示例：某次交付共 16 项适用检查，未通过 4 项，其中阻断项 1 项、重要项 2 项、一般项 1 项，则缺失率为 25%，加权缺失分为 1×5 + 2×2 + 1×1 = 10 分。团队可据历史交付设定分档阈值，用于判断缺失程度。
结果解读有两点限制：一是样本范围要一致，不同交付的适用检查项数量不同，缺失率比较应限定在同类交付之间；二是口径要稳定，权重和分档一旦确定，同一批比较中不宜随意调整，否则分值失去可比性。
阻断项与交付完成条件
阻断项是决定能否放行的检查项，未通过时不得进入交付确认。建议将以下条目列为阻断项：关键交付物缺失或无法打开；无评审记录或评审结论未书面化；关键交付物无签署或确认记录；测试报告缺失或存在未处置的阻断级缺陷；交付物无法追溯到来源需求；无验收方确认记录。
| 情形 | 判定 | 处置动作 |
|---|---|---|
| 阻断项全部通过，非阻断项无缺口 | 通过 | 进入交付确认，归档检查记录 |
| 阻断项全部通过，非阻断项有缺口 | 有条件通过 | 记录缺口、责任人与补证期限，到期复检 |
| 任一阻断项未通过 | 阻断 | 暂停放行，补证后重新检查该阻断项 |
交付完成的判定条件是：全部阻断项通过，非阻断项的缺口已按约定完成补证或经验收方书面接受。有条件通过仅适用于非阻断项缺口，且必须写明补证内容、责任人和期限；阻断项不适用有条件通过。
用工作项与文档承载检查证据
检查清单只有落到可检索的记录中，才能在复检、审计或争议时提供依据。承载方式可以按一条流程组织：把检查项作为工作项或检查表条目建立，逐项填写通过标准与负责人；证据以文档、附件或链接形式关联到对应交付物；评审与确认结论写入条目状态和结论字段；检查完成后，由交付负责人汇总结果交接给验收方确认。
ONES 的能力可以承接这条流程中的记录与追溯环节。其方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯，适合承载交付物与需求的追溯关系；测试用例、缺陷、版本和发布过程关联到需求链路，便于核对测试报告与缺陷处置结论；标准流程、评审节点和交付物模板可沉淀为可复用资产，减少每次交付重新搭建检查结构的工作。检查项本身如何设计、阻断项如何划定，仍需团队按自身交付流程确定。
常见问题
交付评审已经开过会，但评审意见还挂在“处理中”，这种情况算证据完整吗？
不算。评审记录存在只证明会议开过，意见未闭环意味着证据链在评审环节断开。建议把“评审意见逐条闭环”作为重要项单独检查，通过标准写成每条意见有处理结论、状态为已关闭或有明确后续安排，并指定各意见责任人。若该意见涉及阻断级问题，应按阻断项处理，补证后再进入交付确认。
不同交付的检查项数量不一样，缺失率还能直接比较吗？
可以比较，但要限定条件。缺失率的分母是本次交付实际涉及的适用检查项，未涉及的条目不纳入，因此不同规模交付的缺失率天然存在口径差异。建议只在同类交付之间比较，例如同一产品线、相近范围的交付；权重和分档阈值在同一批比较中保持稳定，跨批次调整口径时需重新建立基线，否则分值失去可比性。
非阻断项缺口在有条件通过后一直没补，交付算完成吗？
不算完成。有条件通过的前提是缺口已明确补证内容、责任人和期限，到期需要复检。若期限已过仍未补证，该项应回到未通过状态；如果缺口涉及关键交付物或追溯关系，还需重新评估是否升级为阻断项。建议在检查记录中保留复检结果字段，由交付负责人汇总后交验收方确认，避免有条件通过变成事实上的默认放行。
检查项和证据在协作工具里怎么放，才能支撑后续复检或审计？
可以把检查项作为工作项或检查表条目建立，逐项填写通过标准与负责人；证据以文档、附件或链接关联到对应交付物；评审与确认结论写入条目状态和结论字段。ONES 的方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯，测试用例、缺陷、版本和发布过程关联到需求链路，便于核对测试报告与缺陷处置结论。检查项如何设计、阻断项如何划定，仍需团队按自身交付流程确定。
小范围交付是否也要走完整的三阶段检查？
三阶段结构可以保留，检查项可按交付范围裁剪。裁剪的原则是：与本次交付物直接相关的证据项保留，未涉及的条目不纳入分母；阻断项中涉及关键交付物缺失、无评审结论、无验收确认的条目建议不裁剪。裁剪结果应写入检查表说明，让评审人和验收方知道哪些项不适用及理由，避免用“范围小”笼统跳过检查。
