研发平台选型清单需要包含哪些信息

研发平台选型清单要能直接拿来逐项核对，而不是一份产品介绍汇编。它应覆盖需求与范围、产品能力与集成、部署与安全合规、实施与服务、成本与合同、试点验证与决策证据六类信息，每项写明通过标准、证据材料、负责人和检查时点，并标出阻断项。清单可由研发负责人牵头，架构、运维、安全合规、采购、财务、法务分工确认；ONES 可作为承载需求条目、评审记录与验证结论的工具之一，具体能力以厂商材料为准。

要点总览（TL;DR）

• 清单按六类信息组织：需求与范围、产品能力与集成、部署与安全合规、实施服务与成本、试点验证与决策证据，另加使用责任与阻断项判定。
• 每个检查项都要写明通过标准、证据材料、负责人和检查时点，缺少确认角色的条目在评审会上无法推进。
• 能力与集成条目要用真实需求样例走查、试用环境配置和接口联调来验证，报表指标需核对字段来源与统计口径。
• 成本按许可、实施、培训、运维、扩容等口径逐项列出并折算合同期总投入，服务响应与退出条款写入合同。
• 安全合规不达标、关键集成无法实现、总投入超预算、核心场景试点不通过属于阻断项，清单完成需所有必填项有结论、有证据、有签字。

谁在什么时点使用这份选型清单

清单的第一项信息是使用责任，而非产品功能。研发平台选型涉及技术判断、合规判断和商务判断，任何单一角色都无法独立完成全部确认。清单在立项时建立，在候选初筛、方案评审、试点验证、合同签订前逐轮更新，每个阶段只填写该阶段能取得证据的条目。

建议在清单表头固定三列：检查时点、确认角色、签字状态。检查时点决定这一项在哪个阶段必须给出结论；确认角色决定谁对结论负责；签字状态用于判断清单是否收口。角色分工可参考下表。

角色	主要介入时点	在清单中的确认职责
研发负责人	立项、初筛、方案评审、试点结论	确认业务目标、使用范围、关键场景优先级，对试点成功判据签字
架构/运维	初筛、方案评审、试点	确认集成点、部署资源要求、版本升级与运维责任边界
安全合规	方案评审、合同签订前	确认账号认证、审计日志、数据存放与合规材料，判定安全类阻断项
采购	初筛、商务谈判、合同签订前	确认采购方式、供应商资质、报价口径与合同条款
财务	立项、商务谈判	确认预算区间、成本项完整性与多年总投入测算
法务	合同签订前	确认交付物、验收条件、违约责任与退出条款

这张对照表解决的是“谁来填、什么时候填”。缺少确认角色的条目，在评审会上往往只能得到“再了解一下”的结论，清单也就无法推进。

需求与范围阶段要核对哪些信息

这一阶段的检查项决定后续所有比较是否在同一口径上进行。清单需要把选型前置条件写成可判断的条目，例如“必须解决的问题是否已列出并排序”“本次覆盖的团队与项目类型是否明确”。通过标准是这些内容形成书面版本并经研发负责人确认，证据是立项说明或需求纪要。

检查项	通过标准	证据材料	负责人
业务目标与必须解决的问题	列出不超过若干条核心问题，并说明当前做法与影响	立项说明、访谈纪要	研发负责人
使用范围	明确覆盖的团队、项目类型、研发环节边界（需求、开发、测试、发布等）	范围说明表	研发负责人
现状系统与必须保留的集成点	逐个列出系统名称、对接方式、数据流向，并标注必须保留的原因	系统清单、接口说明	架构/运维
预算区间与采购方式约束	给出预算上限、采购方式与审批路径	预算批复、采购制度	财务、采购
不纳入本次选型的范围	书面列出暂不覆盖的团队、场景或系统	范围说明表	研发负责人

“不纳入范围”这一项常被忽略，却直接影响后续评分。把暂不覆盖的内容写清楚，可以避免评审时用未纳入的场景否定候选方案，也避免供应商在演示中扩大承诺范围。

产品能力与集成检查项

能力类条目要能通过演示或测试用例判断通过，而非停留在功能名称对照。清单应为每项能力附一个验证方式：现场演示、试用环境操作或接口联调。需求管理与研发流程覆盖，可要求供应商按本方提供的真实需求样例走一遍从需求录入、状态流转、任务拆分到迭代规划的过程，观察状态与属性是否可自定义、负责人是否可分配。

权限模型需要按组织架构实际验证。检查项包括：能否按部门、用户组、项目角色分别授权；跨项目访问是否可控；离职或转岗后权限如何回收。通过标准是用本方组织架构在试用环境中配置一遍并记录结果。

集成清单应逐项列出代码仓库、CI/CD、测试管理、发布系统等对接对象，并注明验证方法：接口文档核对、联调测试或供应商提供的历史案例说明。报表与度量条目要核对数据来源和统计口径，例如迭代速率、缺陷密度分别取自哪些字段、按什么时间窗口计算，避免上线后口径不一致。

检查项	验证方式	通过标准	负责人
需求管理与流程覆盖	用真实需求样例现场走查	状态、属性、负责人可配置，流程与团队做法一致	研发负责人
权限模型与组织架构适配	试用环境按实际组织配置	多层级授权可落地，权限回收有明确操作	架构/运维
代码仓库与 CI/CD 集成	接口文档核对加联调	关键集成点全部可对接，数据可回传	架构/运维
报表与度量口径	核对字段来源与计算规则	指标定义书面确认，与团队现有口径可解释差异	研发负责人
扩展与二次开发能力	查阅开放接口与扩展文档	满足已识别的定制需求，或明确替代做法	架构/运维

以 ONES 为例，ONES Project 覆盖需求管理、任务管理、缺陷管理、迭代管理等场景，支持建立需求池、自定义需求状态与属性、将需求和相关任务规划至迭代并分配负责人；权限可按组织架构、用户组、项目角色分配；通过 Code Integration 和 Pipeline Integration 应用支持持续集成与部署，并在项目内监控数据。选型时可将这些能力对应到上表的验证用例中逐项走查，具体兼容系统清单以厂商正式材料为准。

部署、安全与合规检查项

这一组条目通常作为方案评审的硬性输入，只核对是否满足，不在清单中展开部署模式如何选择。检查项包括：部署形态是否在候选方案中明确说明；服务器、存储、网络资源要求是否给出可核算的规格；数据存放位置、备份频率与恢复目标是否书面确认；账号体系能否对接现有认证方式，审计日志覆盖哪些操作、保留多久。

安全测评、等保或行业合规材料，要核对材料名称、出具机构、有效期与覆盖范围，并注明由安全合规角色在合同签订前完成核验。版本升级条目要写清升级由谁发起、窗口如何约定、升级失败的回退方式，以及日常运维由本方还是供应商承担。这些内容写入清单后，评审会上可以直接判断通过与否，减少会后反复确认。

实施、服务与成本检查项

软件报价只是总投入的一部分。清单应把实施范围、里程碑与验收方式列为独立条目，例如实施包含哪些配置、数据初始化是否在范围内、每个里程碑的交付物和验收人是谁。培训与知识转移要核对培训对象、场次、文档交付清单，以及供应商退出后本方能否独立维护。

服务条目包括响应级别、支持渠道、服务时间窗口和升级路径，需在合同中写明而非仅口头承诺。成本条目按计价口径逐项列出：许可或订阅费用、实施服务费、培训费、运维费、扩容单价、接口开发费用，并统一折算为三年或合同期总投入，便于财务比较。合同条目核对交付物清单、验收条件、付款节点、违约责任与退出条款，由法务在签订前确认。

检查项	通过标准	证据材料	负责人
实施范围与里程碑	范围、交付物、验收人逐项列明	实施方案	研发负责人、采购
培训与知识转移	培训对象、场次、文档清单确认	培训计划	研发负责人
服务响应级别	响应时限、渠道、升级路径写入合同	服务条款	采购
成本项与计价口径	全部费用项列出并折算合同期总投入	正式报价单	财务
合同交付与退出条款	验收条件、付款节点、退出安排明确	合同文本	法务

试点验证与决策证据检查项

试点是把前面各阶段的判断落到实际使用中的环节。清单要事先写明试点范围、周期和成功判据，例如覆盖几个团队、运行几个迭代、关键场景通过率达到什么水平、用户反馈如何处理。成功判据应在试点开始前由研发负责人签字，避免结束后再调整标准。

试点过程中形成两类证据：关键场景的实测记录，以及问题清单及处理结论。实测记录对应能力检查表中的验证用例，逐条标注通过、部分通过或不通过；问题清单记录发现的问题、影响程度、供应商答复和复检安排。候选方案评分要写明权重口径和打分人，评分表与实测记录一并归档。决策会议记录需包含参会角色、结论、不同意见和签字确认，遗留风险与后续验证计划作为附件保留。

在这一环节，需求条目、评审记录和验证结论需要有统一的存放位置，便于评审时追溯。ONES 的项目、知识、测试等能力可结合使用，将研发过程中的信息和工作衔接起来，适合作为承载这类记录的工具之一；具体使用方式按团队现有流程配置。

阻断项与清单完成条件

阻断项是无论其他条目得分多高都不能妥协的条目，典型包括：安全合规材料核验不通过、关键集成点无法实现、合同期总投入超出预算上限、核心场景试点不通过。清单中应为阻断项单独加标记列，并写明判定人和升级路径，例如由安全合规角色判定、报选型决策会审议。

清单完成的条件可以归纳为三条：所有必填项均有明确结论，没有空白或“待定”；每项结论附有对应证据材料并归档；每项由确认角色签字。未通过项要写明处理方式，是补充验证、要求供应商整改，还是直接排除该候选方案，并约定复检时点和复检人。满足完成条件后，清单连同试点记录、评分表和会议纪要形成完整的决策档案，供后续合同签订与实施交接使用。

常见问题

清单条目很多，评审时间有限，应该先核对哪些？

先核对阻断项和需求与范围条目。阻断项一旦不通过，候选方案直接排除，后续评分没有意义；需求与范围条目决定其他条目按什么口径判断。能力、实施、成本类条目可以在初筛阶段只填关键项，进入方案评审和试点后再补齐。清单表头标注检查时点，就是为了让不同阶段只处理该阶段能取得证据的条目。

供应商演示效果很好，清单里还需要现场验证吗？

需要。演示通常由供应商按预设脚本准备，清单的作用是把验证条件固定下来。建议要求供应商使用本方提供的真实需求样例，在试用环境中完成需求录入、状态流转、任务拆分和迭代规划，并现场配置一遍组织架构与权限。集成类条目以接口文档核对加联调结果为准，报表指标要核对字段来源和计算规则。验证结果逐条记录，作为评分依据。

试点成功判据应该在什么时候确定？

在试点开始前确定，并由研发负责人签字。判据包括覆盖的团队与项目范围、运行周期、关键场景通过标准以及用户反馈的处理方式。试点结束后再调整标准，会让结论失去可比性。试点过程中同步记录实测结果和问题清单，问题清单写明影响程度、供应商答复和复检安排，与评分表一并归档。

清单里的成本项怎么列，才能和财务口径对上？

按计价口径逐项列出：许可或订阅费用、实施服务费、培训费、运维费、扩容单价、接口开发费用，并统一折算为三年或合同期总投入。每项注明计价单位、数量假设和是否含税。财务角色在立项和商务谈判阶段确认成本项完整性，采购核对正式报价单与合同条款是否一致。只比较软件报价容易遗漏实施和运维投入。

清单填完后，未通过的条目怎么处理？

未通过项要写明处理方式：补充验证、要求供应商整改，或直接排除该候选方案，并约定复检时点和复检人。属于阻断项的未通过条目，由判定人报选型决策会审议，不进入后续评分。清单连同试点记录、评分表和会议纪要形成决策档案，供合同签订与实施交接使用。