客户需求与功能需求映射

概述

本节介绍如何将 JTBD 方法论应用于 IoT 项目的需求分析流程，建立客户需求（业务语言）与功能需求（技术语言）之间的映射关系。学习完成后，您将能够：

将客户模糊的业务诉求转化为结构化的功能需求
构建 JTBD → 业务需求 → 功能需求 → 技术方案的映射链
使用需求优先级矩阵（Importance × Satisfaction）筛选功能
在售前场景中用 JTBD 驱动需求确认与方案定制

前置要求

在开始本节之前，请确保：

已完成上一节”JTBD 方法概述与核心概念”的学习
了解 IoT 系统的基本技术栈（传感器 → MQTT → Node-RED → 数据库 → 可视化）
有实际的客户需求或模拟的售前场景

核心概念

需求断层问题

IoT 项目中最常见的失败模式之一是需求断层：

客户说的话                →  "我们想要一个智能工厂"
产品经理理解的需求        →  "部署传感器监控系统"
工程师实现的功能          →  "ESP32 + DHT22 + MQTT + Grafana"
客户最终看到的交付物      →  "一堆仪表盘，但我不知道怎么用..."

这种断层的根本原因是：从客户诉求到技术实现之间缺少系统化的翻译机制。JTBD 提供了一个结构化的桥梁。

四层需求映射模型

┌─────────────────────────────────────────────────┐
│  Layer 1: JTBD（客户的任务）                      │
│  "我希望产线出现异常时第一时间知道"                  │
├─────────────────────────────────────────────────┤
│  Layer 2: 业务需求（Business Requirements）       │
│  "实时告警 + 异常分类 + 响应跟踪"                  │
├─────────────────────────────────────────────────┤
│  Layer 3: 功能需求（Functional Requirements）     │
│  "阈值告警引擎 + 多级通知 + 告警日志 + 处理工单"    │
├─────────────────────────────────────────────────┤
│  Layer 4: 技术方案（Technical Solution）          │
│  "Node-RED 告警流 + Telegram Bot + InfluxDB"     │
└─────────────────────────────────────────────────┘

每一层都回答不同的问题：

Layer 1: Why — 客户为什么要做这件事？
Layer 2: What — 客户需要什么样的能力？
Layer 3: How（功能层） — 系统需要提供什么功能？
Layer 4: How（技术层） — 用什么技术实现？

映射工作坊

将客户需求映射到功能需求，推荐采用映射工作坊的形式：

参与角色：

客户方：决策者 + 实际使用者
服务方：产品经理（引导者） + 技术负责人

工作坊流程：

Step 1: 需求收集（30 min）
    → 让客户描述日常工作中的问题和期望
    → 用 JTBD 访谈框架引导

Step 2: Job Statement 提炼（20 min）
    → 从访谈记录中提取 Job Statements
    → 客户确认和排序

Step 3: 业务需求拆解（30 min）
    → 每个 Job 对应哪些业务能力
    → 识别关键约束和成功标准

Step 4: 功能需求映射（40 min）
    → 将业务需求翻译为系统功能
    → 标注实现复杂度和依赖关系

Step 5: 优先级确认（20 min）
    → 用重要性×满意度矩阵筛选
    → 确定 MVP 范围和迭代计划

实践：IoT 需求映射全流程

案例背景

某化工厂需要部署环境监测系统。客户的核心诉求是：

满足安监部门的合规要求
减少因环境异常导致的安全事故
降低人工巡检成本

Step 1: JTBD 提取

通过客户访谈，提取以下 Job Statements：

编号	类型	Job Statement
J1	功能性	当车间气体浓度超标时，我希望立即收到告警，以便在事故发生前采取疏散措施
J2	功能性	当我需要向安监部门提交报告时，我希望能自动生成合规报表，以便节省人工整理数据的时间
J3	功能性	当设备运行状态变化时，我希望能追溯历史数据，以便分析事故根因
J4	情感性	我希望在值班时心里有底，知道系统替我盯着一切
J5	社会性	我希望安监部门检查时，能展示一套专业的数字化管理系统

Step 2: 业务需求拆解

JTBD	业务需求	成功标准
J1	实时气体浓度监控 + 多级告警	从浓度超标到收到告警 ≤ 30 秒
J2	自动数据采集 + 合规报表生成	月度报表生成时间 ≤ 5 分钟
J3	历史数据存储 + 多维度查询	支持最近 12 个月的数据追溯
J4	7×24 自动监控 + 状态总览	值班人员无需人工巡检
J5	可视化大屏 + 系统演示能力	检查时可在 3 分钟内展示系统

Step 3: 功能需求映射

业务需求	功能需求	技术实现	复杂度
实时气体浓度监控	传感器数据采集（1s 采样）	ESP32 + MQ-135 + MQTT	低
多级告警	阈值告警引擎（预警/报警/紧急）	Node-RED 告警流	中
多级告警	多通道通知（短信/邮件/声光）	Telegram Bot + 邮件 + 蜂鸣器	中
合规报表生成	数据聚合 + PDF 报表导出	Node-RED + Puppeteer	高
历史数据追溯	时序数据存储 + 查询 API	InfluxDB + Grafana	中
可视化大屏	实时监控看板	Grafana Dashboard	中
状态总览	设备在线状态 + 告警统计	Node-RED + Grafana	低

Step 4: 优先级矩阵

使用重要性 × 满意度矩阵确定功能优先级：

重要性（Importance）
  高 │  [机会区]              │  [必做区]
     │  合规报表              │  实时告警
     │  事故追溯              │  浓度监控
  中 │  [低优先区]            │  [过度满足区]
     │  设备管理后台           │  多通道通知
     │  移动端 App            │  大屏可视化
  低 │                        │
     └────────────────────────┼────────────────────
        低          中          高
                      满意度（Satisfaction）

象限解读：

必做区（高重要性 + 低满意度）：MVP 必须包含的核心功能
机会区（高重要性 + 低满意度）：差异化竞争的机会
过度满足区（低重要性 + 高满意度）：避免过度投入
低优先区（低重要性 + 低满意度）：后续迭代考虑

映射结果输出

最终形成一份结构化的需求映射文档：

## 需求映射文档 — XX化工厂环境监测系统

### 1. 项目背景
- 客户：XX化工厂
- 核心任务：满足安监合规 + 减少安全事故 + 降低巡检成本

### 2. JTBD 清单
- J1: 实时告警（功能性，优先级：必做）
- J2: 合规报表（功能性，优先级：机会）
- J3: 历史追溯（功能性，优先级：机会）
- J4: 值班安心感（情感性，优先级：必做）
- J5: 数字化形象（社会性，优先级：必做）

### 3. MVP 功能范围
| 功能 | 对应 JTBD | 复杂度 | 工期估算 |
|------|----------|-------|---------|
| 传感器采集 | J1 | 低 | 3 天 |
| MQTT 传输 | J1 | 低 | 1 天 |
| 告警引擎 | J1, J4 | 中 | 5 天 |
| 多通道通知 | J1, J4 | 中 | 3 天 |
| 实时看板 | J4, J5 | 中 | 3 天 |
| 大屏展示 | J5 | 中 | 2 天 |

### 4. 二期功能
- 合规报表自动生成
- 历史数据追溯分析
- 移动端 App

需求追溯矩阵（RTM）

为确保每个功能都有对应的客户需求，每个需求都有可验证的交付物，使用需求追溯矩阵：

需求ID	JTBD	业务需求	功能需求	设计文档	测试用例	状态
R1	J1	实时浓度监控	1s 采样 + MQTT 上报	DD-01	TC-01~03	✅
R2	J1	多级告警	阈值引擎 + 3 级告警	DD-02	TC-04~08	✅
R3	J2	合规报表	PDF 导出 + 模板	DD-03	TC-09~12	🔲
R4	J3	历史追溯	InfluxDB + 查询 UI	DD-04	TC-13~16	✅
R5	J5	可视化大屏	Grafana 看板	DD-05	TC-17~19	✅

常见映射陷阱

陷阱 1: 跳过 JTBD 直接定义功能

❌ 客户说："我们要一个 IoT 系统"
❌ 直接开始设计功能列表
✅ 先问："您想用 IoT 系统完成什么任务？"

陷阱 2: 功能堆砌

❌ "我们的系统有 50 个功能模块！"
✅ "我们的系统针对您的 5 个核心任务，提供了完整的支持"

陷阱 3: 忽略情感性/社会性任务

❌ 只展示技术指标："告警延迟 < 1s"
✅ 同时回应情感需求："让您 7×24 放心，系统替您盯着一切"

陷阱 4: 映射断裂

❌ 有功能但没有对应的客户需求（自嗨型功能）
❌ 有需求但没有对应功能（承诺落空）
✅ 每个功能都能追溯到客户需求，每个需求都有功能支撑

验证

验证对需求映射的掌握：

方法论理解
- 能解释四层需求映射模型的每一层
- 能使用优先级矩阵对功能进行分类
实践操作
- 能从一个客户场景提取 5 条以上的 Job Statements
- 能完成从 JTBD 到技术方案的完整映射
- 能生成一份结构化的需求映射文档
售前应用
- 能在售前沟通中使用 JTBD 引导客户需求
- 能用映射结果构建有说服力的方案报价

最佳实践

✅ 推荐: 每次项目启动前完成一次需求映射工作坊
✅ 推荐: 用需求追溯矩阵确保需求-功能的双向覆盖
✅ 推荐: 将情感性和社会性任务显式写入方案文档
✅ 推荐: MVP 优先覆盖”必做区”功能，快速验证价值
❌ 避免: 客户说什么就做什么（要挖掘深层任务）
❌ 避免: 功能越多越好（聚焦于完成任务的功能）
❌ 避免: 技术团队直接面对客户原始需求（需要产品经理翻译）

Summary

本节要点总结：

需求断层是 IoT 项目的核心风险
- 从客户诉求到技术交付之间需要系统化的翻译机制
四层映射模型连接业务与技术
- JTBD → 业务需求 → 功能需求 → 技术方案
- 每一层回答不同的问题（Why → What → How）
优先级矩阵指导 MVP 范围
- 重要性 × 满意度矩阵筛选核心功能
- 必做区优先，机会区差异化
需求追溯矩阵保障完整性
- 每个功能追溯到客户需求
- 每个需求有对应的功能支撑和验证
映射工作坊是协作的核心形式
- 客户方 + 服务方共同参与
- 结构化流程确保高效产出

References

Ulwick, A. W. (2016). Jobs to Be Done: Theory to Practice — Chapter 5: “The Job Map”
Switch Interview Technique - Christensen Institute
Requirements Traceability Matrix Best Practices
Kano Model and JTBD Integration

正在开发商业 IoT 产品？

我们提供 ESP32 ODM 定制设计与制造服务。从原型到量产——编写这套教程的团队，可以和你一起实现。

联系我们 →