## 第1章 MVP范围定义：需求边界、功能列表、交付物标准
### 适用场景
| 场景 | 典型触发条件 | 适用阶段 |
|------|-------------|----------|
| 全新硬件产品从零启动 | 团队拿到市场需求文档（MRD）后首次定义MVP | 概念验证 → 产品定义 |
| 现有产品增加新功能线 | 用户反馈或竞争压力要求快速验证新特性 | 功能拓展 → 原型验证 |
| 技术方案降级/替换 | 原定方案成本或周期不可控，需缩小范围完成验证 | 方案评估 → 快速试错 |
| 多团队协作边界模糊 | 硬件、固件、应用、算法多个子团队需求交叉 | 分工对齐 → 风险控制 |
### 前置条件
- 已完成用户/市场调研，识别出最核心的**待验证假设**（如：某种传感器方案能否在1米内稳定识别人体）
- 团队具备至少1名产品经理、1名硬件工程师、1名嵌入式工程师
- 已确定MVP的**交付窗口期**（通常建议4–8周）
- 已获得决策层对“可能失败”的容错承诺（文字或会议纪要记录）
### 操作步骤
**步骤1：锁定核心待验证假设**
从所有用户痛点和产品功能中，提炼出**1~3个**必须通过硬件原型回答的问题。
例：
> “低成本PIR传感器 + 单透镜方案是否能在走廊环境（2~5米）检测到慢速人体移动，误报率<5%？”
**步骤2：定义需求边界**
使用**MoSCoW法**对功能进行分层：
| 层级 | 含义 | 量化标准 | 示例 |
|------|------|---------|------|
| **Must have** | MVP必须包含，否则无法验证假设 | ≥1个可测试用例通过 | 传感器采样率≥10Hz，通信延迟<200ms |
| **Should have** | 有更好，无也可验证核心假设 | 可在beta版本添加 | 设备端本地数据缓存 |
| **Could have** | 锦上添花，优先级最低 | 不进入本轮开发队列 | 远程OTA升级 |
| **Won't have** | 明确放弃在本轮实现 | 移至Roadmap后续阶段 | 多设备组网协同 |
**步骤3：细化功能列表与验收标准**
将Must have功能逐条转换为**可执行的开发任务**，并附加明确的**通过/不通过指标**。
| 功能模块 | 功能描述 | 验收标准 | 完成标志（DOD） |
|---------|---------|----------|----------------|
| 传感器数据采集 | 每100ms读取一次PIR数字信号 | 连续运行1h无丢帧，数据正确率≥99% | 固件日志输出正常，示波器实测无异常毛刺 |
| 无线通信 | 通过BLE 5.0将数据发至手机App | 有效传输距离≥5m，平均丢包率≤2% | 手机App连续接收1000包，丢包≤20 |
| 供电系统 | 3.7V锂电池供电，续航≥24h | 满载功耗≤50mW，休眠功耗≤50μA | 实测电流数据满足目标值 |
**步骤4：定义交付物清单**
| 交付物类型 | 具体内容 | 责任人 | 交付格式 |
|-----------|---------|--------|---------|
| 硬件设计文件 | 原理图、PCB布局（至少Layout完成）、BOM表 | 硬件工程师 | KiCad/Altium源工程 + PDF |
| 固件源码 | 传感器驱动、通信协议栈、电源管理 | 固件工程师 | GitHub仓库Tag v0.1 |
| 测试报告 | 功能测试用例执行结果、功耗测试数据 | 测试工程师 | Markdown/PDF，含原始数据CSV |
| 用户操作指南 | 开机、配对、数据查看的简易步骤（≤1页） | 产品经理 | 带截图/照片的A4文档 |
| 需求边界文档 | 最终版MoSCoW表格 + 待验证假设声明 | 产品经理 | 共享文档链接 |
**步骤5：签署范围基线**
组织**范围定义评审会**，邀请所有干系人（硬件、固件、测试、项目经理）逐条确认功能列表与交付物标准。如有分歧，以“能否支撑核心假设验证”为唯一裁决原则。评审后由产品经理和项目经理共同签字生效，并锁定变更流程（任何新增需求必须走 **CR（Change Request）** 流程）。
### 输入输出物
**输入：**
- 用户需求调研报告 / 市场分析文档
- 技术可行性评估（硬件选型、成本、周期粗估）
- 项目时间表（里程碑节点）
**输出：**
- 《MVP需求边界定义表》（含MoSCoW分级）
- 《功能列表与验收标准矩阵》
- 《交付物清单及责任人矩阵》
- 评审会议纪要（含签字）
### 责任边界
| 角色 | 责任范围 |
|------|---------|
| **产品经理** | 主导需求边界定义、撰写待验证假设、维护MoSCoW表、组织评审 |
| **硬件工程师** | 评估硬件必须功能的技术实现难度与成本，确认交付物可行性 |
| **固件工程师** | 评估MCU资源、通信协议栈、存储等限制，确认固件功能范围 |
| **测试工程师** | 确认可测试性，撰写验收标准中的通过/不通过指标 |
| **项目经理** | 管控范围变更，组织评审并锁版 |
### 记录材料
- `v0.1_MVP_Scope_Sheet.xlsx`：包含MoSCoW表、功能验收标准、交付物清单
- `MVP_Assumption_Statement.md`：核心待验证假设（1~3个），用“如果…那么…”句式
- `Review_Minutes_v0.1.md`：评审会决策记录，含争议点、结论、责任人
- `Change_Request_Template.md`：供后续范围变更使用
### 异常处理
| 异常场景 | 处理动作 | 决策人 |
|---------|---------|--------|
| 干系人对Must have数量分歧（超过5个） | 使用“单假设验证”要求重新筛选，只保留支撑最核心假设的3±1个功能 | 产品经理 + 项目经理 |
| 某项功能技术上无法在交付周期内完成 | 降级为Should have或Won't have，同时准备备选简化方案 | 硬件工程师 + 产品经理 |
| 测试环境无法构建验收标准中的条件（如50m无线距离） | 调整验收标准为可复现的等效条件（如10m内仿真环境），注明偏差 | 测试工程师 + 产品经理 |
| 团队无可用BOM成本数据 | 先使用选型替代料的参考价格，并在交付物中标记“待确认” | 硬件工程师 |
### 验收标准
- [ ] 所有Must have功能均列出至少一条可量化的通过/不通过指标
- [ ] 核心待验证假设明确写在文档中，并经3人以上评审认同
- [ ] 交付物清单涵盖硬件、固件、测试、文档四类，每类至少一项
- [ ] 范围基线已签字锁定，变更流程已建立
- [ ] 团队成员均理解并接受当前MVP范围，无重大未决争议
💡 最佳实践提示： 在定义Must have时，强制要求每个功能必须直接指向一个核心假设。如果某个功能无法回答“若无此项，核心假设能否验证？”并回答“不能”，则它不应出现在Must have中。这是MVP范围收缩最有效的“剃刀”。
⚠️ 常见陷阱： 团队容易把“用户期待的功能”等同于“MVP必须功能”。请区分“验证假设所需”与“产品正式版所需”。例如，“社交分享”在智能硬件MVP中通常属于Won't have，除非你的核心假设是“用户愿意将数据分享到社交圈”。