工具差距分析表要能把“现有工具差在哪、差多少、先补哪块”变成可复算的结果。做法分四步：把功能差距拆成业务场景、功能项、判定点三层；用等距档位加证据定义评分标尺；按场景重要性分配权重并归一化；用加权差距和差距率汇总。本文给出可直接套用的表结构、公式和一个填好的示例。
要点总览（TL;DR）
- 功能差距维度按“业务场景—功能项—判定点”三层拆解，判定点拆到可观察、可取证为止，全表判定点控制在40–80个便于维护。
- 评分标尺用0–4等距五档，每档写明定义和判定证据；必备项低于2分视为不达标，加分项低分只影响加权结果。
- 权重按场景对业务的影响程度分配，场景层和场景内功能项各自归一化到100%，必备项可设一票否决或封顶规则。
- 差距率=总加权差距÷满分差距×100%，分母为零时标注“无功能差距”，缺失值不按零分处理。
- 差距率只是功能维度的输入，需结合证据复核、权重敏感性检查和迁移成本并行解读，不能作为替换决策的唯一依据。
评估目标：差距表要回答哪些替换问题
差距分析表服务于“换不换、换什么、怎么迁”的判断，前提是已经锁定一个现状工具和一个候选目标工具。它把两者的功能差异量化，供替换决策和迁移规划使用；从零开始的选型、供应商比价不在它的范围内。
评估开始前先写清评估对象和评估时点。对象写成“现状工具A 对比 目标工具B”，时点写成具体日期或版本，因为工具能力会随版本变化，隔几个月再看的分数不能直接沿用。同一张表里只比较一对工具，多候选时分别建表，避免口径混在一起。
建议在表头固定一份评估目标清单，列出本次要回答的问题，并写明不纳入的事项。一份典型的清单如下：
- 目标工具在核心研发流程上的功能差距集中在哪几个场景？
- 按当前权重，整体差距率是多少，是否落在可接受范围？
- 哪些必备项不达标，会直接阻断替换？
- 差距最大的功能项对应多大的迁移改造工作量？
- 不纳入范围：价格谈判、合同条款、组织架构调整。
功能差距要和迁移成本、使用体验、稳定性等非功能项分开评。差距表只回答“能力差多少”，迁移工作量另设维度或用独立表格评估，两类结果在决策时并列看，不混进同一个总分。
功能差距维度怎么拆：三层结构与维度清单
维度按“业务场景—功能项—判定点”三层拆。业务场景对应团队真实的工作流环节，例如需求评审、迭代排期、缺陷闭环、版本发布；功能项是场景内可命名的一类能力，例如“需求与任务的双向关联”；判定点是能直接观察和取证的最小单元，例如“从需求详情页可一键跳转到关联任务列表”。拆到判定点这一层就停，再往下拆会变成操作步骤，评分时难以对齐。
维度来源有三个：现有工作流中的实际环节、各角色的日常任务、集成与权限要求。梳理时让一线使用者参与，把“每天都在用”和“偶尔用一次”分开标注。集成类判定点要写清对接对象，例如与代码仓库、CI 流水线、单点登录的对接方式；权限类判定点要写清角色和可见范围。
维度数量需要控制。一个场景下功能项控制在 5–10 个，全表判定点控制在 40–80 个比较便于维护；同类能力合并成一项，例如把多种通知方式合并为“消息通知覆盖”，在判定点里列出渠道即可。合并的原则是：评分结论一致的功能点可以合并，结论可能相反的要拆开。
必备项与加分项在拆维度时就要标好。必备项是缺了就无法支撑业务运转的能力，例如核心流程的状态流转、关键数据的权限隔离；加分项是提升效率但可以替代或绕行的能力，例如高级报表、批量操作。标注结果直接决定后面标尺和权重的处理方式。
维度清单的表头建议如下，一行一个判定点：
| 业务场景 | 功能项 | 判定点 | 必备/加分 | 证据来源 |
|---|---|---|---|---|
| 需求评审 | 需求与任务关联 | 需求详情页可跳转关联任务 | 必备 | 试用截图、产品文档 |
| 缺陷闭环 | 缺陷状态流转 | 支持自定义状态与流转规则 | 必备 | 配置界面、试用记录 |
| 版本发布 | 发布看板 | 按版本聚合需求与缺陷 | 加分 | 演示环境操作 |
评分标尺怎么定：等距锚点与判定证据
评分标尺推荐用 0–4 五档等距锚点，档位之间间隔一致，便于后续加权计算。每档都写清定义和可观察证据，评估人按证据落档，而不是凭印象给分。
| 档位 | 定义 | 判定证据示例 |
|---|---|---|
| 0 | 目标工具无此能力，也无替代路径 | 试用中找不到对应入口，文档无相关说明 |
| 1 | 有间接或变通实现，需额外人工操作 | 可用其他功能拼凑，但需手工同步数据 |
| 2 | 标准能力可覆盖主要判定点，存在明显缺口 | 核心操作可用，缺少部分配置项 |
| 3 | 标准能力完整覆盖判定点 | 试用中按判定点逐条操作通过 |
| 4 | 覆盖判定点且有增强能力 | 在满足判定点基础上支持自动化或批量处理 |
现状工具和目标工具用同一把尺子打分。现状分反映当前实际使用水平，目标分反映替换后预期能达到的水平，两者都按同一档位定义取证。目标分不按“理论上限”打，按试用或演示中确认可用的能力打，避免高估。
必备项和加分项共用档位定义，但解读不同。必备项低于 2 分即视为不达标，触发后续的否决或封顶规则；加分项低分只影响加权结果，不单独阻断。这样标尺本身保持统一，差异体现在规则层。
评分一致性靠两件事保证：一是每个判定点附证据来源，截图、文档链接或试用记录写进表里；二是至少两人独立打分，分差超过 1 档的判定点组织复核，由双方对照证据重新落档并记录理由。复核记录保留在表内，便于后续追溯。
权重怎么分配：场景重要性与合计规则
权重按场景对业务的影响程度分配。判断依据可以是该场景覆盖的团队人数、发生频率、出问题时的业务影响，三者综合排序后给出相对权重。权重是相对值，不需要绝对精确，但要能说清排序理由。
归一化规则是每组权重合计 100%。场景层权重合计 100%，场景内功能项权重再各自合计 100%，形成两级权重。计算时先算场景内加权差距，再按场景权重汇总，避免功能项多的场景因数量优势被放大。归一化公式为：某项权重 = 该项原始重要性分 ÷ 同组原始重要性分之和 × 100%。
| 层级 | 对象 | 原始重要性 | 归一化权重 |
|---|---|---|---|
| 场景层 | 需求评审 | 5 | 50% |
| 场景层 | 缺陷闭环 | 3 | 30% |
| 场景层 | 版本发布 | 2 | 20% |
必备项设置一票否决或封顶规则。常见做法是：任一必备项现状分低于 2，整表结论标记为“存在阻断项”，差距率照常计算但需单独说明；或者把该场景的差距率封顶为 100%，防止其他高分项稀释阻断信号。规则在评估前确定并写入表头，评估中不临时更改。
权重定完后做敏感性检查：把权重上下调整 10%–20%，看整体差距率和排序是否发生实质变化。如果小幅调整就翻转结论，说明权重依据不够扎实，需要回到影响程度判断上重新讨论，而不是直接采用某一组数字。
计算步骤与公式：从单项分到总差距
计算分四步，每一步都保留中间结果，便于复核。
- 单项差距 = 目标分 − 现状分。结果可能为负，表示目标工具在该项上弱于现状，负值照实保留，不截断为零。
- 场景内加权差距 = Σ（功能项权重 × 单项差距）。权重用归一化后的小数形式，例如 30% 写作 0.3。
- 总加权差距 = Σ（场景权重 × 场景内加权差距）。
- 差距率 = 总加权差距 ÷ 满分差距 × 100%。满分差距按标尺上限计算，0–4 标尺下每项满分差距为 4，加权后得到分母。
分母为零的处理要提前约定。当所有判定点的目标分与现状分相等时，总加权差距为零，差距率无意义，此时直接标注“无功能差距”，不计算百分比。当某个场景内所有权重项都缺失数据时，该场景不参与汇总，并在表内标注缺失原因，缺失值不按零分处理，否则会人为压低差距。
时间窗和单位也要写清。评分对应评估时点的工具版本，差距率是百分比，无量纲，可跨场景比较；单项差距是档位差，单位是“档”。同一张表内不混用不同标尺，若部分判定点改用 1–5 标尺，需单独换算或另表计算。
示例：一张填好的差距分析表
以下为演示情景，数字用于说明计算方法，不代表任何具体产品的实际能力。假设评估对象为现状工具A与目标工具B，采用 0–4 标尺，选取三个场景共五个功能项。
| 场景（权重） | 功能项（权重） | 必备/加分 | 现状分 | 目标分 | 单项差距 |
|---|---|---|---|---|---|
| 需求评审（50%） | 需求与任务关联（60%） | 必备 | 3 | 3 | 0 |
| 需求评审（50%） | 评审流程配置（40%） | 加分 | 2 | 4 | 2 |
| 缺陷闭环（30%） | 缺陷状态流转（50%） | 必备 | 3 | 1 | −2 |
| 缺陷闭环（30%） | 缺陷与版本关联（50%） | 加分 | 1 | 3 | 2 |
| 版本发布（20%） | 发布看板（100%） | 加分 | 2 | 4 | 2 |
场景内加权差距：需求评审 = 0.6×0 + 0.4×2 = 0.8；缺陷闭环 = 0.5×(−2) + 0.5×2 = 0；版本发布 = 1.0×2 = 2。总加权差距 = 0.5×0.8 + 0.3×0 + 0.2×2 = 0.8。满分差距 = 0.5×(0.6×4 + 0.4×4) + 0.3×(0.5×4 + 0.5×4) + 0.2×(1.0×4) = 4。差距率 = 0.8 ÷ 4 × 100% = 20%。
必备项触发否决：缺陷状态流转目标分仅 1 分，低于必备项 2 分门槛，整表结论标记“存在阻断项”。尽管总差距率只有 20%，替换仍需先解决该场景的状态流转能力，否则缺陷闭环无法运转。结果指向的迁移优先级是：先确认缺陷状态流转的替代方案，再评估发布看板的增强能力，需求评审场景差距最小可后置。
解读与限制：结果怎么用、哪里会失真
差距率高低与替换必要性不是线性关系。差距率低说明功能层面接近，替换的功能收益有限，但可能因合规、成本或维护原因仍有替换必要；差距率高也不必然意味着不该换，要看差距是否集中在可绕行或可改造的功能项上。差距率是功能维度的输入之一，不是结论本身。
评分主观性和权重敏感性是两个主要失真来源。同一判定点不同评估人可能差一档，权重调整 10% 也可能改变场景排序。控制方法是保留证据、双人打分、做敏感性检查，并在报告中同时给出原始分和调整后的结果，让决策者看到结论的稳定区间。
功能差距之外要并行评估迁移成本与风险。数据迁移范围、插件与定制场景的替代、切换期间业务连续性，这些都会影响替换可行性。以 Jira 与 Confluence 向 ONES 迁移为例，ONES 方案支持围绕项目、工作项、状态、字段、流程、附件和历史记录迁移，并将 Confluence 空间、页面、附件和权限结构迁入 ONES Wiki；对于原依赖插件的功能，ONES 建议先梳理实际使用的插件清单，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力逐项匹配，定制场景在迁移前单独评估。这些内容适合作为迁移成本维度的取证依据，与功能差距表并列使用。
评分记录和复核过程需要可追溯。把判定点、证据、评分人和复核意见放在同一份可协作的文档或工作项里，评审时按场景逐条过，结论和修改留痕。ONES 的文档与工作项协作方式可以承载这类评分记录和评审流转，具体字段和流程按团队实际配置。
复核与更新频率按工具版本节奏定。目标工具发布大版本、现状工具调整流程、或业务场景发生明显变化时，重新评估受影响的判定点，不必每次全表重算。建议每季度做一次全表复核，评估时点和版本号随表记录，保证不同批次的结果可比。
常见问题
必备项和加分项要不要用两套评分标尺？
建议共用一套档位定义，差异放在规则层处理。这样同一判定点的分数在不同评估人之间可比，也便于跨场景汇总。必备项低于2分即视为不达标，触发否决或封顶规则；加分项低分只拉低加权差距，不单独阻断替换。如果为两类项各设一套标尺，档位含义容易混淆，汇总时还要额外换算。
某个场景内所有判定点都缺数据，差距率怎么算？
该场景不参与汇总，并在表内标注缺失原因和补评计划。缺失值不按零分处理，否则会人为压低差距、让结论偏向“差距小”。如果缺失场景的权重较高，建议先补齐证据再出结论，或者同时给出“含缺失场景”和“不含缺失场景”两个差距率，让决策者看到数据缺口带来的影响范围。
权重调整后结论翻转了，应该采用哪一组权重？
先回到权重依据上重新讨论，而不是在两组数字里挑一个顺眼的。权重按场景覆盖人数、发生频率、出问题时的业务影响综合排序，翻转说明排序理由不够扎实。可以组织场景负责人对照这三项依据重新打分，记录调整理由后再归一化。敏感性检查的价值在于暴露结论的稳定区间，报告中同时给出原始权重和调整后的结果，比只给一个数字更可信。
差距率算出来很低，是不是就不用替换了？
差距率低只说明功能层面接近，替换的功能收益有限。合规要求、维护成本、供应商支持、系统稳定性等因素仍可能推动替换，这些不在功能差距表里。反过来，差距率高也不必然意味着不该换，要看差距是否集中在可绕行或可改造的功能项上。把差距率和迁移成本、风险清单并列看，再决定是否推进。
评分记录和复核意见放在哪里便于追溯？
把判定点、证据、评分人和复核意见放在同一份可协作的文档或工作项里，按场景逐条评审，结论和修改留痕。ONES 的文档与工作项协作方式可以承载这类评分记录和评审流转，具体字段和流程按团队实际配置。评估时点和工具版本号随表记录，保证不同批次的结果可比。
