研发平台选型清单是一张按维度逐项打分的评估表，用来把演示印象、口头承诺和真实证据分开记录。本文提供一张可直接复制填写的空白评分表，并逐字段说明填写口径、必填规则，附一份完整打分示例和后续调整维护方法。适合正在比较多个研发管理平台、需要统一评审口径的团队使用。
要点总览（TL;DR）
- 清单以评估维度、权重、候选平台评分、证据来源、结论和待验证事项为核心字段，权重合计为100，评分统一采用1–5分。
- 评估维度、子项、权重、评分、证据、结论和阻断项为必填；未评估的维度填“未评”而非0分，避免拉低总分。
- 加权总分按Σ(维度得分÷5×权重)换算为百分制，与阻断项判断共同决定是否进入下一轮。
- 清单需按团队业务重点调整权重，每轮评审保存版本，结论变更时补充新证据并记录验证人和时间。
可复制空白选型清单模板
下表为空白模板，候选平台按列展开。实际使用时，先把候选平台名称填入表头，再逐行对每个维度打分。表格行数可按需增删，维度与子项建议保留到评审结束再调整。
| 序号 | 评估维度 | 子项 | 权重(%) | 候选平台A | 候选平台B | 候选平台C | 评分依据/证据来源 | 结论 | 待验证事项 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 需求与项目管理 | 需求收集、优先级、迭代规划 | |||||||
| 2 | 研发流程覆盖 | 需求—开发—测试—发布链路 | |||||||
| 3 | 代码与流水线集成 | 代码库、CI/CD、制品管理对接 | |||||||
| 4 | 测试管理 | 用例、缺陷、测试报告 | |||||||
| 5 | 文档与知识沉淀 | 文档协作、权限、版本 | |||||||
| 6 | 报表与度量 | 进度、质量、效能指标 | |||||||
| 7 | 权限与安全 | 角色权限、审计、数据隔离 | |||||||
| 8 | 易用性与推广成本 | 上手难度、培训量、迁移成本 | |||||||
| 9 | 扩展与开放能力 | API、插件、自定义字段与流程 | |||||||
| 10 | 服务与支持 | 实施支持、响应时效、文档完备度 | |||||||
| — | 加权总分 | 各维度得分×权重求和 | 100 | — | |||||
| — | 阻断项 | 不满足即淘汰的硬性条件 | — |
表格中“评分依据/证据来源”一列按候选平台分别记录时，可在单元格内用分号分隔，或为每个候选平台单独复制一份清单。候选平台超过三个时，向右增加列即可，其余结构不变。
清单字段说明：每个格子填什么
同一张表由多人填写时，字段口径不一致会让分数失去可比性。下表给出每个字段的定义和填写要求，评审前应先对齐这一页。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 评估维度 | 选型关注的一级能力类别 | 用名词短语描述能力范围，如“测试管理”，不写产品名或结论 |
| 子项 | 维度下可观察的具体能力点 | 每个子项应能对应一个可演示或可查证的功能，避免“体验好”这类无法取证的表述 |
| 权重(%) | 该维度在总分中的占比 | 全部维度权重合计为100；权重反映团队业务优先级，不按产品表现反推 |
| 候选平台评分 | 该维度下候选平台的得分 | 统一采用1–5分：1=明显不满足，3=基本满足需变通，5=完全满足且有证据；可给0.5分 |
| 评分依据/证据来源 | 支撑该分数的材料 | 写明证据类型与位置，如“演示环境实测”“产品文档第X节”“试用账号操作录屏”“供应商书面答复”，避免只写“感觉” |
| 结论 | 该维度的判断结果 | 写“满足/部分满足/不满足”并附一句理由，与分数保持一致 |
| 待验证事项 | 打分时尚未确认的问题 | 写成可执行的问题，注明责任人和验证方式，如“确认单点登录是否支持SAML，由IT在试用环境验证” |
| 加权总分 | 各维度得分按权重折算后求和 | 公式为Σ(维度得分÷5×权重)，结果换算为百分制，便于横向比较 |
| 阻断项 | 不满足即淘汰的硬性条件 | 单独列出，如数据存放地点、必须对接的内部系统；阻断项不参与加权，直接决定是否进入下一轮 |
评分与证据要成对出现。一个维度给了4分却没有对应证据，评审时应视为待验证，而不是默认成立。
必填与选填：哪些字段不能空
清单的作用是支撑决策，不是收集所有信息。以下字段在提交评审前必须填写完整，其余可按阶段取舍。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 评估维度、子项 | 必填 | 缺失则无法比较，评审前锁定 |
| 权重 | 必填 | 合计须为100，否则总分不可比 |
| 候选平台评分 | 必填 | 未评估的维度填“未评”，不填0分，避免拉低总分造成误判 |
| 评分依据/证据来源 | 必填 | 每个非“未评”分数都要有证据；仅有口头承诺的，标注“待书面确认” |
| 结论 | 必填 | 与分数对应，评审会上据此讨论 |
| 阻断项 | 必填 | 即使全部通过也要写明“已核对”，空着视为未检查 |
| 待验证事项 | 选填 | 无未确认问题时填“无”；有则必须写责任人和验证方式 |
| 加权总分 | 选填（终评必填） | 初筛阶段可只做阻断项判断，进入终评前补齐 |
| 备注/版本号 | 选填 | 多轮评审时建议填写，便于追溯 |
未确认的信息统一用“待验证”标注，并在待验证事项中写清由谁、用什么方式、在什么时间前确认。阻断项字段不允许留空：确认满足写“通过”，不满足写“淘汰”并注明原因，尚未核对的写“未核对”，由评审主持人跟踪闭环。
填写示例：一个候选平台的完整打分
以下为演示情景，候选平台以“平台A”代称，分数与证据均为示例，不代表任何真实产品的实际表现。假设团队为50人左右的研发组织，当前重点是需求到发布的链路打通和测试管理。
| 评估维度 | 子项 | 权重(%) | 平台A评分 | 评分依据/证据来源 | 结论 | 待验证事项 |
|---|---|---|---|---|---|---|
| 需求与项目管理 | 需求收集、优先级、迭代规划 | 15 | 4 | 试用环境实测需求池与迭代看板；产品文档“需求管理”章节 | 满足，迭代规划可自定义状态 | 无 |
| 研发流程覆盖 | 需求—开发—测试—发布链路 | 15 | 4 | 演示环境走通一条需求到发布的工作项关联 | 部分满足，发布环节需与现有流水线对接 | 确认发布单能否自动关联构建记录，由研发负责人验证 |
| 代码与流水线集成 | 代码库、CI/CD对接 | 10 | 3 | 产品文档列出代码库集成方式；未实际配置 | 部分满足，需配置验证 | 在试用环境接入一条流水线，由运维执行 |
| 测试管理 | 用例、缺陷、测试报告 | 15 | 5 | 试用环境创建用例并执行，生成测试报告 | 满足 | 无 |
| 文档与知识沉淀 | 文档协作、权限、版本 | 10 | 4 | 试用环境创建文档并设置页面权限 | 满足，版本历史可查 | 无 |
| 报表与度量 | 进度、质量、效能指标 | 10 | 3 | 演示中查看内置报表；自定义指标未验证 | 部分满足 | 确认自定义报表字段范围，由项目经理验证 |
| 权限与安全 | 角色权限、审计 | 10 | 4 | 产品文档权限模型说明；试用环境配置角色 | 满足基本角色隔离 | 确认操作日志保留周期，由IT确认 |
| 易用性与推广成本 | 上手难度、培训量 | 5 | 4 | 3名成员试用后反馈，半天可完成基本操作 | 满足 | 无 |
| 扩展与开放能力 | API、自定义字段与流程 | 5 | 3 | 文档列出开放接口；未做实际调用 | 部分满足 | 验证工作项字段能否通过接口读写，由研发验证 |
| 服务与支持 | 实施支持、响应时效 | 5 | 4 | 供应商书面答复支持方式与响应时间 | 满足 | 无 |
| 加权总分 | — | 100 | — | 计算见下 | — | — |
| 阻断项 | 数据存放地点、对接内部账号系统 | — | — | 供应商书面确认数据存放方案；账号对接未验证 | 数据存放通过；账号对接未核对 | 由IT在试用环境验证单点登录 |
加权总分计算：各维度得分先除以5换算为百分比，再乘以权重后求和。需求与项目管理4÷5×15=12；研发流程覆盖4÷5×15=12；代码与流水线集成3÷5×10=6；测试管理5÷5×15=15；文档与知识沉淀4÷5×10=8；报表与度量3÷5×10=6；权限与安全4÷5×10=8；易用性4÷5×5=4；扩展能力3÷5×5=3；服务与支持4÷5×5=4。合计78分（百分制）。
这个结果的使用方式是：78分说明平台A在核心链路上基本可用，但代码集成、报表自定义和开放接口三项证据不足，属于“待验证”而非“已满足”。阻断项中账号对接尚未核对，在验证完成前不应给出最终结论。评审记录可以写入ONES文档，把每个待验证事项转成工作项指派给责任人，验证结果回填后再更新分数，使选型结论与证据保持同步。
清单的调整与维护方法
清单不是一次填完就固定的表格。团队业务重点变化、评审轮次推进、候选平台增减，都需要对清单做有记录的调整。
维度增删与权重调整
调整维度的依据是团队当前最需要解决的问题，而不是候选平台的强弱项。例如测试人力占比高的团队可以提高测试管理权重；正在推进流水线标准化的团队可以提高代码与流水线集成权重。增删维度后必须重新核对权重合计为100，并在备注中写明调整原因和调整人。已经打分的维度若权重发生变化，应重算总分并保留旧版本，避免同一轮评审出现两套不可比的分数。
多轮评审后的版本更新
建议每轮评审保存一个版本，文件名或表头注明轮次与日期，例如“选型清单_v2_第二轮”。新一轮开始时复制上一版，只修改变化部分：新增候选平台加列，淘汰的平台保留列并标注淘汰原因，不直接删除，便于回溯。待验证事项验证完成后，把结论回填到对应单元格，同时更新分数和证据来源。
结论变更的记录方法
结论从“部分满足”变为“满足”或“不满足”时，应在证据栏补充新证据，并在待验证事项中写明验证人和验证时间。若结论变更影响加权总分或阻断项判断，需要在评审记录中单独说明变更前后差异，由评审主持人确认。这样后续复盘时能看清每个结论是基于什么证据形成的。
清单复用的注意事项
下一次选型可以直接复用本清单的维度骨架，但权重需要重新讨论，因为团队阶段和目标已经变化。复用前检查两点：原有子项是否仍能对应可演示的功能；阻断项是否仍与当前合规和系统对接要求一致。清单本身建议放在团队可共同编辑的文档中维护，评审结论和待验证工作项与文档关联，避免表格散落在个人电脑里。
常见问题
候选平台超过三个，或者中途新增一个平台，表格怎么处理？
向右增加候选平台列即可，其余结构保持不变。中途新增平台时，建议从当前版本复制一份清单，为新平台补齐全部必填字段后再并入比较；已淘汰的平台保留原列并标注淘汰原因，不直接删除，便于回溯每轮评审的完整候选范围。
某个维度暂时无法验证，填“未评”还是先给一个估计分？
填“未评”，并在待验证事项中写明由谁、用什么方式、在什么时间前确认。不要用估计分占位：估计分会被计入加权总分，让尚未取证的维度看起来已经评估过。如果该维度属于阻断项，则必须核对到“通过”或“淘汰”，不能停留在“未评”。
权重应该由谁定，评审过程中还能改吗？
权重反映团队当前的业务优先级，建议由选型负责人牵头，与研发、测试、运维等使用方共同确认后锁定。评审过程中如果业务重点发生变化需要调整权重，应记录调整原因和调整人，重新核对合计为100，并对已打分维度重算总分，同时保留旧版本，避免同一轮出现两套不可比的分数。
加权总分高的平台是否一定入选？
不一定。加权总分用于横向比较综合匹配度，阻断项单独判断：数据存放地点、必须对接的内部系统等硬性条件不满足即淘汰，不参与加权。实际操作中先过阻断项，再看总分，最后结合待验证事项的闭环情况决定是否进入下一轮。总分接近时，证据更完整、待验证事项更少的平台风险更低。
清单填完后，评估记录和待验证事项放在哪里维护比较合适？
建议放在团队可共同编辑的文档中，按轮次保存版本，并把每个待验证事项转成可指派的工作项，写明责任人和验证时间。ONES 的文档与工作项能力可以承载这类记录：评审结论写在文档里，待验证事项作为工作项跟踪，验证完成后回填分数和证据，使选型结论与证据保持同步。
