旧工具能力对照表用于在替换或迁移研发管理工具前，把旧工具的实际使用情况逐项记录成可横向比较的表格。本文提供一张可直接复制到表格工具中的空白模板，主线字段为“能力项—旧工具现状—使用程度—迁移影响—目标要求”，并配套字段说明、必填与选填规则、一份完整填写示例和维护方法，便于盘点人员按同一口径填写。
要点总览（TL;DR）
- 模板主线字段为“能力分类—能力项—旧工具现状—使用程度—迁移影响—目标要求—证据来源—备注”，空白表、字段说明与示例表保持同一口径。
- 最低可用集是能力项、旧工具现状、使用程度、迁移影响四列；目标要求在进入迁移方案阶段后转为必填，证据来源在高风险项和争议项上建议填写。
- 使用程度回答团队依赖强度，迁移影响回答替换处理成本，两者分开判断，避免把低频但涉及数据迁移的能力误判为低影响。
- 示例表覆盖需求、缺陷、迭代、文档、权限、报表、集成等能力行，展示高频核心项优先进入首批迁移讨论的判断方式。
- 按团队规模与流程复杂度裁剪能力项，并按盘点、方案设计、实施验收三个阶段维护版本，高风险行可直接转为迁移清单任务。
可复制空白模板：旧工具能力对照表
下表可直接复制到 Excel、在线表格或文档表格中。第一行为表头，第二行为分组示例行，其余为空白行。能力分类用分组行区分模块，同一分类下的能力项连续填写，便于按模块统计迁移工作量。
| 能力分类 | 能力项 | 旧工具现状 | 使用程度 | 迁移影响 | 目标要求 | 证据来源 | 备注 |
|---|---|---|---|---|---|---|---|
| 【分组行示例：需求管理】 | |||||||
| 需求管理 | |||||||
| 需求管理 | |||||||
| 【分组行示例：缺陷管理】 | |||||||
| 缺陷管理 | |||||||
| 缺陷管理 | |||||||
| 【分组行示例：迭代与计划】 | |||||||
| 迭代与计划 | |||||||
| 【分组行示例：文档与知识】 | |||||||
| 文档与知识 | |||||||
| 【分组行示例：权限与组织】 | |||||||
| 权限与组织 | |||||||
| 【分组行示例：报表与统计】 | |||||||
| 报表与统计 | |||||||
| 【分组行示例：集成与扩展】 | |||||||
| 集成与扩展 | |||||||
表格下方预留填写说明区，建议包含三项内容：本表的填写责任人、填写截止时间、以及“使用程度”和“迁移影响”的取值定义。说明区与主表放在同一文件内，避免填写人各自理解不同。
字段说明：每一列记录什么、怎么填
八个字段中，能力分类与能力项负责定位“盘点什么”，旧工具现状与使用程度负责描述“现在怎么用”，迁移影响与目标要求负责判断“换的时候要处理什么”，证据来源与备注负责支撑复核。各字段的填写口径如下。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 能力分类 | 能力所属的模块分组 | 从团队约定的分类清单中选择，不临时新造分类名；同一分类的写法保持一致 | 需求管理 |
| 能力项 | 一条可独立判断的具体能力 | 写到可观察的动作或对象层面，避免“项目管理”这类过大的词；一行只写一项 | 需求状态流转与审批 |
| 旧工具现状 | 旧工具中该能力的实际使用情况 | 描述当前配置与用法，写事实不写评价；包含关键配置项和实际使用范围 | 使用自定义状态6个，需求变更需两级审批 |
| 使用程度 | 该能力在团队中的依赖强度 | 按统一取值填写，建议四档：高频核心、常规使用、少量使用、基本未用；依据实际使用人数或频次判断 | 高频核心 |
| 迁移影响 | 替换后对该能力的影响程度 | 结合使用程度与替代难度判断，建议三档：高（影响主流程，需专项方案）、中（需配置调整或培训）、低（可平移或可放弃） | 高 |
| 目标要求 | 新工具中该能力需要达到的状态 | 写成可验收的要求，说明必须保留、可以简化或可以取消；进入迁移方案阶段后必须填写 | 保留两级审批，状态数量可精简至4个 |
| 证据来源 | 支撑该行判断的依据出处 | 填写截图位置、配置页面、访谈记录或数据导出文件名，便于复核时追溯 | 旧系统状态配置截图（2024-05导出） |
| 备注 | 补充说明 | 记录争议点、待确认事项或关联的其他能力行 | 审批人离职，需确认现任审批人 |
使用程度与迁移影响需要分开判断：使用程度回答“团队有多依赖”，迁移影响回答“替换时要付出多少处理成本”。一项能力使用频率不高但涉及历史数据迁移，迁移影响仍可能为高。目标要求则从新工具视角写，避免直接抄旧工具现状，否则对照表会失去比较意义。
必填与选填：哪些字段不能空
对照表字段较多，全部填满会拖慢盘点进度。建议按“最低可用集”先完成一轮，再按阶段补充。最低可用集为：能力项、旧工具现状、使用程度、迁移影响。这四列缺失时，表格无法支撑迁移优先级判断。
| 字段 | 填写属性 | 缺失后果 | 适用阶段 |
|---|---|---|---|
| 能力分类 | 必填 | 无法按模块汇总工作量，分组统计失真 | 全部阶段 |
| 能力项 | 必填 | 该行无法被识别和比对 | 全部阶段 |
| 旧工具现状 | 必填 | 无法判断替代方案是否覆盖实际用法 | 全部阶段 |
| 使用程度 | 必填 | 无法排序迁移优先级 | 全部阶段 |
| 迁移影响 | 必填 | 无法识别高风险项，方案容易漏项 | 全部阶段 |
| 目标要求 | 阶段必填 | 进入方案设计后缺少验收依据 | 迁移方案阶段起必填 |
| 证据来源 | 选填 | 争议项复核时缺少追溯依据 | 争议项、高风险项建议填写 |
| 备注 | 选填 | 待确认事项容易散落在聊天记录中 | 按需填写 |
按替换阶段区分必填范围：盘点阶段只需保证前五列完整；方案设计阶段补目标要求；实施与验收阶段回填证据来源，用于核对新工具配置是否满足要求。证据来源在两种情况下建议转为必填：该行迁移影响为高，或填写人与复核人对现状描述存在分歧。
填写示例：一份完整的旧工具能力对照表
以下为演示情景：某约30人的研发团队计划替换旧研发管理工具，由项目负责人牵头、各模块负责人分头填写。示例中的工具配置与团队情况为示意，用于展示字段如何联动，不代表真实客户案例。
| 能力分类 | 能力项 | 旧工具现状 | 使用程度 | 迁移影响 | 目标要求 | 证据来源 | 备注 |
|---|---|---|---|---|---|---|---|
| 需求管理 | 需求状态流转与审批 | 自定义状态6个，需求变更需产品与测试两级审批 | 高频核心 | 高 | 保留两级审批，状态精简为4个并统一命名 | 旧系统状态配置截图 | 审批人变更需同步更新 |
| 需求管理 | 需求与客户反馈关联 | 通过标签手工关联，未建立固定字段 | 少量使用 | 低 | 可用自定义字段实现，不要求历史关联全部迁移 | 标签使用记录导出 | 历史关联仅保留近一年 |
| 缺陷管理 | 缺陷严重程度与优先级 | 两级字段，取值各4档，测试提单时必填 | 高频核心 | 中 | 保留两级字段，取值映射关系需逐项确认 | 字段配置截图 | 取值映射表另附 |
| 缺陷管理 | 缺陷与版本关联 | 手工填写版本号文本，无下拉选择 | 常规使用 | 中 | 改为版本字段关联，历史文本需清洗后导入 | 近三个月缺陷导出文件 | 存在格式不统一问题 |
| 迭代与计划 | 迭代周期与燃尽统计 | 双周迭代，按故事点统计剩余工作量 | 高频核心 | 高 | 保留双周节奏与故事点口径，统计视图需可复现 | 迭代报表截图 | 统计口径需与财务口径区分 |
| 文档与知识 | 需求文档存放与版本 | 文档存放在旧工具附件中，版本靠文件名区分 | 常规使用 | 中 | 文档独立管理并保留版本记录，附件按需求归档 | 附件目录导出清单 | 需确认历史附件保留范围 |
| 权限与组织 | 项目级角色权限 | 按项目设置4类角色，跨项目权限需单独授权 | 常规使用 | 中 | 保留项目级角色划分，跨项目授权规则需重新梳理 | 权限配置截图 | 存在个别超范围授权 |
| 报表与统计 | 团队工作量统计 | 按人统计每周关闭工作项数量，管理层每周查看 | 常规使用 | 低 | 保留按人统计口径，报表可导出 | 周报截图 | 统计周期需确认 |
| 集成与扩展 | 代码提交与工作项关联 | 通过提交信息中的编号手工关联 | 少量使用 | 低 | 保留编号关联方式即可，不要求自动同步 | 提交记录样例 | 研发自行维护 |
解读这份示例时注意三点。第一，使用程度为“高频核心”的行，迁移影响普遍为高或中，这些行应进入首批迁移方案讨论；使用程度为“少量使用”的行，迁移影响可以为低，允许在新工具上线后按需补充。第二，目标要求写的是新工具需要达到的状态，例如“状态精简为4个”，与旧工具现状形成对照，而不是照搬现状。第三，证据来源集中出现在高风险行和存在数据清洗需求的行，便于复核时快速定位原始配置。
调整与维护方法：按团队情况改表并持续更新
模板提供的是通用结构，实际使用时应按团队规模和流程复杂度裁剪能力项，并在替换推进过程中维护版本。裁剪的原则是：能力项覆盖团队真实依赖的流程，不追求分类齐全。
- 按团队规模裁剪。十人左右的小团队可合并“报表与统计”“集成与扩展”分类，保留需求、缺陷、迭代、文档、权限五类；五十人以上、多项目并行的团队建议保留全部分类，并在权限分类下细分项目级与组织级。
- 按流程复杂度增删能力项。有正式评审流程的团队增加“评审与审批”能力项；采用持续交付的团队增加“发布与回滚”能力项；流程简单的团队可删除审批相关行，避免表格空转。
- 新增自定义字段的命名约定。字段名采用“对象+属性”结构，如“缺陷+发现版本”；取值定义写在表格说明区，不在不同行中使用同义不同名的写法；新增字段需在表头注明填写人和启用时间。
维护节奏建议与替换阶段对齐：盘点启动时锁定字段版本；每轮盘点结束后由负责人合并重复行、修正分类；进入方案设计后冻结能力项清单，只允许补充备注和目标要求；上线验收后归档为历史版本。版本记录可采用“文件名+日期+版本号”的方式，并在说明区记录每次变更的内容和原因。
| 阶段 | 维护动作 | 产出 |
|---|---|---|
| 盘点启动 | 确定字段版本、分类清单和填写责任人 | 空白模板与填写说明 |
| 盘点进行中 | 每周合并重复行，统一取值写法 | 更新后的对照表 |
| 方案设计 | 冻结能力项，补全目标要求 | 带目标要求的对照表 |
| 实施与验收 | 回填证据来源，核对新工具配置 | 可追溯的验收记录 |
对照表完成后，可将其中的高风险行和待确认事项转为迁移清单的输入：每一条迁移影响为高的能力项对应一个迁移任务，目标要求作为验收标准，证据来源作为核对依据。评估记录、待确认事项和版本变更可以放在统一的工作项与文档中管理，由项目负责人维护状态，各模块负责人按分工更新，评审时直接引用同一份记录，减少表格在多处流转造成的口径不一致。
常见问题
团队第一次填这张表，应该先填全部字段还是先完成最低可用集？
建议先完成最低可用集，即能力项、旧工具现状、使用程度、迁移影响四列，再按阶段补充其他字段。第一次盘点时字段填得过全，容易把时间花在证据整理和措辞统一上，反而拖慢整体进度。可以先用一轮粗填确认能力项清单是否覆盖团队真实依赖的流程，第二轮再补目标要求和证据来源。
如果团队规模较小、能力项数量有限，也可以一次填完，但仍建议把目标要求留到方案设计阶段再写，避免在还没确定替代方案时过早锁定验收口径。
同一项能力在不同项目里用法不一样，应该合并成一行还是拆成多行？
判断标准是迁移处理方式是否相同。如果不同项目的用法差异只体现在配置取值上，处理方式一致，可以合并为一行，在“旧工具现状”中说明差异范围，在备注中列出涉及的项目。如果差异导致迁移动作不同，例如一个项目需要保留审批流、另一个项目可以取消审批，就应拆成多行，否则迁移影响和目标要求无法分别填写。
拆分后建议在备注中互相标注关联行，便于方案设计阶段合并讨论，避免同一项能力在迁移清单里被重复立项。
使用程度填“少量使用”的能力项，是否可以直接不迁移？
不能仅凭使用程度决定放弃。使用程度低说明当前依赖弱，但该项能力可能涉及历史数据、合规留痕或个别关键岗位的固定操作。更稳妥的做法是结合迁移影响一起判断：迁移影响为低且确认无历史数据依赖的，可以在新工具上线后按需补充；涉及历史记录查询或对外交付要求的，即使使用频率低，也应保留在迁移范围内。
对准备放弃的能力项，建议在备注中写明放弃理由和确认人，验收阶段再复核一次，避免上线后才发现有岗位仍在使用。
对照表填完后，怎么和迁移清单衔接？
常用的衔接方式是按迁移影响筛选：每一条迁移影响为高的能力项对应一个迁移任务，任务描述引用旧工具现状，验收标准引用目标要求，核对依据引用证据来源。迁移影响为中的能力项可以合并为配置调整或培训类任务，影响为低的项进入上线后观察清单。
衔接时保留原表的行编号，迁移清单中引用编号而不是重新描述能力项，可以减少两处口径不一致。评估记录和待确认事项放在统一的工作项与文档中管理，由项目负责人维护状态，各模块负责人按分工更新。
替换周期较长时，对照表需要多久更新一次？
更新节奏与替换阶段对齐比固定周期更实用。盘点启动时锁定字段版本；盘点进行中每周合并重复行、统一取值写法；进入方案设计后冻结能力项清单，只允许补充目标要求和备注；上线验收后归档为历史版本。
如果替换周期跨越数月，建议在每次阶段评审前做一次全表复核，重点检查使用程度是否因流程调整发生变化。版本记录采用“文件名+日期+版本号”，并在说明区写明每次变更的内容和原因，便于回溯判断依据。
