4. MVP范围划分的决策要素：用户需求、业务价值、技术可行性、风险
适用场景
- 产品待办列表（Product Backlog）中候选特性过多，团队对“什么是真正的MVP”存在严重分歧。
- 已完成用户故事地图和初步技术预研，需要统一的多维度评估框架来取代凭直觉投票。
- 进入交付冲刺前，需要对候选特性进行最终“生死”裁决，确保MVP范围不膨胀、不遗漏。
前置条件
- 需求池已完成清洗与拆分，各候选特性粒度统一（建议1~3人/天）。
- 已输出至少一个版本的KANO模型分析表或用户调研报告，用于支撑“用户需求”强度判断。
- 技术团队已完成关键技术点（Spike）预研，并能给出“技术可行性”初步等级（高/中/低）。
- 各角色（PO、技术负责人、决策主持人）已到位，并明确各自在决策矩阵中的权责。
操作步骤（SOP）
- 评估用户需求（User Need / Impact）
从用户故事地图中提取待评估特性，判断其解决的是核心痛点（高）、辅助体验（中）还是锦上添花（低）。可借助KANO模型将“基本型需求”直接标记为高需求，将“兴奋型需求”标记为中/低需求。
- 评估业务价值（Business Value）
量化或定性分析每个特性对业务北极星指标的贡献。常见维度包括：获客（Acquisition）、激活（Activation）、留存（Retention）、变现（Revenue）、口碑（Referral）。分三级：
高——直接影响核心转化率或LTV；中——显著提升用户满意度；低——仅带来微小体验提升。
- 评估技术可行性（Technical Feasibility）
开发团队对特性的实现复杂度、架构侵入度、第三方依赖成熟度进行综合评定：
高——现有架构可快速实现，无外部依赖风险；中——需模块级改造或引入成熟的开源组件；低——涉及核心重构或技术栈更换。
- 评估风险（Risk）
识别与特性相关的所有非功能风险，包括但不限于：技术风险、数据合规风险、安全漏洞风险、市场时效风险。风险等级：低（可控/有预案）、中（需额外Spike）、高（存在一票否决类合规或安全问题）。
- 综合决策（决策矩阵汇总）
将四维评分汇总至决策矩阵，应用预设裁决规则：
典型规则示例：
— “全高”必入MVP；
— 任一维度为“低”但其他三维为“高”，进入待定池（需评审）；
— “风险”为高时，除非业务价值极高且可通过Spike降级，否则直接否决；
— “技术可行性”为低且“业务价值”非高时，直接移出MVP候选。
✅ 最佳实践： 建议在决策会议上使用“四维雷达图”或热力图矩阵，将结果可视化，帮助干系人快速达成共识。
输入输出物
| 输入物（Input） | 输出物（Output） |
|---|
| 候选特性清单（Feature Candidates） | MVP四维决策矩阵（已评分） |
| KANO模型分析表 / 用户调研报告 | MVP范围终审列表（Accepted / Pending / Rejected） |
| 技术预研报告（Spike Results） | 高风险项缓解计划 / Spill-over Backlog |
| 业务北极星指标及OKR | 决策会议纪要及签字页 |
责任边界
| 角色 | 职责（Responsibility） |
|---|
| 产品经理（PO） | 提供用户需求证据、KANO模型分类、为业务价值评级的最终解释 |
| 技术负责人（Tech Lead） | 提供技术可行性等级、识别技术债务与集成风险、预估Spike工期 |
| 敏捷教练 / 决策主持人 | 组织决策会议、引导SOP执行、确保争议记录在案、推动裁决 |
| 关键干系人（Stakeholders） | 签署确认最终MVP范围承诺 |
记录材料
所有决策原始数据及结果必须版本化管理，统一存放于项目共享目录（如Confluence、SharePoint或Git项目仓库），命名规范如下：
MVP_Decision_Matrix_v{Version}_{Date}.xlsx
例：MVP_Decision_Matrix_v0.4_20250521.xlsx
矩阵内必须包含以下工作表（Sheet）：
- Sheet 1 – 原始数据： 每个候选特性的四维原始评分及相关证据链接。
- Sheet 2 – 裁决输出： 应用规则后的最终状态（Accepted / Pending / Rejected）及裁决人。
- Sheet 3 – 争议日志： 所有无法达成一致的项的讨论纪要及最终决策人签注。
异常处理
| 异常场景 | 处理对策 |
|---|
| 四维评分严重矛盾（如“高价值 + 技术不可行”） | 自动进入“技术预研（Spike）暂缓池”。由技术负责人给出Spike方案与工期，下个周期重新评估。 |
| 团队对某一维度的评级僵持不下（如“用户需求是痛点还是痒点”） | 1. 现场查看用户录屏/数据；2. 如30分钟内仍无共识，由PO行使“最终解释权”拍板，并记录原因。 |
| 特性涉及合规/安全风险未见评估维度 | 立即启动安全评审，将合规风险单独列为“一票否决项”，若为高风险则直接拒绝，无需等待综合评分。 |
| 会议超时，无法遍历所有候选特性 | 停止讨论，已评定的特性锁定结果，未评定的特性保持“未决”状态，优先处理下一轮即将交付的增量。 |
验收标准
- 所有候选特性均已遍历并至少完成“用户需求/业务价值/技术可行性/风险”四维评分。
- 决策矩阵已输出，且每个特性均被明确标记为“Accepted / Pending / Rejected”三种状态之一。
- PO、技术负责人及关键干系人已在最终MVP范围清单上签字确认。
- 所有争议项及裁决理由均已如实记录在争议日志中，无遗漏。