第3章：用户场景采集与边界线索挖掘
产品功能边界不是凭空拍脑袋定义的，而是从用户的真实使用场景中一层层抽丝剥茧挖出来的。本章聚焦于“6W1H”场景采集框架，教你在访谈和观察中精准锁定边界线索。
3.1 为什么场景挖掘是边界定义的起点
一个IoT产品往往连接设备、云端、App与线下服务。如果连“谁在什么时候、为什么使用”都没搞清楚，边界要么缩得太小（落不了地），要么张得太大（做不完）。
核心认知： 场景描述越具体，边界线索越明显。“用户在上班时用App调空调”不如“业主在夏季工作日13:00-14:00午休期间，通过手机App将卧室空调从26℃调至24℃，期望5分钟内降温且不影响其他房间”更有边界定义价值。
3.2 6W1H 场景采集框架
每次用户访谈或实地调研，都围绕以下七个维度记录原始素材。表格形式便于后续整理和交叉对比。
| 维度 | 挖掘焦点 | 边界线索示例 | 提问示例 |
|---|---|---|---|
| Who | 核心角色、决策者、协作者、旁观者 | 业主 vs 物业 vs 访客权限不同 | 谁最能决定这个功能的开关？ |
| Where | 物理位置、网络环境、设备部署点 | 室内WiFi稳定 vs 地下车库4G弱覆盖 | 这个功能在哪里用最多？信号怎样？ |
| When | 触发时间、频次、时序依赖 | 每天定时触发 vs 突发告警触发 | 你一般在什么时间点需要它？ |
| What | 具体操作、数据流向、设备联动 | 一键离家模式包含关灯、关空调、布防 | 你具体做了什么操作？先点哪里？ |
| Why | 动机、痛点、收益追求 | 为了省电 vs 为了安全 vs 为了省事 | 你为什么要这么做？不这么做会怎样？ |
| Expected | 结果预期、性能期望、交互反馈 | 操作后2秒内生效，App通知确认 | 你希望做完之后看到什么？ |
| Cannot | 限制条件、禁止行为、异常情况 | 不许在睡眠模式下推送通知 | 什么情况是你绝对不能接受的？ |
3.3 从场景描述到边界要素的转换
采集到原始场景后，需要做一次“边界抽提”。以下案例展示一个智能灌溉场景的转换过程。
案例： 一位别墅业主说：“我每周六早上9点浇水，但如果那天下雨就不浇。我太太不想手机总响，所以我只希望在真正出问题（比如管道爆裂）时才报警。”
边界线索提取：
- Who → 业主（管理员权限），太太（免打扰角色）
- When → 每周六 09:00（定时触发），下雨天跳过（条件触发）
- Expected → 非紧急不推送；只推管道爆裂等高危告警
- Cannot → 禁止在非紧急时向太太推送通知；禁止在下雨天执行浇水
由这些线索直接落地成功能边界条目：
# 边界定义：智能灌溉告警策略
1. [规则] 每日浇水计划可配置“下雨跳过”开关（默认开启）。
2. [推送] 告警分级：高危（爆裂/传感器离线）→ 推送所有管理员；
低危（阀门未关/流量异常）→ 仅推送业主，且每日聚合一次。
3. [限制] 除高危告警外，22:00-07:00 静默，不推送任何消息。
4. [异常] 若连续3次浇水执行失败，自动推送给业主并暂停计划。3.4 边界线索挖掘的常见陷阱
用一张流程清单帮助你避开典型坑位。
| 陷阱 | 表现 | 纠正方法 |
|---|---|---|
| 笼统描述 | “用户希望更安全” | 追问：什么算安全？什么算不安全？有没有具体事件？ |
| 缺失角色 | 只聊业主，忽略物业、家人、访客 | 按“Who”维度逐一核对每个场景中涉及的所有人 |
| 遗漏 Cannot | 只采集正向期望，不采集禁止行为 | 直接提问：“你绝对不允许产品做什么？” |
| 混淆场景与时序 | 把安装场景和日常使用场景混在一起 | 将场景按生命周期阶段分开：配置→运行→维保→故障 |
3.5 场景采集与边界挖掘流程（SVG）
下图为完整的6W1H→边界要素→功能条目沉淀流程，每次访谈后可按此图快速整理。
3.6 实操：场景访谈边界挖掘清单
下面的清单可以作为每次用户访谈的随身检查表，避免漏掉关键线索。
- 开始前： 准备6W1H空白记录表，标注“Cannot”强提醒
- 访谈中： 每听完一段描述，追问“如果……会怎样？”（异常条件测试）
- 记录后： 当场标记哪些陈述属于“边界强约束”（直接关乎能不能做、做多少）
- 整理时： 按“功能边界条目”模板输出，每条带有“来源场景编号”可追溯
3.7 交付物模板：场景→边界映射表
每个章节有标准的交付物，本章交付物是一个结构化表格，随同需求文档一起提交。
模板结构：
1. 场景编号（S-001）
2. 原始场景描述（6W1H完整版）
3. 提取的边界要素（谁/哪/时/什么/为什么/期望/不能）
4. 边界条目草稿（供下一章节细化）
5. 访谈来源（用户ID/角色/日期）
1. 场景编号（S-001）
2. 原始场景描述（6W1H完整版）
3. 提取的边界要素（谁/哪/时/什么/为什么/期望/不能）
4. 边界条目草稿（供下一章节细化）
5. 访谈来源（用户ID/角色/日期）
质量红线： 边界条目必须对应至少一个“Expected”或“Cannot”来源。如果某条边界找不到场景来源，说明它是猜测，需要补访或标记为“待确认假设”。
3.8 实践工作坊：边采边挖
请选择一个你熟悉的IoT品类（如智能门锁、空气监测器、宠物喂食器），按以下步骤快速练习：
- 写出一个典型用户的使用场景（50字以内）
- 用6W1H拆解该场景，标注每个维度的关键词
- 提取至少3条“Cannot”线索
- 试写2条功能边界条目（用“如果……则……否则……”句式）