需求优先级排序

---
name: 需求优先级排序
description: >
  输入需求列表，用RICE/ICE/MoSCoW/Kano模型辅助排序，输出优先级矩阵和Sprint规划建议。
  内置框架选择决策树——根据数据充分度和决策场景自动推荐最适合的排序框架。
  连接~~Notion后可将排序决策记录写入团队知识库。
  当用户说"需求排序"、"优先级"、"RICE"、"ICE"、"需求排期"、"MoSCoW"、"排backlog"、
  "sprint规划"、"需求取舍"、"迭代规划"、"backlog排序"、"需求评估"时触发。
argument-hint: "输入需求列表，如：1.用户评价功能 2.商品推荐 3.订单导出 4.会员等级"
name_en: "requirement-prioritization"
description_en: >
  Enter a list of requirements and prioritize them using RICE, ICE, MoSCoW, or KANO models. Outputs
  a priority matrix and sprint planning recommendations. Built-in framework selection decision tree
  -- automatically recommends the best-fit framework based on data availability and the decision
  context. When connected to ~~Notion the prioritization decision log is written directly into the
  team wiki. Trigger when the user says "prioritize requirements", "prioritization", "RICE", "ICE",
  "MoSCoW", "backlog prioritization", "sprint planning", "requirement ranking", "backlog grooming",
  "iteration planning", "requirement trade-offs", "rank requirements", "prioritize backlog".
---

# 需求优先级排序

使用结构化框架对需求进行优先级排序。内置框架选择决策树——RICE适合有数据的量化决策，MoSCoW适合快速对齐，Kano适合功能分类。输出透明可追溯的排序结果和Sprint规划建议。

## 跨技能联动

本技能可与其他产品管理技能联动使用。典型工作流：先用 `/用户反馈分析` 收集痛点 → 用 `/竞品分析` 评估市场机会 → 用 `/PRD生成` 编写需求文档 → 最后用本技能（`/需求优先级排序`）对需求池进行排序。

联动场景示例：
- 从 `/用户反馈分析` 的 Top 10 痛点直接导入为待排序需求
- 从 `/竞品分析` 的"追平层"功能清单导入为待排序需求
- 排序完成后，高优先级需求流转到 `/PRD生成` 撰写详细需求文档
- 从 `/产品脑暴` 输出的创意清单导入为待评估需求

## 工作方式

**独立能力（无需连接器）**

- 4种排序框架（RICE/ICE/MoSCoW/Kano）自动推荐
- 透明评分 + 可追溯依据
- 四象限图 + Sprint规划建议
- 决策记录（核心取舍 + 争议标注）

**增强能力（连接器加持）**

- ~~Notion → 排序决策记录写入团队知识库，支持持续更新

## 连接器（可选增强）

| 连接器 | 增强能力 |
|--------|---------|
| **Notion** | 排序决策记录写入团队知识库，保留决策可追溯性 |

> 没有连接器也完全可以使用。

## 输入要求

| 字段 | 必填 | 说明 |
|------|------|------|
| 需求列表 | 是 | 需求名称+简要描述，至少3个。可直接引用 `/用户反馈分析` 的痛点排序结果或 `/PRD生成` 的需求列表作为输入 |
| 排序框架 | 否 | RICE/ICE/MoSCoW/Kano，未指定则自动推荐 |
| 业务目标 | 否 | 当前核心目标（增长/留存/营收/效率），影响权重分配 |
| 资源约束 | 否 | 本Sprint/季度可用的开发资源（人天或Story Points） |

## 执行流程

### 第一步：框架选择

如果用户未指定框架，按以下逻辑推荐：

**框架选择决策表**：

| 条件 | 推荐框架 | 理由 |
|------|---------|------|
| 有各需求的用户影响数据（DAU、转化率等），且数据可信 | **RICE** | 最量化、最可追溯 |
| 有一定感知但缺乏精确数据 | **ICE** | 快速打分，容忍主观性 |
| 需要快速分四档对齐优先级（适合团队会议） | **MoSCoW** | 逼出"必须做"和"不做"的共识 |
| 需要理解需求性质，做功能规划 | **Kano** | 识别哪些功能能制造惊喜 |

**四种框架对比**：

| 框架 | 适用场景 | 核心优势 | 核心局限 | 耗时 |
|------|---------|---------|---------|------|
| **RICE** | 有数据支撑的季度规划 | 最客观，可横向对比 | 依赖数据质量 | 中 |
| **ICE** | 快速决策、头脑风暴 | 简单快速 | 高度主观 | 低 |
| **MoSCoW** | 版本规划、利益相关方对齐 | 逼出共识 | 容易全归Must Have | 低 |
| **Kano** | 功能规划、用户满意度研究 | 识别惊喜功能 | 需用户调研数据 | 高 |

### 第二步：需求评估

**RICE 框架（默认）**：

| 维度 | 含义 | 打分标准 | 常见错误 |
|------|------|---------|---------|
| **R**each | 一个周期内影响的用户数 | 填具体数字（如"月影响5000人"） | 把"理论上所有用户"当作Reach |
| **I**mpact | 对单个用户的影响程度 | 3=巨大/2=高/1=中/0.5=低/0.25=极低 | 所有需求都打3分（过于乐观） |
| **C**onfidence | 估算的信心程度 | 100%=有数据/80%=间接证据/50%=直觉 | 没数据也打100% |
| **E**ffort | 所有人的总工作量（人月） | 含设计+开发+测试+联调 | 只算开发不算测试和联调 |

**RICE Score = (R x I x C) / E**，分数越高优先级越高。

**评分校准机制**：
- 先对所有需求的同一维度集中打分（如先打完所有R，再打所有I），避免逐个需求打分导致的锚定偏差
- R值校准：选一个基准需求（如"登录功能"影响所有用户），其他需求与之对比
- I值校准：不允许超过50%的需求打3分，强制拉开差异
- E值校准：必须包含设计(20%)+开发(50%)+测试(20%)+联调(10%)全链路

**ICE 框架（快速版）**：

每项1-10分打分，ICE Score = I x C x E / 10

| 维度 | 打分标准 |
|------|---------|
| **I**mpact（影响） | 1=几乎无影响，5=中等，10=根本性改变 |
| **C**onfidence（信心） | 1=纯猜测，5=有间接证据，10=有A/B测试数据 |
| **E**ase（容易度） | 1=极难（>3个月），5=中等（2-4周），10=极易（<1天） |

**MoSCoW 框架**：

| 分类 | 判断标准 | 占比建议 |
|------|---------|---------|
| **Must Have** | 没有就不能上线，砍了用户无法使用核心功能 | <=60% |
| **Should Have** | 重要但有workaround，延期一个Sprint不会致命 | ~20% |
| **Could Have** | 锦上添花，有了更好，没有也行 | ~10% |
| **Won't Have (this time)** | 明确不做，但未来可能做 | ~10% |

> **常见陷阱**：所有需求都被归为Must Have。对策：限定Must Have不超过总需求的60%，逼出取舍。

**Kano 模型**：

| 需求类型 | 特征 | 识别方法 | 产品策略 |
|---------|------|---------|---------|
| **基本型（Must-be）** | 没有会不满，有了觉得理所当然 | 用户不主动提，但缺失会差评 | 必须做到及格线，但不值得过度投入 |
| **期望型（One-dimensional）** | 做得越好满意度越高，线性关系 | 用户主动提的需求多属于此类 | 核心竞争力，做到行业前列 |
| **兴奋型（Attractive）** | 没有不会不满，有了会惊喜 | 用户想不到但体验到会"Wow" | 差异化亮点，但会随时间退化为期望型 |
| **无差异型（Indifferent）** | 有没有都无所谓 | 用户对此无反应 | 不投入 |
| **反向型（Reverse）** | 做了反而降低满意度 | 增加复杂度、打扰用户 | 立即移除 |

**Kano退化定律**：今天的兴奋型需求，2-3年后会退化为期望型甚至基本型（如手机指纹解锁从兴奋变基本）。所以必须持续创造新的兴奋型功能。

### 第三步：排序输出

**RICE排序结果表**：

| 排名 | 需求 | R(触达) | I(影响) | C(信心) | E(工作量) | RICE Score | 建议 |
|-----|------|---------|---------|---------|----------|-----------|------|
| 1 | {需求名} | {数字} | {0.25-3} | {50-100%} | {人月} | {分数} | 本期必做 |

**四象限分析（影响 x 工作量）**：

| 象限 | 影响 | 工作量 | 策略 | 需求列表 |
|------|------|--------|------|---------|
| **Quick Wins** | 高 | 低 | 优先做 | {列表} |
| **Strategic** | 高 | 高 | 规划做 | {列表} |
| **Fill-ins** | 低 | 低 | 有空就做 | {列表} |
| **Avoid** | 低 | 高 | 不做 | {列表} |

**Sprint规划建议**：
- 按资源约束分配需求到Sprint
- Quick Wins优先填入，Strategic按Score排序分配
- 每个Sprint留10-20%缓冲应对突发需求

### 第四步：决策记录

输出排序决策记录：
- **核心取舍**：本期选了A不选B的原因是什么
- **争议需求**：哪些需求的排序可能有争议，争议点是什么
- **信心标注**：哪些评分的信心较低（C<80%），建议做什么来验证
- **下期候选**：本期Won't Have中，下期最可能晋升的需求

### 第五步：写入文档（如已连接）

**如果连接了~~Notion：**
1. 将排序结果和决策记录写入团队知识库

**如果未连接：**
1. 以Markdown格式输出完整排序结果

## 质量标准

1. 评分标准透明——每项评分有一句话依据
2. Effort评估含设计+开发+测试+联调全链路
3. Confidence<80%的需求标注"建议先做小实验验证"
4. Must Have不超过总需求的60%
5. 评分经过校准机制验证，避免锚定偏差

## 红线规则

1. **不替代决策**：排序结果是建议而非决定，最终优先级需团队对齐
2. **不隐藏假设**：所有评分的假设前提必须显式标注
3. **不忽略Effort**：禁止只看Impact不看Effort就推荐"必做"

## 输入不足处理

- **需求列表不足3个**：仍然排序，但提醒"样本过少，建议补充更多需求"
- **缺乏数据**：自动切换到ICE或MoSCoW，标注"因缺乏量化数据，使用定性排序框架"
- **未指定业务目标**：按通用权重排序，建议用户补充以获得更精准结果

## 相关技能

- `/用户故事拆解`：排序完成后，高优先级需求 → 拆解为User Story
- `/PRD生成`：排序确认后，Must Have需求 → 写PRD