交付服务移交要解决的是把一次研发交付成果从建设方交到接收方，并完成确认与责任转移。启动前先固定本次移交范围、交付物清单和验收口径，过程中按清单准备、联合核验、问题处置、签署确认、移交后观察推进，以接收方书面确认和遗留问题闭环作为完成标志。
要点总览（TL;DR）
- 移交启动前先固定本次交付批次边界、交付物清单、验收标准和不纳入事项，形成范围说明与验收标准表，作为后续核验和签署的基线。
- 操作按清单准备、联合核验、问题处置、签署确认、移交后观察五步推进，前一步产出物作为后一步输入，完成标志未达成不进入下一步。
- 建设方交付负责人组织清单与问题处置，接收方接收负责人判定验收并决定是否书面接受未达标项，质量、运维与签署角色各自提供证据和确认。
- 遗留问题按阻断级、重要级、一般级分级，阻断级须在签署前关闭，其余问题明确责任人和时限，或由接收方书面接受。
- 完成判断以交付物齐套、验收标准有证据、遗留问题闭环或书面接受、双方签署归档、观察期结果确认为依据。
移交范围与验收口径怎么定
移交出现反复，多数源于启动前没有把“交什么、交到什么程度、什么不算本次移交”写清楚。范围说明和验收标准表应在联合核验之前完成，并由建设方交付负责人与接收方接收负责人共同确认，后续核验、问题分级和签署都以这份文件为依据。
范围首先对应一个明确的交付批次，例如某个版本、某次上线或某个合同约定的交付节点。范围说明需要写明批次标识、涉及的系统和模块、建设方与接收方的组织边界，以及本次移交对应的起止时间。批次边界不清，核验时就会出现“这个功能算不算本次交付”的争论，遗留问题的归属也无法判断。
交付物清单按类别逐项列出，每项写明名称、存放位置、责任人和接收形式。常见类别包括：
- 文档类：需求说明、设计文档、测试报告、部署手册、操作手册、接口说明。
- 环境类：生产或预发环境地址、配置项、依赖组件、网络与权限开通情况。
- 账号与权限类：系统账号、管理后台权限、第三方服务账号及其交接方式。
- 数据类：初始化数据、历史数据迁移结果、数据字典。
- 服务承诺类：服务级别约定、支持时段、响应时限、升级联系人。
验收标准要写成可判定的条件，避免“运行正常”“文档齐全”这类无法核验的表述。每条标准应说明判定方式，例如通过某项功能测试用例、比对配置清单逐项确认、由接收方按操作手册独立完成一次典型操作。判定方式决定了联合核验时用什么证据说话，也决定了问题处置阶段如何区分“未达标”和“可接受”。
范围说明还需要单列“不纳入本次移交的事项及归属”，例如仍在开发中的功能、由第三方厂商直接支持的部分、下一批次才交付的模块。把排除项写清楚，可以防止接收方在观察期内提出范围外诉求，也便于把这些问题转给正确的责任方。
本节产出两份文件：移交范围说明和验收标准表。前者固定批次、边界和排除项，后者逐条列出验收条件、判定方式和证据要求。两份文件确认后即作为基线，后续如需调整，应记录变更原因和双方确认人。
移交五步操作：从清单准备到签署确认
五步操作按顺序推进，每一步都有明确的输入、动作、输出和完成标志。前一步的产出物是后一步的输入，完成标志未达成时不进入下一步。
第一步：清单准备
输入是已确认的范围说明和验收标准表。建设方交付负责人组织各角色按交付物类别整理实物和记录，形成移交清单，逐项标注状态：已就绪、待补充、不适用。文档类交付物需确认版本为最终版，环境类需确认地址和权限可用，账号类需确认交接方式安全可追溯。输出为带状态标记的移交清单和交付物实体。完成标志是清单中不存在“待补充”项，或待补充项已明确补齐时间且不影响本次核验。
第二步：联合核验
输入是移交清单和验收标准表。双方按标准逐条核验，核验方式包括现场演示、按手册独立操作、比对配置、抽查文档。每条核验结果记录为通过、不通过或带条件通过，并附证据，例如操作截图、测试记录编号、文档页码。输出为核验记录表，逐条对应验收标准。完成标志是所有标准均有明确核验结论，没有“未核验”项。
第三步：问题处置
输入是核验记录中的不通过项和带条件通过项。问题按影响分级：阻断级问题影响核心业务运行或关键交付物缺失，必须在签署前解决；重要级问题影响部分功能或文档完整性，可约定时限在观察期内解决；一般级问题为表述、格式或优化类事项，可列入后续改进。每个问题明确责任人、解决时限和验证方式。接收方对某条未达标项选择书面接受时，需写明接受理由和风险承担方。输出为问题清单及处置结论。完成标志是阻断级问题全部关闭，重要级和一般级问题均有责任人和时限，或已有书面接受记录。
第四步：签署确认
输入是核验记录、问题清单及处置结论、范围说明。签署确认采用书面形式，内容包括移交批次、交付物清单版本、验收结论、遗留问题清单及接受情况、观察期安排。生效条件是双方授权签署人签字或通过约定的电子方式确认，且阻断级问题已关闭。输出为签署确认文件。完成标志是确认文件归档，双方各持一份。
第五步：移交后观察
输入是签署确认文件和遗留问题清单。观察期长度按交付复杂度和服务承诺确定，例如两周到一个月。观察期内接收方按实际使用情况反馈问题，建设方按约定响应并处理遗留问题。观察期结束前进行一次结果确认，逐项核对遗留问题是否关闭、服务响应是否达到承诺。输出为观察期结果记录。完成标志是遗留问题全部关闭或转为正式支持流程，观察期结果经双方确认。
清单、核验记录和遗留问题如果分散在邮件和表格中，状态容易失真。ONES 的需求、基线、版本、变更、测试与发布管理可以把交付物与需求链路关联，测试用例、缺陷、版本和发布过程纳入同一闭环，出现问题时便于定位影响范围；移交清单和核验记录可以作为工作项和文档承载，遗留问题按状态流转并保留处理记录。具体字段和流程配置需按团队实际流程确定。
角色分工与各自交付物
移交涉及建设方、接收方以及质量和运维支持角色，每个角色的职责要落到具体交付物上，避免出现“大家都参与、没人负责”的情况。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 建设方交付负责人 | 组织清单准备，汇总交付物，牵头问题处置，代表建设方参与签署 | 移交范围说明、移交清单、问题处置计划、签署确认文件 |
| 接收方接收负责人 | 确认范围与验收标准，组织接收方核验，决定未达标项是否书面接受，负责观察期反馈 | 验收标准确认记录、核验意见、书面接受记录、观察期反馈记录 |
| 质量或测试角色 | 提供测试证据，执行或见证核验，判定缺陷等级 | 测试报告、核验记录表、缺陷分级意见 |
| 运维与支持角色 | 确认环境、权限和监控就绪，接收服务承诺，承接观察期支持 | 环境配置清单、权限交接记录、服务支持交接说明 |
| 决策与签署角色 | 审批范围变更，裁决争议问题，签署确认文件 | 变更审批记录、争议裁决意见、签署确认文件 |
建设方交付负责人是移交的组织者，负责把各角色的产出汇总成一份可核验的清单，并对清单完整性负责。接收方接收负责人是验收的判定者，其确认意见直接决定移交能否进入签署环节。质量或测试角色提供客观证据，缺陷分级意见影响问题处置的优先级。运维与支持角色关注移交后的可运行性，环境、权限和监控未就绪时不应进入签署。决策与签署角色在范围变更和争议问题上做最终判断，签署确认文件由其授权生效。
角色之间需要明确接口：建设方交付负责人向接收方接收负责人提交清单和核验申请；质量角色向双方提交核验记录；运维角色向接收方支持团队交接环境和权限；签署角色在阻断级问题关闭后签署。每个接口都应有书面记录，口头确认不作为完成依据。
示例：一次版本交付的服务移交记录
以下为演示情景，用于说明移交记录如何落地，不代表真实项目数据。
某内部系统完成一次版本升级，建设方为研发团队，接收方为业务运维团队。本次移交范围为该版本涉及的用户管理模块和报表模块，交付物包括升级说明、部署手册、测试报告、生产环境配置清单、管理员账号交接单和服务支持联系人清单。不纳入本次移交的事项为下一版本计划中的移动端适配，归属研发团队后续批次。
联合核验按验收标准逐条执行。核验中发现三类问题：报表导出功能在数据量较大时响应超时，定为阻断级，责任人为建设方开发人员，要求签署前修复并复测；部署手册缺少回滚步骤说明，定为重要级，责任人为建设方技术文档负责人，约定观察期内补充；管理员账号交接单中一个第三方服务账号的权限说明不完整，定为一般级，责任人为运维角色，要求三个工作日内补全。接收方对回滚步骤缺失选择不接受，要求补充后再签署；对账号权限说明选择书面接受，写明由建设方在观察期内补全并承担相应风险。
阻断级问题修复后复测通过，双方授权签署人签署确认文件，观察期设为两周。观察期内接收方按部署手册完成一次演练，建设方补充了回滚步骤，账号权限说明按期补全。观察期结束，双方确认遗留问题全部关闭，移交完成，后续问题转入正式支持流程。
移交完成检查清单
以下检查项用于判断一次交付服务移交是否完成。任一项不满足且无书面例外说明时，不应认定移交完成。
| 检查类别 | 检查项 | 判定依据 |
|---|---|---|
| 交付物齐套性 | 清单内文档、环境、账号、数据、服务承诺均已就绪 | 移交清单无“待补充”项，或待补充项不影响本次核验 |
| 验收标准达成证据 | 每条验收标准均有核验结论和证据 | 核验记录表逐条对应，无“未核验”项 |
| 遗留问题闭环或书面接受 | 阻断级问题全部关闭，其余问题有责任人和时限或书面接受记录 | 问题清单及处置结论 |
| 签署与归档 | 双方授权签署人完成书面确认，文件已归档 | 签署确认文件，双方各持一份 |
| 观察期结果确认 | 观察期内遗留问题关闭或转入正式支持，服务响应达到承诺 | 观察期结果记录，双方确认 |
阻断条件包括：存在未关闭的阻断级问题；验收标准中有未核验项；接收方未签署确认文件；观察期内出现影响核心业务的问题且未处置。出现任一阻断条件时，移交停留在当前步骤，待条件消除后继续。检查清单可在签署前和观察期结束时各执行一次，两次结果均通过，移交才算完整结束。
常见问题
接收方对某条未达标项选择书面接受，需要写清哪些内容？
书面接受记录至少写明三项：未达标的具体条目和当前状态、接受的理由、风险由哪一方承担。同时约定补全或改进的责任人、时限和验证方式，并纳入遗留问题清单跟踪。书面接受只适用于非阻断级问题，阻断级问题应先解决再进入签署。
观察期应该设多长，什么情况下可以提前结束？
观察期长度按交付复杂度和服务承诺确定，常见做法是两周到一个月。提前结束的前提是遗留问题全部关闭或已转入正式支持流程，且接收方在观察期内未反馈影响核心业务的问题。若观察期内出现阻断级问题，应延长观察期并重新确认结果，而不是直接认定移交完成。
移交过程中范围发生变更，怎么处理才不影响签署？
范围变更应记录变更原因、影响到的交付物和验收标准、双方确认人，并由决策与签署角色审批。变更后的范围说明和验收标准表作为新基线，核验记录同步调整。未走变更记录的临时口头调整，不作为签署依据，避免签署时对“交了什么”产生分歧。
移交清单、核验记录和遗留问题分散在邮件和表格里，怎么保证状态一致？
可以把清单、核验记录和遗留问题放到同一套工作项和文档中承载，按状态流转并保留处理记录，减少多份表格之间的状态失真。ONES 的需求、基线、版本、变更、测试与发布管理可将交付物与需求链路关联，出现问题时便于定位影响范围。具体字段和流程配置需按团队实际流程确定。
移交完成后，接收方在观察期外又提出新问题，还算移交未完成吗？
不算。观察期结果经双方确认后，移交即告完成，后续问题转入正式支持流程，按服务承诺中的响应时限和升级路径处理。若新问题属于本次移交范围内的未达标项且此前已有书面接受记录，则按接受记录中约定的责任和时限处理，不重新开启移交。
