mvp-scoping

name	mvp-scoping
description	划分 MVP 范围、明确非目标范围时使用。适用于第一版功能定义、范围控制、需求收敛。优先使用 MoSCoW 四级分类 + 非目标范围明示。

MVP 范围切分

适用场景

• 新产品/新功能的第一版范围定义
• 防止需求膨胀
• 已有功能列表的优先级收敛
• 给项目经理的输入（哪些必做、哪些可后置）

核心原则

MVP = 能验证核心价值的最小闭环

不是"少做几个功能"，而是"做最少的功能但能跑通完整业务流程"。

错误理解：
  完整产品 = 100 个功能
  MVP = 10 个功能
  → 砍 90 个，但用户体验断裂

正确理解：
  完整产品 = 100 个功能
  MVP = 能完成 1 个核心业务闭环的最少功能
  → 假设 15 个功能能跑通，就做 15 个

MoSCoW 四级分类

Must Have（必须有）
  没有它功能不能成立
  例：电商 MVP 的"下单"功能

Should Have（应该有）
  影响体验，但可在第二版补
  例：电商 MVP 的"优惠券"

Could Have（可以有）
  锦上添花，资源充足时再做
  例：电商 MVP 的"商品评分"

Won't Have（暂不做）
  明确排除，防止范围蔓延
  例：电商 MVP 的"直播带货"

非目标范围（Non-Goals）

比 MVP 范围更重要的是明确写出"不做什么"：

为什么需要非目标：
  - 防止需求方反复加塞
  - 减少团队理解偏差
  - 保留后续版本的设计空间
  - 避免在不重要的事情上浪费精力

写法：
  ❌ "这一版不做太多功能"（模糊）
  ✅ "这一版不做：
      - 多语言支持（仅中文）
      - 移动端原生 APP（仅 H5）
      - 第三方支付集成（仅微信支付）
      - 商家自助入驻（仅运营手动配置）"

MVP 切分工作流

1. 列出所有候选功能
   ↓
2. 识别核心业务闭环
   （用户从进入到完成核心目标的最短路径）
   ↓
3. 标注每个功能在闭环中的角色：
   - 必经节点 → Must
   - 可省略但有损 → Should
   - 完全可选 → Could
   ↓
4. 明确写出 Won't（非目标）
   ↓
5. 用 1 句话描述 MVP：
   "用户可以 [做什么]，从而 [获得什么价值]，但暂时不能 [哪些限制]"
   ↓
6. 检查闭环是否完整（不能有断点）

MVP 描述模板

## MVP 范围：[功能/产品名]

### 核心业务闭环

[一句话描述用户能完成什么]

### Must Have（这一版必须有）

| # | 功能 | 在闭环中的角色 |
|---|------|---------------|
| 1 | 用户注册/登录 | 入口 |
| 2 | 浏览商品列表 | 发现 |
| 3 | 商品详情页 | 决策 |
| 4 | 加入购物车 | 收集 |
| 5 | 下单结算 | 转化 |
| 6 | 在线支付 | 完成 |
| 7 | 订单状态查询 | 反馈 |

### Should Have（第二版补）

- 商品搜索
- 优惠券系统
- 收藏夹

### Could Have（资源充足时）

- 商品评分
- 个性化推荐

### Won't Have（明确不做）

- ❌ 多语言（仅中文）
- ❌ 原生 APP（仅 H5）
- ❌ 直播带货
- ❌ 商家自助入驻
- ❌ 退款流程（人工处理）

### 范围说明

[为什么这样切？哪些是为了验证什么假设？]

质量自检

□ 核心业务闭环是否能跑通（不能有断点）
□ Must 中的功能去掉任何一个，闭环是否会断
□ Should/Could 是否真的可后置（不是"应该有但偷偷觉得不能没有"）
□ Won't 是否明确写出（不能模糊带过）
□ 一句话能不能说清楚 MVP 是什么
□ 范围切分是否服务于验证某个假设

常见坑

1. MVP 范围过大——第一版就想做完整平台
2. Must 全是功能——忘了非功能需求（性能、安全、可观测）
3. 没有 Won't——结果开发到一半被加塞需求
4. 闭环有断点——比如有"下单"没有"支付"
5. 把"可能用得上"放进 Must——优先级失控
6. 没有验证假设——MVP 应该验证某个商业/产品假设，不是"先做点东西看看"
7. Should 和 Could 没区别——边界模糊导致后续版本规划困难

配套模板

• templates/mvp-scope-template.md — MoSCoW 分类 + 非目标范围 + MVP 一页纸简报

与其他 skill 的协作

上游：
  opportunity-tree → 提供候选方案
  prioritization → 提供优先级评分（辅助 MoSCoW 判断）

平行：
  prd-writing → MVP 范围进入 PRD 第 5 节
  pol-probe → 高不确定的 Must 先做验证实验

下游：
  转交项目经理 → 按优先级拆排期
  Must 范围转交 UI/UX/API/开发 → 开始执行