第3章 用户角色与痛点分析
工业IoT项目的需求必须从一线角色的真实工作场景中生长出来。本章聚焦操作工、设备维护员、车间主管、IT运维、产线经理五个核心角色，逐一拆解其岗位职责、日常触点与隐性痛点，并建立从用户语言到需求语言的映射路径。
3.1 用户场景与业务问题
每个角色在产线环境中的目标、工具链与决策链路各不相同，其痛点往往隐藏在重复性故障、信息延迟或跨角色协作断裂中。下表概括了五类角色的职责边界与典型业务问题：
| 角色 | 核心职责 | 典型业务问题 | 业务影响 |
|---|---|---|---|
| 操作工 | 设备启停、参数调整、首件检验 | HMI界面层级深，参数设置无防错提示，误操作导致停线 | 单次误操作平均造成15~30分钟产能损失 |
| 设备维护员 | 日常点检、故障维修、备件更换 | 故障定位依赖个人经验，维修记录纸质化，备件查找耗时 | MTTR（平均修复时间）超过行业基准40% |
| 车间主管 | 排产调度、异常处置、人员管理 | 生产进度依赖人工报表，异常告警通过电话层层通知，响应滞后 | 异常响应窗口期平均超过12分钟 |
| IT运维 | 网络规划、设备接入、系统安全 | 现场设备协议多达7种以上，数据孤岛严重，补丁管理困难 | 新设备接入周期平均2~3周 |
| 产线经理 | OEE管控、成本分析、改善决策 | OEE数据靠手工汇总，成本归集滞后，改善决策缺乏数据支撑 | OEE透明度低于60%，改善措施ROI难以量化 |
避坑提醒：不要直接采信“用户说出来的痛点”作为最终需求。操作工抱怨“屏幕不好用”的背后可能是数据录入频次过高或按键反馈缺失；设备维护员说“找不到备件”背后可能是备件编码体系缺失或库存数据未数字化。痛点是线索，不是答案。
3.2 角色‑痛点‑需求映射结构
下图为五类角色与核心痛点、需求方向之间的映射关系，帮助产品经理在访谈后快速完成“用户语言→业务语言→产品语言”的初步转换：
3.3 用户访谈设计
痛点不应来自猜测，而应来自结构化的用户访谈。针对每个角色设计差异化的访谈问题，才能挖出“场景‑行为‑归因”三层信息：
- 操作工：“请演示一次您最常做的参数修改操作，哪些步骤让您觉得容易出错？”
- 设备维护员：“回想最近一次较长的故障停机，您从接到报修到找到根因用了哪些步骤？卡在哪里？”
- 车间主管：“当产线出现异常时，您通常在第几分钟获得消息？信息来自哪里？”
- IT运维：“目前接入一台新设备需要哪些部门配合？最耗时的环节是什么？”
- 产线经理：“月度OEE报告从数据采集到您拿到手需要几天？您最想增加哪一项数据？”
访谈技巧：避免问“您需要什么功能”，而是问“您最近一次因为XX问题花了多久解决”。行为回忆比需求陈述更可靠，因为用户往往无法抽象出自己的真实需求，但能准确描述具体事件的卡点。
3.4 需求拆解：从痛点倒推产品特性
以设备维护员的痛点“故障定位慢”为例，演示如何从表层痛点拆解出可落地的产品需求：
- 业务场景拆解：维护员接到报修→查看设备报警代码→翻阅纸质手册→电话咨询老员工→逐步排查。
- 根因定位：报警代码含义不直观、历史故障案例未数字化、专家经验未被沉淀。
- 需求转换：
- 需求#1：设备报警时系统自动推送故障原因及处理建议（知识库关联）；
- 需求#2：支持按设备型号/故障码搜索历史维修记录；
- 需求#3：移动端拍照上传故障现象，系统基于图像识别推荐排查步骤。
- 优先级判断：需求#1 覆盖80%常见故障，实施周期短，定为首批迭代范围。
// 需求描述模板示例（以“智能故障诊断”为例）
需求ID: REQ-FAULT-001
需求标题: 故障码自动解析与处理建议推送
用户场景: 设备维护员在接到停机报警后，需要在2分钟内了解故障原因和处置步骤
验收标准:
- 系统能自动识别≥50种常见故障码，匹配准确率≥95%
- 从报警触发到推送建议的端到端延时 ≤5秒
- 建议内容包含：故障原因、影响范围、处置步骤、所需备件清单
数据来源: 设备PLC报警寄存器 + 历史维修工单库
前置条件: 设备已接入边缘网关，报警数据实时上传3.5 指标验证与验收标准
每个角色痛点是否真正被解决，需要定义可量化的验证指标。下表列出与五类角色痛点对应的核心指标：
| 角色 | 关键指标 | 基线（改进前） | 目标值（改进后） | 验证方式 |
|---|---|---|---|---|
| 操作工 | 参数设置单次耗时 | ≥45秒 | ≤15秒 | HMI操作埋点计时 |
| 设备维护员 | MTTR（平均修复时间） | ≥75分钟 | ≤45分钟 | 工单系统自动统计 |
| 车间主管 | 异常告警响应时间 | ≥12分钟 | ≤3分钟 | 告警系统时间戳追踪 |
| IT运维 | 新设备接入周期 | ≥15个工作日 | ≤3个工作日 | 设备接入流程计时 |
| 产线经理 | OEE数据获取时效 | ≥7天（月报） | ≤1天（日报） | 系统报表生成时间 |
3.6 交付物模板：用户需求文档（URD）片段
完成角色痛点分析后，应将关键发现固化到用户需求文档中，作为后续产品需求规格书（PRD）的依据。以下为第3章对应的URD模板结构：
# 用户需求文档（URD）- 工业IoT平台 v1.0
## 第3章 用户角色与痛点分析
### 3.1 角色定义矩阵
| 角色 | 岗位价值 | 关键任务 | 周边系统 |
|------|----------|----------|----------|
| 操作工 | 执行生产节拍 | 参数设置、启停操作 | HMI、MES报工 |
| 设备维护员 | 保障设备可用率 | 故障维修、点检保养 | CMMS、备件库 |
| 车间主管 | 达成当日产出 | 排产调度、异常应急 | MES看板、通讯工具 |
| IT运维 | 保障系统连通性 | 网络管理、设备接入 | SCADA、防火墙 |
| 产线经理 | 优化产线效率 | OEE分析、改善决策 | BI报表、财务系统 |
### 3.2 痛点证据清单
- 证据编号: P-OP-001 | 来源: 操作工访谈（3人） | 描述: 参数设置需翻3级菜单，12%的换型操作出现过输错
- 证据编号: P-MT-002 | 来源: 维护员工单分析（200条） | 描述: 45%的故障排查时间消耗在查找历史记录
### 3.3 需求映射表（痛点→特性）
| 痛点ID | 用户表述 | 根因 | 产品特性 | 优先级 |
|--------|----------|------|----------|--------|
| P-OP-001 | “界面太多层了” | 信息架构未按任务流组织 | 基于角色的快捷操作面板 | P0 |
| P-MT-002 | “查不到以前怎么修的” | 维修记录未结构化 | 全文检索 + 故障知识图谱 | P1 |
### 3.4 关键指标定义
（此部分引用 3.5 节指标表，明确每个指标的采集口径与计算逻辑）
### 3.5 用户验收场景
- 场景UAT-OP-01: 操作工在30秒内完成一次完整的参数修改操作
- 场景UAT-MT-02: 设备维护员通过移动端3步内查看到某故障码的历史维修案例
关键原则：用户需求文档（URD）只记录“谁在什么场景下遇到了什么问题”，不写技术方案。产品经理应克制住直接写“我们要做一个AI诊断模块”的冲动，先确保痛点描述准确、证据充分、指标明确。方案是后续PRD的事。