ahang1598 需求优先级排序
使用结构化框架对需求进行优先级排序。内置框架选择决策树——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 框架（默认）：
| 维度 | 含义 | 打分标准 | 常见错误 |
|---|---|---|---|
| Reach | 一个周期内影响的用户数 | 填具体数字（如"月影响5000人"） | 把"理论上所有用户"当作Reach |
| Impact | 对单个用户的影响程度 | 3=巨大/2=高/1=中/0.5=低/0.25=极低 | 所有需求都打3分（过于乐观） |
| Confidence | 估算的信心程度 | 100%=有数据/80%=间接证据/50%=直觉 | 没数据也打100% |
| Effort | 所有人的总工作量（人月） | 含设计+开发+测试+联调 | 只算开发不算测试和联调 |
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
| 维度 | 打分标准 |
|---|---|
| Impact（影响） | 1=几乎无影响，5=中等，10=根本性改变 |
| Confidence（信心） | 1=纯猜测，5=有间接证据，10=有A/B测试数据 |
| Ease（容易度） | 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：
- 将排序结果和决策记录写入团队知识库
如果未连接：
- 以Markdown格式输出完整排序结果
质量标准
- 评分标准透明——每项评分有一句话依据
- Effort评估含设计+开发+测试+联调全链路
- Confidence<80%的需求标注"建议先做小实验验证"
- Must Have不超过总需求的60%
- 评分经过校准机制验证，避免锚定偏差
红线规则
- 不替代决策：排序结果是建议而非决定，最终优先级需团队对齐
- 不隐藏假设：所有评分的假设前提必须显式标注
- 不忽略Effort：禁止只看Impact不看Effort就推荐"必做"
输入不足处理
- 需求列表不足3个：仍然排序，但提醒"样本过少，建议补充更多需求"
- 缺乏数据：自动切换到ICE或MoSCoW，标注"因缺乏量化数据，使用定性排序框架"
- 未指定业务目标：按通用权重排序，建议用户补充以获得更精准结果
相关技能
/用户故事拆解：排序完成后，高优先级需求 → 拆解为User Story/PRD生成：排序确认后，Must Have需求 → 写PRD