研发工具迁移的业务验收，核心是确认新系统中的研发数据、流程和协作关系能否支撑团队正常开展工作。验收应覆盖六类场景：工作项与状态流转、需求到交付的追溯链、权限与角色可见性、附件与富文本内容、通知与集成触达、报表与历史查询。这份清单供业务负责人、研发团队代表和工具管理员在试迁移完成后、正式切换前以及切换后观察期使用，每项检查都配有通过标准、证据形式和负责人，并标出会阻断上线的项目。
要点总览（TL;DR）
- 研发工具迁移的业务验收覆盖六类场景：工作项与状态流转、需求到交付的追溯链、权限与角色可见性、附件与富文本内容、通知与集成触达、报表与历史查询。
- 通过标准要写成可判定的表述：数量一致、字段完整率、状态映射正确率用计数和比例，流程类用真实账号走通确认，无法量化的写明判定人和口径。
- 阻断项指核心工作项丢失、越权可见、追溯链大面积断裂、关键附件无法打开等会导致业务无法开展或数据错误的问题，关闭并复检通过后才能切换。
- 验收在试迁移完成后、正式切换前、切换后观察期三个时点执行，每项检查留截图、导出比对表、抽样记录或流程走查记录，由业务侧负责人签署结论。
谁在什么时点使用这份验收清单
验收清单在三个时点使用，每个时点的检查重点和参与角色不同。试迁移完成后，重点确认样本数据和比对基准可用；正式切换前，逐项核对六类业务场景；切换后观察期，复检真实使用中暴露的问题。业务侧负责人对验收结论签字，研发团队代表负责走通实际业务流程，工具管理员负责环境、数据和权限的技术核对。
需要区分验收与相邻工作的分工：数据映射设计和字段转换规则在迁移方案阶段确定，验收只核对映射结果是否符合预期；人员推广和治理机制在切换后另行推进，验收只确认新系统具备支撑团队工作的基本条件。验收清单不替代迁移方案，也不替代上线后的运营计划。
| 角色 | 试迁移完成后 | 正式切换前 | 切换后观察期 |
|---|---|---|---|
| 业务侧负责人 | 确认验收范围与样本项目清单 | 确认六类场景检查结论，签署放行意见 | 确认遗留项关闭情况 |
| 研发团队代表 | 提供典型业务流程和样本工作项 | 实际走通需求到交付的完整流程 | 反馈真实使用中的异常 |
| 工具管理员 | 核对试迁移环境与正式环境一致性 | 执行数据比对、权限核验和集成检查 | 执行复检并更新遗留清单 |
迁移前准备检查：验收环境和样本是否就绪
正式验收前要先确认三件事：环境可判断、样本有代表性、基准可回溯。缺少任何一项，验收结论都会失去依据。准备阶段由工具管理员牵头，业务侧负责人确认样本范围。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 试迁移环境与正式环境一致性 | 版本、插件、权限模型、流程配置与计划中的正式环境一致，差异项已列明并有处理结论 | 环境配置对照表 | 工具管理员 |
| 抽样范围覆盖度 | 样本至少覆盖：一个完整项目、包含多种工作项类型的批次、带附件的记录、有历史状态变更的工作项 | 抽样清单 | 工具管理员、业务侧负责人 |
| 旧系统基准留存 | 旧系统只读快照或导出文件已归档，可随时比对 | 快照或导出文件及归档记录 | 工具管理员 |
| 验收负责人和记录方式 | 每类场景有明确检查人，记录模板已下发，证据命名规则已约定 | 验收分工表、记录模板 | 业务侧负责人 |
样本选择要偏向业务上重要的项目，而非随机抽取。核心产品线的项目、跨团队协作的工作项、历史状态变更频繁的记录，更能暴露迁移问题。旧系统基准应在迁移开始前留存，迁移后再补做会失去比对意义。
业务场景检查项：六类场景逐项核对
六类场景构成业务验收的主体。每类场景给出检查动作、通过标准、证据形式和负责人，检查人按表逐项判定“通过”或“不通过”，不通过项进入问题清单。
| 场景 | 检查动作 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|---|
| 工作项字段、类型与状态流转 | 抽取样本工作项，核对字段值、工作项类型、状态名称与流转路径 | 字段完整率达到约定阈值，状态映射与旧系统一致，流转路径可走通 | 字段比对表、状态映射表、流转截图 | 工具管理员 |
| 需求—任务—缺陷—测试追溯链 | 从一条需求出发，逐层查看关联任务、缺陷和测试用例，再反向回溯 | 关联关系完整，双向可追溯，断链数量为零或已登记 | 追溯链截图、断链清单 | 研发团队代表 |
| 角色权限与可见范围 | 用不同角色账号登录，检查项目可见性、字段权限和操作权限 | 无越权可见，无权限缺失导致流程中断 | 权限矩阵对照表、账号检查记录 | 工具管理员 |
| 附件、图片与富文本正文 | 抽查带附件和富文本的工作项、文档页面 | 附件可下载打开，图片正常显示，正文格式无错乱或丢失 | 抽样截图、附件清单 | 工具管理员 |
| 通知、提醒与外部集成触达 | 触发状态变更、评论、指派等动作，检查通知送达和集成消息 | 通知按规则送达，集成消息内容正确、无重复或遗漏 | 通知记录截图、集成日志 | 工具管理员 |
| 报表、看板与历史数据查询 | 打开常用报表和看板，按时间范围查询历史数据 | 统计口径与旧系统一致或在容差内，历史数据可查、结果稳定 | 报表截图、口径对照说明 | 业务侧负责人 |
追溯链检查要双向进行：从需求向下查到测试，再从测试向上回溯到需求。单向检查容易漏掉关联缺失。权限检查应使用真实角色账号，而非管理员账号，管理员视角会掩盖越权问题。通知与集成检查要覆盖团队日常依赖的触达渠道，包括站内通知和已接入的外部协作工具。
在验收执行环节，检查记录本身也需要承载位置。以ONES为例，迁移范围可覆盖项目、工作项、状态、字段、流程、附件和历史记录，验收中发现的问题可以直接登记为工作项，附上截图和比对表，指定负责人和期限，状态流转记录检查进度。测试用例与需求、任务的关联能力也可用于核对追溯链是否完整。是否提供内置的迁移比对报告，需要在选型或实施阶段向服务方确认。
通过标准怎么写才可判断
通过标准要写成检查人能直接判定“是”或“否”的表述。可计数的用数量和比例，可走通的用流程完成确认，两者都不适用的才用定性口径，并写明判定人。
| 检查项 | 模糊写法 | 可判定写法 |
|---|---|---|
| 工作项数量 | 数据基本完整 | 抽样项目的工作项总数与旧系统一致，差异项逐条列明原因 |
| 字段完整性 | 字段迁移正常 | 抽样工作项的关键字段完整率不低于约定阈值，缺失字段有登记 |
| 状态映射 | 状态对应正确 | 抽样工作项的状态映射正确率达标，错误映射逐条修正或登记 |
| 追溯链 | 关联关系保留 | 抽样需求的双向追溯链完整，断链数量为零或已列入遗留清单 |
| 流程走通 | 使用体验良好 | 研发团队代表用真实账号完成一条需求从创建到关闭的完整流程，无阻断 |
| 报表口径 | 报表数据准确 | 选定报表在相同时间范围下与旧系统结果一致，或在约定容差内且差异可解释 |
抽样比对要事先约定容差。数量类指标通常要求完全一致，差异必须逐条说明；比率类指标可设定阈值，但阈值应在验收前确定，避免验收时临时调整。无法量化的场景，例如通知是否“及时”，用业务人员实际走通流程并确认收到通知作为判定口径，由检查人签字确认。
证据留存与负责人分工
每项检查都要留下可复查的证据，证据与检查项一一对应，由检查人签字。证据的作用是在切换后出现争议时能回溯当时的判断依据。
| 证据类型 | 适用检查项 | 留存人 | 归档与命名 |
|---|---|---|---|
| 截图 | 状态流转、权限可见性、附件显示、通知送达 | 工具管理员 | 按“场景-检查项-日期”命名，存入验收归档目录 |
| 导出比对表 | 工作项数量、字段完整性、报表口径 | 工具管理员 | 保留原始导出文件和比对结果两个版本 |
| 抽样记录 | 样本项目、工作项、附件的选取过程 | 业务侧负责人确认 | 记录抽样规则和样本清单 |
| 流程走查记录 | 需求到交付的完整流程走通 | 研发团队代表 | 记录走查步骤、结果和确认人 |
验收结论由业务侧负责人签署，工具管理员附技术核对意见，数据迁移执行人提供迁移执行记录作为支撑。签署方式可以是验收会议纪要加签字，也可以是验收系统中的状态确认，关键是结论、证据和签署人三者对应，可追溯到具体检查项。
阻断项与完成条件
阻断项是未关闭就不能切换上线的问题。判定阻断的标准是：该问题会导致核心业务无法开展，或造成数据错误、权限泄露等不可接受后果。其余问题列为遗留项，明确责任人和期限后可以带项切换。
| 类别 | 示例 | 处理方式 |
|---|---|---|
| 阻断项 | 核心项目工作项丢失；普通角色可越权查看受限项目；需求到测试的追溯链大面积断裂；关键附件无法打开 | 关闭后方可切换，关闭需复检确认 |
| 非阻断项 | 个别历史报表口径差异可解释；少量非关键字段格式变化；边缘集成通知延迟 | 列入遗留清单，明确责任人和完成期限 |
整体验收完成的条件是：阻断项全部关闭并复检通过，遗留项全部有责任人和期限，验收结论已签署。切换后观察期内安排复检，重点复查阻断项是否复发、遗留项是否按期关闭，以及真实使用中是否出现验收样本未覆盖的问题。复检结果更新到同一份验收记录中，形成从试迁移到观察期的完整闭环。
常见问题
验收时抽样应该抽多少、抽哪些项目？
抽样数量没有统一标准，按迁移规模和风险确定。样本要覆盖一个完整项目、包含多种工作项类型的批次、带附件的记录、有历史状态变更的工作项，并优先选择核心产品线和跨团队协作的项目。样本清单在准备阶段由业务侧负责人确认，抽样规则和选取过程留记录，便于后续复查。
旧系统已经下线，还能补做验收比对吗？
比对基准需要在迁移开始前留存，旧系统只读快照或导出文件归档后才能支撑验收。旧系统已下线时，可改用迁移前导出的数据文件、历史报表截图或业务人员保存的工作记录作为参照，但覆盖范围有限，结论要注明依据来源和局限。这类情况应在验收结论中单独说明，不宜直接按完整比对判定通过。
非阻断的遗留项带项切换后，观察期怎么跟踪？
遗留项要逐条登记责任人和完成期限，进入同一份验收记录。切换后观察期安排复检，重点复查阻断项是否复发、遗留项是否按期关闭，以及真实使用中出现的新问题。复检结果更新到原记录中，遗留项到期未关闭的，由业务侧负责人决定是否升级处理。
验收记录用什么方式承载比较合适？
记录方式取决于团队现有工具。可以用验收会议纪要加签字，也可以在研发管理系统中把每个不通过项登记为工作项，附截图和比对表，指定负责人和期限，用状态流转记录检查进度。以ONES为例，迁移范围可覆盖项目、工作项、状态、字段、流程、附件和历史记录，测试用例与需求、任务的关联能力可用于核对追溯链是否完整；是否提供内置的迁移比对报告，需要在选型或实施阶段向服务方确认。
验收通过后，切换上线还需要哪些确认？
验收结论签署只代表迁移结果满足放行条件。切换上线前还需确认阻断项全部关闭并复检通过、遗留项有责任人和期限、切换窗口和回退方案已确定。人员推广和治理机制在切换后另行推进，不属于本次验收范围，但上线计划中要明确衔接安排。
