旧工具能力对照表的价值，在于把“旧工具还能不能用、哪些必须换、先换什么”变成可核查的记录。本文给出一套可直接复制的表头结构，按“圈定范围—采集证据—判断差距—给出处置”四步填写，并说明角色分工、示例写法和验收检查，帮助对照表最终支撑替换范围界定与优先级排序。表格落地后需要一个承载能力项与处置状态的管理载体，可在流程衔接处使用ONES记录与流转。
要点总览（TL;DR）
- 对照表以能力项为行，按需求、任务、缺陷、文档、报表、权限、集成、审计等能力域分组，避免照搬旧工具菜单结构。
- 每行固定旧工具现状、目标要求、差距判断、处置建议四类核心列，另设证据来源列，状态统一为支持、部分支持、不支持、未确认四档。
- 填写按圈定范围、采集证据、判断差距、给出处置四步推进，每步明确输入、输出、完成标志和负责人。
- 业务使用方、工具管理员、架构或平台负责人、采购或预算方分工提供证据、复核差距和确认成本前提，评审会形成决策记录。
- 验收看覆盖度、证据可追溯、口径一致和能否直接导出替换清单与优先级，未确认项单独列出并指定核实人。
对照表先定口径：行、列与证据来源
建表前先固定两件事：能力项按什么维度分组，每一格写到什么程度算合格。口径不统一，后面填出来的表就无法横向比较，也无法直接导出替换范围。
行：按能力域分组，不照搬旧工具菜单
能力项是表格的行。建议按业务能力域分组，而不是按旧工具的菜单结构逐条抄写。菜单结构反映的是旧工具的实现方式，按它建表容易把“旧工具怎么做的”当成“业务需要什么”。常用分组包括：需求管理、任务与计划、缺陷管理、文档与知识、报表与度量、权限与角色、集成与接口、审计与留痕。每个能力域下再列具体能力项，例如缺陷管理下可分“缺陷状态流转”“缺陷与需求关联”“缺陷导出与统计”。
列：四类核心列加证据列
每行固定四类核心列，另设证据来源列，保证每个判断可追溯。可直接使用下表结构：
| 列名 | 填写内容 | 写法要求 |
|---|---|---|
| 能力域 | 所属分组，如缺陷管理 | 从固定分组中选取，不临时新增 |
| 能力项 | 具体能力，如“缺陷状态自定义流转” | 一个能力项只描述一件事 |
| 旧工具现状 | 当前实际做到的程度 | 写清操作路径与实际表现，不写功能名了事 |
| 目标要求 | 替换后必须达到的程度 | 来自业务场景与流程要求，不来自旧工具现状 |
| 差距判断 | 现状与目标的差异及影响 | 说明差异点和对业务的具体影响 |
| 处置建议 | 保留、替换、补齐或暂缓 | 四选一，附一句理由 |
| 证据来源 | 支撑现状判断的材料位置 | 标注类型与位置，如截图、操作路径、访谈记录、导出样例 |
| 状态 | 支持、部分支持、不支持、未确认 | 四档统一写法，未确认项单独标记 |
状态口径与证据标注的统一写法
状态只用四档：支持，指旧工具在当前使用方式下已满足目标要求；部分支持，指核心动作可用但存在明确限制；不支持，指经核实无法满足；未确认，指尚未取得足够证据。未确认项必须写明核实人和计划核实时间，不能因为没查到就填“不支持”。证据标注建议统一为“类型＋位置”，例如“截图：缺陷状态配置页”“访谈：测试组负责人 3 月 12 日”“导出样例：近三个月缺陷流转记录”。同一能力项有多份证据时并列标注，便于评审时抽查。
按输入、动作、输出填完一张对照表
表格结构确定后，按四步推进。每一步都有明确输入、动作、输出和完成标志，避免多人协作时反复返工。
第一步：圈定评估范围与旧工具使用清单
输入是本次替换涉及的团队、业务流程和旧工具清单。动作是列出所有在用旧工具及其承载的业务环节，明确本次评估覆盖哪些团队和流程、哪些暂不纳入。输出是一份范围说明加旧工具使用清单，注明每款工具的使用团队、主要用途和用户规模。完成标志是业务方书面确认范围，负责人为业务使用方代表。范围不清会导致后续证据采集发散，这一步不宜省略。
第二步：逐能力项采集现状证据
输入是范围说明、能力项分组和旧工具使用清单。动作是按能力项逐条操作旧工具，记录实际表现，保存截图、操作路径或导出样例，对关键使用人做简短访谈并记录。输出是填好“旧工具现状”和“证据来源”两列的初稿。完成标志是每个能力项都有至少一份可追溯证据，负责人为工具管理员，业务使用方配合提供场景。证据缺失的能力项标为未确认，进入待核实清单。
第三步：对照目标要求标注差距与影响
输入是现状初稿和业务方提出的目标要求。动作是逐项写出目标要求，与现状对比后填写差距判断，说明差异点以及对业务的具体影响，例如“缺陷状态无法按项目自定义，导致跨项目统计口径不一致，月度质量报表需人工合并”。输出是填好“目标要求”和“差距判断”两列的版本。完成标志是差距描述能被业务方和架构负责人同时理解，负责人为架构或平台负责人复核。
第四步：给出处置建议并定稿
输入是完成差距判断的对照表。动作是对每个能力项给出保留、替换、补齐或暂缓四类处置之一，并写明理由和后续动作，例如“替换：纳入新方案必选能力”“补齐：由现有工具配置调整解决”“暂缓：使用频率低，下阶段再评估”。输出是可提交评审的对照表定稿和处置建议汇总。完成标志是评审会形成决策记录，负责人为评审召集人。四类处置的含义需要在评审前统一，避免同一词在不同行里指向不同动作。
角色分工与各阶段交付物
对照表由单人闭门填写，容易变成功能罗列。把证据提供、差距判断和处置拍板分给不同角色，表格才具备决策效力。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 业务使用方 | 提供真实使用场景，确认评估范围，核对差距对业务的影响 | 范围确认记录、场景说明、差距影响确认意见 |
| 工具管理员 | 操作旧工具复现能力表现，导出配置与使用数据 | 现状证据包（截图、操作路径、导出样例）、未确认项清单 |
| 架构或平台负责人 | 复核差距判断，评估处置建议的技术可行性 | 差距复核意见、技术可行性说明 |
| 采购或预算方 | 确认处置建议涉及的成本前提与采购节奏 | 成本前提说明、处置建议的预算意见 |
评审会议的输入材料包括：对照表定稿、证据包索引、未确认项清单和处置建议汇总。会议输出为决策记录，逐项写明结论、责任人和后续动作时间。决策记录与对照表同版本保存，后续范围调整时同步更新，避免表格与结论脱节。
填写示例：一条缺陷管理能力项
下面以“缺陷状态自定义流转”为例，展示一条合格的能力项从现状到处置的完整写法。
| 字段 | 示例内容 |
|---|---|
| 能力域 | 缺陷管理 |
| 能力项 | 缺陷状态自定义流转 |
| 旧工具现状 | 状态为固定五档，项目管理员无法增删；流转规则仅支持按角色限制，无法按缺陷类型区分 |
| 证据来源 | 截图：缺陷状态配置页；操作路径：项目设置—缺陷—状态；访谈：测试组负责人 3 月 12 日 |
| 目标要求 | 不同产品线可自定义状态集，流转规则可按缺陷类型和严重级别区分，变更留痕可查 |
| 差距判断 | 状态集不可自定义，导致硬件与软件两条产品线共用一套状态，统计口径不一致，月度缺陷报表需人工拆分，影响约两个工作日 |
| 处置建议 | 替换：纳入新方案必选能力，验收时以两条产品线各自跑通一次完整流转为准 |
| 状态 | 不支持 |
常见写法问题有三类。只写功能名，如“缺陷状态：有”，没有说明实际表现和限制，评审时无法判断差距。不写证据，现状描述无法核实，争议时只能重新操作一遍。差距描述含糊，如“不太满足需求”，没有说明差异点和对业务的具体影响，处置建议就缺少依据。合格写法的共同点是：现状可复现、证据可追溯、差距可量化到具体影响、处置可落到验收动作。
当对照表进入执行阶段，能力项、证据位置和处置状态需要在团队间持续同步。ONES 可用于承载这类能力项清单与处置状态，把评审结论、责任人和后续动作记录在同一处，便于替换范围确定后跟踪各项处置的推进情况。
完成检查：对照表能否支撑替换决策
对照表提交评审前，按以下清单逐项检查。全部通过才视为可用状态。
- 覆盖度：需求、任务、缺陷、文档、报表、权限、集成、审计等能力域是否都有对应行；高频使用场景是否全部覆盖；范围说明中列出的旧工具是否都有对应能力项。
- 证据可追溯：每行是否至少有一份证据来源；证据标注是否能定位到具体截图、路径或访谈记录；抽查任意三行能否在十分钟内找到原始材料。
- 口径一致：状态是否只使用支持、部分支持、不支持、未确认四档；处置建议是否只使用保留、替换、补齐、暂缓四类；同一能力项在不同行中的描述粒度是否接近。
- 可直接导出决策：能否按处置建议筛出替换清单并排出优先级；能否按状态筛出未确认项；差距判断是否能对应到验收标准。
- 阻断项处理：未确认项是否单独列出并指定核实人和时间；是否存在把未确认直接写成不支持的情况；未确认项是否在评审记录中明确了后续核实计划。
检查中发现覆盖缺口时，补充能力项后需重新走一遍证据采集；发现口径不一致时，统一修改后再提交评审。对照表通过检查的标志是：评审会能直接依据它确定替换范围、排出迁移优先级，并把关键差距转化为验收标准。
常见问题
对照表里出现“未确认”的能力项，评审时应该怎么处理？
未确认项不能默认写成“不支持”，也不能在评审时直接跳过。建议单独列一张待核实清单，写明能力项、已尝试的核实方式、核实人和计划完成时间。评审会可以先把未确认项排除在替换范围之外，但要在决策记录中注明后续核实计划，核实完成后再回填对照表并同步更新处置建议。如果未确认项涉及关键业务场景，应优先安排核实，避免替换范围在后期反复调整。
评估范围里有多款旧工具，能力项要不要按工具分别建表？
建议用一张总表，通过“所属旧工具”列区分，而不是每款工具各建一张表。分表容易造成同一能力项在不同表中口径不一致，也无法横向比较哪款工具的能力缺口更集中。总表可以按能力域分组，同一能力项下并列多款工具的现状，差距判断和处置建议按工具分别填写。如果某款工具只覆盖少量环节，可以在范围说明中注明其评估深度，避免与其他工具同等对待。
目标要求由谁提出，和旧工具现状冲突时以哪个为准？
目标要求应来自业务场景和流程要求，由业务使用方提出、架构或平台负责人复核，不能从旧工具现状反推。两者出现冲突时，以目标要求为准，旧工具现状只作为差距判断的输入。实际操作中常见的情况是业务方习惯旧工具的做法，把现状当成要求，这时需要在评审前把“业务必须达到的程度”和“当前习惯的做法”分开讨论，必要时请流程负责人确认哪些要求属于硬性约束。
对照表做完后，替换范围调整了怎么维护？
对照表应与决策记录同版本保存，范围调整时同步更新对应能力项，而不是另起一份新表。建议在表中增加版本号和更新记录，注明每次调整涉及的能力项、调整原因和确认人。范围扩大时补充能力项并重新采集证据；范围缩小时保留原行并标注“本次不纳入”，便于后续追溯。处置建议发生变化的能力项，需要重新走一次评审确认，避免表格与最终执行范围脱节。
能力项颗粒度怎么把握，太细和太粗各有什么问题？
颗粒度以“一个能力项只描述一件事、能独立判断差距和处置”为准。太粗如“缺陷管理”，现状和差距无法写具体，处置建议也只能笼统；太细如把每个字段都单列一行，表格会膨胀到难以评审，且大量行共享同一结论。可参考的写法是：缺陷管理下分“缺陷状态自定义流转”“缺陷与需求关联”“缺陷导出与统计”，每项都能对应到具体操作路径和验收动作。填写过程中发现某行无法独立给出处置建议，通常说明还需要拆分或合并。
