RICE优先级评分把覆盖人数、影响程度、置信度和投入放在一起比较：分数＝覆盖人数×影响程度×置信度÷投入。真正决定排序质量的，是候选需求是否使用同一时间窗、同一种覆盖对象和同一套工作量口径。口径没对齐时，算到小数点后两位也不会让决定更可靠。
产品评审时，可以在墨刀白板上整理需求与评分依据：每张需求卡同时放数据来源、关键假设和投入估算，把争论落到某一项参数，再决定先做、先调研还是暂缓。
RICE在回答什么问题
RICE适合在多个可选改进之间比较“有限投入先放在哪里”。它不能直接替团队回答产品方向是否正确，也不适合把安全修复、合同承诺、基础依赖和体验优化全部混成一张排行榜。前两类可能有明确期限，基础依赖则可能必须先完成。
Intercom介绍的RICE方法使用Reach、Impact、Confidence、Effort四个因素，并提醒团队不要机械按分数执行。分数应帮助团队解释取舍；它本身不是需求获准排期的凭证。
如果还不清楚用户在意什么，可先通过KANO模型区分需求对满意度的影响。KANO提供需求性质的线索，RICE帮助比较投入顺序，两者的分值不能直接相加。
先定三条口径，再给需求打分
覆盖人数必须来自同一个时间窗
假设评估的是下一个月的客户服务后台改进，就统一计算“一个月内实际会遇到该功能的客服人数”。不能把A需求的月活人数、B需求的每年订单量和C需求的页面访问次数放在同一列。
重复操作也要讲清楚。一个客服每天搜索20次，不等于覆盖20个人。若本次明确以“受影响工单数”为单位，所有候选都应改成工单口径，而不是在某个项目上临时放大数字。覆盖对象应跟本次目标一致，例如减少客服处理负担，就优先考虑实际处理者与任务发生频次的关系。
影响程度围绕同一个目标解释
“影响大”要能接着回答“对什么影响大”。提高首次任务完成率与减少资深用户操作时间是不同目标，不能只用一个模糊的“体验提升”打分。团队可采用简明等级，但必须给每一档写一句判断依据。
- 较高影响：主要任务在当前流程中经常被阻断，方案直接消除这一阻断。
- 中等影响：任务能够完成，方案减少明显的重复操作或理解成本。
- 较小影响：局部便利性或视觉改善，对本次目标的作用有限。
这些是评审时可用的描述，具体数字由团队统一约定。不要因为方案技术新颖，便把它的影响程度评得更高。
投入要包含完整交付成本
只填开发编码时间，会让需要大量规则确认、历史数据处理或培训的需求显得异常划算。至少把产品确认、设计、开发、测试和上线准备纳入同一估算范围，再统一换算为人周或人月。
还要区分工作量和历时：两位工程师各投入一周是两个人周，即使日历只过去一周。等待第三方审批不一定增加同等工作量，却会改变能否在目标时间窗交付，因此应另记为排期约束。
三项后台改进，怎样从数字走到决定
下面用一组练习数据演示计算。目标是改善下月客服处理工单的体验，覆盖人数按月计算，投入统一用人周。
| 候选改进 | 覆盖R | 影响I | 置信度C | 投入E | RICE分数 |
|---|---|---|---|---|---|
| A：保存常用筛选 | 240人 | 1 | 0.8 | 2人周 | 96 |
| B：批量指派工单 | 100人 | 2 | 0.8 | 2人周 | 80 |
| C：智能摘要入口 | 300人 | 1 | 0.5 | 3人周 | 50 |
A的计算为240×1×0.8÷2＝96。C虽然覆盖人数最多，但影响依据较弱且投入较高，所以初始分数较低。这里的0.8和0.5表示团队对估算的信心等级，不表示项目有80%或50%的成功概率。
下一步不是把A、B、C直接拖进日历，而是查看最可能改变排序的参数。若A的权限逻辑比预计复杂，投入从2人周变成4人周，分数便降至48，B就超过了A。这个差异告诉团队：先用一次针对性的技术讨论核实A的投入，比继续争论96和80哪个更有“战略价值”更有用。
在白板上保留分数背后的证据
建一张评分白板时，建议分成“候选需求”“依据与未知”“决定”三个区域。每张卡保留稳定编号，数字调整后仍能追踪到原来的讨论，避免同一项需求被换个名字重复计算。
- 在候选区写清用户、任务和具体变化，例如“客服把当前筛选条件保存为个人常用视图”，不要只写“优化筛选”。
- 把覆盖人数的统计区间、影响判断依据和工作量拆分放在相邻卡片上。证据可以是脱敏数据、访谈摘要或研发估算说明。
- 对缺少依据的参数添加待确认问题，例如“240人是否包含只查看、不处理工单的主管”。未知项保留为未知，不用高分掩盖。
- 计算分数后，分别标记“进入细化”“先补资料”“受前置条件限制”。讨论结果和原始分数同时保留。
这张白板不必承担复杂计算。可以在表格中算分，把公式和结果贴回需求卡；白板更适合展示“哪一份证据支撑哪个数字”。多人评论时直接围绕这张卡讨论，避免结论散落在不同聊天记录里。
高分需求为什么还可能晚做
若批量指派必须等角色权限改造完成，就算它得分最高，也无法跳过前置工作。应将前置项和受益项连起来，并在排期时考虑整组投入。具体依赖可继续用需求依赖关系图梳理。
另一个常见情况是小群体的严重问题。只有少量管理员遇到结算阻断，按覆盖人数算可能不如一个常用按钮改进，但严重后果和明确期限不能被平均分稀释。把必须处理的事项单独列出，再对可选改进使用RICE，决策会更清楚。
最后，不要把一次评分当作永久标签。覆盖对象变了、成本估算更新了或试用结果与预期不同，都应重新计算。记录变化原因，比只保留最新数字更有价值。
可以直接复制的需求评分卡
需求编号与名称：
本次要改善的用户任务：
评估时间窗与覆盖单位：
R：预计覆盖量；统计来源；是否去重
I：影响等级；对应的具体障碍
C：估算信心；目前最缺的依据
E：产品、设计、研发、测试等总投入
前置依赖与不可错过的期限：
哪一个参数改变会使排序反转：
本轮决定：进入细化 / 先补资料 / 暂缓
负责人及下次重看时间：第一次使用时，从三到五个正在争议的需求开始，把卡片放到同一张白板上。先解决“我们是否在比较同一种东西”，再决定先做哪一个，RICE才会成为沟通工具，而不是给既定答案补一张分数表。
