3. IoT场景分析与用例提炼
3.1 为什么场景分析是PRD的基石
IoT产品的交互链条长、物理环境多变、用户角色复杂。不经过系统化的场景分析，PRD中的功能描述极易遗漏边界条件、混淆触发主体、忽略异常路径。场景分析将“模糊的用户需求”转化为“可验证的交互上下文”，是需求拆解与验收标准制定的直接依据。
课程关键认识： 一个IoT场景必须回答“谁（用户角色），在什么环境（上下文），因为什么（触发条件），做什么操作（交互流程），期望得到什么结果（目标）”。PRD中每个用例都应包含这四要素。
3.2 IoT典型场景速览
IoT覆盖领域极广，但以下三类场景在产品设计中复用度最高。理解它们的共性结构能加速新场景的建模。
| 领域 | 典型场景 | 核心交互对象 | 关键挑战 |
|---|---|---|---|
| 智能家居 | 离家模式：检测无人后关闭灯光、空调、窗帘 | 门磁、人体传感器、智能开关、网关 | 误触发（宠物/访客）、用户离家意图模糊 |
| 工业监控 | 设备预测性维护：振动/温度异常时自动派单 | 传感器、SCADA、MES、维修工单系统 | 数据实时性、告警阈值动态调整 |
| 车联网 | 远程诊断：车辆故障码上传云端并通知车主 | T-Box、云端诊断服务、车主APP | 网络断连时的本地缓存、安全认证 |
用户访谈提示： 在与真实用户（如家庭主妇、工厂设备员、车主）访谈时，不要直接问“你想要什么功能”，而是引导描述“您上次遇到XX情况时，先做了什么，然后发生了什么”。这种叙事结构恰好对应场景四要素。
3.3 场景描述方法：上下文、触发条件、交互流程
一个标准场景描述由三个固定部分构成。下面以智能家居“离家模式”为例展示完整写法。
- 上下文 (Context)：用户角色、物理位置、设备状态、时间窗口。
例：业主离家，家中所有人员已离开，门已上锁，时间为工作日8:00-9:00。 - 触发条件 (Trigger)：明确启动场景的具体事件。
例：门锁从内部反锁且最后一个手机蓝牙信标离开10米范围；或通过APP按键主动触发。 - 交互流程 (Flow)：按时间顺序列出系统与用户、设备之间的数据/动作交换。
例：面板应用→APP发送“离家”指令→网关下发关闭指令→智能灯逐路断电→空调设定为节能温度→推送离家完成通知。
常见错误： 只写流程不写上下文（导致测试时不知道“什么人用什么设备在什么环境下执行”）；触发条件用模糊词如“一段时间后”（必须明确“持续5分钟无人移动”或“门禁传感器触发超时”）。
3.4 用例优先级矩阵
场景通常有数十个，无法全部进入MVP。优先级矩阵（也称价值-复杂度二维矩阵）能帮助团队快速决策。
| 用户价值 \ 技术复杂度 | 低复杂度 | 高复杂度 |
|---|---|---|
| 高价值 | ✅ 立即开发（核心MVP） | 🔶 分阶段投入（高价值大坑，先出原型验证） |
| 低价值 | 🟡 维护期优化（低优先级） | ❌ 暂不开发（除非战略要求） |
评估时，价值维度参考：用户频次、用户付费意愿、竞品覆盖度、品牌影响力；复杂度维度参考：传感器类型数、云端依赖度、算法训练成本、认证合规要求。
需求拆解实践： 将高价值+低复杂度场景直接拆解为用户故事放入PRD；高价值+高复杂度场景需要进一步细化技术方案，并定义阶段验收标准（PoC→MVP→GA）。
3.5 从场景到用例：交付物模板
在PRD中，每个场景对应一个或多个用例。下面是一个可复用的用例模板（JSON格式示例），可直接嵌入PRD附录。
{
"用例ID": "SMART-HOME-003",
"场景名称": "离家模式自动激活",
"上下文": "业主离家，门已上锁，家中无活动人体",
"触发条件": "门锁检测到关门且内部无旋钮转动，同时人体传感器5分钟内无触发",
"交互流程": [
"1. 网关收到门锁状态变更事件",
"2. 网关请求人体传感器状态（最后触发时间戳）",
"3. 判断时间差 ≥5分钟 → 启动离家场景",
"4. 向智能灯、空调、窗帘依次发送关闭/节能指令",
"5. 推送通知至用户手机"
],
"预期结果": "所有受控设备进入节能或关闭状态",
"验收标准": [
"门锁关闭后5分钟内无人体触发 → 场景自动激活",
"任一设备离线时，场景仍执行其余受控设备",
"APP可查看到距现在最近一次离家模式执行记录"
]
}
课程交付物清单： 本章完成后应产出：
- 至少5个典型场景的完整描述（含上下文+触发+流程）
- 场景优先级矩阵打分表
- 优先级最高的3个场景对应的用例模板（包含验收标准）
上图展示了从用户访谈产出到PRD的完整路线，其中场景描述四要素和优先级矩阵是本章核心产出物。实际课程项目中，每位学员需要针对自己项目的5个场景完成该流程，并形成验收标准清单。