统计合作伙伴接口交付完整性，核心是先把“约定接口清单”固定下来：以清单中的接口条目为分母，以按约定字段、格式、版本和时间完成交付并通过验收的接口为分子，计算完整性率；交接是否顺畅则单独用交接问题发生率衡量。两个指标都要锁定清单版本、验收标准和统计截止时间，缺失验收结论、返工和分母为零的情况按统一规则处理，结果才可复算、可比较。
要点总览（TL;DR）
- 统计接口交付完整性，以双方确认的接口清单条目为分母，以按约定字段、格式、版本和时间交付并通过验收的接口为分子，计算完整性率。
- 交接问题单独统计：交接问题发生率＝发生交接问题的接口数÷已交付接口数×100%，与完整性率分开看。
- 统计前固定清单版本、验收标准和截止时间；缺少验收结论的接口标记为待确认，不计入通过，也不从分母剔除。
- 同一接口多次返工按条目计一次，返工次数另作辅助指标；分母为零时报告本期无约定接口，不计算比率。
- 完整性率反映约定范围内的交付符合度，样本量小时波动大，应结合问题明细和返工记录按批次连续观察趋势。
评估目标：要回答协作中的哪个问题
接口交付完整性评估服务于一个具体问题：外部合作伙伴是否按双方约定，把该交的接口交全、交对，交接过程是否顺畅。评估对象是接口交付与交接过程本身，采购招标流程、合同法律条款审查不在这一指标的范围内。
这个问题可以拆成两个独立的评估问题。第一个是交付完整性：约定清单里的接口，有多少按约定字段、格式、版本和时间交付并通过验收。第二个是交接问题发生率：在已经交付的接口中，有多少在交接环节出现了问题，例如文档缺失、联调受阻、版本对不上、责任边界不清。两个问题分开统计，原因是它们回答的方向不同——完整性率低说明“该交的没交齐或没交对”，交接问题发生率高说明“交过来的东西在衔接上不顺”。一个伙伴可能交得很全但交接混乱，也可能交接顺畅但交付缺项，合并成一个数字会掩盖真实问题。
评估结果的使用场景是改进协作节奏与验收安排：哪些接口类型容易缺项，验收环节卡在哪个节点，交接问题集中在文档还是联调。它适合作为协作过程的观察工具，用于和伙伴沟通改进动作；把它直接当作伙伴整体能力或绩效的单一结论，会超出指标本身的解释力。
指标与范围：接口清单、时间窗和统计单位
统计范围以双方确认的接口清单为准。清单需要记录版本号和确认时间，后续所有统计都锚定这个版本。清单在统计期内发生变更时，按变更前后分段统计，并注明两段之间不可直接比较。
统计单位建议为接口条目。一个接口无论涉及几个字段、几次联调，在分母中计一次。如果协作按批次推进，可以在接口条目之上另设批次分组，用于观察不同批次的交付表现；批次分组是观察维度，不改变以接口条目为单位的计算口径。
时间窗按交付批次、里程碑或自然月确定，三者选其一并在统计前写明。选择批次适合按交付节奏复盘，选择里程碑适合与项目节点对齐，选择自然月适合连续趋势观察。时间窗一旦确定，统计截止时间同步固定，截止时间之后补交的接口计入下一期，不回头修改已发布的结果。
| 范围要素 | 口径说明 |
|---|---|
| 统计对象 | 双方确认的接口清单中的接口条目 |
| 统计单位 | 接口条目；可按批次或版本另设分组 |
| 时间窗 | 交付批次、里程碑或自然月，统计前固定 |
| 纳入项 | 清单内全部约定接口，含已交付、未交付、待确认 |
| 排除项 | 合同法律条款、采购招标流程、项目排期管理 |
数据口径与证据：完整性判定需要哪些字段
完整性判定要落到字段上，否则“完整交付”会变成各人各说。建议为每个接口条目记录以下字段，并明确每个字段的证据来源。
| 字段 | 用途 | 证据来源 |
|---|---|---|
| 接口名称与版本 | 唯一标识接口条目，防止重复统计 | 双方确认的接口清单 |
| 约定字段与格式 | 判定交付内容是否符合约定 | 接口文档、接口定义文件 |
| 约定交付时间 | 判定是否按期交付 | 清单中的计划日期 |
| 实际交付时间 | 与约定时间比对 | 交付记录、提交记录 |
| 验收结论 | 判定是否通过验收 | 验收单、评审记录 |
| 验收人 | 确认结论责任人 | 验收单签署信息 |
| 交接问题记录 | 统计交接问题发生率 | 问题单、交接记录、联调记录 |
缺失值要有明确处理规则。未提供验收结论的接口单独标记为“待确认”，不计入通过数，也不从分母中剔除——它仍是约定接口，只是结果未定。待确认接口数量应在结果中单独披露，避免读者误以为它们已经通过。数据不可比时说明原因，例如清单版本变更导致新增接口、验收标准调整导致判定尺度变化，这类情况在报告中注明分段，不强行合并计算。
这些字段需要有稳定的承载位置：接口清单作为受控文档维护版本，每个接口对应一条可追踪的工作项，验收结论和交接问题记录挂在该工作项下。ONES 的需求、基线、版本和变更管理可以支撑交付结果回溯，测试用例、缺陷与版本、发布过程的关联有助于在交接问题出现时定位影响范围；ONES Performance 提供基于系统内研发数据的多维度分析，接口交付完整性这类专用指标仍需按本文口径自行定义统计规则。外部伙伴参与协作时，接口清单、验收记录和问题单在同一平台流转，可以减少口径对不齐的情况。
计算步骤：完整性率与交接问题发生率怎么算
两个指标分别计算，公式和分母不同，不要混用。
接口交付完整性率＝按约定完整交付并通过验收的接口数 ÷ 约定接口总数 × 100%。分子要求同时满足：字段与格式符合约定、版本正确、按约定时间交付、验收通过。四项缺一不计入分子。分母是清单版本内的全部约定接口条目数，包含未交付和待确认的接口。
交接问题发生率＝发生交接问题的接口数 ÷ 已交付接口数 × 100%。分母只算已交付接口，未交付接口尚未进入交接环节，不纳入。同一接口出现多个交接问题时，按接口条目计一次，问题条数另作明细记录。
操作步骤：
- 锁定接口清单版本与统计截止时间，导出清单内全部接口条目。
- 逐条核对交付证据，标记“完整交付并通过验收”“已交付未通过或不符合约定”“未交付”“待确认”四种状态。
- 用通过数除以清单条目总数，得出完整性率。
- 在已交付接口中标记是否发生交接问题，用发生问题的接口数除以已交付接口数，得出交接问题发生率。
- 单独记录待确认接口数、返工接口数与返工次数，作为辅助信息随结果一并披露。
边界情况按以下规则处理：分母为零时，报告“本期无约定接口”，不计算比率，也不写 0%；同一接口多次返工，在分母中仍计一次，返工次数作为辅助指标单独统计，用于观察返工集中度；统计期内清单新增接口，若在截止时间前完成确认，纳入本期分母，截止时间后确认的计入下一期。
算例：一个交付批次如何得出结果
假设某交付批次双方确认的接口清单共 20 个接口，统计截止时间为批次验收结束日。逐条核对后结果如下：
| 状态 | 接口数 | 说明 |
|---|---|---|
| 完整交付并通过验收 | 16 | 计入完整性率分子 |
| 已交付但未通过或不符合约定 | 2 | 计入分母，不计入分子 |
| 待确认（缺少验收结论） | 2 | 计入分母，单独标记，不计入通过 |
| 约定接口总数 | 20 | 完整性率分母 |
完整性率＝16 ÷ 20 × 100%＝80%。
已交付接口为 18 个（16 个通过加 2 个未通过），其中 4 个在交接环节发生问题，例如接口文档字段说明缺失、联调环境版本不一致。交接问题发生率＝4 ÷ 18 × 100%≈22.2%。
该批次另有 1 个接口返工两次，它在分母中只计一次，已包含在上述 16 个通过接口中；返工次数单独记录为 2 次，用于观察返工是否集中在少数接口。2 个待确认接口在结果中单独披露，待验收结论补齐后，在下一期统计中更新状态，不追溯修改本期已发布数字。
结果解读：本期完整性率 80%，说明约定接口中有五分之一未达到完整交付标准或结果未定；交接问题发生率约 22.2%，说明已交付接口中约每五个有一个在衔接环节出现问题。两个数字结合待确认接口数和返工记录一起看，才能判断问题集中在交付缺项还是交接质量。
解读与限制：指标能说明什么、不能说明什么
完整性率反映的是约定范围内的交付符合度：在双方确认的清单里，有多少接口按约定交齐、交对并通过验收。它衡量的是这一批接口的交付结果，不直接代表伙伴的整体研发能力、响应速度或长期合作质量。清单本身如果约定得宽松，完整性率会显得好看；约定得严格，比率可能偏低，两种情况的数字不能直接横向比较。
样本量小时比率波动大。一个批次只有 5 个接口，少交付 1 个就是 20 个百分点的差异，此时应结合接口绝对数量和问题明细一起看，避免用比率单独下判断。交接问题发生率同理，已交付接口少时，一两个问题就会显著拉高比率。
指标需要交叉核验。完整性率要和待确认接口清单、未通过原因、返工记录对照，确认分子分母的判定没有口径漂移；交接问题发生率要和问题单明细对照，确认同一接口的多个问题没有被重复计数，也没有被漏记。清单版本变更或验收标准调整的期间，应在报告中注明不可比，分段呈现。
使用建议是按交付批次或里程碑连续观察趋势，看完整性率是否稳定、交接问题是否集中在某类接口或某个环节，再据此调整验收安排和协作节奏。单期结果适合作为沟通起点，作为伙伴绩效的最终结论则超出了这套指标能支撑的范围。
常见问题
接口清单在统计期内发生变更，完整性率还能直接和上期比较吗？
不建议直接比较。清单变更意味着分母的口径变了，新增接口、删除接口或调整约定内容都会影响比率。处理方式是按变更前后分段统计，在报告中注明两段之间不可直接比较，并说明变更内容和确认时间。如果变更发生在统计截止时间之前且已完成双方确认，新增接口纳入本期分母；截止时间之后确认的，计入下一期。
缺少验收结论的接口，应该算作未通过还是从统计中剔除？
两种做法都不合适。这类接口仍是约定清单内的条目，应从分母中保留；同时它没有验收结论，不能计入通过数。建议单独标记为“待确认”，在结果中披露数量，待验收结论补齐后在下一期更新状态，不追溯修改已发布的本期数字。这样既不会虚增完整性率，也不会让分母失真。
一个接口返工多次，完整性率和交接问题发生率分别怎么计？
两个指标都按接口条目计一次，不按返工次数累加。完整性率中，该接口只要最终按约定交付并通过验收，就计入分子一次；未通过则不计入分子。交接问题发生率中，同一接口出现多个交接问题也只计一次，问题条数另作明细记录。返工次数单独作为辅助指标统计，用来观察返工是否集中在少数接口。
统计结果能不能直接用于评价合作伙伴的绩效？
这套指标衡量的是约定清单范围内的交付符合度和交接顺畅程度，适合作为协作过程沟通和改进的依据。伙伴的整体研发能力、响应速度和长期合作质量超出指标的解释范围；清单约定宽严不同，比率也不能直接横向比较。建议按批次或里程碑连续观察趋势，结合问题明细使用，单期结果作为沟通起点更合适。
接口清单、验收结论和交接问题记录放在哪里，统计时才不用反复对口径？
关键是让清单、验收结论和问题记录有稳定的承载位置并保持关联。ONES 的需求、基线、版本和变更管理可以支撑交付结果回溯，测试用例、缺陷与版本、发布过程的关联有助于在交接问题出现时定位影响范围；ONES Performance 提供基于系统内研发数据的多维度分析，接口交付完整性这类专用指标仍需按本文口径自行定义统计规则。外部伙伴参与协作时，相关记录在同一平台流转，可以减少口径对不齐的情况。
