---
name: feature-prioritization
description: 用 RICE（覆盖面、影响、信心、工作量）给产品 backlog 或需求列表打分，缺少覆盖面数据时用 ICE；每一项都列出计算过程，检验排序对最不可靠的估算有多敏感，按现有产能建议一条截止线，并指出依赖关系。当有人发来 backlog、需求清单或路线图列表，问先做什么、要排优先级、做需求排序或给功能打分时使用。
---

# 需求优先级排序

分数的好坏取决于输入，所以输出要列出每个输入、它的来源，以及最不可靠的估算一旦错了，排序还站不站得住。目标是一条说得清道理的截止线，而不是虚假的精确。

## 适用场景

- 规划周期开始前，手上有 backlog 或候选功能列表。
- 相关方对下一步做什么意见不一，需要一个共同的方法。
- 需求多于产能，需要划一条截止线。
- 不适用于在战略方向差别很大的 2 个选项之间做选择：请写 decision-memo。

## 需要准备

- 需求列表，每项一行描述。
- RICE 需要：覆盖面（每季度的用户数或账户数）、影响、信心、工作量（人周）。某一项缺少输入时问一次；之后自行估算，并标注“[估算]”。
- 这个周期的产能（人周）。缺少时，只排序不划截止线，并说明这一点。
- 可选：这个周期的战略目标、已知的依赖、截止日期。

## 步骤

1. **选 RICE 还是 ICE。** 有使用数据可以估算覆盖面时用 RICE：提出 RICE 的 Intercom 用真实的产品指标，把覆盖面衡量为单位时间内的人数或事件数。覆盖面无法估算时（例如产品上线前，或每一项都覆盖全部用户），用 ICE（影响、信心、容易度，各按 1 到 10 打分后相乘，结果在 1 到 1,000 之间）。说明用了哪个、为什么。
2. **打分前先定好刻度。** 用 Intercom 的刻度。对每个被覆盖者的影响：3 = 巨大，2 = 高，1 = 中，0.5 = 低，0.25 = 极小。信心：100% = 高，80% = 中，50% = 低；低于 50% 的 Intercom 称为“登月项目”（moonshot），这类项目应先做调研，而不是打分。工作量：Intercom 按产品、设计和工程合计的人月计；本技能对短周期的默认值是人周，规则相同。用 ICE 时，在任何人打分前先写下 3 分、6 分、9 分各代表什么，让两个人打的“7 分”是同一个意思。
3. **逐项打分并列出计算过程。** RICE = 覆盖面 × 影响 × 信心 ÷ 工作量，可以理解为单位工作量带来的总影响。每一行都写出带数字的公式，让任何人都能重算。给每个输入标注来源：数据、客户需求或估算。
4. **检验敏感度。** 对排名前 5 的项目，找出信心最低的那个输入，把它减半或翻倍。这项检验是本技能的默认做法，不属于 RICE 本身。如果这样一改项目就掉到截止线以下，标注为“不稳”。截止线附近的不稳项目，承诺之前要快速核实。
5. **梳理依赖。** 如果 B 需要 A，不管 B 分数多高，都不能在 A 之前开始。注明团队以外的阻碍（法务、合作方 API、其他团队）。
6. **划截止线。** 从最高分开始累加工作量，直到达到产能；留出 20% 的产能作为处理 bug 和意外的缓冲（本技能的默认值）。无论分数如何都必须做的项目（法定截止日期、合同承诺）先放到线上，并标注“已承诺”。
7. **给出建议。** 写明做什么、不做什么、哪些不稳，以及最能改变结论的那一个估算。

## 输出格式

```markdown
# 优先级排序：[周期]

**方法：** [RICE 或 ICE] — [原因] · **产能：** [n] 人周（扣除 20% 缓冲后 [n]）

## 排序
| 排名 | 项目 | 覆盖面 | 影响 | 信心 | 工作量 | 得分（计算） | 输入来源 |
|---|---|---|---|---|---|---|---|
| 1 | [项目] | [n] | [n] | [%] | [n] | [R×I×C÷E = 得分] | [数据 / 需求 / 估算] |

**截止线：** 线上合计 = [n] 人周

## 敏感度
- [项目]：如果 [输入] [减半/翻倍]，得分变为 [n] → [仍在线上 / 掉到线下]

## 依赖
- [项目 B] 需要 [项目 A]

## 建议
- **做：** [项目]
- **本周期不做：** [项目]
- **承诺前要核实：** [不稳的项目，以及要核实什么]
- **最关键的估算：** [输入]
```

## 示例

**输入：** 第二季度。产能 10 人周。项目：CSV 导出（覆盖 400 个账户/季度，影响中，有数据，1 周）；自动提醒（覆盖 900 来自数据，影响高是猜测，4 周）；只读席位（覆盖 150 来自客户需求，影响高，有一些依据，2 周）；SSO（覆盖 20，影响巨大，有数据，3 周，已写进签署的合同）。

**输出：**

```markdown
# 优先级排序：第二季度

**方法：** RICE — 所有项目都有使用数据可估算覆盖面 · **产能：** 10 人周（扣除 20% 缓冲后 8）

## 排序
| 排名 | 项目 | 覆盖面 | 影响 | 信心 | 工作量 | 得分（计算） | 输入来源 |
|---|---|---|---|---|---|---|---|
| 1 | CSV 导出 | 400 | 1 | 100% | 1 | 400×1×1.0÷1 = 400 | 数据 |
| 2 | 自动提醒 | 900 | 2 | 50% | 4 | 900×2×0.5÷4 = 225 | 覆盖面：数据；影响：估算 |
| 3 | 只读席位 | 150 | 2 | 80% | 2 | 150×2×0.8÷2 = 120 | 需求 |
| 4 | SSO | 20 | 3 | 100% | 3 | 20×3×1.0÷3 = 20 | 数据 |

**截止线：** SSO（已承诺，3）+ CSV 导出（1）+ 自动提醒（4）= 8 人周

## 敏感度
- 自动提醒：如果影响是 1 而不是 2，得分变为 112.5 → 低于只读席位；只有产能允许时才留在线上。
- CSV 导出：覆盖面减半得 200 → 仍排第 2 或更高。
- 只读席位：覆盖面（来自需求）翻倍到 300，得 240 → 超过自动提醒，进入线上。
- SSO：覆盖面减半到 10，得 10 → 已承诺，不论得分都留在线上。

## 依赖
- 这些项目之间没有依赖。SSO 依赖客户提供身份提供商（IdP）的配置信息 [待确认：收到了吗？]。

## 建议
- **做：** SSO（合同已承诺）、CSV 导出、自动提醒。
- **本周期不做：** 只读席位。
- **承诺前要核实：** 自动提醒不稳；在第 2 周之前访谈 5 位客户，确认影响。只读席位的覆盖面也值得核实。
- **最关键的估算：** 自动提醒的影响。
```

## 发送前检查

- [ ] 每个得分都写出了带数字的公式。
- [ ] 每个输入都标注了数据、需求或估算。
- [ ] 截止线以上的工作量不超过扣除 20% 缓冲后的产能。
- [ ] 已承诺的项目已标注，并且不论分数都放在线上。
- [ ] 前 5 个项目（不足 5 个时为全部）都有一行敏感度说明。
- [ ] 没有出现用户没给、又没标“[估算]”的覆盖面或工作量数字。

## 常见错误

- 把 225 和 210 当成真正的差距。本技能的规则：相差约 20% 以内的分数视为持平；持平时按战略或依赖决定。
- 工作量里漏掉设计和测试，结果小项目全挤到了前面。
- 因为某位相关方意见强烈，就把信心打成 100%。没有数据时最多 50%。