3. 用户反馈收集流程总览

本章从全局视角构建 EVT 阶段用户反馈收集的标准操作流程(SOP)。通过明确流程框架、关键节点、输入输出物以及责任角色,确保团队在验证早期能够高效、无遗漏地捕获用户痛点,并为设计修正提供可追溯的一手证据。

适用范围说明:本流程适用于所有进入 EVT 阶段、已具备可工作原型且需面向目标用户群体(内测/种子用户/合作伙伴)进行现场或远程体验验证的硬件产品项目。

3.1 流程框架总览

完整的用户反馈收集流程共包含 8 个核心节点,从“启动任务”到“归档结案”,形成一个闭环。每个节点都有严格的输入/输出物与责任边界。

EVT阶段用户反馈收集流程框架图 1️⃣ 启动验证任务 2️⃣ 下发反馈模板 3️⃣ 用户体验 & 数据采集 4️⃣ 反馈初步分类 5️⃣ 硬件Bug确认 6️⃣ 设计修正 7️⃣ 二次验证闭环 8️⃣ 归档 & 知识沉淀 说明:节点1→4为采集阶段(产品工程验证+项目经理主导),节点5→7为修正闭环阶段(研发+测试主导),节点8为全流程归档。

3.2 关键节点详解

节点编号 节点名称 核心操作 预期时长
1 启动验证任务 产品经理向指定用户群发布验证任务确认函,同时组建反馈评审小组(含硬件、ID、测试)。 1 个工作日
2 下发反馈模板 使用统一的结构化模板,包含:使用场景、操作步骤、故障现象、严重度分级(P0~P3)。 0.5 个工作日
3 用户体验 & 数据采集 用户在受控环境(实验室/指定场景)中按脚本操作,记录日志、视频和问卷。 3–5 个连续工作日
4 反馈初步分类 工程验证(EVT)负责人按 硬件问题、结构干涉、散热/电气、可用性 四大类别打标。 1 个工作日
5 硬件 Bug 确认 硬件团队根据分类结果进行复现、量测,输出《Bug 确认报告》。 2 个工作日
6 设计修正 责任工程师(结构/电子/工艺)制定修改方案,输出新的 ED/ECN 变更通知。 3–5 个工作日
7 二次验证闭环 更新样机后由原用户或测试工程师执行回归验证,签字确认。 2 个工作日
8 归档 & 知识沉淀 将完整反馈链路、修正前后对照、经验教训录入 PLM 系统。 0.5 个工作日

3.3 输入输出物清单

每个节点必须产生明确的交付物,作为流程审计和回溯的依据。下表列出各节点核心输入/输出物。

节点 输入物 输出物
1 EVT 样机清单、用户名单、受控测试环境说明 《验证任务启动书》
2 结构化反馈模板(空白版) 已派发的模板记录(含用户回执)
3 体验脚本、录屏工具、温度/电流采集设备 原始日志、脱敏视频、填写完成的模板
4 所有原始采集物 《反馈分类汇总表》(按P0/P1/P2/P3分色标记)
5 分类汇总表 《硬件 Bug 确认报告》(含复现步骤、实测数据)
6 Bug 确认报告 修改方案、ECN 变更单、变更后的 2D/3D 图
7 变更后的样机、回归测试用例 《二次验证签字确认单》
8 所有节点输出物 PLM 归档记录 + 《Lesson Learn》卡片

3.4 责任角色分工

角色定义遵循 RACI 原则:R=负责执行,A=审批/最终责任,C=必须被咨询,I=知会。

流程节点 产品经理 硬件/结构工程师 测试工程师 项目经理
1 启动任务 R I I A
2 下发模板 R I C A
3 采集 C I R A
4 初步分类 R C C A
5 硬件 Bug 确认 I R C A
6 设计修正 C R I A
7 二次验证 C C R A
8 归档 I I I R/A
边界规则:项目经理是每个节点的最终审批人(A),确保流程不被跳过;产品经理对分类准确性负第一责任;硬件/结构工程师只对确认后的 Bug 出具修改方案,不参与分类环节。

3.5 前置条件与准入标准

  • 硬件前置:EVT 样机累计运行无致命故障时长 ≥ 72 小时(连续稳定性测试通过)。
  • 文档前置:已签署《用户保密协议》(NDA) 和《知情同意书》。
  • 环境前置:受控实验室温湿度、供电、网络已校准并记录基线。
  • 人员前置:至少配备 1 名专职测试工程师 + 1 名产品经理现场陪同。

3.6 异常处理预案

常见异常及响应:
• 用户反馈信息严重不足(缺故障复现步骤): 立即由测试工程师在 4 小时内发起远程/现场补采,不允许跳过节点 4 直接分派至研发。
• 反馈重复或冲突(不同用户描述相同问题但严重度不一): 由产品经理牵头召开 30 分钟快速评审会,统一 P 级定级后再进入节点 5。
• 硬件 Bug 确认无法复现: 标记为“弱证据”,暂不启动设计修正,但需在归档阶段记入《待排查清单》。
• 二次验证周期超过 2 周: 项目经理需发起变更评审,明确延迟对 EVT 里程碑的影响,并更新项目计划。

3.7 验收标准

流程执行结束后,需满足以下全部条件方可视为闭环:

  1. 流程覆盖率:100% 的反馈条目均已走完节点 1→8,无遗漏。
  2. 文档完整性:每个节点输出物均上传至项目 PLM 系统,命名规范符合《EVT 文档标准》(%项目代码%_%日期%_%节点编号%_%版本%.pdf)。
  3. 二次验证通过率:P0/P1 级别硬件问题修正后二次验证通过率 ≥ 95%;P2/P3 类问题修正后通过率 ≥ 80%。
  4. 固化经验:至少产出 1 份《Lesson Learn》卡片并经由技术委员会签收。

3.8 记录材料模板示例

以下为节点 3 中必须填写的统一反馈模板结构,用户每次体验后需在 30 分钟内完成提交:

---
### EVT用户反馈记录卡 ###
用户编号:U_0001         设备编号:P3-2025-EVT-009
体验场景:高负载连续渲染 30 分钟

1. 故障现象描述(必填):
   设备正面右上角温度触感明显烫手,金属边框温度实测 48℃。

2. 影响严重度:
   [ ] P0 – 系统崩溃/数据丢失
   [ ] P1 – 核心功能无法使用
   [x] P2 – 影响体验但可容忍
   [ ] P3 – 建议改进

3. 复现操作步骤:
   ① 打开渲染软件,载入 200M 模型;
   ② 设置渲染帧率为 60FPS,连续运行;
   ③ 约 22 分钟开始感到明显升温。

4. 附件:红外热成像图 2 张(文件路径:/evt_log/009_thermo.jpg)

5. 软硬件版本:
   FW: v2.3.1-beta; 驱动: 2025-04-11-01; 外壳批次: B3
---
SOP 最佳实践:建议 EVT 阶段每日 17:00 由产品经理汇总当天反馈分类表,并同步给硬件团队与项目经理,确保问题“不过夜”。重大 P0 问题触发 2 小时紧急响应机制,直接进入节点 5 硬件 Bug 确认,不受时间窗口限制。