需求评分表的价值在于让不同角色用同一套口径讨论需求价值，并把结论落到可追溯的记录上。设计时先明确排序要回答的问题和评分对象，再选4–6个互不重叠的维度，为每档分值写出可观察的判断依据，分配权重并约定门槛规则，最后补上评审角色、争议处理和定期校准。本文按这个顺序给出一套可直接填写使用的评分表，并附一条需求的完整打分示例。
要点总览（TL;DR）
- 设计顺序是：先定评分对象与排序问题，再选4–6个互不重叠的维度，写1–5分可观察锚点，分配权重与门槛，最后补评审角色和校准机制。
- 评分对象是需求条目，排序问题写成一句具体的话，如“本季度做哪些需求、暂缓哪些”，避免与任务优先级、产品功能规划混用一张表。
- 权重之和为100%，价值类维度常见合计六到七成；成本类维度要么作为减分项参与加权，要么单独列出作排序参考，口径须在表中写明。
- 评审前设需求描述最低完整度要求，分歧先取均值、再复议、最后由决策人裁定；合同或合规需求保留例外通道并记录原因。
- 上线后每周期回看评分与实际交付价值的偏差，偏差集中在某维度时先检查锚点描述，调整须记录版本与变更说明。
先定评分对象与排序问题
评分表设计的第一步是写清它服务什么决策。同一张表如果既想排需求优先级，又想排任务执行顺序，打分口径会互相干扰，最后谁都不认。建议先用一页说明把四件事定下来：评什么、回答什么问题、多久评一次、谁来参与。
评分对象是需求条目，即一条可独立描述、可独立交付价值的需求，而不是开发任务、缺陷或某个功能模块。任务优先级关注的是“先做哪一步”，需求优先级关注的是“先做哪一件事”，两者的判断依据不同，不应共用一张表。产品功能规划讨论的是功能布局与取舍，属于另一个层面的决策，评分表只负责对已经形成的需求条目排序。
排序问题要写成一句具体的话，例如“本季度研发资源有限，确定做哪些需求、暂缓哪些需求”。问题越具体，维度和门槛越容易对齐。评分周期通常与规划节奏一致，如按季度或按月评审；参与范围包括需求提出人、产品负责人、业务方代表和技术评估人，人数控制在能充分讨论又不至于拖长会议的规模。
这一页说明的完成标志是：任何人拿到评分表，都能说出它评的是需求条目、回答的是哪个规划问题、下一次评审在什么时候、哪些角色必须到场。
评分维度怎么选：4–6个互不重叠的价值维度
维度选择遵循三个原则：可判断，即评分人依据现有信息能给出判断；可区分，即不同需求在同一维度上能拉开差距；少而互斥，即维度之间不重复计分。维度数量建议控制在4–6个，每增加一个维度，评分工作量和争议点都会增加，而排序结论未必更准。
常见维度候选如下，可按业务特点组合，不必全部采用：
| 维度 | 回答的问题 | 适用条件 |
|---|---|---|
| 业务价值 | 这条需求对收入、成本或关键业务指标的影响有多大 | 能说清影响对象和影响方式 |
| 用户覆盖 | 受影响用户的范围和频次如何 | 有用户规模或使用频次的基本估计 |
| 紧迫性 | 延迟交付会带来什么后果，是否有时间窗口 | 存在合同、活动或合规时限 |
| 实现成本 | 研发、测试和上线需要投入多少资源 | 技术评估人能在评审前给出量级判断 |
| 风险与合规 | 是否涉及安全、合规或重大技术风险 | 业务受相关监管或安全要求约束 |
避免维度重叠的常用做法是检查两两之间是否在问同一件事。例如“业务价值”和“战略契合度”如果评分人总是给出相同分数，说明二者区分度不足，可合并为一个维度。再如“用户覆盖”和“影响用户数”本质相同，保留一个即可。维度重叠的直接后果是某一因素被重复加权，排序结果被单一因素主导。
维度清单的完成标志是：每个维度有一句定义、说明它衡量什么、不衡量什么，并注明由谁提供判断依据。定义写清楚，后续写分值和权重才有依据。
分值锚点与权重怎么定
抽象维度要变成可打分的量表，关键是给每一档分值写出可观察的判断依据，也就是锚点。以1–5分为例，锚点描述的是“看到什么就打这个分”，而不是“感觉重要就打高分”。
| 分值 | 业务价值锚点示例 | 实现成本锚点示例 |
|---|---|---|
| 5 | 直接影响核心收入指标，影响可量化 | 需要跨团队改造，周期超过一个季度 |
| 4 | 影响重要业务环节，效果可估算 | 涉及多个模块，周期约一个月 |
| 3 | 改善体验或效率，影响范围有限 | 单模块改动，周期约两周 |
| 2 | 间接影响，主要起辅助作用 | 小范围改动，周期约一周 |
| 1 | 影响不明显，暂无可验证依据 | 配置或文案级调整，数天内完成 |
权重分配的依据是本次排序问题中各因素的相对重要性，权重之和为100%。常见思路是价值类维度合计占六到七成，成本与风险类合计占三到四成；如果本周期以合规整改为主，可临时提高风险与合规的权重，并在表中注明调整原因。总分采用加权求和：每个维度得分乘以权重后相加，得到0–5区间的加权总分，便于横向比较。
成本类维度有两种处理口径，必须在表中写明采用哪一种。第一种是作为减分项参与加权，成本越高总分越低，适合资源紧张、需要快速见效的周期；第二种是不计入总分，单独列出成本量级作为排序参考，适合价值差异明显、成本只用于排先后顺序的场景。两种口径混用会让总分失去可比性。
字段表的完成标志是：每个维度都有定义、1–5分锚点、权重和判断依据来源，成本口径在表头注明，任何人按表填写能得到大致一致的分数。
门槛规则、争议处理与评审流程
评分表要嵌入一次可执行的评审会才有用。评审前设置最低完整度要求：需求描述包含背景、目标用户、预期效果和基本约束，缺少关键信息的需求不进入当次评分，退回补充。这一条能显著减少会上因信息不足产生的空转。
角色分工建议如下：
| 角色 | 职责 | 交付物 |
|---|---|---|
| 需求提出人 | 按模板提交需求描述，说明业务背景与预期效果 | 完整的需求条目 |
| 产品负责人 | 主持评审，校准维度口径，汇总评分 | 评分汇总与排序建议 |
| 业务方代表 | 对业务价值和紧迫性给出判断依据 | 价值类维度的评分与理由 |
| 技术评估人 | 评估实现成本与技术风险 | 成本与风险类维度的评分与理由 |
分歧处理按固定顺序进行：先由各角色说明打分理由，差距在一档以内取均值；差距超过一档进入复议，由提出异议的一方补充依据；仍无法收敛时由决策人裁定，并记录裁定理由。门槛规则方面，可设定加权总分达到某一数值进入本周期候选，低于门槛的进入待观察列表；同时保留例外通道，用于合同约定、合规要求等必须插入的需求，例外需求需注明原因和插入依据，避免例外变成常态。
评分结果和评审记录需要落到需求条目上，便于后续追溯。使用 ONES 时，可以把评分字段和评审结论记录在需求工作项中，评审意见随需求流转保留，下一次复盘时能直接对照当初的打分理由。具体字段配置以实际使用的产品版本为准。
流程的完成标志是：一次评审会结束后，每条参评需求都有分数、有理由、有结论，未达门槛和走例外通道的需求都有明确记录。
填写示例：一条需求如何被打分
以下为演示情景，用于说明打分过程，数据为示例设定。
需求背景：客服团队提出“工单列表支持按客户等级筛选”，理由是重点客户工单响应超时较多，客服需要优先处理。预期效果是重点客户工单平均响应时间缩短。技术评估认为涉及列表查询改造，单模块改动，周期约两周。
| 维度 | 权重 | 得分 | 打分理由 |
|---|---|---|---|
| 业务价值 | 30% | 4 | 影响重点客户服务质量，效果可估算 |
| 用户覆盖 | 20% | 3 | 客服团队内部使用，覆盖范围有限 |
| 紧迫性 | 20% | 4 | 重点客户投诉有上升趋势，存在时间压力 |
| 实现成本 | 20% | 2 | 单模块改动，周期约两周，成本较低 |
| 风险与合规 | 10% | 1 | 无合规要求，技术风险低 |
加权计算：4×0.30 + 3×0.20 + 4×0.20 + 2×0.20 + 1×0.10 = 1.2 + 0.6 + 0.8 + 0.4 + 0.1 = 3.1。本例成本作为减分项参与加权，成本得分低意味着投入小，对总分有利。
排序结论：加权总分3.1，高于当季门槛3.0，进入本周期候选；由于成本较低，可安排在周期前段执行。后续动作是补充响应时间的基线数据，交付后对比验证效果。若该需求总分低于门槛，则进入待观察列表，并在下次评审时更新紧迫性评分。
上线后的校准与完成检查
评分表投入使用后，需要定期回看评分结果与实际交付价值的偏差。做法是每个周期结束后，抽取若干已交付需求，对照当初的评分理由和实际效果，标记明显高估或低估的条目。偏差集中出现在某个维度时，优先检查该维度的锚点是否描述模糊，而不是直接调整权重。
锚点漂移和权重调整应有触发条件，例如连续两个周期同一维度争议超过一定比例，或业务重点发生阶段性变化。每次调整都要记录版本号和变更说明，保留旧版本，便于对比不同周期的评分结果。评分表版本与需求记录分开管理，避免历史评分被新口径覆盖。
完成检查清单如下，可逐项核对：
- 评分对象已明确为需求条目，排序问题写成一句具体的话
- 评分周期和参与角色已确定并通知到人
- 维度数量在4–6个之间，两两之间无重复计分
- 每个维度有定义、1–5分锚点和判断依据来源
- 权重之和为100%，成本类维度的处理口径已在表中注明
- 总分计算方式和门槛规则已写明，例外通道有记录要求
- 评审前置的完整度要求和分歧处理顺序已确定
- 评分结果与评审记录可追溯到具体需求条目
- 校准周期、触发条件和版本变更记录方式已约定
清单全部满足，评分表即可进入试用；试用一到两个周期后，再根据偏差回看结果做第一次校准。
常见问题
评分表算出的总分很接近，怎么排出先后？
总分接近说明当前维度对这几条需求的区分度不足。可以先看单项得分：如果两条需求在业务价值上差距明显，而总分被成本或覆盖度拉平，就按业务价值排序，并在记录中写明理由。也可以设置次级排序规则，例如总分相同或相差0.2以内时，优先紧迫性得分高的一条。若这种情况反复出现，说明维度或锚点需要校准，而不是每次会上临时裁定。
业务方和技术方对同一条需求的打分差距很大，怎么办？
先确认双方是否在评同一件事。常见原因是业务方按预期效果打分，技术方按当前方案的成本打分，而需求描述里没有写清约束条件。处理时按固定顺序：各自说明打分依据，差距在一档以内取均值；超过一档进入复议，由提出异议的一方补充依据；仍无法收敛由决策人裁定并记录理由。如果同一维度连续多个周期出现大差距，应检查该维度的锚点是否描述模糊。
需求数量多、评审时间有限，能不能只让产品负责人一个人打分？
可以，但要区分场景。单人打分适合需求量大、需要快速初筛的环节，由产品负责人按表打分，把明显低分的需求直接放入待观察列表，只把边界需求带到会上讨论。涉及成本评估和合规判断的维度，仍需要技术评估人和业务方提供依据，否则分数缺乏支撑。单人打分的风险是口径随个人偏好漂移，建议定期抽取部分需求由多人复评，对照差异。
评分表用了一段时间，大家开始凭印象打分，怎么纠正？
这是锚点漂移的典型表现。先抽取若干条已交付需求，对照当初的打分理由和实际效果，找出高估或低估集中的维度。若偏差集中在某个维度，优先重写该维度的锚点，把“影响较大”这类模糊描述换成可观察的判断依据，例如影响哪个指标、影响范围多大。重写后组织一次校准会，用同一批需求让各角色重新打分，对比差异并统一口径。每次调整记录版本号和变更说明，保留旧版本以便对比。
例外插入的需求多了，门槛规则还有意义吗？
门槛规则仍然有用，但要给例外设置记录要求。每条走例外通道的需求需注明插入原因和依据，例如合同约定、合规时限或重大客户承诺，并在周期复盘时统计例外占比。例外占比持续偏高，说明门槛值或权重与当前业务节奏不匹配，应调整评分表而不是取消门槛。例外记录本身也是校准依据，能看出哪类需求经常绕过评分。
