工具差距分析表把“现状用法—目标要求—差距—影响—处置建议”逐项对齐，让研发工具替换评估从印象判断变成可核对、可讨论的依据。设计时先锁定评估范围和基线，再按业务场景拆出能力项，为每项写明现状证据、目标标准、差距等级、影响范围、处置方案与验证方式，并配套责任人和评审节点。这样一张表既能回答“值不值得换”，也能支撑“先补哪块、怎么分期”。
要点总览（TL;DR）
- 先写评估范围与基线说明，锁定团队、工具、场景三类对象和统计口径，差距等级与影响范围用统一判定句，表格才具备横向可比性。
- 核心字段按“场景—能力—现状—证据—目标—差距—影响—处置—验证—责任”组织，能力项以“能否独立判断”为拆分粒度，现状描述与证据分开填写。
- 制表按五步推进：收集证据登记基线、拆解能力项设定目标、判定差距与影响、形成处置与验证方式、汇总差距分布输出初步结论，每步都有输入、输出和完成标志。
- 评审按填表、初审、复核、决策四个节点组织，业务负责人、工具管理员、研发骨干、采购或财务、决策层各司其职，争议项与证据不足项不进入结论统计。
- 交付前检查字段完整性、证据可追溯性、等级一致性、处置可执行性和结论匹配度，核心场景缺基线或严重差距无证据即为阻断项。
先定评估范围与基线，表格才有可比口径
差距分析表最常见的失效原因，是不同人填的是不同范围的数据：有人按团队填，有人按项目填；有人描述当前版本，有人描述两年前的印象。表格设计的第一步是写一份评估范围与基线说明，作为全表的统一口径。
范围说明需要列清三类对象。团队对象写明纳入评估的研发团队、测试团队或平台团队，以及各自人数；工具对象写明当前使用的工具名称、版本、部署方式和许可状态；场景对象写明纳入评估的关键业务场景，例如需求流转、代码评审、缺陷跟踪、版本发布、文档协作。范围之外的对象明确排除，避免评审时反复拉扯。
现状基线解决“现在到底是什么样”。建议登记当前工具版本、使用人数、活跃项目数、关键流程节点数量，以及近一个统计周期内的使用数据，如周活跃人数、月均工单量、平均流转时长。数据口径要写清统计时间和来源，例如“取自工具后台近三个月报表”。
目标基线解决“换成什么样才算达标”。目标要落到业务结果和约束条件上，例如发布周期缩短到什么水平、跨团队协作覆盖哪些角色、数据迁移允许的停机窗口、预算与合规要求。目标写成可判定的表述，避免“体验更好”“效率提升”这类无法验收的说法。
判定口径要在填表前统一。差距等级建议用四级：无差距、轻微差距、明显差距、严重差距，每一级给出可观察的判定描述。影响范围按受影响的团队数、场景数或流程节点数划分，例如单团队、跨团队、全研发体系。口径写进说明文档，所有填表人按同一把尺子判断。
差距分析表的核心字段与填写规则
字段设计的目标是让每一行差距都能被独立阅读和复核。建议按“场景—能力—现状—目标—差距—影响—处置—验证—责任”的顺序组织字段，下面给出字段清单与填写要求。
| 字段 | 填写要求 | 必填 |
|---|---|---|
| 编号 | 按“场景缩写-序号”编排，便于引用和汇总 | 是 |
| 业务场景 | 取自范围说明中的场景清单，不临时新增 | 是 |
| 能力项 | 一个可独立判断的能力点，如“代码评审与合并请求关联”“缺陷与需求双向追溯” | 是 |
| 现状描述 | 写当前工具在该能力上的实际用法，含操作路径和限制 | 是 |
| 现状证据 | 截图、后台报表、流程记录、访谈纪要等可追溯材料的位置或编号 | 是 |
| 目标要求 | 替换后该能力需要达到的标准，尽量可判定 | 是 |
| 差距等级 | 按统一四级口径判定，附一句判定理由 | 是 |
| 影响范围 | 受影响的团队、场景或流程节点，按统一口径标注 | 是 |
| 处置建议 | 替换、补齐配置、调整流程、接受现状四类之一，并说明理由 | 是 |
| 验证方式 | 替换或补齐后如何确认差距已消除，如试点团队验证、数据对比、评审演示 | 是 |
| 责任人 | 对该项差距核实与处置跟进负责的具体人员 | 是 |
| 目标节点 | 计划完成处置或验证的时间节点 | 否 |
| 关联条目 | 与其他差距项的依赖关系，如迁移前置条件 | 否 |
| 备注 | 争议点、待补充证据等说明 | 否 |
能力项的拆分粒度决定表格是否好用。拆得太粗，一行里混着多个问题，无法判定；拆得太细，表格膨胀到几百行，评审无法收敛。建议以“一个业务动作能否独立判断”为标准：同一场景下，能分别给出不同差距等级和处置建议的，就拆成两行。
现状描述与现状证据要分开写。描述回答“现在怎么做”，证据回答“凭什么这么说”。证据可以是工具后台截图、流程配置导出、访谈记录编号。没有证据的条目在初审阶段标记为待补，不进入结论汇总。
差距等级的判定规则要写成判定句。例如“严重差距”指目标要求中的核心能力当前完全缺失，且影响跨团队流程；“明显差距”指能力存在但需要大量人工补偿；“轻微差距”指可通过配置或流程调整解决。判定理由一句话即可，但要指向具体事实。
处置建议要与差距等级和影响范围匹配。严重且跨团队的差距，通常对应替换或重点补齐；轻微且单团队的差距，可以接受现状或排入常规优化。验证方式要写清验证对象、验证方法和通过标准，避免只写“上线后观察”。
从现状盘点到达成结论的操作步骤
制表过程按五步推进，每步都有明确的输入、动作、输出和完成标志，便于分派和检查。
第一步：收集现状证据并登记基线数据。输入是范围说明和工具后台权限。动作包括导出使用数据、整理关键流程配置、访谈业务负责人并记录原话。输出是基线数据表和证据清单。完成标志是范围说明中每个团队、每个场景都有对应的基线数据和至少一份证据。
第二步：按场景拆解能力项并设定目标要求。输入是基线数据和业务目标。动作是逐场景列出能力项，对照目标基线写出每项的目标要求，并请业务负责人确认。输出是能力项清单与目标要求。完成标志是每个场景的能力项经业务负责人签字或书面确认，目标要求均可判定。
第三步：逐项判定差距等级与影响范围。输入是能力项清单、现状证据和判定口径。动作是填表人逐项写现状描述、挂接证据、判定等级和影响范围，再由工具管理员复核技术事实。输出是完成判定的差距条目。完成标志是所有必填字段无空缺，等级判定均附理由。
第四步：形成处置建议并标注验证方式。输入是判定完成的差距条目。动作是按条目给出处置建议、验证方式、责任人和目标节点，跨条目依赖写入关联字段。输出是可执行的处置清单。完成标志是每条建议都有责任人和验证通过标准。
第五步：汇总差距分布，输出初步结论。输入是全表数据。动作是按场景、等级、影响范围做交叉汇总，统计严重差距数量及其分布，判断替换、补齐或维持现状的倾向，并给出分期建议。输出是差距分布汇总和初步结论。完成标志是结论能对应到具体条目编号，且与差距分布一致。
角色分工、评审节点与交付物
差距分析表涉及多类角色，分工不清会出现“填表的人不掌握事实、拍板的人没看过证据”。建议按下表明确职责。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 业务负责人 | 确认场景范围、目标要求和差距影响，对业务侧判断负责 | 场景清单确认、目标要求确认 |
| 工具管理员 | 提供版本、配置、使用数据等技术事实，复核现状描述 | 基线数据表、技术事实复核意见 |
| 研发骨干 | 以实际使用者视角填写现状用法和影响感受 | 现状描述与证据、使用体验记录 |
| 采购或财务 | 提供许可、预算、合同约束，评估处置建议的成本可行性 | 成本约束说明、采购可行性意见 |
| 决策层 | 对替换、补齐或维持现状的结论拍板，确认分期安排 | 决策结论与分期批复 |
评审按四个节点组织。填表节点由研发骨干和工具管理员完成条目填写，交付完整的差距条目；初审节点由业务负责人逐条确认场景、目标和影响，交付初审意见，争议项标注待议；复核节点由工具管理员和采购或财务核对技术事实与成本约束，交付复核记录；决策节点由决策层基于汇总结果拍板，交付决策结论和分期计划。
争议项和证据不足项要有专门处理方式。证据不足的条目退回填表人补充，补充期限写入评审记录；争议项由业务负责人组织小范围对焦，形成书面结论后回填表格。两类条目都不进入最终结论统计，避免用未核实的信息支撑决策。
结论变更要留痕。每次评审后记录变更条目编号、变更前后内容、变更原因和确认人。替换范围或分期安排调整时，同步更新汇总表和结论页，保持表格与决策文件一致。
当差距条目需要多人协同填写、评审意见需要按条目留痕时，可以把表格拆成工作项登记在ONES中，按场景建立视图，处置建议和验证结论随工作项状态流转，评审记录关联到对应文档，减少版本散落。这一做法适合参与团队较多、评审轮次较多的评估；小范围评估用一张共享表格也能完成。
填写示例：一条能力差距如何写完整
以下为演示情景，用于说明字段写法，不代表真实企业数据。
场景为“缺陷跟踪”，能力项为“缺陷与需求的双向追溯”。现状描述写：当前缺陷单与需求单分属两个系统，缺陷单只能手工填写需求编号，需求侧无法查看关联缺陷列表，统计缺陷密度需人工汇总。现状证据挂接后台截图两张和一次访谈记录编号。
目标要求写：缺陷单创建时可选择关联需求，需求详情页展示关联缺陷及状态，支持按需求统计缺陷数量。差距等级判为“明显差距”，理由是该能力当前依赖人工补偿，影响缺陷密度统计的准确性。影响范围标注为“跨团队”，涉及三个研发团队和测试团队。
处置建议写“替换”，理由是两个系统的追溯能力均无法通过配置满足目标要求，且该差距影响发布质量统计。验证方式写：选取一个试点团队，在新工具中完成二十条缺陷与需求的关联，核对需求侧展示和统计结果，由测试负责人确认。责任人填测试负责人，目标节点填试点结束时间。
这条示例可迁移的规律是：现状写到操作层面，证据挂到可查位置，目标写成可判定句，等级附理由，处置与影响范围匹配，验证写到对象、方法和通过标准。按同样结构填写其他条目，整张表就具备横向比较的基础。
完成检查：表格可用与结论可信的判定标准
交付前按以下清单逐项检查，任一项不通过即返工。
- 字段完整性：所有必填字段无空缺，选填字段的空缺有说明；每个场景至少有一条能力项。
- 证据可追溯：每条现状描述都能找到对应证据编号或位置，证据与描述指向同一版本、同一统计周期。
- 等级一致性：抽查不同填表人判定的同类条目，等级和理由符合统一口径；同一能力在不同场景下的判定不矛盾。
- 处置可执行：每条处置建议都有责任人、验证方式和通过标准，涉及成本的建议已经过采购或财务确认。
- 结论匹配：初步结论中的替换、补齐或维持判断，能在汇总表中找到对应的条目分布支撑；严重差距的数量和分布与结论方向一致。
阻断项包括：核心场景缺少基线数据、严重差距条目无证据、结论与差距分布明显不符、争议项未形成书面结论。出现任一阻断项，表格退回对应节点返工，返工完成后重新走复核节点。检查通过的标准是：评审参与人能够仅凭表格和证据，复现出同样的差距判定和结论方向。
常见问题
评估范围里要不要把边缘团队和低频场景纳入？
取决于这次评估要回答的问题。如果结论只用于核心研发流程的替换判断，可以把边缘团队和低频场景列入范围说明的排除项，并写明排除理由，避免评审时被反复追问。如果替换决策会涉及全研发体系的许可采购或统一流程，建议至少把边缘团队的代表性场景纳入，用较低权重标注影响范围。
无论纳入还是排除，都要在范围说明中写清楚，后续新增对象走变更记录，不同批次的数据不混在同一张汇总表里比较。
现状证据不足时，条目应该怎么处理？
证据不足的条目在初审阶段标记为待补，退回填表人补充，补充期限写入评审记录。这类条目暂不进入结论统计，避免用未核实的信息支撑替换判断。
如果确实无法取得证据，例如旧系统已下线或后台报表缺失，可以在备注中写明原因，并由业务负责人以书面访谈纪要作为替代证据，同时把该条目的差距等级标注为待确认，在结论页单独说明其影响。
差距等级判定出现分歧时，以谁的意见为准？
以填表前统一的判定口径为准，先对照判定句核对事实，再讨论等级。分歧通常来自对现状的描述不同，建议让争议双方各自指出所依据的证据编号，由工具管理员复核技术事实，业务负责人确认影响范围。
仍无法达成一致的，由业务负责人组织小范围对焦，形成书面结论后回填表格，并在备注中记录分歧点和处理方式。结论变更时同步记录变更条目编号、变更前后内容和确认人。
小团队评估也需要走四个评审节点吗？
可以合并节点，但职责不能省。小团队评估中，初审和复核可以由业务负责人与工具管理员一次会议完成，决策由团队负责人拍板，交付物仍要保留：场景与目标确认、技术事实复核意见、决策结论。
合并的前提是参与人对范围和口径已有共识。如果评估涉及跨团队流程或较大预算，建议保留完整节点，把技术事实核对和成本可行性分开处理，减少决策阶段的返工。
表格填完后，结论怎么写才不算拍脑袋？
结论要能对应到具体条目编号。先按场景、等级、影响范围做交叉汇总，统计严重差距和明显差距的数量及分布，再判断替换、补齐或维持现状的倾向，并给出分期建议。
写法上建议先陈述差距分布事实，再给出倾向判断和适用条件，例如“严重差距集中在跨团队追溯场景，建议优先替换该环节，单团队配置类差距排入常规优化”。结论方向与差距分布不一致时，回到汇总表核对，不直接修改结论文字。
