需求评分表把需求按价值、成本、风险等维度逐项打分并加权汇总，用于在需求池中排出先后顺序。本文提供一张可直接复制到表格工具的空白表，并说明字段含义、必填项划分和一条完整填写示例，帮助团队统一评分口径、减少评审时的口径分歧。
要点总览（TL;DR）
- 需求评分表按价值、成本、风险三类维度打分并加权汇总，用于在需求池中排出先后顺序；本文提供可直接复制的空白表和一条完整填写示例。
- 成本与风险维度先取反向分（6减原始得分）再参与加权，使总分越高代表综合优先级越高；默认权重以用户价值、业务价值各0.2为主。
- 影响排序计算的字段设为必填，缺失时该行不参与本轮排序，不用默认分补齐；提出人、目标用户、评审结论等可作选填。
- 权重调整建议在表格上方单独维护参数区，保留旧版本、不回溯修改历史评分；每季度抽取已交付需求对比预期与实际，偏差持续时先修正评分标准。
- 评分结果落到需求池排序与评审时，可用 ONES Wiki 页面模板库统一表格模板，并通过页面组关联项目，具体配置以实际开通版本为准。
可复制空白需求评分表
下面这张表可以直接复制到 Excel、在线表格或文档表格中。表头分为三类：需求基本信息、维度得分、汇总结论。复制后先保留全部列，再按团队情况决定是否隐藏选填列。
| 需求编号 | 需求名称 | 提出人 | 目标用户 | 用户价值 (1–5) |
业务价值 (1–5) |
战略契合度 (1–5) |
研发工作量 (1–5) |
依赖复杂度 (1–5) |
技术不确定性 (1–5) |
交付时限压力 (1–5) |
加权总分 | 优先级 | 评审结论 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
各列填写位置说明：
- 前三列填写需求的基本信息，需求编号建议与需求池中的编号保持一致，便于回溯。
- 中间七列是维度得分列，每格只填 1–5 的整数，不填小数或文字。
- 加权总分列由公式自动计算，不建议手工填写。
- 优先级列按总分区间映射，评审结论列记录会议决定，例如“本迭代排入”“延后至下季度评估”“暂不采纳”。
如果团队使用在线表格，可在加权总分列设置公式，把权重单独放在表格上方的参数区，避免每次调整权重都改动每一行。
评分维度与字段说明
评分表的核心是让不同评审人对同一条需求给出可比较的判断。每个维度都需要一句明确的判断标准，否则同一分数在不同人那里含义不同。下表给出各维度的含义与取值方向。
| 维度 | 类别 | 含义 | 1 分 | 5 分 |
|---|---|---|---|---|
| 用户价值 | 价值 | 对目标用户完成核心任务的实际帮助 | 影响少数用户的边缘场景 | 解决多数目标用户的高频痛点 |
| 业务价值 | 价值 | 对收入、留存、转化等业务指标的预期贡献 | 贡献难以量化或间接 | 直接支撑关键业务指标 |
| 战略契合度 | 价值 | 与当前阶段产品方向和公司目标的匹配程度 | 与既定方向关联较弱 | 直接服务于当前重点方向 |
| 研发工作量 | 成本 | 完成需求所需的设计、开发、测试投入 | 投入很小，数人日可完成 | 投入很大，需要跨迭代交付 |
| 依赖复杂度 | 成本 | 对外部团队、系统或前置需求的依赖程度 | 无外部依赖，可独立推进 | 依赖多个团队或关键前置项 |
| 技术不确定性 | 风险 | 方案可行性、技术选型上的未知程度 | 方案成熟，路径清晰 | 需要预研或验证关键技术 |
| 交付时限压力 | 风险 | 外部承诺、合规节点等时间约束的紧迫程度 | 无硬性时间要求 | 有明确且临近的截止时间 |
价值类维度分数越高越应优先，成本类和风险类维度分数越高越应谨慎。为了让两类方向在同一个总分里可比，通常对成本与风险维度取反向分，即用 6 减去原始得分，再参与加权。这样总分越高，代表综合优先级越高。
加权总分的计算公式为：
加权总分 = 用户价值×W1 + 业务价值×W2 + 战略契合度×W3 + (6−研发工作量)×W4 + (6−依赖复杂度)×W5 + (6−技术不确定性)×W6 + (6−交付时限压力)×W7
其中 W1 至 W7 为各维度权重，合计为 1。一组可用的默认权重是：用户价值 0.2、业务价值 0.2、战略契合度 0.15、研发工作量 0.15、依赖复杂度 0.1、技术不确定性 0.1、交付时限压力 0.1。这组权重适合以产品价值为主要排序依据的团队，其他团队可按业务阶段调整。
优先级字段把连续的总分转成可执行的档位，例如总分 4.0 以上为 P0，3.0–4.0 为 P1，2.0–3.0 为 P2，2.0 以下为 P3。评审结论字段记录人的判断，用于补充分数无法表达的信息，例如“分数达标但依赖未就绪，暂缓”。
必填项与选填项怎么划分
评分表被填成残缺表，最常见的原因是必填与选填没有提前约定。划分原则是：影响排序计算的字段必须填，影响追溯和沟通的字段可以选填。
| 字段 | 属性 | 缺失时的处理 |
|---|---|---|
| 需求编号 | 必填 | 退回补填，不进入评分 |
| 需求名称 | 必填 | 退回补填，名称需能独立识别需求 |
| 七个维度得分 | 必填 | 任一维度空缺则该行不参与排序，标记为待补评 |
| 加权总分 | 必填 | 由公式计算，公式缺失时按字段说明手工核算 |
| 优先级 | 必填 | 按总分区间映射，评审前完成 |
| 提出人 | 选填 | 空缺不影响排序，但影响后续沟通 |
| 目标用户 | 选填 | 空缺时在评审中口头补充 |
| 评审结论 | 选填 | 评审会后补录，未评审的需求可留空 |
| 备注、参考链接 | 选填 | 按需填写，用于补充背景材料 |
必填缺失的处理方式建议统一为“不参与本轮排序”，而不是用默认分补齐。用默认分补齐会让未评估的需求混入排序结果，掩盖真实的信息缺口。对于批量导入的需求，可以先导入基本信息，再集中补评维度得分。
不同团队可以按场景增减选填字段。例如面向客户交付的团队可以增加“客户名称”和“合同节点”，内部平台团队可以增加“影响系统”。增减时保持必填字段不变，避免不同批次的评分结果无法比较。
完整填写示例：一条需求如何打分
以下示例为演示情景，需求名称与得分均为虚构，用于说明从打分到得出结论的过程。
| 字段 | 填写内容 |
|---|---|
| 需求编号 | REQ-0142 |
| 需求名称 | 订单列表支持按交付状态筛选 |
| 提出人 | 运营组 |
| 目标用户 | 日常处理订单的运营人员 |
| 用户价值 | 4 |
| 业务价值 | 3 |
| 战略契合度 | 3 |
| 研发工作量 | 2 |
| 依赖复杂度 | 2 |
| 技术不确定性 | 1 |
| 交付时限压力 | 2 |
按默认权重计算，成本与风险维度先取反向分：研发工作量 6−2=4，依赖复杂度 6−2=4，技术不确定性 6−1=5，交付时限压力 6−2=4。
加权总分 = 4×0.2 + 3×0.2 + 3×0.15 + 4×0.15 + 4×0.1 + 5×0.1 + 4×0.1 = 0.8 + 0.6 + 0.45 + 0.6 + 0.4 + 0.5 + 0.4 = 3.75。
总分 3.75 落在 3.0–4.0 区间，优先级判定为 P1。评审结论可写为：“价值明确、实现成本低，排入下一迭代；需与订单服务团队确认筛选字段的数据来源。”这条结论既记录了排序结果，也把待确认事项写清楚，便于后续跟进。
把多条需求按同样方式填写后，按加权总分从高到低排序，即可得到本轮需求池的优先顺序。总分接近时，可以优先看用户价值或战略契合度的单项得分，再结合评审结论做人工调整。
评分表的调整与维护方法
评分表用久了容易出现两类问题：权重长期不变导致排序偏离业务重点，评分标准逐渐模糊导致分数不可比。维护的重点是让调整有触发条件、有记录、可复核。
权重调整的触发条件可以设为：业务阶段变化，例如从拉新转向留存；连续两个评审周期出现高分需求交付后业务收益不明显；或某类维度长期全部打满分、失去区分度。调整方式建议在表格上方单独维护权重参数区，修改后保留旧版本，新周期使用新权重，不回溯修改历史评分，避免同一批需求前后口径不一致。
1–5 分锚点的维护，建议每个维度保留一句可判断的描述，并在评审前用一两条已知需求做校准。当评审人频繁对同一维度给出差异很大的分数时，说明锚点描述需要补充例子，而不是简单要求大家“打分一致”。
字段增删需要版本记录。可以在表格中增加“模板版本”列，或在文件命名中标注版本号和生效日期，并在变更说明中写清新增字段、删除字段及原因。删除字段前先确认历史数据是否还需要按该字段筛选。
定期复核是保持表格可信的关键。每个季度可以抽取若干条已交付需求，对比评分时的预期与实际结果，例如高分需求是否真的带来了预期价值、低工作量预估是否准确。偏差持续出现时，优先修正评分标准，再考虑调整权重。
评分结果最终要落到需求池中排序和评审。使用 ONES 时，可以借助 ONES Wiki 的页面模板库把这张评分表做成统一模板，一键创建制式化文档，减少每次新建表格时的字段遗漏；通过页面组关联项目，使需求与评分文档互相对应；文档支持嵌入任务进度和报表，评审时可以在同一页面查看需求进展；页面版本记录支持随时查看与回滚，权重和字段调整留下的历史版本可以追溯。具体可用的模板类型与配置以实际开通版本为准。
常见问题
团队刚开始用评分表，权重应该怎么定？
可以从一组默认权重起步：用户价值 0.2、业务价值 0.2、战略契合度 0.15、研发工作量 0.15、依赖复杂度 0.1、技术不确定性 0.1、交付时限压力 0.1。这组权重适合以产品价值为主要排序依据的团队。若当前阶段重点是交付节奏，可适当提高工作量与时限压力的权重，但每次调整后要保留旧版本，新周期使用新权重，避免同一批需求前后口径不一致。
两个维度打分时拿不准，评审人之间分歧大怎么办？
分歧通常来自锚点描述不够具体。可以先检查该维度的 1 分和 5 分描述是否可判断，再补充一两个团队内已知需求的例子作为参照。评审前用一两条已知需求做校准，让评审人对同一分数形成共同理解。若分歧集中在某个维度，优先细化该维度的判断标准，而不是要求大家统一打某个分数。
需求还没评估完，能先放进评分表排序吗？
可以先把基本信息录入，但维度得分未填齐的行建议标记为待补评，不参与本轮排序。用默认分补齐会让未评估的需求混入排序结果，掩盖真实的信息缺口。批量导入时，可以先导入需求编号和名称，再集中补评各维度得分，评审前完成优先级映射。
评分表里的总分和评审结论冲突时，以哪个为准？
总分用于形成可比较的排序基础，评审结论用于补充分数无法表达的信息，例如依赖未就绪、合规节点变化等。两者冲突时，建议在评审结论中写清调整理由和后续动作，例如“分数达标但依赖未就绪，暂缓至下季度评估”。这样既保留了评分记录，也让排序调整有据可查。
评分表用了一段时间，怎么判断权重该不该调？
可以设几个触发条件：业务阶段变化，例如从拉新转向留存；连续两个评审周期出现高分需求交付后业务收益不明显；或某类维度长期全部打满分、失去区分度。出现这些情况时，在表格上方的参数区调整权重并记录生效日期。定期抽取已交付需求对比评分预期与实际结果，偏差持续出现时，先修正评分标准，再考虑调整权重。
