研发工具替换评估回答的是“现有工具要不要换、换得起吗”，产出替换必要性判断、迁移资源估算和实施约束清单；从零选型回答“没有存量时选哪个”，产出候选名单与选型标准；迁移执行回答“已经决定换，数据怎么搬”，产出字段映射、试迁移和验收结果。三者常被混成一次动作，实际决策时点和交付物并不相同。本文用同一口径区分这四类任务，并给出替换评估阶段可直接使用的输出物结构，帮助判断当前该先做哪一步。
要点总览（TL;DR）
- 替换评估回答“现有工具要不要换、换得起吗”，产出替换必要性结论、迁移资源估算和实施约束清单，决策点在换与不换之前。
- 从零选型回答“没有存量时选哪个”，产出候选名单、选型标准和验证记录；替换评估的约束清单是它的输入条件。
- 迁移执行回答“已经决定换，数据怎么搬”，产出字段映射、试迁移结果和验收记录，发生在目标工具与方案确定之后。
- 单点问题处理只解决某个具体故障或使用痛点，不涉及工具去留；同类问题反复出现且修复成本上升时，才具备升级为替换评估的信号。
- 行动顺序按已知条件判断：只有局部痛点先处理问题，明确要换但未定目标先做评估，已定目标工具则把评估压缩为可行性确认后进入迁移。
四类任务各自回答什么问题
把四类任务放在同一张表里对照，最容易看清它们的差别不在工作量大小，而在提问对象和决策时点不同。替换评估面对的是“存量”，从零选型面对的是“空白”，迁移执行面对的是“已决策后的搬运”，单点问题处理面对的是“某个具体故障或使用痛点”。
| 任务类型 | 核心提问 | 所需输入 | 主要产出物 | 决策时点 |
|---|---|---|---|---|
| 替换评估 | 现有工具要不要换、换得起吗 | 使用范围与活跃度、替换动因、集成依赖、数据体量、迁移代价 | 替换必要性结论、迁移资源估算、实施约束清单 | 换与不换的决策之前 |
| 从零选型 | 没有存量时选哪个 | 业务需求、团队规模与角色、流程要求、预算与合规条件 | 候选名单、选型标准、验证方式与结论 | 目标工具确定之前 |
| 迁移执行 | 已经决定换，数据怎么搬 | 迁移范围、字段与流程映射、切换窗口、回退方案 | 字段映射表、试迁移结果、核验与验收记录 | 目标工具与方案确定之后 |
| 单点问题处理 | 某个故障或使用痛点怎么解决 | 问题现象、影响范围、临时与根本原因 | 修复方案或替代操作方式 | 问题发生时，不涉及工具去留 |
四类任务存在先后衔接关系：替换评估的结论若为“换”，其约束清单交给选型阶段作为筛选条件，迁移范围交给执行阶段作为工作边界；若结论为“暂缓”或“局部优化”，则回到单点问题处理或使用方式调整。把这条链路画清楚，可以避免在评估尚未完成时就启动迁移，也避免把一次故障处理当成替换决策的依据。
替换评估的判断对象：值不值得换、换得起吗
替换评估包含两个判断面，缺一不可。第一面是替换必要性：现有工具带来的问题是否已经影响到研发工作的正常开展，问题是否只能通过更换工具解决。第二面是替换可行性：即使值得换，企业是否具备完成替换的资源与条件。只谈必要性容易低估代价，只谈可行性容易把“能换”误当成“该换”。
替换动因需要分类，而非笼统归为“不好用”
常见动因可以归为几类：成本类，如许可费用增长或总体拥有成本上升；协作断点类，如多套工具造成数据割裂、跨团队流转依赖人工搬运；合规与安全类，如数据存放位置、审计要求或信创适配要求；供应商变化类，如产品路线调整、服务支持能力下降。不同动因对应的评估重点不同：成本类要算清替换与保留的长期账，协作断点类要定位断点发生在哪些流程节点，合规类要先确认约束是硬性门槛还是可协商条件。企业考虑替换 Jira 和 Confluence 的常见诉求就包括信创及数据安全要求、海外工具成本增长、多套工具造成的数据割裂，以及对长期自主可控能力的考虑，这类归纳可作为动因盘点的参照，具体到本企业仍需逐项核实。
现状盘点要落到可核查的对象
现状盘点至少覆盖四项：使用范围，即哪些部门、团队和项目在用，是否存在名义在用实际闲置的情况；活跃度，即活跃用户数、高频功能与低频功能分布；集成依赖，即与代码仓库、CI/CD、即时通讯、单点登录、报表等系统的对接关系；数据体量，即项目数、工作项数、附件与历史记录规模。这四项直接决定迁移工作量，也决定替换后哪些能力必须保留。对于原来依赖插件的功能，可以先梳理实际使用的插件清单，再逐项判断替换后如何匹配，企业已有的定制场景在迁移前仍需逐项评估，避免直接假设所有插件都能一一对应。
迁移资源估算与实施约束
资源估算要回答三笔账：人力，包括数据整理、映射配置、测试验证和切换支持分别需要哪些角色投入多少时间；时间，包括准备期、试迁移期、正式切换期和并行观察期；数据工作量，包括清洗规则、字段与流程映射的复杂度、验证抽样比例。实施约束则包括可接受的停机窗口、是否需要新旧系统并行、权限与审计要求在迁移期间如何保持、切换失败时的回退条件。真正实施替换时，还需要同时保障现有功能、历史数据和日常研发工作的连续性，这一条应作为约束清单中的硬性项写入。
这些盘点结果和约束条目需要被持续记录和复核，而不是停留在个人文档里。ONES 的项目与 Wiki 能力可用于承载现状盘点表、动因清单和约束条目，让评估结论、责任人和后续动作在同一处留痕，便于移交选型或迁移阶段时直接引用。
从零选型与迁移执行的分界在哪里
从零选型的重心是建立标准再筛选对象。没有存量包袱时，先梳理业务需求与角色场景，形成评估标准，再按标准缩小候选范围，最后通过演示、试用或场景验证确认结论。它的产出是候选名单、选型标准和验证记录，交付对象是决策者。替换评估向它交接的是约束清单：哪些能力必须保留、哪些合规条件是硬门槛、可接受的成本区间是多少。带着这些约束进入选型，候选范围会明显收窄。
迁移执行的重心是把已确定的方案落到数据上。工作内容包括数据范围确认、字段与流程映射、试迁移、结果核验、正式切换与回退预案。Jira 迁移范围可以覆盖项目、工作项、状态、字段、流程、附件和历史记录，重点在于尽可能保持原有研发过程和工作方式的连续。降低数据丢失或业务中断风险的常见做法，是把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。替换评估向它交接的是迁移范围与约束条件：哪些数据必须完整迁移、停机窗口多长、并行期如何安排。
单点问题处理不构成替换评估，原因在于它的判断对象是具体问题而非工具去留。修复一个流程配置错误、调整一处权限设置、为某个团队补充使用培训，都能改善体验，但不回答“是否值得整体更换”和“更换代价是否可承受”。当同类问题反复出现、影响多个团队、且修复成本持续上升时，才具备升级为替换评估的信号；此时应把问题记录作为动因证据纳入评估，而不是直接跳到更换结论。
替换评估该产出哪些文档与结论
替换评估阶段交付到什么程度算完成，可以用四份材料衡量：一份结论、一张资源估算表、一份约束清单、一份移交说明。四份材料齐备，后续选型或迁移才有可靠输入。
评估结论的三种走向
结论应明确落到三种走向之一。替换：动因成立且资源与约束可满足，进入选型或方案确定阶段。暂缓：动因存在但当前资源不足或时机不合适，写明触发重新评估的条件，例如许可到期、合规要求生效或问题影响范围扩大。局部优化：问题集中在少数流程或团队，通过配置调整、使用规范或补充培训即可缓解，不启动整体更换。三种走向都要写明依据，避免只给结论不给理由。
迁移资源估算表与实施约束清单的字段
| 文档 | 建议字段 |
|---|---|
| 迁移资源估算表 | 工作项、涉及系统与数据范围、所需角色、人力投入（人天）、时间窗口、前置依赖、风险等级、责任人 |
| 实施约束清单 | 约束类型（停机、并行、权限、审计、合规、集成）、具体要求、来源依据、是否硬性、满足方式、验证责任人 |
| 移交说明 | 移交对象（选型或迁移）、移交内容、未决事项、建议下一步、决策人与确认时间 |
评估未通过时，替代动作应与结论走向对应：暂缓情形下设定复核时间点和监测指标；局部优化情形下把问题清单转为改进任务并跟踪效果；动因证据不足时补充使用数据再评估。这样处理可以避免评估流于形式，也避免在证据不充分时仓促启动更换。
按场景选择先做哪一步
行动顺序取决于两个已知条件：是否已有明确的更换意向，是否已有目标工具。按这两个条件可以分出几种典型场景。
- 存量工具仍在稳定使用、只有局部痛点：先做单点问题处理，记录问题类型与影响范围；同类问题反复出现且修复成本上升时，再启动替换评估。
- 已明确要换但未定目标：先完成替换评估，拿到必要性结论与约束清单，再进入从零选型，用约束条件筛选候选。
- 已定目标工具：替换评估可以压缩为可行性确认，重点核对迁移范围、功能匹配与实施约束，随后直接进入迁移执行。
- 多套工具并存、数据割裂：先做现状盘点与集成依赖梳理，判断割裂发生在哪些流程节点，再决定是整合还是替换。
评估结论需要证据支撑，常见证据包括使用活跃度数据、问题工单记录、集成清单、数据体量统计和合规要求原文。复核时重点检查三项：动因是否有多源证据而非单一抱怨，资源估算是否包含验证与回退工作量，约束清单中的硬性条件是否都有满足方式。涉及具体产品的功能匹配、版本兼容与合规认证范围，应以实际方案和官方说明为准逐项确认，不在评估阶段作笼统假设。
常见问题
替换评估结论为“暂缓”时，后续应该做什么？
暂缓不等于搁置。结论中要写明触发重新评估的条件，例如许可到期、合规要求生效、问题影响范围扩大或使用活跃度出现明显变化，并设定复核时间点与监测指标。在暂缓期间，可以先把已识别的问题转为局部优化任务跟踪效果，同时持续记录动因证据。当触发条件出现时，用积累的数据重新评估，避免每次从零开始。
已经确定要换工具，还需要完整做替换评估吗？
可以压缩，但不宜完全跳过。此时评估的重心从“值不值得换”转向“换得起吗”，重点核对迁移范围、功能匹配与实施约束，包括停机窗口、并行期安排、权限与审计要求在迁移期间如何保持、回退条件是否明确。这些内容直接决定迁移执行能否顺利推进，缺少这一步容易在执行阶段才发现约束冲突。
原来依赖插件的功能，在替换评估阶段要处理到什么程度？
评估阶段至少要梳理实际使用的插件清单，并逐项判断替换后如何匹配，避免直接假设所有插件都能一一对应。企业已有的定制场景需要单独列出，作为约束清单中的条目移交给选型或迁移阶段。具体到每个插件能否对应、需要何种替代方式，应在方案确认时逐项核实，评估阶段给出的是待确认清单而非最终结论。
评估中如何判断一个问题该走单点处理还是升级为替换评估？
可以看三个信号：同类问题是否反复出现、是否影响多个团队、修复成本是否持续上升。只影响单个团队且能通过配置调整或培训解决的问题，按单点问题处理更合适。当三个信号同时出现时，把问题记录作为动因证据纳入替换评估，用使用活跃度数据、问题工单记录和集成清单支撑判断，而不是直接跳到更换结论。
替换评估中的资源估算容易漏掉哪些工作量？
常见遗漏有两类。一是验证类工作量，包括试迁移后的抽样核验、字段与流程映射的比对确认，这部分往往被低估。二是回退类工作量，包括回退方案的准备与演练、并行观察期的人力投入。估算表建议按工作项列出所需角色、人力投入、时间窗口、前置依赖和风险等级，并明确责任人，便于在移交迁移阶段时直接引用。
