研发工具替换评估要形成可提交决策的材料，需要四层依据：替换触发条件、现状基线、候选差距、投入与风险。四层分别回答“为什么换”“现在是什么样”“换成什么更合适”“代价和退路是什么”。评估任务、问题清单和结论文档可以在ONES中组织与留档，便于评审和交接。
要点总览（TL;DR）
- 替换评估需要四层依据：触发条件说明为什么换，现状基线说明当前用了多少、依赖多深，候选差距说明换成什么更合适，投入与风险说明代价和退路。
- 现状基线用系统导出加访谈采集，覆盖用户与团队、项目与工作项量、附件与历史数据、集成清单、自定义流程与字段，并标注采集日期与口径。
- 候选比较应在接触方案前确定统一标准，按流程覆盖、数据迁移、集成兼容、权限合规、使用成本、扩展维护逐项记录差距与证据来源。
- 投入估算要覆盖许可、实施、迁移、培训与并行运行人力；回退条件在切换前写定，明确到可执行的判断标准和决策人。
- 评估任务、问题清单与结论文档可在ONES中组织留档，评审意见与签核版本可追溯，结论确定后切换计划可从评估任务派生。
先明确：替换评估要回答哪几个问题
替换评估容易做成功能清单对比，列了几十项能力，却无法回答管理层最关心的问题。开始采集数据前，先把评估要回答的问题写清楚，后续每项数据采集和比较才有落点。
一次完整的替换评估通常包含三类问题，它们的判断对象和产出不同：
| 问题类型 | 核心判断 | 主要产出 | 决策人 |
|---|---|---|---|
| 是否值得换 | 现有工具的问题是否严重到必须通过替换解决，维持现状或局部优化是否可行 | 触发条件说明与现状基线报告 | 研发管理者与业务负责人 |
| 换成什么 | 候选方案在统一标准下与现状的差距、迁移代价和适配程度 | 评估标准表与候选差距对照表 | 评估小组评审，研发管理者确认 |
| 如何切换 | 投入是否可接受，风险是否可控，回退条件是否明确 | 投入估算表、风险清单与切换计划 | 研发管理者、IT、采购与安全合规共同确认 |
同时要界定本次评估覆盖的工具范围。例如只评估项目与需求管理工具，还是连同知识库、测试管理一起评估；哪些团队在范围内，哪些团队暂不纳入。范围界定表至少写明：工具名称与当前版本、使用团队、评估起止时间、明确不纳入的对象及原因。范围写清楚，可以避免评估过程中不断追加对象导致结论失效。
评估结论的产出形式也应提前约定，常见形式是“现状与触发条件说明＋候选差距对照＋投入与风险测算＋建议结论”四部分组成的决策材料，附一份待决策事项清单。明确谁签核、在什么会议上决策，评估才不会停留在分析阶段。
依据一：替换触发条件与现状基线
替换理由需要事实支撑。触发条件回答“为什么现在要评估”，现状基线回答“当前到底用了多少、依赖多深”。两者合在一起，才能判断问题是局部优化能解决，还是必须替换。
常见触发类型
- 业务变化：团队规模扩张、多产品线并行、研发模式调整，现有工具的流程模型或协作方式跟不上。
- 成本：许可费用增长、按人头计费模式下成本随团队扩张快速上升，或维护投入持续偏高。
- 合规与安全：数据存放位置、权限审计、国产化适配等要求发生变化，现有工具难以满足。
- 维护与厂商支持：版本升级停滞、插件生态萎缩、原厂支持响应变慢，日常问题积压。
- 体验与效率：高频操作路径冗长、跨工具切换频繁、报表口径不一致，团队反复反馈同类问题。
每类触发条件尽量落到可核对的证据上，例如成本项附上近两年的许可账单，合规项附上审计发现或安全部门的要求文件，体验项附上工单记录或访谈中重复出现的具体场景。仅有“大家觉得不好用”的判断，不足以支撑替换决策。
现状基线字段
基线数据建议用系统导出与访谈结合的方式采集。系统导出提供数量与结构，访谈补充依赖关系和实际使用情况。
| 基线字段 | 采集方式 | 用途 |
|---|---|---|
| 用户数与团队分布 | 系统用户列表导出，按部门与角色归类 | 估算许可与培训成本，识别活跃与沉默用户 |
| 项目数与工作项量 | 按项目类型、状态、年份导出统计 | 评估迁移数据量与迁移窗口 |
| 附件与历史数据 | 导出附件总量、单文件大小分布、历史记录条数 | 判断迁移工具适配性与存储成本 |
| 集成清单 | 梳理与代码仓库、CI、IM、监控、报表等系统的对接关系 | 识别切换后可能失效的集成点 |
| 自定义流程与字段 | 导出工作流、字段、权限方案的配置清单 | 评估候选方案能否承载现有流程 |
| 插件与自动化规则 | 列出实际在用的插件和自动化脚本，标注使用频率 | 逐项评估替代方式，避免假设一一对应 |
访谈对象应覆盖不同角色：一线研发人员说明日常操作痛点，项目经理说明流程依赖，IT 说明集成与运维负担，安全合规说明审计要求。访谈记录按触发类型归档，与系统导出数据相互印证。基线数据要标注采集日期和口径，例如“工作项量统计截至某月末，含已关闭项目”，避免后续比较时口径不一致。
依据二：统一评估标准与候选差距对照
候选比较的前提是同一组标准、同一套判定口径。标准应在接触候选方案之前确定，避免被演示效果牵着走。建议从以下维度建立评估标准表：
| 评估维度 | 判定方式 | 证据来源 |
|---|---|---|
| 流程覆盖 | 用现状基线中的自定义流程逐条对照，记录可原生支持、需配置实现、需定制开发、无法支持 | 候选方案配置演示、流程配置文档 |
| 数据迁移 | 核对可迁移对象范围（项目、工作项、状态、字段、流程、附件、历史记录），确认迁移工具与试迁移安排 | 迁移方案说明、试迁移结果 |
| 集成兼容 | 对照集成清单逐项确认对接方式与工作量 | 开放接口文档、集成验证记录 |
| 权限与合规 | 核对权限模型粒度、审计日志、部署形态与安全要求 | 安全合规部门评审意见 |
| 使用成本 | 核算许可、实施、培训与运维的年度总成本 | 报价材料、同类项目历史数据 |
| 扩展与维护 | 评估自定义能力、自动化能力、版本升级节奏与厂商支持方式 | 产品资料、厂商服务说明 |
每个维度给出明确的判定等级，例如“满足／部分满足／不满足”，并附证据出处。差距记录采用同一格式：现状做法、候选方案对应能力、差距描述、影响范围、缓解方式。这样记录的好处是，评审时可以直接看到差距集中在哪些环节，而不是面对一份笼统的评分。
插件和定制场景需要单独列出逐项评估。原来依赖插件的功能，先梳理实际在用的插件清单，再逐项确认候选方案中由哪项能力承接、需要配置还是开发、工作量多大。企业已有的定制场景在评估阶段就要标注，不能默认所有插件都能一一对应。
依据三：投入、风险与回退条件
功能匹配只是决策的一半，另一半是代价与退路。投入估算要覆盖完整周期，不能只算许可费用。
- 许可费用：按实际活跃用户数和所需能力核算，注意计费口径与合同周期。
- 实施费用：流程配置、权限方案设计、集成开发的工作量。
- 迁移费用：数据梳理、试迁移、正式迁移及校验的人力与工具投入。
- 培训费用：分角色的培训组织、材料准备与上手期效率损失。
- 并行运行人力：新旧系统并行期间的双份维护投入，通常按周或按月估算。
风险项按发生概率与影响程度列出，常见风险包括：历史数据迁移不完整或附件丢失、流程切换期间工作项状态断点、关键集成失效导致研发链路中断、用户抵触造成新系统使用率低。每项风险写明预防措施和责任人，例如试迁移校验、分阶段切换、集成预验证、分角色培训与试点团队先行。
回退条件要在切换前写定，而不是出问题后再讨论。可操作的设定方式包括：试迁移数据校验不通过则暂停正式迁移；试点团队使用两周后关键流程无法跑通则回退；正式切换后约定周期内严重故障超过设定次数则启动回退。止损点与决策人一并写明，回退方案本身也要评估成本，例如并行期延长带来的额外投入。
角色分工与各阶段交付物
评估依据由不同角色提供，评审和决策也各有归属。分工不清，容易出现数据无人采集、结论无人签核的情况。
| 角色 | 主要输入 | 对应交付物 |
|---|---|---|
| 业务负责人 | 业务变化与流程诉求、触发条件说明 | 触发条件说明表 |
| 研发管理者 | 团队分布、流程依赖、评估范围界定 | 范围界定表、评估结论建议 |
| IT／运维 | 系统导出数据、集成清单、运维负担记录 | 现状基线表、集成兼容评估 |
| 采购 | 许可账单、报价材料、合同条款 | 投入估算表 |
| 安全合规 | 审计要求、数据存放与权限要求 | 合规评审意见 |
评估小组建议由研发管理者牵头，包含上述角色的代表，按阶段组织评审：范围界定完成后评审一次，基线与触发条件完成后评审一次，候选差距与投入风险完成后形成决策材料提交决策会。每个阶段交付物标注编制人和签核人，签核记录与版本一并留存。
示例：一次中等规模研发团队的替换评估
以下为演示情景，用于说明四层依据如何填写，数据为示例值。
触发条件与基线：某研发团队约150人，使用现有工具管理8条产品线的需求与缺陷。触发条件记录为：许可成本两年内随人数增长上升约四成；安全部门在审计中提出数据存放位置要求；团队反馈跨项目报表需要手工整理。基线数据导出显示：活跃用户约120人，历史项目60余个，工作项约18万条，附件约200GB，集成系统6个，自定义工作流12套，在用插件5个。
评估标准与差距：按六个维度对照两个候选方案，流程覆盖维度记录“12套工作流中9套可配置实现、2套需定制、1套需调整流程”；数据迁移维度确认项目、工作项、状态、字段、流程、附件与历史记录在迁移范围内，安排试迁移校验；集成维度6个系统中4个有现成对接方式、2个需开发；合规维度由安全部门出具评审意见。
投入与回退：投入估算包含许可、实施、迁移、培训与约六周并行运行人力；风险清单列出附件迁移校验、集成预验证和试点团队先行三项预防措施；回退条件设定为试迁移校验不通过暂停正式迁移、试点两周关键流程无法跑通则回退。
结论表述：建议在满足合规要求的前提下替换，选择差距集中在可配置范围内的候选方案，按试点、分批迁移、全面切换三阶段推进，并保留回退窗口。结论中同时标注未验证项，例如两个待开发集成的工作量尚需技术验证。
评估过程中的协作承载与记录留痕
评估涉及多角色、多轮评审和大量附件，材料散落在个人文档和聊天记录中，后续决策和切换交接都会失去依据。建议把评估过程本身当作一个项目来组织：建立评估任务清单，按四层依据拆分为工作项，每项标注负责人、截止时间和交付物；问题清单单独维护，记录评估中发现的待确认事项及其关闭状态；结论文档按版本管理，每次评审后的修改可追溯。
在ONES中，可以用项目承载评估任务与问题清单，用Wiki组织结论文档和评审记录，评审意见与签核结果随文档留存。评估结论确定后，切换计划可以直接从评估任务派生，保持依据与执行之间的对应关系。这样做的价值在于：决策会上引用的数据、评审中提出的疑问、最终签核的版本，都能在同一处查到，切换阶段出现争议时也有据可依。
完成检查：评估材料是否足以支撑决策
提交决策前，用以下清单逐项核对。任何一项无法确认，都应标注为待补充或未验证项，而不是默认通过。
- 触发条件是否有具体证据支撑，每类触发是否对应到账单、审计意见、工单或访谈记录。
- 现状基线是否覆盖用户与团队、项目与工作项量、附件与历史数据、集成清单、自定义流程与字段，是否标注采集日期与口径。
- 评估标准是否在接触候选方案前确定，每个维度的判定方式和证据来源是否写明。
- 候选差距是否逐项记录，插件与定制场景是否逐项评估而非整体假设可替代。
- 投入估算是否覆盖许可、实施、迁移、培训与并行运行人力，是否注明计费口径。
- 风险清单是否包含预防措施与责任人，回退条件与止损点是否明确到可执行的判断标准。
- 关键假设与未验证项是否单独列出，例如待验证的集成工作量、待确认的合规适配范围。
- 各阶段交付物是否有编制人与签核人，决策人和决策会议是否已确定。
- 评估结论是否明确回答“换不换、换什么、怎么换”，并与后续切换计划建立对应关系。
四层依据齐备、未验证项标注清楚、决策人与回退条件明确，评估材料才具备提交决策的条件。
常见问题
团队规模不大、问题也不算严重，还需要做完整的四层评估吗？
可以按比例裁剪，但四层依据的逻辑不宜省略。触发条件仍要写清楚，哪怕只有一两条证据；现状基线可以简化到用户数、工作项量、集成清单和关键自定义流程；候选比较至少覆盖流程覆盖与数据迁移两个维度；投入与回退条件可以简短，但要写明什么情况下暂停或放弃切换。评估材料的详略取决于决策金额和影响范围，判断标准是决策人能否据此回答“换不换、换什么、怎么换”。
评估过程中发现候选方案某项能力资料不全，应该怎么处理？
把该项标注为未验证项，写明待确认的问题、需要谁提供材料、在哪个节点前关闭，不要用推测填补。涉及集成工作量、合规适配范围这类关键项，可以安排技术验证或由厂商提供方案说明后再更新评估表。未验证项集中列在结论材料中，与已验证结论分开呈现，决策人才能判断剩余不确定性是否可接受。
回退条件设得太严会拖慢切换，设得太松又失去意义，怎么把握？
回退条件应绑定可观察的事实，而不是主观感受。常见做法是绑定试迁移校验结果、试点团队关键流程能否跑通、正式切换后约定周期内的严重故障次数。设定时同时评估回退本身的成本，例如并行期延长带来的人力投入。条件写定后由评估小组和决策人共同确认，切换过程中按约定触发，避免临时争论。
评估结论支持替换后，评估材料和切换计划怎么衔接？
结论材料中的四层依据应能直接对应到切换计划的工作项：触发条件对应切换目标与验收标准，基线数据对应迁移范围，候选差距对应配置与开发任务，投入与风险对应资源安排和回退预案。在ONES中，评估任务可以派生出切换计划的任务清单，结论文档与评审记录留在Wiki中，切换阶段出现争议时可回溯当时的依据和签核版本。
评估阶段需要把插件和定制场景全部验证完吗？
不要求全部验证完，但需要逐项列出并给出初步判断。做法是先梳理实际在用的插件和定制清单，标注使用频率和影响范围，再逐项确认候选方案中由哪项能力承接、需要配置还是开发、工作量大概多少。工作量尚不明确的项标为待技术验证，作为未验证项进入结论材料。整体假设“都能替代”会让后续切换阶段集中暴露风险。
