研发管理系统选型容易在演示环节被功能数量带偏，真正决定成败的是需求边界、可验证能力和落地条件。这份清单按四个阶段组织：需求与范围确认、候选与能力核验、试点与集成验证、合同与落地准备，每项写明通过标准、所需证据和负责人。任一阻断项未通过，就暂停进入下一阶段。
要点总览（TL;DR）
- 清单按四个时点推进：立项前定需求边界、候选筛选后核验能力与报价、试点结束看指标、签约前审合同与实施安排，每个时点产出可归档结论。
- 需求条目要写到环节、角色和验收口径，只写“需要支持敏捷管理”这类描述无法在后续核验中使用。
- 候选核验只用支持、部分支持、待验证三种结论，待验证项要约定验证方式，不接受口头承诺。
- 试点在真实团队和真实数据上跑，成功指标试点前书面确认，未闭环问题不带入签约。
- 核心流程无法支撑、关键接口无法打通、数据无法导出、合规要求不满足属于阻断项，任一未通过即暂停选型。
谁在什么时点使用这份选型清单
这份清单服务于一个跨部门选型小组，而非研发部门单独采购。研发负责人判断流程与角色是否被支撑，IT/平台负责人核对集成、部署与运维条件，采购与法务统一报价口径并审查合同条款，安全合规确认数据存放与权限要求。四类角色在各时点分别签字，避免某一方在后期才发现无法接受的条件。
清单在四个时点介入，每个时点结束时应形成一份可归档的结论，作为进入下一阶段的前提。
| 时点 | 主要参与角色 | 应产出 |
|---|---|---|
| 立项前 | 研发负责人、IT/平台负责人、安全合规 | 需求确认检查表、需求优先级清单、合规约束说明 |
| 候选筛选后 | 研发负责人、IT/平台负责人、采购 | 候选核验对照表、缺口清单、统一口径报价表 |
| 试点结束 | 试点团队负责人、IT/平台负责人 | 试点验证记录表、问题处置清单、试点结论 |
| 签约前 | 采购与法务、IT/平台负责人、研发负责人 | 签约前检查表、实施里程碑表、放行判定表 |
时点之间设放行判断：上一时点的产出未通过复核，不启动下一时点的工作。这样做的目的是把返工成本控制在早期，避免在试点或签约阶段才发现需求本身有缺口。
第一阶段：需求与范围确认检查项
这一阶段在接触供应商之前完成，目标是把需求边界固定成可核验的条目，后续所有能力核验都以这份清单为基准。需求写得越具体，候选阶段的对照越容易判断。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 必须支撑的研发流程环节与角色 | 列出需求、任务、缺陷、版本、测试等环节及对应角色，每条注明是必须还是期望 | 流程清单与角色说明，经研发负责人确认 | 研发负责人 |
| 用户规模、项目数量与数据量级 | 给出当前值与未来一到两年的预估区间，注明统计口径 | 账号统计、项目台账、历史数据量估算 | IT/平台负责人 |
| 现有系统清单与必须打通的接口 | 每个接口写明系统名称、数据流向、同步频率和业务用途 | 系统清单与接口说明，标注必须与可选 | IT/平台负责人 |
| 部署与数据存放的合规要求 | 写明数据存放位置、访问控制、审计留存的硬性要求 | 合规部门出具的约束说明 | 安全合规 |
| 需求条目优先级与验收口径 | 每条需求有优先级，并写明怎样算满足 | 需求确认检查表，研发与IT双方签字 | 研发负责人、IT/平台负责人 |
通过标准是：需求条目全部有优先级和验收口径，且经研发与IT双方确认。只写“需要支持敏捷管理”这类描述无法在后续核验中使用，应改为具体环节、角色和操作。部署方式的具体选择与旧工具替换方案属于另外的主题，本阶段只需记录约束条件，不在此展开。
需求条目确定后，需要一个可追踪的载体。ONES 可以用工作项承载需求条目、标注优先级与验收口径，并让研发与IT在同一份记录上确认，减少需求在邮件和文档之间反复转述造成的偏差。
第二阶段：候选与能力核验检查项
这一阶段的任务是用统一口径核对供应商的能力陈述，把演示中看到的效果与可验证事实分开记录。核验结论只有三种：支持、部分支持、待验证，不允许留空或写“基本可以”。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 需求覆盖度逐条对照 | 第一阶段每条需求都有明确结论，部分支持与待验证项写明差异 | 候选核验对照表 | 研发负责人 |
| 权限模型核验 | 能说明角色、项目、数据范围的权限层级，并现场演示一个跨项目隔离场景 | 演示记录或配置截图 | IT/平台负责人 |
| 工作项类型与流程配置灵活性 | 能按团队实际流程配置状态、字段和流转规则，变更不需要开发介入 | 配置演示记录 | 研发负责人 |
| 集成能力核验 | 每个必须接口写明接口类型、认证方式、同步方向与频率 | 接口文档或技术确认函 | IT/平台负责人 |
| 报价口径统一 | 用户数、模块、实施、运维费用分列，可按同一口径横向比较 | 分项报价表 | 采购 |
通过标准是：关键需求没有未解释的缺口，报价可以横向比较。对“待验证”项要约定验证方式，例如在试点中验证或由供应商提供技术确认，不能以口头承诺代替。报价比较时注意用户数的计算方式是否一致，按账号数、活跃人数还是并发数计价，会直接影响可比性。
第三阶段：试点与集成验证检查项
试点要在真实团队和真实数据上运行，验证的是可用性与集成效果，而非再次确认功能列表。试点开始前先约定团队、周期和成功指标，结束后按指标判断，避免结论停留在主观感受。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 试点团队、周期与成功指标 | 选定一个代表性团队，周期与指标在试点前书面确认 | 试点方案 | 试点团队负责人 |
| 关键接口连通性 | 必须打通的接口在试点环境完成联调，记录同步结果 | 联调记录与数据比对结果 | IT/平台负责人 |
| 字段映射与异常处理 | 字段对应关系有文档，异常数据有明确处理方式 | 映射表与异常处理记录 | IT/平台负责人 |
| 迁移或初始化数据抽样校验 | 抽取样本核对字段完整性与数量一致性 | 抽样校验记录 | IT/平台负责人 |
| 用户接受度与培训成本 | 记录试点成员的操作反馈、常见问题和培训投入工时 | 反馈记录与培训工时统计 | 试点团队负责人 |
通过标准是：试点指标达成，阻断级问题清零或有明确处置方案。试点期间发现的问题要逐条登记，写明责任人和处理时限，未闭环的问题不能带入签约阶段。试点中的验证记录和问题跟踪同样需要载体，ONES 可以把试点任务、验证结论和问题处置放在同一工作项下流转，让试点结束时的结论有据可查。
第四阶段：合同与落地准备检查项
这一阶段把选型结论转成可执行的签约与上线条件。技术验证通过不等于可以签约，服务范围、数据条款和实施安排都需要落到书面。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 服务范围、SLA与响应时限 | 服务内容、响应时限、故障分级写入合同附件 | 合同条款与SLA附件 | 采购与法务 |
| 数据归属、导出方式与退出安排 | 明确数据归属方、导出格式与频率、合同终止后的数据处理方式 | 合同数据条款 | 采购与法务、安全合规 |
| 实施计划、里程碑与双方责任人 | 每个里程碑有交付物、验收方式和双方责任人 | 实施里程碑表 | IT/平台负责人 |
| 培训、文档与运维交接 | 培训对象、场次、文档清单和运维交接内容已约定 | 培训计划与文档清单 | 研发负责人、IT/平台负责人 |
通过标准是：合同条款覆盖退出与数据条款，实施计划有可验收的里程碑。数据导出与退出安排需要在签约前确认，而非上线后再协商；实施里程碑要写成可判断完成与否的交付物，例如“完成核心团队配置并通过验收”，而非“推进上线”。
阻断项与完成条件
阻断项是一票否决的检查项，任一未通过即暂停选型流程，不进入下一阶段。以下为常见阻断项示例，实际使用时可按项目补充，但不应随意删减。
| 阻断项 | 判定依据 | 复核方式 | 责任人 |
|---|---|---|---|
| 核心流程无法支撑 | 第一阶段标记为必须的流程环节存在无法满足项 | 研发负责人复核核验对照表 | 研发负责人 |
| 关键接口无法打通 | 必须打通的接口在试点中未完成联调或无可行方案 | IT/平台负责人复核联调记录 | IT/平台负责人 |
| 数据无法导出 | 无法按约定格式和频率导出业务数据 | 采购与法务、安全合规共同复核 | 采购与法务 |
| 合规要求不满足 | 数据存放、访问控制或审计要求存在硬性缺口 | 安全合规出具复核意见 | 安全合规 |
阻断项的复核由对应责任人发起，结论写入放行判定表并留档。完成条件是：全部阻断项通过，一般项缺口有书面处置计划，写明责任人和完成时限。满足这两条，选型小组方可签署放行结论，进入签约与实施。
常见问题
选型小组里研发、IT、采购、安全合规各自负责哪些检查项？
按检查项的性质分工，避免所有条目都压在一个人身上：
- 研发负责人：流程环节与角色覆盖、工作项与流程配置灵活性、试点指标达成情况。
- IT/平台负责人：用户规模与数据量级、接口清单与联调、字段映射、实施里程碑。
- 采购与法务：报价口径统一、服务范围与SLA、数据归属与退出条款。
- 安全合规：数据存放与访问控制要求、合规复核意见。
分工之外要设共同确认环节，例如需求条目由研发与IT双方签字，阻断项由对应责任人复核后写入放行判定表。角色缺位时，相关检查项应视为未完成，不能由其他角色代为签字。
供应商在演示中展示了某项能力，还需要在清单里标“待验证”吗？
需要。演示能说明产品具备某种操作路径，但无法证明它在你的数据量、权限结构和流程配置下同样可用。核验时把演示看到的内容记为“待验证”，并约定验证方式：在试点环境中复现、由供应商提供技术确认函，或提供配置说明。只有经过验证或书面确认后，才改为“支持”。
“部分支持”也要写清差异，例如支持状态流转但不支持按团队自定义字段，这类差异在试点和合同阶段都会影响判断。
试点周期多长合适，指标怎么定才算可判断？
周期取决于流程复杂度和接口数量，没有统一标准，但指标应在试点前书面确认，并与第一阶段的必须项对应。可判断的指标通常包含三类：关键接口完成联调并记录同步结果；试点团队按真实流程完成若干轮迭代或任务流转；阻断级问题数量清零或有明确处置方案。
用户接受度和培训工时作为观察记录，用于评估上线后的推广成本，不宜单独作为通过与否的唯一依据。试点结束时若仍有未闭环问题，应写明责任人和时限，再决定是否放行。
报价看起来差不多，为什么还要统一口径？
报价的可比性取决于计价基础是否一致。用户数按账号数、活跃人数还是并发数计算，模块是否包含实施与运维，接口开发是否单独计费，这些差异会让表面接近的总价在实际使用中拉开差距。核验时要求供应商把用户数、模块、实施、运维费用分列，并注明计价口径和调价条件。
统一口径后的报价表也是签约阶段的对照依据，合同金额与范围应能与该表逐项对应。
阻断项未通过时，是直接放弃候选还是可以带条件放行？
阻断项按一票否决处理，未通过即暂停进入下一阶段。实际操作中可以先判断问题是否可解：接口无法打通但供应商给出了可行的替代方案和验证计划，可以列为待验证并限期复核；核心流程无法支撑、数据无法导出、合规硬性要求不满足，通常没有折中空间。
一般项缺口可以带条件放行，但要有书面处置计划，写明责任人和完成时限，并在签约前复核关闭情况。放行判定表应记录每次复核的结论，便于后续追溯。
