marsloting RICE / 优先级评分
何时触发
- 用户 列出 ≥ 3 个待办 / 想法 / 实验 / 需求要排序
- "这个先做还是那个先做"类二选一以上
- "这个值不值得做" / "这个需求该不该接"
- backlog grooming / sprint planning 准备阶段
- 老板列了一堆"都很重要"的东西要消化
- 多个团队抢资源时的仲裁需求
何时不触发
- 单一选项是否做 → 用 pre-mortem 做正反推演
- 已有明确数据驱动的 A/B 实验排序 → 用 gtm-ops:growth-engine
- 紧急 hot fix 不需要评分（救火不是优先级问题）
默认框架：RICE（最常用）
RICE Score = (Reach × Impact × Confidence) / Effort
| 维度 | 含义 | 单位 / 范围 |
|---|---|---|
| Reach | 一个时间窗口内会被影响的用户数 | 具体数字（每月触达人数） |
| Impact | 命中后单用户的影响程度 | 3 = 大量影响 / 2 = 高 / 1 = 中 / 0.5 = 低 / 0.25 = 极低 |
| Confidence | 你对前三项估计的自信度 | 100% 高 / 80% 中 / 50% 低 / < 50% 不要做 |
| Effort | 团队投入（person-month） | 具体数字 |
输出：每个候选项一个 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 步标准流程
- 列候选：把所有要排序的项列清单（写下来，不在脑里）
- 选框架：默认 RICE。没 reach 数据 → ICE。跨 epic → WSJF。MVP 范围 → MoSCoW
- 维度评分：每个项每个维度写具体数字 / 等级，不允许"高/中/低"模糊填
- 算分排序：算出 RICE/ICE/WSJF 分数，降序排列。MoSCoW 直接归类
- 审视 Confidence：所有 Confidence < 80% 的项标"⚠️ 假设需验证"，列具体要验证什么
- 二级决策：分数前 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
| 逃逸路径 | 为什么不行 |
|---|---|
| "凭直觉排个序就行了" | 直觉排序 = 隐藏的"我觉得"。强迫维度拆分会暴露被低估 / 高估的假设 |
| "Reach 没数据就跳过 RICE" | 没 reach 数据用 ICE。完全跳过评分 = 回到 gut-feel = 决策不可追溯 |
| "Confidence 全填 80%" | 80% 是默认偷懒值。必须按具体维度想：reach 数据可信度？impact 估算可信度？effort 估算可信度？三者同 80% 概率极低 |
| "Effort 估不准就不估" | 估不准也要估。估错可调整，不估整张表就废了 |
| "排出来分高的不是我想做的，那 RICE 是错的" | RICE 没错，是你想做的项假设没列清。回 step 5 把"我想做"的真实理由列出来——可能是战略 / 个人偏好 / 老板压力——这些是另外的输入维度，不该让 RICE 背锅 |
| "Impact 全打 3 反映这些都很重要" | Impact = 3 上限是 20% 候选项。全 3 = 没认真区分 = 评分失效 |
| "MoSCoW 比 RICE 简单先用 MoSCoW" | MoSCoW 是 MVP 范围工具不是优先级工具。Must have 之间还要 RICE 排，Could have 也要 RICE 评。框架场景不同 |
关联
- 评分完后下一步：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 首发。