研发工具能力差距分析可以做成一次有证据的逐项比对：先按需求、测试、缺陷、知识等域建立现状能力清单，记录当前工具的实际做法与证据；再用同一套编号建立目标能力清单，写明期望做法与判定标准；然后逐项比对，把每项标为已满足、部分满足、缺失或待验证；最后按影响和成本排序，回答替换是否值得、先补哪几项。本文给出可直接执行的步骤、角色分工、缺陷域示例和完成检查清单。
要点总览（TL;DR）
- 差距分析的核心是两份对齐清单：按需求、测试、缺陷、知识等域拆出可判定的能力条目，用同一套编号分别建立现状清单和目标清单。
- 现状清单记录当前做法、覆盖范围和证据位置，并区分“工具支持但团队未用”与“工具本身做不到”，后者才是工具能力差距。
- 比对结论分为已满足、部分满足、缺失、待验证四类，每条附证据引用；证据不足的条目保留待验证，不直接判为不支持。
- 排序按对研发流程的影响程度和补齐成本两个维度进行，区分配置或流程可解决的差距与需要更换工具的差距，据此回答替换是否值得、先补哪几项。
- 分析由工具负责人牵头、各域负责人采集、关键角色复核，交付条目框架、现状清单、目标清单、差距表和替换判断说明。
先定比对口径：能力域与条目怎么拆
差距分析的第一步是确定比对口径。口径不统一，现状清单和目标清单就无法逐项对齐，后面的证据采集和结论排序都会失去基础。建议按研发流程的主要环节划分能力域，域下再拆成可判定的能力条目。
常见的域包括需求、测试、缺陷、知识四类，也可以根据本次替换判断的需要增加迭代计划、发布管理等域。划分域时遵循一个原则：只覆盖与替换判断相关的域。如果本次评估的核心疑问是“现有工具能否支撑需求到缺陷的闭环”，就不必把工时统计、文档模板等边缘功能全部纳入，否则条目过多会稀释结论。
条目写法决定比对能否落地。好的条目写成可观察的动作或产出，例如“缺陷登记包含复现步骤、影响版本、严重程度三个字段”“测试用例可以关联到需求条目”“需求变更后能追溯到受影响的测试用例”。这类描述有明确的判定对象，采集时能直接查看配置或样例。相反，“协作能力强”“体验好”“扩展性高”这类描述无法比对，应拆解为具体动作后再写入清单。
编号体系要统一。建议采用“域缩写-序号”的格式，例如 REQ-01、TEST-03、DEF-02、DOC-04。现状清单和目标清单使用同一套编号，比对时按编号逐行对照，避免两份清单各写各的、最后靠人工匹配。下表是条目框架的示例结构：
| 域 | 条目编号 | 能力条目 | 判定说明 |
|---|---|---|---|
| 需求 | REQ-01 | 需求条目可关联到下游任务与测试用例 | 在工具中打开任一需求，能看到关联的任务和用例列表 |
| 测试 | TEST-02 | 测试计划可关联到迭代 | 创建测试计划时可选择所属迭代，计划页显示迭代信息 |
| 缺陷 | DEF-03 | 缺陷状态流转包含验证环节 | 缺陷从修复到关闭之间有一个由测试人员操作的验证状态 |
| 知识 | DOC-01 | 知识页面可按空间或目录组织并控制访问权限 | 存在至少两级目录结构，且不同目录可设置不同访问范围 |
这张框架表是后续所有工作的基准。框架定稿后再开始采集，能避免采到一半发现条目无法判定而返工。
建立现状能力清单并留存证据
现状清单回答的是“当前工具实际怎么用”，重点在事实和证据，不在评价。采集时建议组合四种方式：查看工具配置，走查典型流程，导出样例数据，访谈关键角色。配置查看能确认字段、状态、权限的设置；流程走查能确认一个需求或缺陷从创建到关闭经过哪些环节；样例导出能确认实际数据里字段是否被填写、关联是否建立；访谈能补充配置看不出来的使用习惯和变通做法。
每条能力记录三项内容：当前做法、使用频率或覆盖范围、证据位置。当前做法写具体操作，例如“缺陷登记使用系统默认字段，复现步骤写在描述文本中，没有独立字段”。覆盖范围写实际情况，例如“近三个月 120 条缺陷中约 40 条描述包含复现步骤”。证据位置写清楚去哪里核查，例如“缺陷字段配置页截图”“2024 年 10 月缺陷导出样例”“测试负责人访谈记录”。
采集时要区分两种看似相同的情况：工具支持但团队未用，以及工具本身做不到。前者属于推广和流程问题，补齐成本低；后者才是工具能力差距，可能需要配置改造或更换工具。判断方法是先查工具是否提供该能力，再看实际数据中是否使用。例如缺陷严重程度字段在系统中存在，但导出样例显示该字段大面积为空，这属于使用问题；如果系统中根本没有该字段，才属于工具能力缺失。
证据类型要便于复核。配置截图适合证明字段和流程设置；流程记录适合证明状态流转路径；样例工作项适合证明字段填写和关联关系；报表导出适合证明统计口径。证据不必追求完整，但要能让复核人独立判断结论是否成立。在承载方式上，可以把每条能力的现状描述和证据链接放在同一份文档中，工作项和文档在同一平台内关联，复核时从条目直接跳到证据，减少来回查找。ONES 的项目工作项与 Wiki 文档可以承担这类记录，具体组织方式按团队现有习惯确定。
建立目标能力清单与判定标准
目标清单回答的是“换成什么样的工具才算够用”，来源要具体，不能凭印象罗列。常见来源有三类：业务与研发流程的实际要求，例如需求变更后必须能追溯受影响用例；合规与审计要求，例如缺陷处理记录需要保留完整操作日志；团队协作中的具体痛点，例如测试与研发之间缺陷流转靠口头通知。每一条目标都应能追溯到上述来源之一，写清来源可以避免目标清单变成愿望清单。
每条目标能力要写明期望做法和判定标准。期望做法描述希望工具如何支撑，判定标准描述做到什么程度算满足。例如目标条目“缺陷与需求关联”，期望做法是“缺陷登记时可选择关联需求，需求详情页能看到关联缺陷列表”，判定标准是“在需求详情页能直接看到至少一条关联缺陷，且关联关系在缺陷侧同步可见”。判定标准越具体，比对时的争议越少。
目标清单还要区分必须满足与可接受替代。必须满足的条目通常是流程闭环、数据追溯、权限控制等硬性要求；可接受替代的条目允许用不同实现方式达成同样效果，例如“缺陷看板”可以由工具内置看板实现，也可以由自定义视图加筛选条件实现。区分这两类，能避免把实现方式的差异误判为能力缺失。
目标清单沿用现状清单的编号体系，一条现状对应一条目标。如果目标清单中出现现状清单没有的新条目，说明框架阶段遗漏了能力域，应回到框架表补充编号，而不是在目标清单里另起编号。两份清单编号一致，比对才能逐行进行。
逐项比对并记录差距结论
比对按编号逐行进行，每行填写现状、目标、结论、证据和影响说明。结论分为四类：已满足、部分满足、缺失、待验证。已满足指现状做法达到目标判定标准；部分满足指方向一致但差一部分；缺失指现状没有对应做法或工具不具备该能力；待验证指现有证据不足以判断，需要进一步确认。
部分满足要写清差在哪一部分。例如目标要求“缺陷登记包含复现步骤、影响版本、严重程度三个独立字段”，现状是“复现步骤写在描述中，影响版本和严重程度有独立字段”，结论应写“部分满足：复现步骤未独立成字段，影响检索和统计”。缺失要写清影响的具体动作，例如“缺失：缺陷无法关联需求，导致需求变更时无法定位受影响缺陷，需人工比对”。
每条差距附证据引用，引用现状清单中已记录的证据位置，不重复采集。比对结论以证据为准，避免只写主观判断。对于无法确认的条目，保留待验证状态，并写明需要什么证据才能判定，例如“待验证：需确认工具是否支持按自定义字段筛选导出，验证方式为在测试环境创建筛选视图并导出”。把不确定的条目直接判为不支持，会让差距表失真，也会误导后续的替换判断。
| 条目编号 | 现状 | 目标 | 结论 | 证据 | 影响说明 |
|---|---|---|---|---|---|
| DEF-02 | 缺陷有状态流转，修复后直接关闭 | 修复与关闭之间有测试验证状态 | 部分满足 | 状态配置截图；10 月缺陷流转记录 | 缺少验证环节，修复质量依赖人工确认 |
| DEF-04 | 缺陷无法关联需求 | 缺陷可关联需求并在两侧可见 | 缺失 | 缺陷字段配置截图；需求详情页样例 | 需求变更时无法定位受影响缺陷 |
| DEF-05 | 缺陷分布报表按状态统计 | 可按模块和版本统计缺陷分布 | 待验证 | 报表配置页截图 | 需确认是否支持自定义维度，验证方式为测试环境配置 |
差距排序与替换判断
差距表本身不回答“要不要换工具”，排序和判断才是这一步的产出。排序按两个维度：对研发流程的影响程度，以及补齐成本。影响程度看该差距是否阻断流程闭环、是否造成数据不可追溯、是否带来合规风险；补齐成本看需要配置调整、流程改造还是更换工具。两个维度结合，可以把差距分成四类处理方式。
- 高影响、低成本的差距：优先通过配置或流程调整解决，不必更换工具。
- 高影响、高成本的差距：进入替换判断的核心依据，需要评估新工具能否覆盖。
- 低影响、低成本的差距：列入改进清单，随流程优化逐步处理。
- 低影响、高成本的差距：通常不构成替换理由，可接受现状或寻找替代做法。
替换判断的初步结论应写明依据。例如“本次比对共 32 条能力条目，缺失 6 条，其中 4 条属于高影响且无法通过配置解决，集中在缺陷与需求关联、测试用例追溯两个环节，现有工具在这些环节的改造空间有限，建议进入替换方案评估”。结论要能回答两个问题：替换是否值得，以及如果暂不替换，先补哪几项。对于待验证条目，列出验证方式和责任人，验证结果可能改变排序，因此替换判断应在待验证条目收敛后再定稿。
角色分工与交付物
差距分析涉及多个域的事实采集和结论复核，角色不清容易出现条目遗漏或证据不足。建议由研发负责人或工具负责人牵头，负责确定分析范围、主持框架定稿、组织结论复核。各域负责人分别负责本域的现状采集和证据留存，需求、测试、缺陷、知识四个域各有一名负责人，通常由对应环节的骨干或流程负责人担任。关键角色包括一线研发、测试、产品，参与访谈和结论复核，重点核对现状描述是否与实际使用一致。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 研发负责人或工具负责人 | 确定范围，主持框架定稿，组织复核，形成替换判断 | 条目框架表、差距优先级清单、替换判断说明 |
| 需求域负责人 | 采集需求域现状与证据，编写目标条目 | 需求域现状清单与目标清单 |
| 测试域负责人 | 采集测试域现状与证据，编写目标条目 | 测试域现状清单与目标清单 |
| 缺陷域负责人 | 采集缺陷域现状与证据，编写目标条目 | 缺陷域现状清单与目标清单 |
| 知识域负责人 | 采集知识域现状与证据，编写目标条目 | 知识域现状清单与目标清单 |
| 一线研发、测试、产品 | 参与访谈，复核现状描述与结论 | 访谈记录、复核意见 |
交付物按阶段归集：条目框架表在采集前定稿；现状清单和目标清单按域分别完成；差距比对表由牵头人汇总各域结果；差距优先级清单与替换判断说明是最终决策材料。所有交付物使用同一套编号，便于交叉引用。
示例：缺陷域的一次完整比对
以缺陷域为例，演示从条目到结论的完整过程。先拆出四条能力条目：DEF-01 缺陷登记字段，DEF-02 缺陷状态流转，DEF-03 缺陷与需求关联，DEF-04 缺陷统计报表。每条写成可判定的动作，例如 DEF-01 写成“缺陷登记包含复现步骤、影响版本、严重程度三个独立字段”。
现状采集时，查看缺陷字段配置，导出近三个月缺陷样例，访谈测试负责人。记录结果：DEF-01 现状为“复现步骤写在描述文本中，影响版本和严重程度有独立字段”，证据是字段配置截图和缺陷导出样例；DEF-02 现状为“状态流转为新建、处理中、已修复、已关闭，修复后直接关闭”，证据是状态配置截图和流转记录；DEF-03 现状为“缺陷无需求关联字段”，证据是字段配置截图；DEF-04 现状为“有按状态统计的缺陷报表，模块和版本维度未确认”，证据是报表配置页截图。
目标清单对应四条：DEF-01 要求三个字段独立存在，判定标准是导出样例中三个字段均有值；DEF-02 要求在修复与关闭之间有测试验证状态，判定标准是存在由测试角色操作的验证状态；DEF-03 要求缺陷可关联需求且两侧可见，判定标准是需求详情页显示关联缺陷；DEF-04 要求可按模块和版本统计，判定标准是报表配置中能选择这两个维度。
比对结论示例：DEF-01 部分满足，差在复现步骤未独立成字段，影响检索和统计；DEF-02 部分满足，缺少验证状态，修复质量依赖人工确认；DEF-03 缺失，需求变更时无法定位受影响缺陷；DEF-04 待验证，需在测试环境确认是否支持自定义统计维度。四条结论都附证据引用，待验证条目写明验证方式。
进入排序时，DEF-03 属于高影响且需要工具层面改造，是替换判断的重点；DEF-02 可通过流程配置增加验证状态解决，成本较低；DEF-01 可通过字段配置补充，但历史数据需要清洗；DEF-04 待验证结果出来后再定。这个示例说明，同一域内的差距影响和成本并不相同，排序要逐条判断，不能按域整体下结论。
完成检查：差距分析是否可交付
分析结束前，用以下清单逐项核对，确认结果达到可用于决策的程度：
- 每条能力都有统一编号，现状清单与目标清单编号一一对应，没有孤立条目。
- 每条能力条目写成可观察的动作或产出，没有“能力强”“体验好”这类无法判定的描述。
- 每条现状都有当前做法、覆盖情况和证据位置，证据可被独立复核。
- 现状采集区分了工具支持但未使用与工具本身做不到两种情况。
- 每条目标都有来源、期望做法和判定标准，并标注必须满足或可接受替代。
- 每条差距都有结论、证据引用和影响说明，部分满足写清差在哪一部分。
- 待验证条目已列出，写明验证方式和责任人，并有收敛时间。
- 差距排序有影响程度和补齐成本的依据，区分了配置可解决与需要更换工具两类。
- 替换判断说明能回答替换是否值得、先补哪几项，并注明结论依赖的待验证条目。
- 各域交付物已汇总到同一份差距表，角色分工和复核意见有记录。
清单全部通过，说明本次差距分析具备交付条件。若待验证条目尚未收敛，可以先交付差距表和优先级清单，在替换判断说明中标注结论的暂定状态，待验证完成后再更新。
常见问题
差距分析要覆盖多少能力域，范围怎么控制？
范围以本次替换判断的核心疑问为准。如果核心疑问是现有工具能否支撑需求到缺陷的闭环，就重点覆盖需求、测试、缺陷三个域，知识域按团队实际依赖程度决定是否纳入。工时统计、文档模板等边缘功能可以暂不纳入，避免条目过多稀释结论。范围确定后写入条目框架表，采集过程中如需增加域，回到框架表补充编号，保持两份清单编号一致。
现状采集时，怎么判断是工具做不到还是团队没用起来？
分两步查：先看工具是否提供该能力，例如字段配置中是否存在对应字段、状态配置中是否有对应环节；再看实际数据中是否使用，例如导出样例里该字段的填写比例、流转记录中该状态的出现频率。工具提供而数据为空，属于推广和流程问题，补齐成本低；工具本身没有该能力，才计入工具能力差距。两种情况在现状清单中分开记录，排序时的处理方式不同。
待验证条目一直确认不了，替换判断还能不能出？
可以先出暂定结论。做法是在替换判断说明中标注结论依赖的待验证条目，写明验证方式、责任人和收敛时间，并说明验证结果可能如何改变排序。如果待验证条目集中在低影响范围，暂定结论的参考价值较高；如果集中在高影响环节，建议先完成验证再定稿。差距表和优先级清单可以先交付，替换判断说明随验证结果更新。
各域负责人采集的口径不一致，汇总时怎么对齐？
靠框架表和证据规范对齐。框架表在采集前定稿，每条能力条目写明判定说明，各域按同一格式记录当前做法、覆盖范围和证据位置。汇总时由牵头人按编号逐行核对，重点检查三类问题：条目描述是否仍可判定、证据能否独立复核、结论是否与证据对应。发现口径偏差退回该域补充，不在汇总环节直接改结论。
差距分析的结果如何衔接到后续的替换方案评估？
差距表按影响和成本排序后，高影响且无法通过配置解决的条目构成替换方案评估的输入。评估新方案时，用同一套能力条目逐项核对能否覆盖这些差距，而不是重新列一份需求清单。这样前后口径一致，替换方案能否解决原有问题可以直接对照。涉及数据迁移的部分，迁移范围、功能匹配和系统适配需要在正式迁移前逐项确认，例如 ONES 的 Jira 与 Confluence 迁移方案建议先梳理实际使用的插件再逐项匹配，不能假设所有插件都能一一对应。
