RICE / 优先级评分

何时触发

• 用户 列出 ≥ 3 个待办 / 想法 / 实验 / 需求要排序
• "这个先做还是那个先做"类二选一以上
• "这个值不值得做" / "这个需求该不该接"
• backlog grooming / sprint planning 准备阶段
• 老板列了一堆"都很重要"的东西要消化
• 多个团队抢资源时的仲裁需求

何时不触发

• 单一选项是否做 → 用 pre-mortem 做正反推演
• 已有明确数据驱动的 A/B 实验排序 → 用 gtm-ops:growth-engine
• 紧急 hot fix 不需要评分（救火不是优先级问题）

默认框架：RICE（最常用）

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

输出：每个候选项一个 RICE 分数，按分数降序排列。不允许只看分数，必须列出 Confidence < 80% 的项哪些假设需要验证。

备选框架（按场景挑）

ICE（轻量版，没 Reach 数据时用）

ICE Score = Impact × Confidence × Ease

适合早期阶段、没 reach 数据、需要快速排序。

WSJF（SAFe 框架，跨团队多 epic 时用）

WSJF = Cost of Delay / Job Size
Cost of Delay = Business Value + Time Criticality + Risk Reduction / Opportunity

适合多 epic 跨团队竞争资源、季度规划、年度路线图。

MoSCoW（产品阶段定义时用）

• Must have：核心价值，没它产品不成立
• Should have：重要但不致命
• Could have：锦上添花
• Won't have（this time）：明确 kill

适合 MVP 范围定义、版本边界划定。

6 步标准流程

1. 列候选：把所有要排序的项列清单（写下来，不在脑里）
2. 选框架：默认 RICE。没 reach 数据 → ICE。跨 epic → WSJF。MVP 范围 → MoSCoW
3. 维度评分：每个项每个维度写具体数字 / 等级，不允许"高/中/低"模糊填
4. 算分排序：算出 RICE/ICE/WSJF 分数，降序排列。MoSCoW 直接归类
5. 审视 Confidence：所有 Confidence < 80% 的项标"⚠️ 假设需验证"，列具体要验证什么
6. 二级决策：分数前 30% 进 do-list；中段 30% 标"等条件"；后 30% 标 kill 或归档

小红线

• 不接受全 100% Confidence：意味着没人在认真估
• 不接受 Reach = 1：单用户级需求要么是 Tier A 战略合作（直接走例外通道），要么不该上 backlog
• Effort 估错优于不估：先填一个数后续调整 > 留空导致整个 RICE 算不出
• Impact = 3 不超过 20%："大量影响"是稀缺信号，不能稀释

模板（Markdown 表格）

| 项目 | Reach | Impact | Confidence | Effort | RICE 分 | 假设需验证 |
|---|---|---|---|---|---|---|
| <项目 1> | 5000/月 | 2 | 80% | 2 | 4000 | - |
| <项目 2> | 1000/月 | 3 | 50% ⚠️ | 1 | 1500 | "用户真的会用"未验证 |
| <项目 3> | 10000/月 | 1 | 100% | 3 | 3333 | - |

排序后给：top 3 do-list / 中段 hold-list / 底部 kill-list。

Anti-Rationalization

关联

• 评分完后下一步：do-list 项进 story-splitting 拆故事 → pre-mortem 失败推演
• 假设需验证项进 gtm-ops:growth-engine 设 A/B 验证
• 大型 epic 用 WSJF 后再往下拆 sprint → product-management:sprint-planning

Status

v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。