研发平台采购评估标准要解决的是把采购诉求转成可打分、可取证的结构，让评标讨论有共同依据。标准应在发出选型需求、观看供应商演示之前定稿，评分口径、权重和证据来源由业务、研发、IT、安全、采购共同确认，避免演示后按印象改分。下文按四层结构、需求拆分、维度权重、证据采集、角色分工、评分表示例和定稿检查依次展开。
要点总览（TL;DR）
- 评估标准按评估目标、需求清单、评估维度与权重、评分规则与证据要求四层搭建，自上而下逐级细化，最终汇总为一张可执行的评分表。
- 需求清单先按角色和流程环节收集原始诉求，再改写成含场景、动作和判定标准的可验证条目，并区分必须项、加分项与可选项。
- 权重从评估目标推导，核心目标相关维度合计占多数权重；评分采用统一刻度，每个评分项同步定义证据来源，无证据按0分处理。
- 证据通过按需求条目设计的演示脚本、覆盖完整迭代的试用和参考客户核验取得，评分与证据记录表关联留痕，保证评标可复核。
- 标准在发出选型需求和观看演示前定稿，经业务、研发、IT、安全、采购共同确认并版本归档，评标期间调整按变更流程记录。
评估标准先定哪几层结构
评估标准可以按四层搭建：评估目标、需求清单、评估维度与权重、评分规则与证据要求。四层自上而下逐级细化，每一层都为下一层提供约束，最后汇总成一张可执行的评分表。搭建顺序建议从目标开始，先明确这次采购要解决什么业务问题，再往下拆解，避免一上来就罗列功能。
第一层：评估目标
评估目标来自采购要解决的业务问题，例如缩短需求到交付的流转周期、统一多团队的项目进度口径、让质量数据可追溯。目标要写成可观察的结果，并注明当前基线和期望方向。目标条目不宜过多，三到五条足够，后续所有需求条目都应能追溯到其中至少一条目标。
第二层：需求清单
需求清单分为必须满足、重要加分、可选三类。必须满足项是缺了就无法支撑评估目标的硬性条件；重要加分项影响使用效果和长期成本，但允许供应商以不同方式实现；可选项用于区分方案的完善程度，不构成淘汰依据。分类标准要在清单形成时一次定清，后续不再随意升降级。
第三层：评估维度与权重
维度是对需求条目的归并，常见如功能匹配、集成与数据、易用性与推广成本、安全与合规、服务与实施能力、总体拥有成本。权重依据评估目标分配：与核心业务问题直接相关的维度权重高，辅助性维度权重低。权重总和设为100%，并在标准中写明每个维度的权重理由。
第四层：评分规则与证据要求
每个评分项要同时定义打分刻度和证据来源。例如功能匹配项采用0—5分制，5分要求现场演示指定场景并留存录屏或截图，3分要求提供配置说明，无证据不得给分。评分规则与证据要求同步定义，可以防止评标时出现“感觉不错但说不清依据”的情况。
需求清单怎么从业务场景拆出来
需求清单的形成分两步：先按角色和流程环节收集原始诉求，再把诉求改写成可验证的需求描述。原始诉求往往是“希望进度看得清”“评审别再靠邮件”这类表达，直接拿来评分会产生歧义，必须转成有对象、有动作、有判定标准的条目。
按角色和流程环节收集
角色维度覆盖产品经理、研发工程师、测试、项目经理、质量与安全负责人、IT 运维和管理层，每个角色列出日常工作中与研发平台相关的动作和痛点。流程环节维度覆盖需求提出、排期、开发、测试、发布、缺陷处理、度量复盘。两个维度交叉，可以避免只收集到某一类岗位的声音。收集方式可用访谈加问卷，每条例出的诉求注明提出角色和使用频率。
把诉求改写成可验证的需求描述
改写后的条目应包含场景、动作和判定标准。例如把“希望需求变更可追踪”改写为“需求变更后，关联任务、测试用例和发布记录能显示变更前后版本，并可按需求编号查询变更历史”。这样的描述在演示和试用中都能直接验证，评分时也有明确对照物。
区分必须项与加分项
判断依据有三条：该条目缺失是否直接导致评估目标无法达成；是否有法规、审计或企业制度的硬性要求；是否存在不依赖该平台的替代做法。前两条成立通常列为必须项，第三条成立则更适合列为加分项或可选项。必须项数量要控制，过多会让合格供应商范围过窄，也会稀释真正关键的判断。
需求条目与评分项的对应
每条需求分配唯一编号，并在评分表中标注对应的评分项和维度。一条需求可以对应一个评分项，也可以几条同类需求合并为一个评分项，但合并后要在评分项说明中列出覆盖的需求编号。这样在评标出现争议时，可以回溯到具体需求，也便于检查是否有需求未被任何评分项覆盖。
评估维度、权重与评分规则怎么设
维度、权重和评分规则共同决定评标结果的可比性。设定时先确定维度清单，再按评估目标分配权重，最后统一打分刻度和口径。三者要在同一份文档中定稿，单独修改其中一项都会影响结果的可解释性。
常见评估维度及适用条件
| 维度 | 考察内容 | 适用条件 |
|---|---|---|
| 功能匹配 | 必须项与加分项的满足程度 | 所有采购均适用，权重通常最高 |
| 集成与数据 | 与现有代码库、CI/CD、身份系统、报表工具的对接方式 | 已有工具链较完整、数据需要汇总分析时重点考察 |
| 易用性与推广成本 | 学习成本、配置复杂度、迁移与培训工作量 | 使用团队多、一线工程师占比高时权重上调 |
| 安全与合规 | 权限模型、审计日志、数据存放与合规要求 | 涉及敏感项目或受监管业务时列为必须项 |
| 服务与实施能力 | 实施方法、响应机制、成功案例的可核验程度 | 首次引入平台或缺少内部运维力量时重点考察 |
| 总体拥有成本 | 许可、实施、运维、培训与后续扩展成本 | 所有采购均适用，按三到五年口径估算 |
权重分配的依据与调整
权重从评估目标推导：与核心业务问题直接相关的维度合计应占多数权重。分配完成后做一次反向检查，假设某供应商在某一维度得满分、其余维度中等，看总分是否合理，以此发现权重失衡。权重调整只在标准定稿前进行，定稿后如需调整，按变更流程记录原因并重新确认。
评分刻度与打分口径
推荐采用0—5分制并写明每一档的含义，例如5分表示演示中完整满足且无需额外定制，3分表示满足但需要配置或二次开发，1分表示仅部分满足，0分表示不满足或无证据。所有评分项使用同一刻度，评委独立打分后再合议，合议差异超过两档时要说明理由并记录。
一票否决项的设置原则
一票否决项只用于后果严重且无法通过其他手段弥补的条件，例如关键安全合规要求不满足、必须项存在缺失、无法提供可核验的参考客户。否决项数量宜少，每条都要写明判定证据，避免把普通加分项误设为否决项而排除合理方案。
证据怎么取：演示、试用与参考核验
评分要有证据支撑，证据采集计划应与评分表同步制定。演示、试用和参考客户核验各有适用范围：演示适合验证功能是否存在和操作路径，试用适合验证真实数据下的可用性，参考核验适合验证实施效果和服务质量。
演示脚本按需求条目设计
演示脚本从必须项和重要加分项中选取场景，按业务流程串联成若干段，每段注明对应需求编号、期望看到的操作和判定标准。脚本提前发给供应商，保证各家演示同一组场景，减少因演示内容不同造成的不可比。演示过程安排记录人，对每个场景填写是否满足、证据形式和疑点。
试用范围与验证周期
试用选取一到两个真实项目或团队，覆盖主要角色和关键流程环节，周期通常为两到四周，以能跑完一个完整迭代为准。试用前明确验证清单和成功标准，试用中记录操作问题、性能表现和推广阻力，试用结束由参与人员按评分项打分并附说明。
参考客户核验的提问要点
核验参考客户时，重点询问与本次采购场景相近的部分：上线周期、实施中遇到的主要问题、日常使用率、服务响应情况、后续扩展时付出的额外工作。提问要具体到场景和数字，避免只得到“还不错”这类评价。参考客户由供应商提供时，应确认其使用范围与本次需求的可比性。
证据记录表与评分留痕
建立证据记录表，字段包括需求编号、评分项、证据类型（演示录屏、试用记录、参考访谈、文档说明）、证据存放位置、记录人和日期。评分时每个分数都要关联证据记录，无证据的评分项按0分处理。留痕既保证评标可复核，也为后续合同条款和验收标准提供依据。
角色分工与各阶段交付物
标准能否落地取决于分工是否清晰。建议由采购牵头组织，业务与研发提供需求，IT 与安全把关技术与合规，各方在关键节点共同确认。下表给出角色职责与阶段交付物。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 业务负责人 | 提出评估目标，确认需求优先级 | 评估目标说明、需求清单确认意见 |
| 研发与测试代表 | 提供流程环节诉求，参与演示脚本设计和试用 | 需求条目、演示脚本、试用记录 |
| IT 与运维 | 评估集成方式、部署条件与运维工作量 | 集成需求条目、技术评估意见 |
| 安全与合规 | 设定安全合规必须项与否决项 | 安全合规检查项、否决项清单 |
| 采购 | 组织流程、维护评分表、汇总评分与证据 | 评分表、证据记录表、评标汇总 |
阶段交付物按顺序为：评估目标说明、需求清单、维度权重表与评分规则、证据采集计划、评标汇总报告。评审与签字确认设在三个节点：需求清单定稿、评分规则定稿、评标结果汇总。标准变更采用版本控制，每次修改记录变更内容、原因、影响范围和确认人，已发出的选型文件如需同步修改，要通知全部参与供应商。
需求条目、评分表和证据记录需要在多个角色之间反复流转和评审。ONES 的文档与工作项协作方式可以承载这类过程：需求条目作为工作项分配责任人和状态，评分表与证据记录作为文档关联到对应评审节点，评审意见和版本变更留存在同一处，便于评标时回溯。是否采用工具承载取决于参与人数和评审频次，小规模采购用共享表格加邮件确认也能完成。
示例：一份研发平台采购评分表
以下示例演示评分表如何填写，权重和分值为示意，实际使用时按评估目标调整。假设本次采购的核心目标是统一多团队的项目进度口径并提升需求变更的可追踪性。
| 维度（权重） | 评分项 | 类型 | 评分刻度 | 证据要求 | 示例得分 |
|---|---|---|---|---|---|
| 功能匹配（35%） | 需求变更后关联任务、用例、发布记录可追溯 | 必须 | 0—5 | 演示录屏＋试用记录 | 4 |
| 功能匹配（35%） | 多团队进度按统一口径汇总 | 必须 | 0—5 | 演示＋配置说明 | 5 |
| 功能匹配（35%） | 度量报表自定义能力 | 加分 | 0—5 | 演示 | 3 |
| 集成与数据（20%） | 与代码库、CI/CD 的对接方式 | 必须 | 0—5 | 技术方案＋试用验证 | 4 |
| 易用性与推广（15%） | 一线工程师上手所需培训量 | 加分 | 0—5 | 试用反馈 | 3 |
| 安全与合规（15%） | 权限模型与审计日志 | 必须 | 0—5 | 安全说明＋演示 | 5 |
| 服务与实施（10%） | 实施方法与参考客户可核验程度 | 加分 | 0—5 | 参考访谈记录 | 4 |
| 总体拥有成本（5%） | 三年期许可、实施与运维成本 | 加分 | 0—5 | 报价单＋成本测算 | 3 |
加权总分按“各维度得分×权重”求和计算。上例中功能匹配维度取三项平均4分，乘以35%得1.40；集成与数据4分乘20%得0.80；易用性3分乘15%得0.45；安全5分乘15%得0.75；服务4分乘10%得0.40；成本3分乘5%得0.15，合计3.95分（满分5分）。必须项中任何一项得0分即触发否决，不再计算总分。评分结果用于支撑决策讨论：总分接近时，重点比较核心目标相关维度的得分差异和证据质量，而不是简单取高者。
完成检查：标准定稿前要确认什么
定稿前逐项检查，可以防止标准带着漏洞进入采购流程。以下清单建议由采购组织，各角色分别确认后签字归档。
- 需求覆盖检查：每条评估目标都能追溯到至少一条需求条目，每条需求都对应到评分项，无遗漏、无重复计分。
- 权重合理性检查：核心目标相关维度权重合计占多数，做过反向验算，权重总和为100%。
- 分类检查：必须项数量控制在合理范围，每条必须项和否决项都有明确的判定证据和判定人。
- 口径一致性检查：评分刻度各档含义统一，证据要求与评分项一一对应，无“凭印象给分”的条目。
- 可取证性检查：每个评分项都写明了证据类型和采集方式，演示脚本、试用清单和参考访谈提纲已准备好。
- 干系人确认：业务、研发、IT、安全、采购均已确认并签字，异议已记录处理结果。
- 版本归档：标准版本号、定稿日期、确认人清单归档保存，变更流程已告知全部参与方。
- 后续衔接：评分表中的必须项和关键加分项已能对应到合同验收条款和上线后的验收标准，评标汇总模板已准备。
以上检查全部通过后，标准即可随选型需求一并发出。评标过程中如需调整，按变更流程记录并重新确认，保持评分口径在整个采购周期内一致。
常见问题
评估标准应该在选型流程的哪个时点定稿？
建议在发出选型需求、观看供应商演示之前定稿。演示内容会直接影响评委印象，如果标准在演示后才确定，权重和评分口径容易向某家方案倾斜。定稿时点至少应早于演示脚本发出，使各家供应商面对同一组场景和同一套评分规则。
必须项设得太多会有什么问题，如何控制数量？
必须项过多会让合格供应商范围过窄，也会稀释真正关键条件的判断力。控制方法是对每条候选必须项问三个问题：缺失是否直接导致评估目标无法达成；是否有法规、审计或企业制度的硬性要求；是否存在不依赖该平台的替代做法。前两条成立才列为必须项，第三条成立更适合放入加分项或可选项。
试用周期短、参与团队少，评分结果还可信吗？
试用范围有限时，评分结果更适合作为演示证据的补充，而不是独立结论。可以采取两项措施提高可信度：一是试用选取覆盖主要角色和关键流程环节的项目，以跑完一个完整迭代为周期下限；二是试用结束由参与人员按评分项逐条打分并附说明，与演示证据交叉比对。若试用条件确实受限，在评标汇总中注明证据强度，决策讨论时对相关维度降低确定性表述。
评标过程中发现评分项设计有遗漏，能否临时增加？
可以补充，但要按变更流程处理：记录新增内容、原因、影响范围和确认人，重新通知全部参与供应商，并保证各家在同一口径下补充材料。临时增加评分项若只对部分供应商执行，会破坏可比性。更稳妥的做法是在定稿前的检查环节核对需求覆盖，尽量把遗漏消灭在标准发出之前。
评分表定稿后，如何与合同和验收衔接？
定稿检查时确认评分表中的必须项和关键加分项能对应到合同验收条款。具体做法是把必须项转为验收的硬性条件，把影响使用效果的关键加分项转为上线后的验收标准或服务指标，并在评标汇总中保留对应证据记录。这样评标阶段的判断依据可以直接延续到合同履行和验收环节，减少两套口径之间的落差。
