服务移交是否完成，按“条件清单全部满足、证据可核验、接收方书面确认”三项同时成立来判定。本文针对一次具体研发交付中的服务移交，给出五类确认条件、每类条件的证据标准、可复算的完成率口径和一个核验示例，帮助移交双方在确认评审会上得出可追溯的结论。
要点总览（TL;DR）
- 服务移交完成按三项同时成立判定：约定条件全部满足、证据可核验、接收方书面确认。
- 移交条件拆成范围与文档、环境与权限、知识与培训、运行与支持、责任与流程五类，逐项配证据和定性通过标准。
- 完成率=已满足条件数÷应满足条件总数×100%，分母取本次移交约定范围内的条件总数，缺失证据按未满足计，分母为零判定为不适用。
- 阻断项优先于完成率：存在未关闭阻断项时，完成率再高也按未完成处理。
- 判定结论连同条件清单、证据记录和遗留项清单一并归档，便于后续追溯与复盘。
判定服务移交完成的目标与边界
判定服务移交完成，回答的是一个有限范围内的问题：本次约定移交的服务内容，接收方是否已经具备独立承接的条件，并书面确认承接。判定对象是一次具体的服务移交，例如某个系统模块、某条业务链路或某项运维职责从交付团队转到接收团队；它不等同于项目整体收尾，也不覆盖项目结项、合同结算、产品上线后的使用效果评估。
判定时点定在移交确认评审日。评审日之前完成的准备动作计入本次判定，评审日之后补交的材料不计入本次结论，只能作为遗留项在后续跟踪。这样处理的原因是让判定有明确截止线，避免“边评审边补材料”导致结论反复。
本文的边界包括三点：第一，只讨论单次移交的完成确认，不讨论多个移交批次之间的优先级安排；第二，不评估服务上线后的稳定性表现和用户满意度，这些属于运行期评估；第三，不涉及具体工具的价格、版本与认证信息。明确边界后，判定结论才能被双方共同接受，也便于在出现争议时回到约定范围核对。
移交完成需要满足的五类条件
把移交拆成五类条件，目的是让“完成”从一句笼统的判断变成可以逐项核对的清单。五类条件分别回答不同问题，缺一类就可能留下承接盲区。条件范围由移交双方在移交协议或移交说明中约定，本文给出的是常用的条件框架，具体条目按本次移交的实际内容裁剪。
范围与文档
这一类条件回答“移交了什么”。需要明确移交清单，列清服务边界、包含与不包含的内容；交付物清单，列清文档、配置、脚本、数据等物件及其版本；接口与依赖说明，列清上下游系统、外部依赖和对接方式。范围不清是移交争议最常见的来源，清单要写到接收方能够据此判断自己接的是哪一块。
环境与权限
这一类条件回答“在哪里操作、能不能操作”。需要确认生产环境与测试环境的可用状态和访问方式，账号与权限完成交接，包括应用账号、数据库账号、监控平台账号和必要的审批权限。权限交接要落到具体账号和具体范围，避免只交“管理员账号”而实际缺少关键操作权限。
知识与培训
这一类条件回答“接收方会不会做”。需要提供操作手册、应急预案和常见问题说明，完成培训并留下培训记录，关键岗位通过操作考核。培训完成的标志是接收方人员能够独立完成主要操作，而不是听过一次讲解。
运行与支持
这一类条件回答“出问题怎么办”。需要确认监控告警已配置并指向接收方，明确值班安排与响应时限约定，说明支持期内的支持方式和升级路径。监控告警的接收人、告警级别和处理时限要写清楚，避免告警仍然发往交付团队。
责任与流程
这一类条件回答“谁负责、按什么流程走”。需要明确各服务的责任人，约定问题升级路径，确认变更流程与故障处理流程的归属。责任交接完成的标志是接收方知道自己在该服务上的决策权限和上报对象。
每类条件的证据与通过标准
条件只有配上证据才能核验。证据的作用是让第三方在评审会上能够复核“这条条件是否真的满足”，减少口头确认带来的分歧。下表给出五类条件常用的证据形式和定性通过标准，实际使用时可按本次移交的复杂度增减条目。
| 条件类别 | 证据形式 | 定性通过标准 |
|---|---|---|
| 范围与文档 | 带版本号的移交清单、交付物清单、接口与依赖说明文档 | 清单覆盖本次约定范围，文档版本为当前有效版本，接收方确认内容完整、可据此操作 |
| 环境与权限 | 环境访问说明、权限开通工单或账号开通记录截图 | 接收方账号可实际登录并完成关键操作，权限范围与职责匹配 |
| 知识与培训 | 操作手册、培训签到记录、考核结果记录 | 培训覆盖关键岗位，考核结果显示接收方人员可独立完成主要操作 |
| 运行与支持 | 监控告警配置记录、值班表、支持与响应约定文档 | 告警接收人已切换为接收方，值班与响应时限有书面约定 |
| 责任与流程 | 责任人清单、升级路径说明、变更与故障流程文档 | 责任人到人，升级路径和流程归属经接收方确认 |
证据核验有两个操作要点。一是核对版本，文档类证据要确认是评审时点的有效版本，过期版本按未满足计。二是核对可操作性，权限和培训类证据不能只看“已开通”“已培训”的记录，要确认接收方实际能够操作。缺失证据的条件一律按未满足计，不用“应该没问题”替代证据。
当移交条件、证据和确认状态需要在多个角色之间流转时，可以把每条条件作为工作项管理，把文档、工单记录和确认意见挂在对应条目下，评审时按条目逐项核对状态。ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，便于在出现问题时定位影响范围。这类能力适合承载移交条件的清单化跟踪和证据留存，具体条目设计仍由移交双方约定。
完成率怎么算：公式、分母与时间窗
完成率用于把逐项核对的结果汇总成一个可复算的数字，公式为：完成率 = 已满足条件数 ÷ 应满足条件总数 × 100%。分子是经证据核验判定为满足的条件条数，分母是本次移交约定范围内的条件总数。分子分母都以“条件条”为单位，同一条条件不重复计数。
分母口径需要特别注意。分母取本次移交协议中约定的条件总数，不取组织层面的通用清单条数，也不取历史移交的平均条数。如果本次移交只涉及部分服务，分母只计这部分服务对应的条件。分母确定后应在评审前锁定，评审过程中新增条件需双方确认后调整分母并记录调整原因。
时间窗以移交确认评审日为截止日。评审日当天及之前取得并可核验的证据计入本次判定；评审日之后补交的证据不计入本次完成率，转为遗留项跟踪。缺失证据的条件按未满足计，不计入分子，但仍计入分母。分母为零时，说明本次移交未约定任何可核对条件，完成率判定为不适用，不能记为100%，此时应回到条件约定环节补齐清单。
完成率算出后还要叠加两个判断：是否存在阻断项，以及接收方是否书面确认。阻断项指不解决就无法承接的问题，例如关键权限未开通、核心操作无人会做、监控告警仍指向交付团队。存在未关闭阻断项时，无论完成率多高，结论都按未完成处理。
判定示例：一次服务移交的核验过程
以下为演示情景，用于说明判定过程，不对应任何真实项目数据。某研发团队将一套订单服务的日常运维职责移交给运维团队，双方在移交协议中约定条件共20条，按五类分布：范围与文档5条、环境与权限4条、知识与培训4条、运行与支持4条、责任与流程3条。
评审日核对结果如下：范围与文档满足5条，环境与权限满足3条，知识与培训满足3条，运行与支持满足3条，责任与流程满足3条，合计已满足17条。未满足的3条分别是：一条接口依赖说明仍为旧版本、一条数据库只读账号权限未开通、一名值班人员未通过操作考核。
完成率计算：17 ÷ 20 × 100% = 85%。其中数据库只读账号权限未开通被认定为阻断项，因为接收方无法在故障时查询数据。按判定规则，完成率85%未达到全部满足，且存在未关闭阻断项，本次移交判定为未完成。
遗留项记录如下：接口依赖说明更新，责任人交付方文档负责人，期限评审日后3个工作日；数据库只读账号开通，责任人交付方系统管理员，期限评审日后1个工作日；值班人员补考，责任人接收方值班主管，期限评审日后5个工作日。三项关闭后重新组织确认评审，届时重新计算完成率并以新评审日为截止日。接收方在遗留项清单上签字确认，作为本次评审的记录。
结果解读与判定限制
完成率是判定完成的必要条件，不能单独作为结论。完成率100%只说明约定条件在证据层面全部满足，仍需接收方书面确认才算完成；完成率不足100%时，结论直接为未完成，不需要再讨论接近程度。把完成率当作唯一依据，容易出现“数字好看但实际接不住”的误判。
阻断项优先于完成率。评审时要先识别阻断项，再计算完成率。阻断项的认定标准应在移交协议中事先约定，避免评审时临时争论。常见误判包括：把“已发文档”当作“文档已确认”，把“已开通账号”当作“权限可用”，把“已培训”当作“能独立操作”。这些误判的共同点是用动作记录替代结果验证。
证据质量差异会导致完成率不可比。不同移交批次的证据形式、核验严格程度不同，完成率数字之间不宜直接横向比较，更不能用于跨团队排名。本文不设通用达标线，是否完成以本次约定范围的条件全部满足为准，具体条件范围和阻断项定义由移交双方在移交协议中约定。判定结论应连同条件清单、证据记录和遗留项清单一并归档，便于后续追溯和复盘。
常见问题
移交条件在评审前没有约定完整，评审时还能补吗？
可以补，但要按规则处理。评审前应锁定分母，即本次移交约定范围内的条件总数。评审过程中新增条件，需移交双方确认后调整分母，并记录调整原因，避免事后追加条件影响结论的可比性。如果评审时才发现本次移交没有约定任何可核对条件，完成率判定为不适用，应先回到条件约定环节补齐清单，再重新组织确认评审。
完成率达到100%，是否就可以直接判定移交完成？
不能直接判定。完成率100%只说明约定条件在证据层面全部满足，仍需接收方书面确认才算完成。同时要确认不存在未关闭的阻断项。完成率是必要条件，书面确认和阻断项核查是另外两项独立条件，三者同时成立才判定完成。
阻断项由谁认定，评审时出现分歧怎么办？
阻断项的认定标准应在移交协议中事先约定，例如关键权限未开通、核心操作无人能独立完成、监控告警仍指向交付团队等不解决就无法承接的问题。评审时按事先约定的标准逐条核对，减少临时争论。若协议未约定，双方应在评审会上就争议条目达成书面共识并记录，作为本次判定依据和下次移交的约定基础。
评审日后补交的证据能否追溯计入本次完成率？
不计入本次完成率。时间窗以移交确认评审日为截止日，评审日当天及之前取得并可核验的证据计入本次判定，之后补交的证据转为遗留项跟踪。遗留项关闭后重新组织确认评审，以新评审日为截止日重新计算完成率。这样处理是为了让每次判定有明确截止线，避免结论反复。
不同移交批次的完成率可以直接比较吗？
不宜直接横向比较。不同批次的证据形式、核验严格程度和条件范围不同，完成率数字之间缺乏共同口径，更不能用于跨团队排名。完成率适合用于同一批次内跟踪遗留项关闭进度，以及作为本次移交是否完成的判定输入之一。是否完成以本次约定范围的条件全部满足为准，本文不设通用达标线。
