1. MVP范围定义

## 第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范围，无重大未决争议