第2章 RICE框架概述：从优先级困境到量化决策

用户场景：产品经理的优先级困境

每个 sprint 周期开始前，产品经理小张的桌面总会堆满来自不同渠道的需求：用户反馈群里的高频吐槽、销售团队签单需要的关键功能、技术团队的架构升级提案、运营团队的活动支持请求。团队评审会上，每个人都认为自己的需求“最重要”，但 sprint 容量只有 4 周 120 人天。

小张尝试用直觉排序，结果上线后核心指标没有变化；尝试按客户等级排列，又被技术负责人质疑投入产出比。团队需要一个统一、可量化、可沟通的优先级标尺。

业务问题：主观判断的局限性

传统的优先级方法——如 MoSCoW、Kano 模型、单纯 ROI 计算——在实战中暴露三个共性问题：

需求拆解：RICE 四维度的定义与量化

RICE 由 Intercom 产品团队提出，四个字母分别代表一次需求评估必须回答的四个问题：

RICE 的最终分数通过一个简单乘法除法公式得出：

RICE Score = (Reach × Impact × Confidence) / Effort

分数越高，代表单位投入带来的综合价值越大，优先级就越高。

方案表达：在 PRD 中嵌入 RICE 评分表

将 RICE 直接写进 PRD 的「优先级标注」区域，代替模糊的“P0 / P1 / P2”。推荐在 PRD 正文后附一张标准评分表，使每个需求的价值构成完全透明：

指标验证：如何判断 RICE 评分是否可靠

RICE 的输出质量取决于输入的准确性。四个自我校验问题可以帮助团队提前发现偏差：

• Reach 校准：预估用户数是否与历史同类功能上线后的实际触达数在同一量级？差异超过 2 倍就需要重新核定。
• Impact 对齐：1–5 分是否对应了明确的业务指标？例如 Impact=4 必须是“预期提升核心转化率 ≥ 5%”，避免“感觉上很重要”。
• Confidence 分级：建议建立证据等级映射——有完整 A/B 实验数据 = 100%，有用户访谈 + 行业报告 = 80%，只有内部推测 = 40% 或更低。
• Effort 审计：是否包含了设计 review、跨团队联调、测试回归和文档撰写？遗漏隐性成本会导致分数虚高。

验收标准：一份合格 RICE 标注的检查清单

在 PRD 评审前，用以下清单逐一核对每个需求的 RICE 标注完整性：

交付物模板：标准 RICE 评分卡

下面的评分卡模板可以直接复制到 PRD 的交付物章节中，作为每个需求的标准化附录。填写时保持四维度口径一致，分数由公式自动计算。