第2章 适用场景判断
2.1 适用场景全景
并非所有产品或功能都适合用MVP（最小可行产品）启动。本章建立一套结构化判断框架，帮助团队在立项前快速识别：哪些项目适合MVP、哪些不适合，以及关键风险点。
核心原则：MVP的适用性取决于“不确定性”与“验证成本”的比值。不确定性越高、验证成本越低，越适合MVP；反之则不适合。
2.2 前置条件
进行适用场景判断前，团队必须完成以下准备工作：
- 产品愿景声明：一句话说清产品要解决什么核心问题、为谁解决。
- 初步用户画像：至少识别1~3个目标用户角色及其典型场景。
- 功能候选列表：所有被提议的功能点，无需排序。
- 可用资源盘点：团队规模、可用研发时间、预算上限、关键技术约束。
检查项：如果以上任何一项缺失，建议先补齐再进入本章判断；否则输出结果失真。
2.3 适用性判断矩阵
以下矩阵列出适合/不适合MVP的典型场景，团队可逐条对照：
| 维度 | 适合MVP | 不适合MVP |
|---|---|---|
| 市场不确定性 | 全新领域、假设驱动的创新 | 已验证市场、需求明确且稳定 |
| 技术风险 | 主要依赖现有技术栈，核心逻辑可快速验证 | 依赖未成熟技术、需要重大基础设施搭建 |
| 用户反馈价值 | 早期用户能为功能取舍提供关键数据 | 用户无法通过初步版本获得有效体验 |
| 业务约束 | 时间窗口短、需要快速试错 | 法规合规要求高、不可逆决策（如医疗设备核心模块） |
| 团队成熟度 | 团队具备快速迭代、接受失败的文化 | 团队抗拒频繁变更、缺乏精益交付经验 |
2.4 操作步骤
- 列出现有认知：将前置条件的输出整理成清单，包括所有假设和已知事实。
- 逐项匹配矩阵：每个维度给出“适合/不适合/待确认”标记，并记录理由。
- 计算适用得分：适合得+1，不适合得-1，待确认得0；若总分 ≥ +1 则进入MVP执行通道；若 ≤ -2 则建议传统瀑布或非MVP方式；其余情况需团队讨论决策。
- 识别核心风险：对每个“待确认”或“不适合”项，转化为风险条目（格式见下文异常处理）。
- 输出场景结论：明确写出“该产品/功能【适合/不适合】MVP”，并附上3~5条关键依据。
实战速查：如果连一个核心用户假设都无法定义，建议先做用户研究再进入判断，不要强行套用MVP框架。
2.5 风险识别与分类
在适用性判断过程中，必须同步识别三类风险：
| 风险类型 | 典型表现 | 应对策略 |
|---|---|---|
| 市场风险 | 目标用户群体不存在、或需求假设错误 | 拆分更小的验证实验（如登陆页测试、预注册） |
| 技术风险 | 核心功能无法在预期成本内实现 | 单独做技术Spike（时间盒探索），再决定是否继续 |
| 交付风险 | 团队不具备Hack能力、依赖外部支持 | 调整MVP范围至团队能独立交付的最小闭环 |
注意：风险识别不是一次性活动。当判断结果为“适合MVP”时，这些风险必须纳入迭代回顾的监控清单。
2.6 决策流程总览
下图为适用场景判断的完整决策链，包含输入、判断节点和输出路径：
2.7 输入输出物
| 类别 | 名称 | 格式/载体 | 责任人 |
|---|---|---|---|
| 输入 | 产品愿景声明 | 文档（Markdown/Confluence） | 产品经理 |
| 输入 | 初步用户画像 | 1页画像卡片 | 用户研究员/产品经理 |
| 输入 | 功能候选列表 | 电子表格或看板 | 产品经理 |
| 输入 | 资源盘点表 | 表格（人/时间/预算） | 项目经理 |
| 输出 | 适用性结论报告 | 文档（含判断矩阵逐项结果、得分、最终结论） | 产品经理 |
| 输出 | 风险登记册 | 表格（风险描述、类型、可能性、应对措施） | 技术负责人/产品经理 |
2.8 责任边界
- 产品经理：组织判断流程、撰写结论报告、确保输入完备。
- 技术负责人：评估技术风险、识别技术Spike需求。
- 用户研究员（如有）：提供用户画像及假设验证建议。
- 项目经理：盘点资源约束、记录异常并推动决策。
- 决策委员会（如Scrum团队+PO）：对“剩余情况”分支的讨论做出最终裁决。
2.9 记录材料
以下为每次判断需归档的标准化记录：
适用性判断记录表
项目/功能名：[填写]
日期：[填写]
参与人：[PM, Tech Lead, UX, PMO]
| 维度 | 判断结果 | 依据 |
|---------------|----------|--------------------------------------|
| 市场不确定性 | 适合/不适合/待确认 | [简述假设或事实] |
| 技术风险 | 同上 | [简述技术约束或Spike结果] |
| 用户反馈价值 | 同上 | [目标用户能否在最小版本中体验价值] |
| 业务约束 | 同上 | [合规/时间窗口/不可逆决策] |
| 团队成熟度 | 同上 | [迭代经验/失败接受度] |
| 适用得分 | [数值] | 最终建议：[适合/不适合/团队讨论] |
风险登记册（关联此判断）：
| 风险描述 | 类型 | 可能性 (1-5) | 影响 (1-5) | 应对措施 |
|----------|--------|--------------|------------|---------------------|
| ... | 市场/技术/交付 | ... | ... | ... |2.10 异常处理
| 异常状况 | 处理措施 |
|---|---|
| 前置条件清单不全 | 暂停判断，补齐资源盘点或用户画像后再继续 |
| 矩阵逐项结果全部为“待确认” | 说明产品假设过弱，建议启动用户调研或技术POC（概念验证）后再判断 |
| 团队内部对某个维度意见严重分歧 | 使用加权投票（每个决策人2票）后取均值，并记录少数意见作为风险 |
| 外部资源限制导致无法按标准流程执行 | 至少完成矩阵匹配和风险识别两个核心步骤，后续结论注明“受限判断” |
2.11 验收标准
完成本章内容后，需满足以下条件才算结束：
- ✅ 所有前置条件已具备并归档
- ✅ 判断矩阵完整填写，每个维度均有明确结果或风险标记
- ✅ 适用得分计算无误，结论清晰（适合/不适合/团队讨论）
- ✅ 风险登记册至少识别3条风险，每一条包含应对措施
- ✅ 适用性结论报告和风险登记册已上传至共享知识库
- ✅ 团队全员（PM、Tech Lead、UX、PMO）确认无异议或已记录分歧
自检问题：本结论是否经得起“假如客户明天要求给原因”的拷问？如果回答不出，请补充依据。