现状评估做完后，真正影响选型质量的一步，是把“哪里不好用”转成“候选工具必须满足什么”。本文给出一套可落地的转换方法：先把评估结论整理成替换需求清单，再把需求写成带验证方式的筛选条件，按五类维度补齐，最后用同一套条件对候选工具逐项对照并小范围试跑。文中会说明条件如何记录、评审和冻结，并自然提及ONES在需求清单与证据留痕上的承载方式。
要点总览（TL;DR）
- 把现状评估中的零散问题按业务对象、受阻动作、影响范围、约束条件四类归集，区分必须解决的痛点与可接受现状，再改写成带场景和判断标准的需求陈述。
- 每条需求配一个可验证的筛选条件，写明验证方式、证据来源和判定口径；不满足即淘汰的进硬性门槛，满足程度有差异的进加权评分项，条件总量建议收敛到20–30条。
- 筛选条件按流程与工作项模型、数据迁移与集成、权限与合规、使用成本与推广难度、服务与演进能力五类维度补齐，避免只围绕最痛的一两个问题设计。
- 候选对照按条件编号逐项填写，先筛门槛再评加权项，单元格记录结论、证据来源和确认状态；未确认项统一标注，不默认满足也不直接淘汰。
- 定稿前用1–2个真实业务场景试跑，检验条件是否可判定，调整门槛与权重后冻结版本，作为后续对照、演示提问和验收的依据。
从评估结论到替换需求清单：先整理四类信息
现状评估的原始产出通常是访谈记录、工单统计、使用反馈和流程梳理文档，内容零散且以抱怨和现象为主。要让它变成可执行的选型输入，第一步是按四类信息归集：业务对象（需求、任务、缺陷、迭代、版本、文档等被管理的实体）、受阻动作（谁在什么环节做不下去或反复返工）、影响范围（涉及哪些团队、角色、项目数量、发生频率）、约束条件（预算周期、部署环境、合规要求、切换时间窗）。四类信息齐了，问题才具备被改写成需求的基础。
归集之后要做一次取舍：区分必须解决的痛点和可接受的现状。判断标准可以看三条——是否直接造成交付延误或质量风险、是否影响多个团队且高频发生、是否有明确的业务后果可描述。只影响个别角色操作习惯、有临时绕行方案且成本可控的问题，可以标注为“可接受现状”，不进入替换需求，避免需求清单膨胀成愿望清单。
问题描述要改写成需求陈述，句式建议为“在【场景】下，【角色】需要【能力/结果】，以满足【业务目标】，判断标准是【可观察的结果】”。例如“缺陷状态流转要手工通知测试，经常漏”可改写为“在缺陷修复环节，测试角色需要状态变更自动通知相关人，以减少漏通知导致的回归延误，判断标准是状态变更后相关角色在工具内可收到提醒”。改写时同步标注需求来源（访谈、工单、数据统计）和影响角色，后续排序和试跑选人都会用到。
| 问题现象 | 业务对象 | 受阻动作 | 影响范围 | 需求陈述 | 来源角色 |
|---|---|---|---|---|---|
| 缺陷状态变更靠口头通知，回归经常漏测 | 缺陷 | 缺陷流转与通知 | 测试组3个小组，每周约20次 | 缺陷状态变更后自动通知相关角色，通知记录可查 | 测试负责人 |
| 需求变更后任务清单不同步，开发做旧版本 | 需求、任务 | 需求与任务联动 | 2条产品线，每月5–8次 | 需求变更后关联任务同步更新并提示影响范围 | 产品经理 |
| 跨项目统计要手工导出汇总，耗时两天 | 迭代、工作项 | 跨项目报表 | PMO，每季度一次 | 支持跨项目按维度汇总并导出，口径可配置 | PMO |
需求清单本身也需要一个可协作的载体：每条需求有编号、来源、影响角色、状态和评审结论，评审意见与修改记录可追溯。ONES的文档与工作项可以承载这类清单，把需求条目作为工作项管理状态，把评估记录放在文档中随评审更新，便于后续把需求编号直接带到筛选条件和候选对照表里，减少多头维护。
把需求转成筛选条件：硬性门槛与加权项分开
需求回答“要解决什么”，筛选条件回答“怎么判断候选工具能不能解决”。转换的关键是给每条需求配一个可验证的判定方式。硬性门槛指不满足即淘汰的条件，通常来自不可协商的约束：部署方式、数据存放地、必须对接的现有系统、必须迁移的历史数据范围、合规审计要求。加权评分项指满足程度有差异、可以比较优劣的条件，例如自定义字段的灵活度、报表配置的便捷性、移动端体验。划分规则可以问一句：这条不满足时，业务是否直接无法运转或违反硬性规定？是则入门槛，否则进评分项。
每条筛选条件至少写清四项：验证方式（演示、试用操作、文档查阅、供应商书面答复）、证据来源（具体文档章节、试用环境记录、答复邮件）、判定口径（什么算满足、部分满足如何计）、权重（仅评分项需要）。判定口径要具体到可观察的行为，例如“支持按角色配置字段可见性，且在试用环境中完成一次配置验证”，避免写成“权限灵活”这类无法判定的表述。
两类常见错误需要提前规避。一是把偏好写成门槛：某角色习惯了某种看板样式，就要求候选工具必须一致，这会无谓淘汰可用方案，应降为评分项并给较低权重。二是把未确认能力写成不支持：供应商未答复或演示未覆盖，应标注“未确认”，保留在清单中继续取证，不能直接判定淘汰或判为满足。
条件数量需要控制。需求清单可能有几十条，筛选条件建议收敛到20–30条，其中门槛项控制在10条以内。去重方法是将指向同一能力的需求合并为一条条件，在“对应需求”字段列出多个需求编号；对影响范围小、发生频率低的需求，合并进评分项或暂不纳入首轮筛选。
| 条件编号 | 对应需求 | 类型 | 验证方式 | 证据来源 | 判定口径 | 权重 |
|---|---|---|---|---|---|---|
| C01 | R03、R07 | 门槛 | 文档查阅+试用 | 部署文档、试用环境 | 支持本地化部署，数据存放于指定机房 | — |
| C02 | R05 | 门槛 | 演示操作 | 演示记录 | 可与现有代码仓库对接，提交记录关联工作项 | — |
| C03 | R02 | 评分 | 试用操作 | 试用环境记录 | 需求变更后关联任务可同步更新并提示影响 | 5 |
| C04 | R09 | 评分 | 供应商书面答复 | 答复邮件 | 开放接口支持批量导出工作项与附件 | 3 |
筛选条件应覆盖的五类维度
按维度补齐条件，可以避免只围绕最痛的一两个问题设计筛选，漏掉迁移、权限、推广等后期才暴露的风险。下面五类维度覆盖研发管理工具替换中最常见的评估面，每类给出可直接改写为门槛或评分项的条件示例。
流程与工作项模型
关注需求、任务、缺陷、迭代与自定义字段的承载方式，以及流程能否按团队差异配置。示例条件：支持为不同项目配置独立工作流与状态机（门槛或高权重评分）；自定义字段支持必填校验与联动显示（评分）；缺陷与需求可建立关联并双向追溯（评分）。
数据迁移与集成
关注历史数据迁移范围和与代码仓库、CI/CD及现有系统的对接方式。示例条件：支持迁移历史工作项、附件与评论，字段映射可配置（门槛）；与现有代码仓库对接，提交与合并请求可关联工作项（门槛）；提供开放接口供内部系统调用（评分）。迁移范围要写明时间跨度和项目数量，避免“全量迁移”这类无法验收的表述。
权限与合规
关注角色权限粒度、审计留痕、部署方式与数据存放要求。示例条件：支持按项目、角色、字段三级配置权限（门槛或评分）；关键操作有审计日志且可导出（门槛）；部署方式与数据存放地符合内部规定（门槛）。合规类条件应以内部制度条款为依据，写明对应条款编号。
使用成本与推广难度
关注学习成本、角色覆盖和并行期安排。示例条件：核心角色完成基础操作培训不超过半天（评分）；覆盖产品、开发、测试、项目管理四类角色的日常操作（门槛）；支持新旧工具并行期数据双向同步或只读访问（评分）。这类条件容易写成主观感受，建议用培训时长、操作步骤数、试点团队反馈等可观察指标。
服务与演进能力
关注版本节奏、支持响应、二次开发与开放接口。示例条件：提供明确的版本发布节奏说明（评分）；支持通过开放接口或插件扩展自定义能力（评分）；支持响应时限有书面服务约定（门槛，若业务连续性要求高）。供应商口头承诺应转为书面答复再作为证据。
| 维度 | 条件示例 | 建议类型 |
|---|---|---|
| 流程与工作项模型 | 不同项目可配置独立工作流；自定义字段支持校验与联动 | 评分/评分 |
| 数据迁移与集成 | 历史工作项、附件、评论可迁移且字段映射可配置；与代码仓库对接 | 门槛/门槛 |
| 权限与合规 | 项目、角色、字段三级权限；关键操作审计日志可导出 | 评分/门槛 |
| 使用成本与推广难度 | 覆盖四类核心角色日常操作；并行期支持只读访问旧系统 | 门槛/评分 |
| 服务与演进能力 | 开放接口支持扩展；支持响应时限有书面约定 | 评分/门槛 |
用同一套条件做候选同口径对照
条件定好后，候选比较要按条件编号逐项填写，先筛门槛再评加权项。门槛项任一不满足即淘汰，不进入后续评分，避免用高分掩盖硬伤；通过门槛的候选再按评分项逐条打分。对照表行是筛选条件，列是候选工具，单元格填写“结论+证据来源+确认状态”，三者缺一不可，否则该格视为未完成。
证据来源建议分级：官方文档为一级，试用环境中的实际操作记录为一级（针对可试用能力），供应商书面答复为二级，同行参考为三级。评分时优先采用一级证据；仅有二级证据的条目在结论旁标注，并在决策说明中列出；三级证据只用于补充背景，不单独支撑门槛判定。
未确认项统一标注“未确认”，处理规则是：门槛项未确认按不满足处理并保留复核机会，评分项未确认按零分计入但当轮不据此淘汰，待补充证据后更新。这样既不让未确认项悄悄变成默认满足，也不因信息缺口误杀候选。
加权评分按“得分×权重”求和后归一化比较，同时做敏感性检查：把权重上下调整一档，观察候选排序是否翻转。若排序对某一项权重高度敏感，说明该项证据不足或权重设定缺乏依据，应回到条件清单复核，而不是直接采用当前排序。
| 条件编号 | 候选A | 候选B | 候选C |
|---|---|---|---|
| C01（门槛） | 满足｜部署文档第3章｜已确认 | 满足｜供应商答复｜已确认 | 未确认｜待演示｜未确认 |
| C02（门槛） | 满足｜试用记录｜已确认 | 不满足｜演示记录｜已确认 | 满足｜试用记录｜已确认 |
| C03（评分，权重5） | 4分｜试用记录｜已确认 | —（门槛未过） | 3分｜供应商答复｜二级证据 |
对照过程产生的演示记录、试用截图、答复邮件和评分说明，需要与条件编号绑定保存，供评审和后续复核使用。ONES的工作项与文档可以把每条条件的确认状态、证据附件和评审意见放在同一处，候选对照表随评审推进更新，避免证据散落在个人邮箱和聊天记录里。
筛选条件定稿与验证：先小范围试跑再扩大
条件清单在纸面上看起来完整，不代表实际可判定。定稿前应选1–2个真实业务场景做试跑，例如“一次需求变更从提出到任务同步”或“一个缺陷从提交到回归关闭”，用候选工具或试用环境走一遍，检验每条条件是否能给出明确结论。试跑中频繁出现“说不清算不算满足”的条件，说明判定口径需要细化或降级为评分项。
试跑后的调整规则：门槛项若在试跑中被证明可通过配置绕行且不影响业务结果，可降为评分项；评分项若发现实际是业务运转的前提，应升为门槛并补充验证方式；权重调整需写明原因，例如某维度在试跑中暴露的风险高于预期。每次调整记录调整原因、提出角色和影响的条件编号。
试跑参与角色应覆盖需求来源中的主要角色，至少包括业务方代表、日常使用者和后续运维负责人，各自按自己关心的条件给出判定。记录方式建议用统一表格：条件编号、试跑场景、观察结果、判定结论、参与角色、遗留问题。试跑结论由选型负责人汇总，不采用单一角色意见直接定稿。
定稿后进入条件冻结：给条件清单打上版本号，明确冻结日期和变更流程。冻结后新增或修改条件需说明原因并经评审确认，避免在候选比较中途反复改标准导致结论不可比。冻结版本与候选对照表、试跑记录一并归档，作为后续切换和验收的依据。
| 检查项 | 通过标准 | 记录字段 |
|---|---|---|
| 每条门槛项均有明确判定结论 | 无“说不清”条目 | 条件编号、结论、证据 |
| 评分项权重有依据 | 权重与影响范围、频率对应 | 权重、调整原因 |
| 试跑覆盖主要角色 | 业务方、使用者、运维均参与 | 参与角色、意见摘要 |
| 条件清单已冻结 | 有版本号与冻结日期 | 版本号、冻结日期、变更记录 |
完成冻结后，这套条件就可以直接用于候选对照、演示提问清单和后续验收标准，现状评估的结论也由此转化为可执行、可追溯的选型依据。
常见问题
现状评估里问题很多，怎么判断哪些该进入替换需求、哪些可以暂时接受？
可以用三条标准做取舍：是否直接造成交付延误或质量风险、是否影响多个团队且高频发生、是否有可描述的业务后果。三条都不满足的问题，例如只影响个别角色操作习惯、有临时绕行方案且成本可控，标注为“可接受现状”，不进入替换需求。这样做的目的是让需求清单保持可执行规模，避免把评估中所有抱怨都变成选型条件。
取舍结论要写明理由和来源角色，后续条件评审时若有人提出异议，可以回到原始记录复核，而不是凭印象重新讨论。
硬性门槛设多少条比较合适？门槛太多会不会把可用方案都筛掉？
门槛项建议控制在10条以内，只保留不满足时业务直接无法运转或违反硬性规定的条件，例如部署方式、数据存放地、必须对接的现有系统、必须迁移的历史数据范围、合规审计要求。偏好类需求，比如某种看板样式或操作习惯，应降为评分项并给较低权重。
门槛过多通常说明部分条件被写成了“必须完全一致”，可以逐条追问：这条不满足时，是否有配置或流程上的替代做法？有替代做法的转入评分项，没有的保留为门槛。
供应商没有答复或演示没覆盖到的能力，在对照表里怎么处理？
统一标注“未确认”，并按类型分别处理：门槛项未确认按不满足处理，但保留复核机会，继续向供应商取证；评分项未确认按零分计入当轮，不据此直接淘汰候选。关键是不要让未确认项悄悄变成默认满足，也不要因为信息缺口误杀候选。
补充证据后及时更新对照表，并在决策说明中记录确认时间和证据来源，便于评审时区分“已确认满足”和“后来补证满足”。
试跑应该选什么场景、找哪些人参与？
场景选1–2个真实且高频的业务流程，例如一次需求变更从提出到任务同步，或一个缺陷从提交到回归关闭，用候选工具或试用环境实际走一遍，检验每条条件能否给出明确结论。试跑中频繁出现“说不清算不算满足”的条件，说明判定口径需要细化或降级为评分项。
参与角色至少覆盖业务方代表、日常使用者和后续运维负责人，各自按关心的条件给出判定，由选型负责人汇总，不采用单一角色意见直接定稿。
条件冻结之后，候选比较中途发现漏了一条重要条件怎么办？
冻结的目的是保证候选之间同口径可比，因此新增或修改条件需要走变更流程：说明原因、影响哪些候选、是否需要重新取证，经评审确认后发布新版本，并在对照表中标注哪些结论基于旧版本、哪些已按新版本更新。
如果遗漏的条件只影响个别候选且不改变门槛结论，可以作为补充项记录，不打断当前比较；如果影响门槛判定，则应暂停排序，补齐证据后重新对照。
