第16章 MVP 与质量底线
第15章定义了交付闭环，但闭环不是让你一次做完所有功能。真正的问题是：哪些必须做，哪些必须砍，哪些再急也不能牺牲质量。本章解决 MVP 与质量底线的边界。第17章会进入接单交付 SOP。
16.1 结论先行：MVP 是最小可验证产品，不是最低质量产品
MVP（Minimum Viable Product）的关键词不是 Minimum，而是 Viable。它可以小，但必须能验证真实需求、能跑完核心路径、能被用户理解。
text
合格 MVP = 最小范围 + 核心路径可用 + 验收标准可验证呼应第01章公式二：MVP 仍然要走范围、实现、验证、验收。只砍范围，不砍闭环。
铁律：半成品不是 MVP，能验证假设的最小完整闭环才是 MVP。
16.2 MVP 与原型、Demo、正式版的差异
| 类型 | 目的 | 是否交付用户 | 是否能收费 |
|---|---|---|---|
| 原型 | 展示想法 | 不一定 | 通常不能 |
| Demo | 演示能力 | 不一定 | 通常不能 |
| MVP | 验证需求 | 是 | 可以 |
| 正式版 | 规模化使用 | 是 | 应该 |
MVP 的目标不是让人夸你做得完整，而是让真实用户用核心路径完成任务。
16.3 三条质量底线
text
MVP 质量底线
├─ 可运行：目标环境能跑
├─ 可验证：核心路径能测
└─ 可解释：用户知道怎么用、为什么用| 底线 | 最小标准 | 不能牺牲的原因 |
|---|---|---|
| 可运行 | 无致命错误，核心链路可用 | 否则无法验证 |
| 可验证 | 有明确验收项 | 否则反馈无意义 |
| 可解释 | 有说明/引导/边界 | 否则用户不会用 |
16.4 范围裁剪：砍什么，留什么
优先保留：
- 直接验证付费假设的功能。
- 用户完成核心任务必须经过的路径。
- 影响安全、数据、支付、权限的底线功能。
优先砍掉：
- 美化但不影响理解的细节。
- 管理后台的高级功能。
- 低频边缘场景。
- 还没有用户证据的“未来可能需要”。
16.5 实战：MVP 范围裁剪表
text
需求名称：
核心假设：
必须保留：
- [ ] 功能：____ 验证什么：____
- [ ] 功能：____ 验证什么：____
可以延后：
- [ ] 功能：____ 延后原因：____
明确不做：
- [ ] 功能：____ 不做原因：____
质量底线：
- [ ] 可运行
- [ ] 可验证
- [ ] 可解释验证：如果砍掉某功能仍能验证核心假设，就砍；如果砍掉后无法验证，就留。
16.6 MVP vs 低价交付
| 维度 | MVP | 低价交付 |
|---|---|---|
| 范围 | 小而完整 | 什么都少一点 |
| 质量 | 底线不降 | 全面降级 |
| 目标 | 验证假设 | 勉强交差 |
| 结果 | 可迭代 | 损害信任 |
不要用 MVP 为低质量找借口。
16.7 失败边界
死法一：把半成品当 MVP
对抗：核心路径不能跑通就不能给用户验证。
死法二：过度打磨
对抗：任何不能验证核心假设的优化都延后。
死法三：没有核心路径
对抗：先画用户从进入到完成任务的路径，再决定功能。
死法四：为了快牺牲安全
对抗：权限、数据、凭据、支付不进入可裁剪范围。
16.8 小结 / 核心心法
MVP 的本质是砍掉非核心范围，保留完整闭环。
执行清单：
- [ ] MVP 要验证的核心假设是什么？
- [ ] 核心路径能跑通吗？
- [ ] 哪些功能可以延后？
- [ ] 安全/数据/权限底线是否保留？
上一章：第15章 交付闭环 下一章：第17章 接单交付 SOP