工具差距分析表把“现有工具做不到什么”转成可判断、可比较、可决策的结构化记录。设计时先锁定评估对象与决策问题，再按统一维度记录现状、目标、差距、影响与证据，最后给出替换、补齐或暂缓的结论。本文给出可直接复用的字段结构、五步填写流程、角色分工、示例记录与交付前自检清单，适用于单个工具、工具链或某类研发环节的替换评估。
要点总览（TL;DR）
- 差距分析表围绕“现状—目标—差距—影响—证据—结论”设计字段，核心是让每条差距可复核、可比较、可决策，而非罗列功能清单。
- 动笔前先用一页纸锁定评估对象、评估边界、决策问题与不纳入项；替换是否值得与如何规划是这张表要回答的问题。
- 填写按五步推进：定维度与权重、采集现状与目标并附证据、判定等级与影响、形成处理建议并排序、评审复核与归档。
- 填表人、业务与研发代表、平台负责人、评审人、决策人分工明确，提供证据的人与下结论的人分开，结论才经得起复核。
- 交付前用自检清单把关，无证据、无结论、等级口径不一致的记录作为阻断项退回。
先定评估范围：差距分析表回答什么问题
差距分析表的第一项工作不是列字段，而是写清这张表要支撑哪个决策。范围不清时，表格会不断膨胀：有人填功能对比，有人填迁移风险，有人填采购预算，最后无法汇总。建议在动笔前用一页纸固定四件事：评估对象、评估边界、决策问题、不纳入项。
评估对象要具体到可指认的程度。可以是一个工具（例如某项目管理工具）、一条工具链（需求管理到测试管理的衔接），或某类研发环节（代码评审、缺陷跟踪、文档协作）。对象越宽，维度越多，单张表越难收敛；对象过窄，又容易漏掉上下游衔接问题。一个实用做法是：先按研发环节拆成若干张子表，再在一张汇总表里合并结论。
评估边界决定表格回答到什么深度。差距分析表回答“替换是否值得、差距集中在哪些方面、如何排优先级”，并给出后续验证方向；具体迁移执行、数据映射、版本兼容细节属于下一阶段工作，放在表里会稀释判断重点。若组织同时在做从零选型，也应另立评估，避免把“有没有替代品”和“现有工具差在哪”混在同一张表里。
决策问题建议写成一句话，例如：“现有工具在需求追溯与跨团队协作上是否已构成必须替换的差距，若是，优先补齐还是整体替换？”这句话会直接决定维度取舍：与追溯、协作无关的字段可以不进表。最后列出不纳入项，例如价格谈判、合同条款、具体迁移排期，让填表人知道边界在哪里。
一页评估范围说明可包含：评估对象及覆盖的研发环节；评估边界与决策问题；表格的使用者与评审时点；明确不纳入的内容。完成标志是评审人能在不看正文的情况下，仅凭这一页说清“这张表要证明什么”。
差距分析表的核心字段与填写口径
字段设计围绕一条主线：现状—目标—差距—影响—证据—结论。每个判断字段都要有统一口径，否则不同人填出的“高”“中”“低”无法比较。下表给出可复用的字段清单，组织可按评估对象增删，但建议保留“证据来源”“处理建议”“复核状态”三类字段。
| 字段名 | 含义 | 填写口径 | 是否必填 | 示例 |
|---|---|---|---|---|
| 评估维度 | 差距所属的能力或管理方面 | 使用预先评审过的维度清单，不在填写过程中临时新增 | 是 | 需求追溯 |
| 子项 | 维度下可单独判断的具体条目 | 一条记录只对应一个子项，避免一条记录混多个问题 | 是 | 需求与测试用例的双向关联 |
| 权重 | 该维度对本次决策的相对重要性 | 由评审组在填表前统一设定，填写人不得自行调整 | 是 | 高 |
| 现状描述 | 当前工具在该子项上的实际表现 | 写可观察的事实与操作方式，不写主观评价 | 是 | 需求变更后需人工在测试用例中补关联，平均滞后一个迭代 |
| 目标要求 | 业务对该子项的期望状态 | 来自业务或研发代表确认的要求，注明提出方 | 是 | 需求变更后测试用例关联状态可自动提示并留痕 |
| 差距描述 | 现状与目标之间的具体差异 | 用“现状缺少什么、导致什么”表述，与上下两栏对应 | 是 | 缺少自动关联与变更提示，追溯依赖人工检查 |
| 差距等级 | 差距的大小 | 按统一量表判定，如“严重/较大/一般/无”，并写明判定依据 | 是 | 较大：影响每个迭代的追溯核对 |
| 影响范围 | 差距造成的业务后果与波及面 | 写受影响的团队、环节、频率或合规要求 | 是 | 影响测试与需求两个团队，涉及审计场景 |
| 紧急程度 | 处理的时限压力 | 与差距等级分开判断，可由合规节点、项目里程碑驱动 | 是 | 本季度审计前需有结论 |
| 证据来源 | 支撑现状与差距的材料 | 注明截图、操作记录、访谈记录、工单编号等可复核来源 | 是 | 近两个迭代的追溯核对记录 |
| 验证方式 | 如何确认差距真实存在或已消除 | 写可执行的验证动作 | 否 | 抽取十个变更需求核对关联完整率 |
| 记录人 | 该条记录的填写者 | 填实名或岗位，便于复核时追问 | 是 | 测试负责人 |
| 处理建议 | 针对该差距的行动方向 | 限定为替换、补齐、暂缓三类，并简述理由 | 是 | 补齐：先评估现有工具的自动化配置能力 |
| 负责人 | 推进该条结论的责任人 | 一条记录一个负责人 | 是 | 平台管理员 |
| 复核状态 | 记录所处的评审阶段 | 使用固定状态值，如待填、待评审、已确认、已退回 | 是 | 待评审 |
常见误填集中在三处。其一，现状描述写成“体验差、不好用”，无法复核，应改为具体操作与耗时。其二，差距等级凭印象打分，同一类问题在不同记录里等级不一致，应在填表前给出等级定义和示例。其三，处理建议直接写“替换为某产品”，跳过了差距与影响的对应关系，评审时无法判断结论是否成立。
从差距到结论：五步操作流程
表格从空白到可决策，建议按五步推进。每一步都明确输入、动作、输出与完成标志，避免填表变成一次性的大讨论。
第一步：确定评估维度与权重
输入是评估范围说明和业务目标。动作是由评审组列出维度清单，逐项确认权重，并对每个维度给出等级判定口径。输出是维度与权重表。完成标志是所有填表人对“哪些维度进表、权重多少、等级怎么判”没有分歧。
第二步：采集现状与目标，标注证据
输入是维度清单。动作是填表人按子项采集现状，业务与研发代表确认目标要求，每条现状附上证据来源。输出是完成现状与目标两栏的初稿。完成标志是每条记录都有可追溯的证据，目标要求注明提出方。
第三步：判定差距等级与影响范围
输入是初稿记录。动作是按统一口径判定差距等级，单独评估影响范围与紧急程度，两者不互相替代。输出是带等级和影响的记录集。完成标志是同一类差距在不同记录中的等级一致，抽查可由第三人复现判定结果。
第四步：形成处理建议并排序
输入是带等级与影响的记录。动作是为每条记录给出替换、补齐或暂缓的建议及理由，再按权重、等级、影响和紧急程度排出处理顺序。输出是带结论和优先级的差距清单。完成标志是每条建议都能对应到具体差距和证据，排序规则可被解释。
第五步：评审复核与结论归档
输入是完整表格。动作是评审人复核证据、口径与结论一致性，退回不合格记录，决策人确认最终结论。输出是已确认的差距分析表与评审记录。完成标志是全部记录处于已确认或已退回状态，结论可归档并作为后续替换规划的输入。
角色分工与交付物
差距分析表由单人闭门完成时，最容易出现现状失真和结论无依据。建议至少区分五类角色，并明确各自交付物与时点。
| 角色 | 主要职责 | 交付物 | 时点 |
|---|---|---|---|
| 填表人 | 按维度填写现状与差距描述，附证据 | 差距记录初稿 | 第二步结束前 |
| 业务与研发代表 | 确认目标要求，判断影响范围 | 目标要求确认意见、影响说明 | 第二步至第三步 |
| 工具管理员或平台负责人 | 提供现状证据，评估补齐或替换的可行性 | 现状证据、可行性意见 | 第二步至第四步 |
| 评审人 | 复核差距等级与结论一致性，退回不合格记录 | 评审意见、退回清单 | 第五步 |
| 决策人 | 确认替换、补齐或暂缓的最终结论 | 决策结论与优先级 | 评审完成后 |
分工的关键是让“提供证据的人”和“下结论的人”分开。填表人负责把事实写清，业务代表负责说明目标从哪来，平台负责人负责判断技术可行性，评审人检查三者是否对得上，决策人对最终方向负责。角色可以由同一人兼任，但职责边界仍应在表头或说明中写清，便于复核时追溯。
填写示例：一条差距记录怎么写
以下为演示情景，用于说明记录方式，不代表任何真实组织的评估结论。某研发团队评估现有工具在需求与测试协作上的表现，其中一条记录如下。
| 字段 | 填写内容 |
|---|---|
| 评估维度 / 子项 | 需求追溯 / 需求变更与测试用例的关联 |
| 权重 | 高 |
| 现状描述 | 需求变更后，测试人员需人工比对变更内容并在用例中补充关联，近两个迭代平均滞后约一周完成核对 |
| 目标要求 | 需求变更后，关联的测试用例状态可被提示并保留变更记录，由测试负责人提出 |
| 差距描述 | 现有工具缺少变更与用例关联的自动提示，追溯依赖人工检查，变更记录分散在沟通群中 |
| 差距等级 | 较大：每个迭代均发生，且需额外人工核对 |
| 影响范围 | 影响需求与测试两个团队，涉及版本发布前的追溯核对 |
| 紧急程度 | 中：下季度审计前需形成结论 |
| 证据来源 | 近两个迭代的追溯核对记录、测试负责人访谈记录 |
| 验证方式 | 抽取十个变更需求，核对关联完整率与核对耗时 |
| 处理建议 | 补齐：先评估现有工具的自动化配置与流程改造空间；若验证后仍无法满足，再纳入替换评估 |
| 负责人 / 复核状态 | 平台管理员 / 待评审 |
这条记录可迁移的规律有三点。现状写操作与频率，不写感受；差距等级与影响范围分开判断，等级说明差距大小，影响说明业务后果；处理建议先给成本较低的补齐路径，并写明触发替换评估的条件，使结论可被后续验证修正。
完成检查：表格可用的判断标准
交付前用以下清单自检。表格能支撑决策的标志是：每条差距可复核、每个等级可复现、每个结论有对应依据。
- 每条差距是否附有证据来源，且证据可被第三人查阅；
- 差距等级是否按统一口径判定，同类问题等级是否一致；
- 影响范围是否写明受影响的团队、环节或合规要求；
- 处理建议是否限定为替换、补齐或暂缓，并与差距和影响对应；
- 是否覆盖评估范围内的关键维度，权重是否经过评审确认；
- 每条记录是否明确负责人与复核状态；
- 结论是否能追溯到具体记录，而非汇总时的临时判断。
以下情况应作为阻断项退回：无证据来源的记录；只有现状没有结论的记录；同一维度内等级口径不一致的记录；处理建议与差距明显不匹配的记录。退回时注明原因和补充要求，避免记录在评审环节反复往返。
用ONES承载差距记录与评审流转
表格定稿后，真正的管理动作发生在填写、评审和跟踪过程中。把每条差距作为一条工作项记录，可以保留维度、现状、目标、等级、影响、证据附件、处理建议、负责人和复核状态等字段，使记录与评审意见在同一处留痕。填写人提交后按状态流转，依次完成填写、评审、结论确认；评审意见与退回原因随记录保存，后续复核时可直接查看历史判断。
差距条目确认后，还需要与替换规划事项关联，例如把“补齐”类条目挂到流程优化任务，把“替换”类条目汇总为替换评估的输入。ONES 提供 Jira 与 Confluence 替换方案，围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，并将 Confluence 空间、页面、附件和权限结构迁移到 ONES Wiki；对于依赖插件的功能，官方建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配，定制场景需逐项评估。这些能力可用于承接差距条目确认后的替换规划与验证，具体字段配置与流转方式应结合组织实际流程设计。
常见问题
差距分析表里的差距等级和紧急程度为什么要分开填？
两者回答的问题不同。差距等级反映现状与目标之间差多少，紧急程度反映处理的时间压力，后者常由合规节点、审计安排或项目里程碑驱动。一条差距可能等级较大但时限宽松，也可能等级一般却因审计临近而必须尽快有结论。分开记录后，排序时才能同时考虑“差得多”和“等不起”，避免把所有高等级条目都排到最前面。
评估范围里已经写了不纳入项，填表过程中又出现新问题怎么办？
先判断新问题是否影响本次决策问题。若它属于同一评估对象且会改变替换、补齐或暂缓的结论，应由评审组确认后补充维度，并同步更新维度与权重表，保持口径统一。若它属于迁移执行、合同条款或从零选型等已声明不纳入的内容，记入待办清单另立评估，不塞进当前表格。关键是新增维度要经过评审确认，不能由填表人临时加栏。
处理建议写“补齐”之后，还需要在表里写替换条件吗？
建议写明。补齐类建议通常带有验证动作，例如先评估现有工具的自动化配置或流程改造空间。把“验证后仍无法满足哪些条件则转入替换评估”写进记录，可以让结论在后续验证中被修正，也便于评审人判断建议是否成立。这样表格既给出当前方向，也保留了升级为替换评估的触发条件。
差距条目从表格转入工具管理后，评审意见和历史判断怎么保留？
把每条差距作为一条工作项记录，保留维度、现状、目标、等级、影响、证据附件、处理建议、负责人和复核状态等字段，按状态流转完成填写、评审与结论确认。评审意见和退回原因随记录保存，后续复核时可直接查看历史判断。ONES 提供 Jira 与 Confluence 替换方案，围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移；具体字段配置与流转方式应结合组织实际流程设计。
一张差距分析表覆盖多少研发环节比较合适？
以能收敛结论为准。对象过宽，维度数量膨胀，单张表难以汇总；对象过窄，又容易漏掉上下游衔接问题。实用做法是先按研发环节拆成若干张子表，各自完成现状、目标与差距记录，再在一张汇总表里合并结论和优先级。若评估对象是一条工具链，维度应覆盖链路上的关键衔接点，而不只是单个工具的功能项。
