# 需求优先级排序

> 输入需求列表，用RICE/ICE/MoSCoW/Kano模型辅助排序，输出优先级矩阵和Sprint规划建议。 内置框架选择决策树——根据数据充分度和决策场景自动推荐最适合的排序框架。 连接~~Notion后可将排序决策记录写入团队知识库。 当用户说"需求排序"、"优先级"、"RICE"、"ICE"、"需求排期"、"MoSCoW"、"排backlog"、 "sprint规划"、"需求取舍"、"迭代规划"、"backlog排序"、"需求评估"时触发。

- Skill: `ahang1598/skill-82` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ahang1598/skill-82`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/skill-82/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ahang1598/skill-82

---


# 需求优先级排序

使用结构化框架对需求进行优先级排序。内置框架选择决策树——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