pm-feature-prioritization

name	pm-feature-prioritization
description	产品功能优先级排序技能。支持 RICE、MoSCoW、ICE、Kano 模型等多种优先级框架。适用场景：(1) 需求池排序，(2) 版本规划功能筛选，(3) 资源有限时决策哪些功能先做，(4) 用户说「功能排优先级」「需求排期」「哪些功能先做」「功能评估」时触发

功能优先级排序

支持的优先级框架

根据场景自动选择或让用户选择：

框架	适用场景
RICE	需要量化评分，功能较多（>10个）时
MoSCoW	版本范围快速决策，功能较少时
ICE	快速评分，早期探索阶段
Kano	用户满意度导向，偏用户体验决策

工作流程

Step 1: 采集需求清单

要求用户提供待排序的功能列表，格式：

- 功能名称：[简要描述]
- 来源：[用户反馈/业务诉求/技术债/战略规划]
- 背景：[可选，相关上下文]

Step 2: 选择框架并评分

RICE 框架

计算公式：RICE = (Reach × Impact × Confidence) / Effort

评分标准：

• Reach（覆盖用户数）：预计每月受影响的用户数量
• Impact（影响程度）：0.25(极小) / 0.5(小) / 1(中) / 2(大) / 3(极大)
• Confidence（信心度）：100%(高) / 80%(中) / 50%(低)
• Effort（工作量）：以人天为单位估算

输出格式：

| 功能  | Reach | Impact | Confidence | Effort | RICE分 | 优先级 |
| ----- | ----- | ------ | ---------- | ------ | ------ | ------ |
| 功能A | 1000  | 2      | 80%        | 5天    | 320    | P0     |
| 功能B | 500   | 1      | 100%       | 3天    | 167    | P1     |

MoSCoW 框架

分类标准：

• Must Have（必须有）：没有此功能产品无法上线或核心价值缺失
• Should Have（应该有）：重要但非绝对必要，可在第一版后加入
• Could Have（可以有）：锦上添花，有余力时做
• Won't Have（本次不做）：明确排除在本版本外

ICE 框架

• Impact（影响力）：1-10分
• Confidence（信心度）：1-10分
• Ease（易实现度）：1-10分
• ICE = Impact × Confidence × Ease

Kano 模型

分类：

• 基本型（Must-be）：没有会不满意，有了用户认为理所当然
• 期望型（One-dimensional）：做得越好越满意，越差越不满意
• 兴奋型（Attractive）：有了会惊喜，没有不会不满
• 无差异型（Indifferent）：有没有都无所谓
• 反向型（Reverse）：有反而会不满意

Step 3: 输出优先级排序结果

## 功能优先级排序结果

**使用框架**：[RICE/MoSCoW/ICE/Kano] **评估日期**：[日期] **评估版本**：[版本号]

### P0 - 立即做（本版本必须）

1. [功能名] - RICE: XXX - 理由：[关键原因]
2. [功能名] - RICE: XXX - 理由：[关键原因]

### P1 - 重要（本版本尽量）

1. [功能名] - RICE: XXX
2. [功能名] - RICE: XXX

### P2 - 次要（下个版本考虑）

1. [功能名]
2. [功能名]

### 暂不考虑

1. [功能名] - 原因：[为什么暂时不做]

### 决策依据说明

[解释关键决策背后的逻辑，特别是有争议的排序]

Step 4: 可视化建议

输出影响力 vs 工作量 的象限图（文字版）：

高影响 │ 快速赢得        │ 大工程
      │ (高优先)        │ (慎重规划)
------┼-----------------┼---------
低影响 │ 填充项          │ 避坑区
      │ (空闲时做)      │ (放弃)
      └─────────────────────────
         低工作量          高工作量

注意事项

• 优先级是动态的，建议每个迭代回顾一次
• RICE分数是相对值，不同产品间不可横向对比
• 最终决策需结合战略目标，不能完全依赖分数
• 记录评估依据，方便后续复盘