研发效能工具评估表的设计，核心是把“选哪个工具”这个模糊判断拆成可填写、可核验的字段：先锁定评估对象与结论用途，再按数据采集、指标口径、分析与可视化、集成、权限合规、实施成本六类标准设置评分项，每项写明评分依据、证据来源和权重，最后用加权总分加阻断项得出结论。本篇聚焦度量分析工具的评估表设计，全研发平台选型与指标框架设计不在范围内。
要点总览（TL;DR）
- 评估表设计的第一步是锁定范围：评估对象限定为度量分析工具，明确发起人、数据负责人、工具管理员、使用方代表四类填写角色，并按立项比选、续约复核或替换评估确定字段颗粒度。
- 表头固定为评估项、评分标准、权重、证据来源、评分、状态、备注七列，按数据采集、指标口径、分析与可视化、集成、权限合规、实施成本六类维度拆子项。
- 评分用1–5分并逐档写行为描述，权重按维度到子项两级分配并在取证前冻结，状态区分已确认、待验证、不适用，结论用阻断项加加权总分组合判定。
- 执行按五步推进：收集候选与场景、拆子项写标准、分配权重设阻断项、逐项取证填写、汇总复核形成结论，每步都有输入、输出和完成标志。
- 交付前用字段完整性、标准可观察、证据可追溯、状态与阻断项、结论与评分一致五项检查验收，全部通过才算可用。
评估表先定范围：评估对象、使用角色与结论用途
评估表最常见的失效方式是范围蔓延：表格里既比度量工具，又比项目管理、CI/CD、测试平台，最后每个维度都填得很浅，无法支撑决策。设计前先写一页范围说明，锁定三个前提。
评估对象。把对象限定为度量分析工具，即承担研发数据采集、指标计算、报表与看板呈现的那一类工具。全研发平台的整体选型、指标框架本身的定义与治理，属于另外的议题，可以在评估表中作为约束条件引用，不展开为评分项。
填写角色。至少四类角色参与：发起人负责定义评估目的和结论用途；数据负责人判断数据源、口径与质量；工具管理员评估部署、权限与运维；使用方代表（如研发经理、项目经理）判断日常可用性。角色缺位会导致某一类评分项无人能提供证据。
结论用途。用途决定字段颗粒度。立项比选需要覆盖全部六类维度并保留候选对比；续约复核可以压缩集成与实施成本部分，加重现有使用反馈；替换评估则要额外记录迁移成本与并行期安排。用途不同，权重和阻断项也应不同。
| 范围要素 | 需要写清的内容 | 示例写法 |
|---|---|---|
| 评估对象 | 工具类别与边界 | 度量分析工具；不含项目管理与流水线工具本体 |
| 填写角色 | 角色、姓名、负责的评分项 | 数据负责人：数据采集与指标口径两类 |
| 结论用途 | 比选、复核或替换 | 立项比选，需输出候选排序与阻断项结论 |
| 时间点 | 取证截止日与评审日 | 取证截止 3 月 20 日，评审会 3 月 25 日 |
这页说明的完成标志是：任何人拿到它，都能说清这张表评什么、不评什么、谁来填、结论给谁用。
核心答案：评估表的字段结构与评分规则
一张可用的评估表由表头字段、评估维度、评分刻度、状态标注和判定规则五部分组成。表头字段建议固定为：评估项、评分标准、权重、证据来源、评分、状态、备注。前四项在评审前填写完毕并冻结，评分与状态在取证阶段填写，备注记录分歧与补充说明。
六类评估维度与典型子项
| 维度 | 典型子项 | 取证方向 |
|---|---|---|
| 数据采集能力 | 可对接的数据源类型、采集方式（接口拉取或推送）、同步频率、历史数据回填 | 数据源清单、接口文档、试采样本 |
| 指标口径与模型 | 预置指标清单、口径定义文档、自定义指标能力、口径变更管理 | 指标字典、口径说明、变更记录 |
| 分析与可视化 | 报表与看板类型、多项目多团队对比、下钻与筛选、导出与订阅 | 演示环境、报表样例、操作录屏 |
| 集成与数据打通 | 与项目、代码、流水线、测试工具的对接方式、账号体系打通、数据回写 | 集成清单、联调记录 |
| 权限与合规 | 角色权限粒度、数据可见范围、审计日志、合规材料 | 权限配置截图、合规证明文件 |
| 实施与运维成本 | 部署形态、实施周期、日常维护工作量、培训与支持方式 | 实施方案、人力估算、服务条款 |
评分刻度与权重
评分刻度建议用 1–5 分，并为每一档写行为描述，例如 1 分表示“无此能力或需大量人工替代”，3 分表示“具备能力但需额外配置或存在明显限制”，5 分表示“开箱可用且有证据支撑”。刻度描述写在评分标准列，避免评分人各自理解。
权重分配采用“先分维度、再分项”的两级方法：先按结论用途给六个维度分配合计 100% 的权重，再在维度内部分配子项权重。立项比选通常加重数据采集与指标口径；替换评估通常加重集成与实施成本。权重在取证前确定并冻结，防止看到结果后调权重。
状态字段与判定规则
状态字段设三个值：已确认、待验证、不适用。已确认要求附证据来源；待验证要写明补证方式和责任人；不适用要写明理由，且不计入加权总分，按剩余项权重归一化计算。
最终结论采用“阻断项 + 加权总分”组合判定：先检查阻断项，任一阻断项不满足即不进入候选排序；阻断项全部通过后，再按加权总分排序。阻断项建议控制在三到五条，例如核心数据源无法对接、权限模型无法满足数据隔离要求、无法提供必要的合规材料。
操作步骤：从零到一份可用的评估表
以下五步按顺序执行，每步都有明确的输入、动作、输出和完成标志。
步骤一：收集候选与使用场景。输入是业务方的选型需求与现有工具清单；动作是与发起人和使用方代表确认典型场景，如多项目效能对比、迭代交付分析、资源投入分析；输出是评估对象清单和场景列表；完成标志是每个候选都对应至少一个具体场景。
步骤二：拆子项并写评分标准。输入是六类维度和场景列表；动作是把每个维度拆成可观察的子项，并为 1–5 分写行为描述，标准要指向可看到的东西，如“支持按项目、团队、时间三个维度筛选并下钻”；输出是完整的评估项清单；完成标志是任意两名评分人对同一证据能给出相近分数。
步骤三：分配权重并设定阻断项。输入是结论用途和评估项清单；动作是先定维度权重再定子项权重，同时列出阻断项及其判定条件；输出是带权重的评估表模板；完成标志是权重合计为 100%，阻断项均有明确的通过条件。
步骤四：逐项取证填写。输入是冻结后的模板；动作是按评估项收集演示、文档、试采数据等证据，填写评分、状态和证据来源，无法当场确认的标为待验证并写明补证方式；输出是填写完成的评估表；完成标志是所有评估项都有评分或待验证标注，已确认项均附证据。
步骤五：汇总评分、复核分歧、形成结论。输入是填写完成的评估表；动作是计算加权总分，检查阻断项，对分歧超过约定分差的评估项组织复核；输出是评估结论与遗留待验证清单；完成标志是结论可追溯到具体评分项和证据，待验证项有责任人和截止时间。
角色分工与交付物
评估表由多角色共同完成，单一角色闭门填写会让证据来源单一、结论难以被使用方接受。下表给出职责与交付物对照。
| 角色 | 具体职责 | 交付物 | 提交时点 |
|---|---|---|---|
| 发起人 | 定义评估目的、结论用途、时间点；确认阻断项 | 评估范围说明 | 启动前 |
| 数据负责人 | 评估数据采集与指标口径两类，提供数据源与口径证据 | 数据类评分项及证据 | 取证截止前 |
| 工具管理员 | 评估部署、权限、集成与运维成本 | 技术与运维类评分项及证据 | 取证截止前 |
| 使用方代表 | 评估报表可用性、日常操作体验，参与演示验证 | 使用体验类评分项与反馈记录 | 取证截止前 |
| 评审主持人 | 组织复核分歧、汇总评分、定稿结论 | 评估结论与待验证清单 | 评审会后 |
分歧处理规则建议提前约定：同一评估项评分分差不超过 1 分直接取均值；分差达到 2 分及以上，由评审主持人组织补证或复测，仍无法统一时记录两种意见并说明取舍理由。最终定稿责任归评审主持人，发起人对阻断项判定结果签字确认。
填写示例：一条评估项的完整写法
以“数据采集能力—可对接数据源类型”为例，合格写法如下：
| 字段 | 填写内容 |
|---|---|
| 评估项 | 可对接数据源类型覆盖度 |
| 评分标准 | 1 分：仅支持手工导入；3 分：支持接口对接主要数据源，部分需定制；5 分：支持接口对接项目、代码、流水线、测试四类数据源，且有对接文档与成功案例 |
| 权重 | 维度内 30% |
| 证据来源 | 供应商接口文档第 3 章；试采环境对接两个数据源的记录 |
| 评分 | 4 |
| 状态 | 已确认（四类数据源中测试类对接方式待验证，见备注） |
| 备注 | 测试类数据源需通过中间表对接，补证方式：申请试用环境联调，责任人：工具管理员，截止 3 月 18 日 |
反例是只写“功能强”“体验好”“数据全”这类判断。这类写法没有可观察的标准，不同评分人无法对齐，评审时也无法追溯依据，等于把判断留给了印象。
待验证项的记录要点是：写清缺什么证据、通过什么方式补、谁负责、何时截止。补证完成后更新评分与状态，并在备注中保留变更痕迹，便于复核时理解分数变化的原因。
完成检查：评估表可用性的验收清单
交付前逐项检查，全部通过才算可用。
| 检查项 | 通过标准 |
|---|---|
| 字段完整性 | 每个评估项均包含评估项、评分标准、权重、证据来源、评分、状态、备注七列，无空缺 |
| 评分标准可观察 | 每档分数都有行为描述，描述指向可演示或可查证的现象，不含“强大”“优秀”等主观词 |
| 证据可追溯 | 已确认项均附具体证据，能定位到文档章节、演示记录或试采数据 |
| 状态与阻断项 | 待验证项均有补证方式、责任人和截止时间；阻断项逐条给出通过与否的判定 |
| 结论与评分一致 | 加权总分可由表格直接复算；结论排序与总分、阻断项结果一致，无手工调整痕迹 |
评估表落地为可协作填写的文档和评审流程时，可以用 ONES 承载：评估项作为文档中的结构化条目，由各角色分工填写，待验证项转为工作项跟踪补证进度，评审意见与结论留在同一处，后续续约复核时可直接复用上一版表格并对比变化。ONES Performance 提供数据同步与可视化分析能力，管理者可从统一入口查看多项目、多团队、多流程的效能表现，评估表中“分析与可视化”类评分项可结合演示环境实际验证；其支持为不同角色配置读写权限，便于在评估过程中控制数据可见范围。具体版本与部署形态以官方版本方案为准。
常见问题
评估表里的权重应该在什么时候确定，看到评分结果后再调整可以吗？
权重应在取证开始前确定并冻结，维度权重合计100%，子项权重在维度内部分配。看到评分结果后再调权重，会让结论失去可复核性，评审时也难以解释排序依据。如果评估过程中结论用途发生变化，例如从立项比选转为替换评估，应作为一次范围变更重新确认权重，并在备注中记录变更原因和时间，保留前后两版对照。
候选工具的资料不完整、部分能力无法当场确认时，评估表怎么处理？
把该评估项状态标为“待验证”，在备注中写清缺什么证据、通过什么方式补、谁负责、何时截止，例如申请试用环境联调或索取接口文档。待验证项不按猜测打分，也不计入已确认结论；汇总时先看阻断项，再按已确认项的加权总分排序，并在结论中附遗留待验证清单。补证完成后更新评分与状态，保留变更痕迹。
阻断项应该设几条，和加权总分是什么关系？
阻断项建议控制在三到五条，选取那些一旦不满足就无需再比总分的条件，例如核心数据源无法对接、权限模型无法满足数据隔离要求、无法提供必要的合规材料。判定顺序是先查阻断项，任一不满足即不进入候选排序；阻断项全部通过后，再按加权总分排序。阻断项由发起人在启动阶段确认，评审时逐条给出通过与否的结论。
评估表填完后，续约复核或下一轮选型还能复用吗？
可以复用，但要保留版本对照。续约复核时可压缩集成与实施成本部分，加重现有使用反馈类评分项；替换评估则需补充迁移成本与并行期安排。复用上一版表格时，建议保留原评分、证据来源和状态，新增一列记录本轮变化，便于说明分数升降的原因。评估表落地为可协作填写的文档时，可以用 ONES Wiki 承载结构化条目与评审记录，待验证项转为工作项跟踪补证进度，下一轮直接对比历史版本。
评估表由一个人集中填写，能保证结论被使用方接受吗？
单一角色闭门填写会让证据来源单一，使用方对结论缺乏认同。建议按评分项分工：数据负责人填数据采集与指标口径，工具管理员填部署、权限、集成与运维成本，使用方代表填报表可用性与日常操作体验，评审主持人负责复核分歧和定稿。分歧处理规则提前约定，例如分差不超过1分取均值，达到2分及以上组织补证或复测，仍不统一时记录两种意见并说明取舍理由。
