需求优先级与价值评估评分表通常由三部分组成：需求基本信息、1–5分评分项，以及权重与判定结果。字段决定评分能否横向比较，权重决定价值与成本风险如何平衡，分档阈值和一票升级条件决定最终排序。下面给出一张可直接复制的空白表，并说明字段口径、必填规则、填写示例和长期维护方法。
要点总览（TL;DR）
- 评分表由三部分组成：需求基本信息、五项1–5分评分项（业务价值、用户覆盖、紧急程度、实现成本、风险与依赖），以及权重、加权总分与判定结论字段。
- 权重合计须为100%，通用建议价值类合计约60%–70%、成本与风险类约30%–40%，比例在评审前固定，按团队阶段调整。
- 判定规则用加权总分分档：≥4.0为P0，3.0–3.9为P1，2.0–2.9为P2，低于2.0为P3，并另设合规、安全、重大客户承诺等一票升级条件。
- 影响计算的字段必须补齐后才能定级，只影响追溯的字段允许评审后补充；条件必填项在触发情形出现时须写明依据。
- 模板落地后按季度校准评分口径、记录模板版本号，权重或阈值调整后用最近10–20条已定级需求回算对比。
可复制空白评分表模板
下表按“基本信息—评分项—加权计算—判定结论”的顺序排列，可直接复制到表格工具或文档中使用。评分项固定为五项，每项1–5分；权重列由团队在评审前统一填写，合计须为100%。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 需求编号 | |
| 需求名称 | ||
| 提出人 / 提出部门 | ||
| 目标用户 | ||
| 关联业务目标 | ||
| 提交日期 | ||
| 评分项（1–5分） | 业务价值 | |
| 用户覆盖 | ||
| 紧急程度 | ||
| 实现成本 | ||
| 风险与依赖 | ||
| 权重与计算 | 业务价值权重 | % |
| 用户覆盖权重 | % | |
| 紧急程度权重 | % | |
| 实现成本权重 | % | |
| 风险与依赖权重 | % | |
| 加权总分 | ||
| 判定结论 | 优先级等级 | P0 / P1 / P2 / P3 |
| 一票升级条件 | ||
| 评审结论 | ||
| 评审人与评审日期 | ||
| 复核日期 |
使用前先补齐权重行，使五项权重之和为100%，再逐条打分。加权总分保留一位小数，便于与分档阈值对照。
字段说明：每个字段填什么、怎么算
字段说明的作用是让不同评审人对同一需求打出接近的分数。基本信息用于识别和追溯，评分项用于量化判断，权重与计算字段把五项分数合成一个可排序的总分。
| 字段 | 含义 | 取值 / 计算 | 示例值 |
|---|---|---|---|
| 需求编号 | 需求在需求池中的唯一标识 | 按团队编号规则填写，提交后不再变更 | REQ-2024-0186 |
| 需求名称 | 一句话说明需求要解决的问题 | 动宾结构，不超过30字 | 支持批量导出订单明细 |
| 提出人 / 提出部门 | 需求来源，便于后续澄清 | 填写具体人员与部门 | 张明 / 客服中心 |
| 目标用户 | 需求直接服务的用户群体 | 写明角色或客户分层 | 一线客服、区域运营 |
| 关联业务目标 | 需求支撑的季度或年度目标 | 引用已确定的业务目标名称 | 降低订单查询工单量 |
| 提交日期 | 需求进入评审流程的时间 | 日期格式 | 2024-06-12 |
| 业务价值 | 需求对收入、成本或关键指标的贡献 | 1分=贡献不明确；3分=有可量化改善；5分=直接影响核心指标 | 4 |
| 用户覆盖 | 受影响用户的范围与占比 | 1分=个别用户；3分=部分用户群；5分=多数或全部目标用户 | 4 |
| 紧急程度 | 时间窗口的紧迫性 | 1分=可延后；3分=本季度内需要；5分=有明确截止日期或外部约束 | 3 |
| 实现成本 | 研发、设计、测试的投入规模 | 1分=成本很高；3分=中等；5分=成本很低。分数越高越有利 | 2 |
| 风险与依赖 | 技术不确定性、外部依赖与合规影响 | 1分=风险高或依赖多；3分=可控；5分=风险低、依赖少。分数越高越有利 | 3 |
| 各项权重 | 该评分项在总分中的占比 | 百分比，五项合计100% | 30% |
| 加权总分 | 五项分数按权重合成的结果 | Σ（单项得分×该项权重），保留一位小数 | 3.4 |
| 优先级等级 | 按总分落入的档位 | 对照分档阈值填写P0–P3 | P1 |
| 一票升级条件 | 不依赖总分、直接提升优先级的特殊情形 | 命中则记录具体条件，未命中填“无” | 涉及客户合同承诺 |
| 评审结论 | 评审会的最终处理意见 | 进入排期 / 待补充信息 / 暂缓 / 不采纳 | 进入下季度排期 |
| 复核日期 | 下次重新评估的时间 | 按需求变化频率设定 | 2024-09-30 |
计算关系只有一条：加权总分等于各评分项得分乘以对应权重后求和。实现成本与风险两项采用“分数越高越有利”的口径，避免在公式中再做反向处理，减少填错的可能。
必填与选填：哪些字段不能空
必填字段缺失时，需求不进入评分环节；选填字段缺失不影响计算；条件必填字段在触发对应情形时必须补齐，否则评审结论不能生效。
| 类别 | 字段 | 缺失时的处理 |
|---|---|---|
| 必填 | 需求编号、需求名称、提出人、目标用户、提交日期 | 退回提出人补充，暂不排入评审议程 |
| 必填 | 业务价值、用户覆盖、紧急程度、实现成本、风险与依赖 | 任一项空缺则加权总分无效，不得定级 |
| 必填 | 各项权重、加权总分、优先级等级、评审结论 | 由评审主持人在会上统一填写，会后不得单独修改 |
| 选填 | 关联业务目标、复核日期、评审人 | 可后补；复核日期建议在定级时一并填写 |
| 条件必填 | 一票升级条件 | 涉及合规、安全、重大客户承诺时必填具体依据，未涉及填“无” |
| 条件必填 | 风险与依赖的说明 | 该项打1–2分时必须写明具体风险或依赖对象 |
| 条件必填 | 实现成本的估算依据 | 该项打1–2分时须注明估算人或估算方式 |
缺失处理遵循一条原则：影响计算的字段必须补齐后才能定级，只影响追溯的字段允许在评审后补充。对条件必填项，评审主持人负责在会前检查触发情形，避免会上临时补材料。
填写示例：一条需求如何从评分到定级
以下示例为演示情景，用于说明字段填写与计算过程，数值不代表任何真实团队的评估结果。
需求背景：客服中心提出“支持批量导出订单明细”，目标是减少客服逐单查询的时间。目标用户为一线客服与区域运营，关联目标为降低订单查询工单量。评审会给出的权重为：业务价值30%、用户覆盖20%、紧急程度10%、实现成本25%、风险与依赖15%，合计100%。
| 评分项 | 得分 | 权重 | 加权分 | 打分理由 |
|---|---|---|---|---|
| 业务价值 | 4 | 30% | 1.20 | 可量化减少查询工时，间接影响工单量指标 |
| 用户覆盖 | 4 | 20% | 0.80 | 覆盖全部一线客服及部分区域运营 |
| 紧急程度 | 3 | 10% | 0.30 | 本季度内需要，无外部截止日期 |
| 实现成本 | 2 | 25% | 0.50 | 涉及导出权限与数据量控制，投入偏高 |
| 风险与依赖 | 3 | 15% | 0.45 | 依赖订单服务接口，风险可控 |
| 合计 | — | 100% | 3.25 | — |
计算过程：1.20＋0.80＋0.30＋0.50＋0.45＝3.25，保留一位小数为3.3。对照分档规则，3.0–3.9为P1。该需求未命中合规、安全或重大客户承诺等一票升级条件，因此评审结论为P1，进入下季度排期，复核日期设为季度末。
这个示例说明两点：实现成本得分低会明显拉低总分，团队如果希望更重视投入产出，可以提高成本项权重；紧急程度权重较低时，时间压力对总分的影响有限，需要通过一票升级条件单独处理。
权重设置与判定规则怎么调
权重决定评分表把团队注意力引向哪里。通用建议是价值类合计约60%–70%，成本与风险类合计约30%–40%，具体比例按团队当前阶段调整，并在评审前固定，避免逐条需求临时改权重。
| 团队情形 | 价值类（业务价值＋用户覆盖＋紧急程度） | 成本与风险类（实现成本＋风险与依赖） | 调整意图 |
|---|---|---|---|
| 增长期，机会多、资源紧 | 约70% | 约30% | 优先抓住高价值需求，成本作为参考 |
| 稳定期，交付压力大 | 约60% | 约40% | 提高投入产出比，抑制高成本低价值需求 |
| 合规或稳定性敏感 | 约65% | 约35% | 保留风险项权重，同时用一票条件兜底 |
分档阈值建议以加权总分为依据：≥4.0为P0，3.0–3.9为P1，2.0–2.9为P2，低于2.0为P3。阈值应结合历史需求分布校准，如果某档长期没有需求落入，说明阈值与评分口径不匹配，需要同时检查评分标准和权重，而不是只改阈值。
一票升级条件用于处理总分无法反映的情形：涉及合规要求、安全事件、重大客户合同承诺的需求，可直接提升至P0或P1，并在表中记录具体依据。对应地，可以设置一票降级条件，例如需求依赖的外部系统已确定下线，或目标用户群体已不再使用该功能。一票条件宜少而明确，每条都要写清触发情形和审批人。
权重或阈值调整后，应选取最近10–20条已定级需求重新计算，对比新旧结果。如果大量需求等级发生跳变，说明调整幅度过大，可分步实施并保留一个评审周期的观察期。
评分表在文档中定稿后，落地到需求管理工具时，可以把评分项做成自定义字段、把加权总分和等级做成计算或状态字段，让评审记录与需求条目放在一起。ONES 的需求管理支持工作项字段配置与状态流转，ONES Wiki 的页面模板库可用于存放评分表模板和评审记录，便于团队按同一版本填写。具体字段配置方式以团队实际使用的产品版本为准。
模板的调整与维护方法
评分表的价值来自长期一致的口径。落地后需要固定的校准节奏、明确的调整触发条件和可追溯的版本记录，否则不同季度的分数无法比较。
- 评分口径校准：每季度抽取5–10条已评审需求，由两名以上评审人独立打分，对比分歧较大的评分项，修订评分标准中的描述，而不是直接改分数。
- 权重调整触发条件：团队目标发生切换、连续两个季度某类需求集中积压、或成本超支成为主要问题时，启动权重复核。
- 阈值调整触发条件：某一等级长期为空或过度集中、一票升级条件频繁触发，说明分档或评分项需要重新设计。
- 版本记录字段：在模板中增加模板版本号、生效日期、修订人和修订说明，每次调整保留旧版本，便于回溯历史需求的定级依据。
- 评审结果回溯：需求交付后记录实际投入与预期收益的偏差，按季度汇总，作为下一轮权重和评分口径调整的依据。
- 复盘节奏：每季度一次轻量复盘，每年一次完整复核，复盘结论写入版本记录，不停留在会议纪要中。
维护时保持字段名称稳定，新增字段放在表格末尾并标注生效版本。历史需求继续沿用其定级时的版本，不追改旧分数，这样跨期比较才有可靠基础。
常见问题
评分表里的实现成本和风险项，为什么分数越高代表越有利？
这是为了统一计算方向。业务价值、用户覆盖、紧急程度三项天然是分数越高越优先；实现成本与风险依赖如果按“成本越高分越高”打分，加权公式里就要对这两项做反向处理，填写时容易出错。把口径统一为“分数越高越有利”，即成本很低打5分、成本很高打1分，五项得分直接乘权重求和即可，公式只有一条。
代价是打分人需要先转换一次判断。可以在评分标准描述里直接写出参照，例如“1分=成本很高；3分=中等；5分=成本很低”，减少理解偏差。
团队刚开始用评分表，权重和分档阈值应该先定多少？
可以先采用通用起点：价值类合计约60%–70%，成本与风险类约30%–40%；分档阈值用≥4.0为P0、3.0–3.9为P1、2.0–2.9为P2、低于2.0为P3。这个起点的作用是让第一轮评审有统一依据，不代表长期最优。
运行一到两个评审周期后，用已定级需求的实际分布检验：如果某一档长期没有需求落入，或大量需求挤在同一档，说明阈值与评分口径不匹配，应同时检查评分标准和权重，而不是只挪阈值。调整幅度大时分步实施，保留一个评审周期观察。
一票升级条件和加权总分冲突时，以哪个为准？
以一票升级条件为准，但要在表中记录具体依据和审批人。一票条件处理的是总分无法反映的情形，例如合规要求、安全事件、重大客户合同承诺，这类需求即使加权总分落在P2，也应提升至P0或P1。
为了让这条规则可执行，一票条件宜少而明确，每条写清触发情形和审批人；未命中时在字段中填“无”，避免留空导致无法判断是未检查还是未触发。对应的一票降级条件同理，例如依赖的外部系统已确定下线。
需求信息不全时，是先评分还是先退回补充？
按字段对结果的影响分两类处理。影响计算的字段，包括五项评分、各项权重、加权总分和优先级等级，必须补齐后才能定级，任一项空缺则总分无效；基本信息中的需求编号、名称、提出人、目标用户、提交日期缺失时，退回提出人补充，暂不排入评审议程。
只影响追溯的字段，如关联业务目标、评审人，允许评审后补充。条件必填项由评审主持人在会前检查触发情形：涉及合规、安全或重大客户承诺时须写明依据，风险与依赖打1–2分时须写明具体风险或依赖对象，实现成本打1–2分时须注明估算依据。
评分表放在文档里还是放进需求管理工具，怎么选？
两种承载方式解决不同问题，可以并用。文档适合存放模板本体、评分口径说明和评审记录，便于统一版本和传阅；需求管理工具适合承载逐条需求的评分字段、加权总分和评审状态，让评分结果与需求条目放在一起，排序和筛选更直接。
常见做法是在文档中定稿模板，再把评分项配置为工具中的字段，评审结论对应到需求状态。ONES Wiki 的页面模板库可用于存放评分表模板与评审记录，ONES 的需求管理支持工作项字段配置与状态流转；具体字段配置方式以团队实际使用的产品版本为准。
