zhaoxuya520 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 是什么
□ 范围切分是否服务于验证某个假设
常见坑
- MVP 范围过大——第一版就想做完整平台
- Must 全是功能——忘了非功能需求（性能、安全、可观测）
- 没有 Won't——结果开发到一半被加塞需求
- 闭环有断点——比如有"下单"没有"支付"
- 把"可能用得上"放进 Must——优先级失控
- 没有验证假设——MVP 应该验证某个商业/产品假设，不是"先做点东西看看"
- 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/开发 → 开始执行