Requirement Eval

Requirement Evaluation Skill

PM 抛来一个需求，问「值得做吗 / 优先级多高」，本 skill 按步骤分析，产出一份 评估初稿 + 明确建议（做 / 不做 / 补充信息再定）。

铁律（先声明，避免糊弄）

1. 先暴露假设：Reach/Effort 没有真实数据支撑的，必须写明是估的，并把 Confidence 压低， 不许用假数字装出高信心。
2. 产出是初稿不是拍板：结论用「建议」措辞，末尾列出「需核实的数据」。
3. 信息不足先问：需求描述、目标用户、涉及端缺失时先问，别猜着算。
4. 数据现状决定 Confidence 上限：product.md「数据现状」写了无真实行为数据的， Reach 靠估 → Confidence ≤50%，并提示"埋点补齐后重估"。

第 0 步：读产品上下文

按 prd-writing skill 目录下的 PRODUCT-CONTEXT.md 协议定位 product.md，取覆盖端、 产品知识库、数据现状。不存在 → 按协议做首次访谈并落盘（之后 prd-writing / tracking-plan 直接复用，不再重问）；有知识库的，评估现状/竞品前先去查。 未安装 prd-writing（找不到该协议文件）时单独可用：跳过协议，直接问涉及端、有无真实 行为数据两项，本次会话内用，不落盘。

第 1 步：收集本需求信息（缺就问）

• 需求一句话描述
• 来源（用户反馈 / 评审意见 / 竞品 / 数据 / 内部想法）——影响可信度
• 目标用户 & 使用场景
• 涉及端（在 product.md 覆盖端范围内勾选）
• 是否有大致工作量预估

第 2 步：KANO 定位（这是哪类需求）

判断落在哪一类，并说明理由：

• 基础型（必备，缺了掉信任）→ 倾向于做，属底线
• 期望型（越好越满意）→ 看竞争态势和 RICE 分
• 兴奋型（惊喜、差异化）→ 结合战略，可能值得为它赌一把
• 无差异型（有没有无所谓）→ 倾向不做
• 反向型（做了招人烦）→ 建议砍掉

定位时结合产品定位（product.md 一句话定位）：同一个功能在工具型产品是基础型， 在内容型产品可能是无差异型——别脱离产品谈 KANO。

第 3 步：RICE 打分（能排序）

逐项给值 + 依据，算 (Reach × Impact × Confidence) ÷ Effort：

第 4 步：综合建议

把 KANO 定位和 RICE 分放一起给结论：

• 明确建议：值得做 / 暂不做 / 补数据再定 / 拆小做一部分
• 理由：一句话说清为什么
• 建议排期：进哪个版本 / 放需求池观察
• 需核实的数据：列出要确认的假设（尤其 Reach 和 Effort）

第 5 步：输出为需求池可用的一行

最后给一行能直接贴进需求池的结构化结果（需求名｜KANO 类型｜RICE 分｜建议｜目标版本）。

输出模板

## 需求评估：<需求名>

**一句话**：<描述>ㅤ**来源**：<来源>ㅤ**涉及端**：<端>

### KANO 定位
类型：**<基础型/期望型/兴奋型/...>** — <理由>

### RICE 打分
| 因子 | 值 | 依据 |
|------|-----|------|
| Reach | 8000 | ⚠️ 估算，无埋点数据支撑 |
| Impact | 1 | 中等，改善但非核心路径 |
| Confidence | 50% | Reach 靠估，压低 |
| Effort | 2 人月 | 待开发确认 |
**RICE 得分 = (8000×1×0.5)/2 = 2000**

### 建议
**<值得做 / 暂不做 / 补数据再定>** — <理由>
建议排期：<版本/需求池观察>

### ⚠️ 需核实
- Reach 真实数（埋点补齐后重估）
- Effort 请开发确认

### 需求池一行
| 需求 | KANO | RICE | 建议 | 目标版本 |
|------|------|------|------|----------|
| <名> | 期望型 | 2000 | 排期 | MVP+2 |

相关

• 产品上下文协议：prd-writing skill 目录下的 PRODUCT-CONTEXT.md
• 立项后写 PRD：prd-writing skill（复用同一份 product.md，不重复访谈）
• 独立产出落产品文件夹（product.md 所在目录）的 eval/<需求名>.md