研发工具现状评估需要四类依据：工具与资产清单、使用与运行数据、成本与合同信息、用户与流程反馈。采集时先书面确认评估范围与判定口径，再按“清单—数据—访谈—核对”的顺序取证，每项依据标注来源、时间、负责人和可信度，最终汇总为现状基线，用于判断替换是否值得以及如何规划。ONES 可作为承载资产清单、流程断点记录与基线文档的协作载体。
要点总览（TL;DR）
- 评估依据分四类：工具与资产清单、使用与运行数据、成本与合同信息、用户与流程反馈，四类齐全才能支撑替换判断。
- 取证前先书面确认评估范围与判定口径，包括活跃用户计算方式、成本周期和数据时间窗，并记录排除项。
- 按“清单—数据—访谈—核对”的顺序执行，每项依据标注来源、时间、负责人与可信度，差异项回访负责人并记录原因。
- 现状基线用于回答替换是否值得、还需要补哪些证据；已确认事实与待验证问题应分开列示。
- 完成检查以依据完整性、数据一致性、成本口径和结论严谨性为通过标准，不通过项先补证再进入判断。
先定评估范围与判定口径
评估启动前，牵头人应先产出一页《评估范围说明》，把对象边界和判断标准写清楚。范围不清会导致后续取数口径混乱，例如不同团队按不同时间窗统计活跃用户，汇总时无法比较。
范围说明至少包含四项内容：
- 评估对象：明确纳入哪些团队、哪些工具类别（如项目管理、代码托管、持续集成、需求与文档协作）、哪些项目与仓库。建议按“团队—工具—项目”三层列出清单，避免遗漏边缘团队使用的工具。
- 评估目的：区分续费决策、替换可行性判断、整合冗余工具或成本压缩。目的不同，依据的侧重点不同：续费决策更依赖使用活跃度与成本，替换可行性更依赖流程断点与迁移影响。
- 判定口径：定义活跃用户的计算方式（如近30天有登录且有操作记录）、成本按年还是按合同周期统计、使用数据取哪个时间窗（如近6个月或近12个月）。口径一旦确定，全部数据按同一标准采集。
- 排除项：列出本次不纳入的系统与团队，并记录原因，例如“某团队刚完成工具切换，本次不重复评估”或“某自研系统不在替换范围内”。排除项有记录，后续结论才不会被质疑遗漏。
范围说明需由决策人确认后生效。确认动作本身也是依据：它表明评估目的和边界经过授权，后续结论有明确的适用范围。
四类依据的采集清单与取证方法
四类依据分别回答不同问题：资产清单回答“有什么”，使用数据回答“用得怎么样”，成本信息回答“花了多少”，用户反馈回答“哪里不顺”。四类齐全，才能支撑替换判断。
| 依据类别 | 具体内容 | 取数来源与采集方式 | 产出 |
|---|---|---|---|
| 工具与资产清单 | 账号数、项目/仓库/流水线数量、工具间集成关系与数据流向 | 各工具管理后台导出；集成关系由工具管理员逐项盘点，记录接口方向与同步字段 | 资产清单表，含工具名称、资产类型、数量、集成对象 |
| 使用与运行数据 | 活跃用户数、关键操作频次、构建发布次数、故障与工单记录 | 系统日志或统计报表导出；故障与工单从运维或支持渠道汇总 | 使用数据底稿，按统一时间窗统计 |
| 成本与合同信息 | 许可数量与单价、续费周期、运维人力投入、培训与迁移预算 | 财务或采购提供合同与历史支出；运维人力按投入工时折算 | 成本汇总表，区分许可支出与人力投入 |
| 用户与流程反馈 | 角色访谈记录、问卷结果、流程断点与手工补位环节 | 按角色分层访谈（管理员、团队负责人、一线用户）；问卷覆盖使用频率与痛点 | 访谈纪要与断点清单 |
每类依据在采集时同步登记四项元信息：来源系统、导出或采集时间、负责人、可信度（如“系统导出，高”“访谈口述，中”）。可信度标注让后续核对有优先级：低可信度数据需要更多交叉验证。
集成关系与数据流向容易被忽略，却是替换评估的关键依据。两个工具之间若存在自动同步，替换其中一个就会影响另一个的数据完整性，盘点时应记录同步方向、频率和涉及字段。
按步骤完成取证与交叉核对
采集清单确定后，按以下顺序执行，每步都有明确的输入、动作和输出。
- 导出资产与使用数据：工具管理员从各系统导出账号、项目、仓库、流水线及使用统计，形成原始数据底稿，保留导出记录（导出时间、操作人、筛选条件）。输出为原始底稿文件夹。
- 核对账号数与许可数：将系统账号数与合同许可数对比，识别闲置账号、共享账号和超许可使用情况。输出为账号差异表。
- 核对活跃用户与访谈反馈：将统计口径下的活跃用户名单与访谈中用户自述的使用情况比对。若访谈反映某团队高频使用但数据未体现，需检查统计口径是否遗漏该团队的操作类型。输出为活跃度差异说明。
- 差异项回访负责人：对每项差异回访对应负责人，记录差异原因，例如“账号数高于许可数是因为测试环境共用账号”。记录原因而非直接修正数据，保留原始值与解释，便于后续复核。
- 汇总现状基线：将四类依据按统一口径汇总为基线表，标注数据缺口与待验证项。输出为现状基线汇总表与差异说明记录。
完成标志是：每项依据都有来源与负责人，主要差异均已解释，未解释项明确列为待验证。达到这一状态，基线才可用于替换判断；否则应先补证再进入结论环节。
角色分工与各环节交付物
评估停留在信息收集阶段，通常是因为没有明确谁做判断、谁对结论负责。下表按角色列出输入、输出与完成时点。
| 角色 | 输入 | 输出 | 完成时点 |
|---|---|---|---|
| 工具管理员 | 各系统管理权限 | 账号、项目、集成与运行数据导出件 | 取证第一步结束前 |
| 财务或采购 | 合同、付款记录 | 许可数量、单价、续费周期与历史支出表 | 与数据导出并行 |
| 团队负责人与一线用户 | 访谈提纲 | 流程断点说明、手工补位环节记录 | 数据核对阶段 |
| 评估牵头人 | 四类依据与差异记录 | 统一口径的现状基线、差异说明、待验证清单 | 汇总阶段 |
| 决策人 | 范围说明与基线摘要 | 范围确认、后续动作决定（继续评估、补证或终止） | 评估启动时与基线完成后 |
牵头人是整个评估的枢纽：统一口径、组织核对、汇总基线，并对“哪些结论有依据、哪些仍是推测”负责。决策人不参与取数，但需在范围确认和基线验收两个节点做出明确表态，避免评估无限期延长。
当评估涉及多个团队和多个工具时，资产清单、断点记录和基线文档需要持续更新并保持版本一致。ONES 的项目与工作项可用于登记各工具的资产条目和待验证问题，文档模块可承载范围说明与基线版本，使牵头人汇总时有统一入口，差异项也能指派到具体负责人跟进。
示例：一次工具现状评估的依据组织
以下为演示情景，用于说明依据如何组织成结论，不代表任何真实组织的数据。
背景：某研发组织评估现有项目管理工具与代码托管工具是否继续使用，评估目的为判断替换可行性。范围包括两个研发团队的约120名用户、近12个月的使用数据，排除刚上线的一个试验团队。
依据组织：
- 资产清单显示项目管理工具中有46个项目、代码托管工具中有88个仓库，两工具之间存在需求编号与提交记录的自动关联。
- 使用数据显示近30天活跃用户约95人，构建流水线月均执行约600次。
- 合同信息显示项目管理工具许可100个、按年续费，代码托管工具按仓库数量计费。
- 访谈中三个团队负责人提到需求状态需要在两个工具间手工同步，每周约耗费数小时。
交叉核对：账号数显示110个账号，高于许可数100个，回访确认为离职人员账号未回收与测试共用账号所致，记录原因后保留原始数据。活跃用户95人与访谈反馈基本一致，但其中一个团队反映高频使用却未进入活跃名单，核查发现该团队主要通过接口操作，统计口径未包含接口调用，差异记录后列为口径待调整项。
结论形式：形成现状基线摘要，包含资产规模、活跃度、年度支出、手工同步断点四项主要发现，以及“接口操作是否计入活跃”“测试账号如何清理”两项待验证问题，供替换评估判断迁移影响与整合收益。
完成检查：依据是否足以支撑判断
进入替换判断前，用以下检查表逐项核对。任一项不通过，应补证或明确标注为待验证，不能直接进入结论。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 范围与口径 | 范围说明已书面确认，排除项有记录 | 补确认后再取数，阻断后续汇总 |
| 依据完整性 | 四类依据均有来源、时间与负责人 | 缺失类别列为待补，标注对结论的影响 |
| 数据一致性 | 主要差异已解释，未解释项列为待验证 | 回访负责人补充说明，不直接修改原始数据 |
| 成本口径 | 覆盖许可、运维人力与迁移培训 | 补充人力折算与迁移预算估算 |
| 结论严谨性 | 区分已确认事实与推测，并说明下一步验证动作 | 将推测项移入待验证清单，不作为决策依据 |
检查通过后，现状基线即可作为替换评估的输入：已确认事实支撑“是否值得替换”的判断，待验证问题决定“还需要补哪些证据”。基线不是一次性文档，替换方案推进过程中出现新的使用数据或成本变化时，应回到基线更新对应条目，保持评估依据与决策同步。
常见问题
评估范围已经确认，中途发现遗漏了某个团队或工具，应该怎么处理？
先判断遗漏项是否影响当前结论。若遗漏团队使用的工具与评估对象存在集成关系或成本关联，应补充进范围说明并重新确认口径，再补采对应依据；若关联较弱，可记录为“本次不纳入”并写明原因，留待下一轮评估。无论哪种处理，都要更新范围说明的版本和确认记录，避免后续引用旧版本造成口径不一致。
活跃用户数据与访谈反馈对不上时，以哪个为准？
两者都不直接作为最终结论，先查差异原因。常见原因是统计口径未覆盖某些操作方式，例如通过接口或命令行操作的用户未计入活跃名单，也可能是访谈对象对使用频率的判断偏主观。处理方式是回访对应负责人，记录差异原因并保留原始数据，必要时调整口径后重新统计。差异解释清楚之前，该项数据在基线中标注为待验证。
成本依据只拿到许可费用，运维人力和迁移培训投入怎么估算？
许可费用可从合同和付款记录直接取得；运维人力按实际投入工时折算，可由工具管理员和运维人员估算日常维护、账号管理、故障处理所占工时比例；迁移培训投入属于预估项，应标注为估算而非已发生支出，并说明估算假设。三类成本分开列示，避免把估算值混入已确认数据，影响替换收益的判断。
评估结论需要多细才算可以支撑替换决策？
结论至少要能回答三个问题：现有工具的实际使用规模与活跃程度、年度总成本（含许可与人力）、以及替换会影响的集成关系和流程断点。每项结论都要能追溯到具体依据和负责人。对于无法确认的部分，明确列为待验证问题并说明验证方式，不用推测填补。决策人据此判断是继续推进替换评估、补充证据还是终止。
现状基线完成后，后续还需要维护吗？
需要。替换方案推进过程中，使用数据、合同续费和团队范围都可能变化，基线应随关键节点更新对应条目，并保留版本记录。牵头人负责维护基线的一致性，差异项指派到具体负责人跟进。基线保持更新，替换评估的结论才有持续的依据支撑，避免用过期数据做决策。
