研发管理平台选型最容易出问题的地方，是把演示效果当成落地结果：功能看着齐全，签约后却发现权限映射、系统集成或数据导出卡住。这份清单按“需求与范围确认—候选初筛—能力与集成核验—试点验证—合同与落地准备”五个阶段组织，每项给出通过标准、所需证据和负责人，任一阶段阻断项未关闭就不进入下一阶段。清单适用于研发负责人、平台管理员、采购、安全合规与财务共同参与的评审，能力核验部分以ONES Project、ONES Wiki等产品作为可核验对象的示例。
要点总览（TL;DR）
- 清单按需求与范围确认、候选初筛、能力与集成核验、试点验证、合同与落地准备五个阶段组织，每项检查都写明通过标准、所需证据和负责人。
- 需求确认单是后续所有判断的基准，硬约束条目必须可判断、无模糊表述，并由研发负责人与采购共同签字。
- 能力核验以演示记录和配置截图作为证据，口头承诺不计入通过；ONES Project、ONES Wiki 可作为核心对象关联、权限映射与集成方式的对照样本。
- 阻断项一旦出现就暂停推进，包括硬约束不满足、核心集成不可行、数据无法导出、试点关键流程走不通。
- 整份清单判定通过的条件是全部阻断项关闭、五阶段产出物齐备、各评审节点签字完成。
谁在什么时点使用这份选型清单
这份清单服务于一次完整的选型评审，参与角色各有分工：研发负责人对需求范围和试点结论负责，平台/工具管理员负责能力与集成核验，采购负责商务条款与供应商沟通，安全与合规角色核验数据存放、账号体系与资质要求，财务确认预算区间与计费口径。清单在立项前启动，在候选初筛后、试点前、合同签署前分别设置评审节点，每个节点都要有书面产出，不能只靠会议口头确认。
| 角色 | 介入时点 | 主要产出 | 评审节点 |
|---|---|---|---|
| 研发负责人 | 立项前、试点前、合同签署前 | 需求确认单、试点总结报告 | 需求评审、试点结论评审 |
| 平台/工具管理员 | 候选初筛后、试点前 | 能力与集成核验表、演示记录 | 能力核验评审 |
| 采购 | 立项前、合同签署前 | 初筛记录表、合同条款确认单 | 初筛评审、合同评审 |
| 安全与合规 | 需求确认、能力核验 | 合规约束清单、核验意见 | 合规核验 |
| 财务 | 需求确认、合同签署前 | 预算区间确认、价格构成核对 | 预算评审、合同评审 |
使用顺序上，先由研发负责人牵头完成需求确认，再进入候选初筛；初筛通过后由平台管理员组织能力核验；核验无阻断项才允许进入试点；试点结论通过后，采购与财务主导合同与落地准备。每个节点结束时形成签字记录，作为下一阶段的准入依据。
第一阶段：需求与范围确认检查项
这一阶段在接触任何产品之前完成，目标是把要解决的问题和不可让步的约束固定下来，后续所有判断都以需求确认单为基准。检查项如下：
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 核心问题与现状痛点 | 用一段话写清当前研发流程中要解决的具体问题，并列出受影响的团队和环节 | 现状说明，含问题实例 | 研发负责人 |
| 硬约束：部署方式与数据存放 | 明确部署形态要求与数据存放位置要求，写成可判断的约束条目 | 约束清单，经安全与合规确认 | 安全与合规 |
| 硬约束：账号体系与合规要求 | 列出必须对接的账号体系及需满足的合规要求，标注必须与期望两档 | 账号与合规要求清单 | 安全与合规、平台管理员 |
| 必须对接的系统清单 | 逐项列出代码仓库、CI/CD、IM、SSO等系统，注明集成方向（单向/双向） | 系统对接清单 | 平台管理员 |
| 预算区间与人力投入上限 | 给出预算区间和内部投入人力上限，作为后续方案比较的统一口径 | 预算确认记录 | 财务 |
通过标准是需求确认单经研发负责人与采购共同签字，硬约束条目全部可判断、无模糊表述。签字后的确认单是初筛淘汰候选的唯一依据，后续阶段如需修改约束，须回到本阶段重新确认。
第二阶段：候选初筛检查项
初筛的目的是用统一口径把候选缩到可以深入评估的范围，避免在明显不匹配的产品上耗费评审时间。每款候选都按同一张表打分或判断，保留与淘汰都要写明理由。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 硬约束覆盖情况 | 需求确认单中的每条硬约束都有明确的是/否结论，任一硬约束不满足即淘汰 | 逐条对照记录 | 平台管理员 |
| 厂商资质与服务能力 | 厂商具备持续服务能力，本地支持方式（远程/现场、响应渠道）明确 | 厂商资料、服务说明 | 采购 |
| 同类规模团队使用情况 | 有可核实的同类规模团队使用信息，参考信息可追溯 | 参考信息记录 | 采购、研发负责人 |
| 淘汰理由记录 | 每款被淘汰的候选都有书面理由，对应到具体检查项 | 初筛记录表 | 采购 |
通过标准是形成初筛记录表，每款候选都有保留或淘汰的书面理由，保留名单经研发负责人确认后进入能力核验。初筛阶段不深入比较功能细节，功能层面的判断留到下一阶段。
第三阶段：能力与集成核验检查项
这一阶段逐项核验候选平台在需求、任务、缺陷、测试、发布、文档等环节的实际能力，以及与企业现有系统的对接可行性。核验以演示记录和配置截图作为证据，口头承诺不计入通过。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 核心对象齐全且可关联 | 需求、任务、缺陷、测试、发布、文档等对象均存在，且能建立关联关系 | 演示记录、配置截图 | 平台管理员 |
| 权限模型与组织架构映射 | 能按组织架构、用户组、项目角色分配权限，映射方案可落地 | 权限配置截图、映射说明 | 平台管理员 |
| 与代码仓库、CI/CD、IM、SSO集成 | 各集成方式与限制写清，关键集成在演示环境中实际跑通 | 集成方案说明、演示记录 | 平台管理员 |
| 数据导入导出与报表 | 历史数据可导入，数据可导出，报表能满足管理查看需求 | 导入导出演示记录 | 平台管理员 |
以ONES为例，核验时可以对照的具体对象包括：ONES Project支持需求池、迭代规划、需求状态与属性自定义，需求可关联任务并分配负责人；缺陷跟踪与TestCase数据互通，可一键提Bug并统计缺陷状态分布；权限按产品、项目、任务多层级设置，可按组织架构、用户组、项目角色分配；通过Code Integration和Pipeline Integration应用支持持续集成与部署，并在平台内监控交付数据；ONES Wiki支持文档关联任务，并可插入工作项列表。这些能力可作为核验表中“核心对象关联”“权限映射”“集成方式”几项的对照样本，具体集成工具清单与版本仍需在演示中逐项确认。
通过标准是能力与集成核验表逐项打勾并附证据，由平台管理员与研发负责人共同确认。核验中发现的缺口要标注为阻断项或可接受差异，阻断项未关闭不进入试点。
第四阶段：试点验证检查项
试点用真实团队和真实项目验证平台能否跑通日常研发流程，把演示阶段的判断落到可观察结果上。试点范围不宜过大，选一个流程完整、成员配合度高的团队即可。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 试点团队与项目范围 | 试点团队、项目、覆盖的流程环节书面确定 | 试点方案 | 研发负责人 |
| 试点周期与观察指标 | 周期明确，指标含流程走通率、数据完整性、成员反馈 | 指标记录表 | 平台管理员 |
| 问题记录与厂商响应 | 试点问题逐条登记，厂商响应时效有记录 | 问题清单及响应记录 | 平台管理员、采购 |
| 试点结论 | 关键流程走通，问题清单中的阻断项全部关闭 | 试点总结报告 | 研发负责人 |
通过标准是形成试点总结报告，包含问题清单与关闭情况，关键研发流程在试点中完整走通。试点中暴露的流程适配问题要区分是平台能力不足还是使用方式问题，前者影响选型结论，后者通过培训解决。
第五阶段：合同与落地准备检查项
签约前把价格口径、服务承诺、数据归属和上线计划确认清楚，避免落地阶段出现预期落差。这一阶段由采购与财务主导，研发负责人确认上线安排。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 许可数量与计费口径 | 许可数量、计费方式、价格构成逐项写明，与预算区间核对一致 | 报价单、条款确认单 | 采购、财务 |
| 服务级别与升级路径 | 响应时效、服务级别、问题升级路径写入合同或附件 | 服务条款 | 采购 |
| 数据归属与退出安排 | 数据归属明确，导出方式与退出时的数据处理安排可执行 | 合同条款、导出方案 | 安全与合规、采购 |
| 上线计划与培训安排 | 上线时间表、培训计划、内部推广责任人确定 | 上线计划表 | 研发负责人 |
通过标准是合同条款确认单与上线计划表完成签署。价格、版本与认证类信息以合同文本和厂商正式文件为准，评审阶段不采信口头报价。
阻断项清单与整体完成条件
阻断项是任一阶段出现就必须暂停、不得进入下一阶段的检查结果。常见阻断项包括：需求确认单中的硬约束不满足；核心集成（如代码仓库、SSO）经演示确认不可行；数据无法按约定方式导出；试点中关键研发流程走不通。每项阻断项都要登记责任人、关闭证据和关闭时间，关闭后由原评审角色复核签字。
| 阻断项 | 关闭证据 | 关闭责任人 |
|---|---|---|
| 硬约束不满足 | 厂商书面方案或重新确认的约束条目 | 平台管理员、安全与合规 |
| 核心集成不可行 | 集成演示记录或替代方案说明 | 平台管理员 |
| 数据无法导出 | 导出演示记录或合同中的导出条款 | 安全与合规、采购 |
| 试点关键流程走不通 | 问题关闭记录与复测结果 | 研发负责人 |
整份清单判定“通过”的条件是：全部阻断项关闭并有证据，五个阶段的产出物齐备，各评审节点签字完成。任一条件不满足，处理方式是退回上一阶段补充核验，或终止该候选并回到初筛名单。清单的价值在于把“感觉合适”转成可核验的结论，签字记录和证据文件就是选型决策的依据。
常见问题
需求确认单签字后，评审中发现约束需要调整怎么办？
回到第一阶段重新确认，更新需求确认单并重新签字，再据此复核已经完成的初筛与核验结论。约束调整会影响候选名单和核验项的判断口径，直接在后续阶段打补丁容易造成前后标准不一致。
如果调整涉及硬约束，例如数据存放位置或必须对接的系统发生变化，此前被淘汰的候选可能需要重新纳入初筛。
试点中暴露的问题，怎么区分是平台能力不足还是使用方式问题？
先看问题能否通过配置、培训或流程约定解决，并记录解决过程。能通过配置或培训解决、且不影响关键流程走通的，归为使用方式问题；需要厂商改产品、改集成或无法在试点周期内解决的，归为能力问题，影响选型结论。
两类问题都要进入试点问题清单，能力类问题按阻断项处理，关闭后再出试点结论。
能力核验阶段，演示环境和真实环境的结果不一致怎么办？
以真实环境或与生产环境配置一致的测试环境结果为准，演示环境只用于初步确认功能是否存在。核验表中应注明每项证据的取得环境，关键集成项要求在接近真实配置的环境中跑通。
如果厂商无法提供可验证的环境，该项按未通过处理，并在阻断项登记表中记录。
合同阶段发现报价口径与预算区间不一致，应该怎么处理？
先核对许可数量、计费方式和价格构成，确认差异来自数量口径、服务范围还是附加模块。差异在预算区间内且经财务确认的，可继续推进；超出预算区间的，退回需求确认阶段重新确认预算或调整范围，不带着未解释的差额进入签约。
价格、版本与认证类信息以合同文本和厂商正式文件为准。
小团队选型时，这份清单可以简化吗？
可以按风险裁剪，但需求确认和阻断项判定两部分建议保留。团队规模小、系统集成少时，能力核验表的检查项可以合并，试点周期可以缩短，证据仍要留存。
裁剪结果应写进评审记录，说明哪些检查项未执行及理由，避免后续追责时缺少依据。
