需求优先级评分表的判定规则，核心是让不同评审人按同一张表打分后得到一致的排序结果。规则通常由四层组成：每个字段的取值档位与分值、权重与加权总分计算、总分到优先级等级的映射、以及一票否决和复核调整等例外条款。本文按这四层给出可填写的写法、对照表和一条完整示例，适用于需要定期评审需求池的产品与研发团队。
要点总览（TL;DR）
- 判定规则由四层组成：字段取值档位与分值、权重与加权总分计算、总分到优先级等级的映射、例外规则，四层写在同一份文档中。
- 档位描述要写成可观察的事实，例如“覆盖全部活跃用户记5分”，成本类字段采用反向计分，让高分统一代表高优先级。
- 权重总和归一为100%，加权公式、保留位数和四舍五入规则唯一确定，避免不同评审人算出不同总分。
- 总分区间左闭右开、首尾相接，边界值归属写明；同分按战略契合、业务价值、实现成本的固定顺序比较。
- 一票否决、强制升级与复核调整要写明触发条件、裁定权限和留痕要求，发布前用历史需求试打分验证一致性。
判定规则的核心结构与写法
判定规则要写成可逐条执行的判断语句，而不是原则性描述。评审人拿到规则后，应当只需对照需求事实选择档位、填入分值，就能算出总分并查到等级，中间不留下需要主观解释的空间。四层结构各自承担不同的回答任务。
| 层级 | 回答的问题 | 典型写作句式 | 产出物 |
|---|---|---|---|
| 字段取值档位 | 这个字段打几分 | “当需求满足……时，记N分” | 字段档位分值表 |
| 权重与计分 | 各项分值如何合成总分 | “总分＝Σ（字段得分×权重），保留一位小数” | 权重表与计算公式 |
| 总分到等级映射 | 这个总分对应哪个优先级 | “总分≥85记为P0；80≤总分＜85记为P1” | 区间映射表 |
| 例外规则 | 常规打分之外如何处理 | “出现……情形时，直接定为P0，无需计算总分” | 例外条款清单 |
组织方式上，建议把字段定义、档位分值、权重、计算公式、区间映射放在同一份文档的连续章节中，例外规则紧随其后。评审人打开一份文档即可完成全部判断，避免在多个文件之间来回查找造成口径漂移。文档需要标注版本号和生效日期，每次调整档位或权重都升版并记录变更原因。
字段取值档位与评分标准怎么写
档位描述要写成评审人可以直接观察和核对的事实，例如“影响全部付费客户的核心下单流程”，而不是“价值较高”“影响一般”这类需要二次解释的表述。判断标准是：两位评审人看到同一条需求，能独立选出同一个档位。
价值类字段的档位划分
业务价值、用户覆盖、战略契合这类字段，适合按影响范围和影响程度两个维度组合成档位。档位数量建议控制在3到5档，档位过多会增加判断成本，过少则区分度不足。
| 字段 | 档位描述（可观察） | 分值 |
|---|---|---|
| 业务价值 | 直接影响核心收入流程，或对应已承诺的合同交付 | 5 |
| 业务价值 | 影响关键业务环节效率，有明确的可量化收益 | 4 |
| 业务价值 | 改善部分用户的日常操作体验，收益需上线后观察 | 2 |
| 业务价值 | 锦上添花型优化，无明确业务指标关联 | 1 |
| 用户覆盖 | 覆盖全部活跃用户 | 5 |
| 用户覆盖 | 覆盖某一类角色或某一行业客户群体 | 3 |
| 用户覆盖 | 覆盖个别客户或内部少数使用者 | 1 |
| 战略契合 | 直接支撑本年度既定战略方向 | 5 |
| 战略契合 | 与战略方向相关但非当前重点 | 2 |
| 战略契合 | 与当前战略无直接关联 | 1 |
成本与风险类字段的档位划分
实现成本、技术风险、依赖程度这类字段，档位要绑定可核对的估算依据，例如人天区间、是否涉及外部系统改造、是否依赖尚未就绪的上游能力。成本类字段需要统一分值方向：要么高分代表成本高并在公式中取负向，要么直接反向定义分值，让高分代表“成本低、更易做”。后一种做法更不容易在计算时出错，推荐采用。
| 字段 | 档位描述（可观察） | 分值 |
|---|---|---|
| 实现成本（反向计分） | 估算≤5人天，无需跨团队协作 | 5 |
| 实现成本（反向计分） | 估算6–15人天，单团队可完成 | 3 |
| 实现成本（反向计分） | 估算超过15人天，或需两个以上团队配合 | 1 |
| 技术风险（反向计分） | 方案成熟，团队有同类实现经验 | 5 |
| 技术风险（反向计分） | 存在技术不确定点，需先做验证 | 3 |
| 技术风险（反向计分） | 依赖未验证的新技术或外部系统改造 | 1 |
| 依赖程度（反向计分） | 无外部依赖，可独立排期 | 5 |
| 依赖程度（反向计分） | 依赖其他需求的交付结果 | 3 |
| 依赖程度（反向计分） | 依赖外部合作方或合规审批 | 1 |
档位数量与分值跨度的取舍取决于字段的区分需求。需要精细排序的价值字段可用5档，成本类字段用3档通常足够，因为估算本身存在误差，档位过细会制造虚假精度。分值跨度建议保持等差或接近等差，便于评审人理解权重叠加后的效果。
权重设置与加权总分计算规则
权重表达的是当前阶段各字段的相对重要程度，应与团队本阶段的明确目标对应。例如本阶段以拓展新客户为主，用户覆盖和战略契合的权重可以调高；本阶段以稳定交付为主，技术风险和依赖程度的权重相应提高。权重调整属于规则变更，需要走版本记录。
| 字段 | 权重 | 说明 |
|---|---|---|
| 业务价值 | 30% | 核心判断依据 |
| 用户覆盖 | 20% | 反映影响面 |
| 战略契合 | 20% | 对齐阶段目标 |
| 实现成本 | 15% | 反向计分 |
| 技术风险 | 10% | 反向计分 |
| 依赖程度 | 5% | 反向计分 |
| 合计 | 100% | 权重总和必须归一 |
加权总分公式写成：总分＝业务价值得分×30%＋用户覆盖得分×20%＋战略契合得分×20%＋实现成本得分×15%＋技术风险得分×10%＋依赖程度得分×5%。由于各字段满分均为5分，总分区间为1到5分。若希望总分落在百分制区间，可在公式末尾乘以20，并在规则中明确写出这一步，避免不同评审人自行换算。
四舍五入规则要唯一确定：统一保留一位小数，采用四舍五入，并在映射表中使用一位小数的边界值。所有字段的分值方向必须统一为高分代表高优先级，成本类字段通过反向档位实现这一点，公式中不再出现减号，减少计算错误。
分数到优先级等级的判定规则
总分算出后，需要一张区间映射表把分数转成可直接落到需求条目上的等级。区间必须首尾相接、不重叠、不留空档，边界值的归属在表中明确写出。
| 总分区间 | 优先级等级 | 处理约定 |
|---|---|---|
| 4.5 ≤ 总分 ≤ 5.0 | P0 | 进入当前迭代候选，优先排期 |
| 3.5 ≤ 总分 ＜ 4.5 | P1 | 纳入近期规划，按容量安排 |
| 2.5 ≤ 总分 ＜ 3.5 | P2 | 进入需求池，定期复评 |
| 1.0 ≤ 总分 ＜ 2.5 | P3 | 暂缓，记录保留 |
边界值归属采用“左闭右开”写法，即区间包含下限、不包含上限，最高档包含上限。这样任何总分都只落入一个区间，不会出现两个等级同时成立的情况。
同分时的平局处理需要预设顺序，常见做法是依次比较：战略契合得分高者优先；战略契合相同则业务价值高者优先；仍相同则实现成本得分高者优先，即成本更低者先做。平局规则要写成固定顺序，评审会上直接执行，不临时协商。
等级数量应与团队的实际处理能力匹配。如果团队每个迭代只能稳定承接少量P0需求，等级划分过细会导致大量需求堆积在同一档而失去排序意义；等级过少则无法区分中段需求。可以先用历史需求试算分布，再确定档位数量。
例外规则：一票否决、强制升级与复核调整
常规打分覆盖不到的情形需要单独写成条款，否则规则会在特殊需求上失效或被人为绕过。例外规则同样要写成可判断的条件句，并明确裁定人和记录方式。
一票否决条件
一票否决用于无论总分多少都必须优先处理的需求，典型条件包括：涉及合规或法律要求的强制整改；存在明确的安全漏洞或数据风险；对应已向重大客户做出的书面交付承诺。写法示例：“当需求涉及监管合规整改且存在明确截止日期时，直接定为P0，不参与加权计算，并在评分表中注明否决依据。”
强制升级与降级
强制升级适用于总分不高但时机关键的需求，例如竞品已上线同类能力、或某需求的交付窗口即将关闭。强制降级适用于总分较高但当前不具备实施条件的需求，例如依赖的上游能力尚未就绪。两类调整都要写明触发条件和调整幅度，例如“最多上调或下调一个等级”。
复核调整的权限与留痕
复核调整应限定在指定角色，例如产品负责人或评审组长，并规定调整必须记录：原总分、调整后等级、调整理由、裁定人和日期。记录随需求条目保存，供后续复盘。例外规则需要设定生效范围和回顾周期，例如每季度检查一次否决条件是否仍然适用，避免条款长期累积后失去约束力。
角色分工、评审流程与规则落地
规则内容确定后，执行效果取决于角色是否清晰、节奏是否固定。建议在规则文档中直接附一张角色职责表。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 需求提出人 | 按字段准备事实依据，填写可观察的影响范围与估算 | 带依据的需求条目 |
| 评审人 | 独立按档位打分，不参考他人分数 | 各字段得分 |
| 优先级裁定人 | 汇总总分、执行区间映射与平局规则、裁定例外调整 | 定级结果与调整记录 |
打分时点建议固定在需求进入评审队列之前，评审会上只核对依据和分歧，不现场重新估算。分歧处理路径为：先核对事实依据是否一致，依据一致而档位选择不同时，由裁定人按档位描述裁定；涉及例外规则的，由裁定人按权限处理并留痕。规则版本与变更记录随文档维护，每次调整权重、档位或区间都记录变更内容和生效日期。
评分表需要承载在团队日常使用的协作工具中，才能保证版本统一和评审留痕。ONES Wiki 支持使用模板库一键创建文档，可将评分表模板固化为标准页面；页面组可关联项目，使需求条目与评分文档互相对应；文档记录所有页面版本并支持查看与回滚，便于追溯规则变更；同时可为不同角色配置读写权限，区分评审人与查看者。规则文档与需求条目分处两地时，评审人容易拿到过期版本，把模板和版本管理放在同一处可以缓解这个问题。
填写示例：一条需求如何按规则定级
以下为演示情景，用于说明规则如何执行，数值为示例设定。
示例需求：为全部付费客户的核心结算流程增加批量导出功能，估算约10人天，单团队可完成，方案成熟，无外部依赖，支撑本年度效率提升方向。
| 字段 | 档位判断 | 得分 | 权重 | 加权分 |
|---|---|---|---|---|
| 业务价值 | 影响核心业务环节效率，收益可量化 | 4 | 30% | 1.2 |
| 用户覆盖 | 覆盖全部活跃用户 | 5 | 20% | 1.0 |
| 战略契合 | 直接支撑本年度战略方向 | 5 | 20% | 1.0 |
| 实现成本 | 6–15人天，单团队可完成 | 3 | 15% | 0.45 |
| 技术风险 | 方案成熟，有同类经验 | 5 | 10% | 0.5 |
| 依赖程度 | 无外部依赖 | 5 | 5% | 0.25 |
| 合计 | — | — | 100% | 4.4 |
总分4.4，落入3.5≤总分＜4.5区间，定为P1，纳入近期规划。若该需求同时对应某重大客户的书面交付承诺，则触发一票否决条款，直接定为P0，并在评分表中记录否决依据和裁定人。这个示例体现的可迁移要点是：每个得分都能回溯到一条档位描述，总分计算过程可复核，例外调整有明确触发条件和记录位置。
完成检查：判定规则是否可用
规则发布前，按以下清单逐项核对，全部通过再投入使用。
- 每个字段的每个档位都有可观察的判定描述，不含“较高”“一般”等模糊词。
- 所有字段分值方向统一为高分代表高优先级，成本类字段已通过反向档位处理。
- 权重总和为100%，加权公式、保留位数和四舍五入规则唯一确定。
- 总分区间首尾相接、不重叠、不留空档，边界值归属已写明。
- 平局处理有固定比较顺序，评审会上可直接执行。
- 一票否决、强制升级与降级均写明触发条件、调整幅度和裁定人。
- 复核调整有权限限定和记录要求，记录随需求条目保存。
- 例外规则有生效范围和回顾周期。
- 已用若干条历史需求组织试打分，不同评审人得出的等级一致或分歧可解释。
- 规则文档标注版本号和生效日期，变更记录完整。
常见问题
评分表刚上线，历史需求没有按字段记录依据，怎么补做试打分？
不必为全部历史需求补齐依据，挑选10到20条近期已排期或已交付的需求即可。由需求提出人按现有信息补填影响范围和估算，评审人独立打分，重点看不同人得出的等级是否一致。分歧集中的字段，说明档位描述还不够可观察，优先修订这些档位，再扩大试打分范围。
团队阶段目标变化后，权重需要跟着调整吗？
权重表达的是当前阶段各字段的相对重要程度，阶段目标变化时可以调整，但要按规则变更处理：记录调整内容、生效日期和原因，并重新试打分确认等级分布合理。频繁调整会让历史评分失去可比性，建议把权重调整与季度或半年度规划节奏对齐，期间保持稳定。
一票否决用得太多，评分表还有意义吗？
一票否决应限定在合规整改、安全风险、重大客户书面承诺等少数情形，并且每次使用都要记录否决依据和裁定人。如果一段时间内否决频繁出现，说明常规字段没有覆盖这类需求的判断维度，可以考虑把相关因素纳入正式字段，而不是继续扩大否决范围。定期回顾否决记录，是判断条款是否仍然适用的直接方式。
多个评审人打分分歧较大时，评审会上怎么处理？
先核对事实依据是否一致，例如影响范围、估算人天是否有共同口径。依据一致而档位选择不同时，由优先级裁定人对照档位描述裁定，并把裁定理由记录在评分表中。依据本身不一致的，退回需求提出人补充材料，不在会上现场重新估算，避免打分变成讨价还价。
评分表放在文档里，怎么保证评审人拿到的都是最新版本？
把评分表模板、档位表、权重表和区间映射放在同一份文档中统一维护，标注版本号和生效日期，每次调整升版并记录变更。ONES Wiki 支持使用模板库一键创建文档，文档记录所有页面版本并支持查看与回滚，可为不同角色配置读写权限，便于评审人取用同一版本并追溯规则变更。
