| 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分数是相对值，不同产品间不可横向对比
- 最终决策需结合战略目标，不能完全依赖分数
- 记录评估依据，方便后续复盘
