第2章 · 业务痛点预诊断：前置条件、历史数据收集、关键干系人识别、初步问题清单
章节定位：业务痛点预诊断是正式访谈前的“侦察”环节。目标是在不打扰一线干系人的前提下，利用已有信息快速勾勒出业务痛点的轮廓，为后续访谈提纲设计提供方向，避免访谈时“从零开始”提问。
2.1 适用场景
业务痛点预诊断并非所有项目的必经阶段，但在以下四类场景中强烈建议执行：
| 场景类型 | 典型表现 | 不执行的风险 |
|---|---|---|
| 新业务域进入 | 团队首次接手该行业或职能域，业务术语、关键角色、核心流程均不熟悉 | 访谈问题流于表面，被访者认为“你根本不了解我们的业务” |
| 痛点扩散模糊 | 业务方反馈“到处都是问题”，但无法说清优先级和核心矛盾 | 访谈范围失控，资源被分散到大量低价值议题上 |
| 历史信息丰富 | 已有大量工单、客诉、运营报表、审计报告等二手数据 | 重复造轮子，忽视已有洞察，增加业务方参与成本 |
| 干系人关系敏感 | 涉及跨部门利益冲突或历史遗留问题，直接访谈可能引发防备 | 访谈中收到“官方口径”，无法触及真实的业务痛点 |
2.2 前置条件
进入预诊断前，必须确认以下四项基础条件已就绪，否则预诊断结果可能失真或无法落地：
- 项目授权已确认：获得明确的书面或口头授权，知晓可调用的资源范围和保密等级。
- 业务接口人已指定：至少有一位熟悉业务全局的接口人，能在1小时内响应基础问题。
- 基础文档已获取：组织架构图、岗位职责说明、近3个月的运营/工单/投诉数据（如存在）。
- 预诊断时间窗口已锁定：团队需预留 2~5 个工作日专注完成预诊断，不被打断。
最佳实践：在项目启动会上直接向业务方提出“预诊断清单”（包含所需文档、接口人、时间承诺），作为启动会交付物之一，避免后续反复沟通。
2.3 操作步骤
业务痛点预诊断按“收集 → 识别 → 聚焦”三段式展开，共5个步骤：
| 步骤 | 操作名称 | 关键动作 | 产出物 |
|---|---|---|---|
| Step 1 | 历史数据采集 | 收集工单系统、客诉记录、运营月报、审计报告、过往调研报告等，按时间倒序整理 | 数据收集清单 + 原始数据包 |
| Step 2 | 数据标签化与聚类 | 对每一条数据进行“问题类型 + 发生环节 + 频次”三字段标注，形成高频词云 | 数据标注表 + 频次分布图 |
| Step 3 | 关键干系人识别 | 基于组织架构 + 数据中提及的角色 + 接口人推荐，建立干系人地图 | 干系人识别表 + 影响力-兴趣矩阵 |
| Step 4 | 初步问题清单编制 | 将聚类后的高频痛点按“问题描述 → 影响范围 → 疑似根因 → 数据佐证”结构化输出 | 初步问题清单（草案） |
| Step 5 | 预诊断报告（内部） | 团队内部评审清单，标记“需访谈验证”和“可直接确认”两类痛点 | 预诊断报告（内部版） |
2.4 输入输出物
| 类别 | 输入物（来源） | 输出物（去向） |
|---|---|---|
| 文档类 | 项目立项书、组织架构图、岗位职责手册、过往调研报告（如有） | 数据收集清单（已标注）、原始数据包（加密归档） |
| 数据类 | 工单系统导出（近3月）、客诉记录、运营月报、审计报告 | 数据标注表 + 频次分布图（用于内部讨论） |
| 人员类 | 业务接口人推荐名单、组织架构中的关键角色列表 | 干系人识别表 + 影响力-兴趣矩阵（指导访谈排序） |
| 清单类 | （无） | 初步问题清单（草案）→ 进入访谈提纲设计环节 |
2.5 责任边界
| 角色 | 职责范围 | 不承担的责任 |
|---|---|---|
| 用户研究团队 | 数据采集、标签化、干系人识别、问题清单编制、内部预诊断报告输出 | 不负责验证数据真实性（由业务方确认）、不代替业务方做优先级决策 |
| 业务接口人 | 提供文档清单、推荐关键干系人、解答基础业务疑问、审核初步问题清单 | 不承担数据标注工作、不替代一线干系人发表意见 |
| 项目经理 | 协调资源、确认预诊断时间窗口、组织内部评审会 | 不参与具体的数据聚类和干系人分析工作 |
常见责任混淆：预诊断阶段的研究团队不应直接向业务方输出“最终问题清单”，该清单仅为内部假设。正式访谈后才形成经过验证的痛点清单。过早对外输出未验证的结论会引发信任风险。
2.6 记录材料
本章执行过程中需归档以下4份记录材料，作为项目过程资产：
| 材料名称 | 内容要点 | 格式要求 | 保管期限 |
|---|---|---|---|
| 数据收集清单 | 数据来源、时间范围、数据量、获取状态（已得/待申请/不可用） | Excel 或 Sharepoint 列表 | 项目完结后12个月 |
| 数据标注表 | 每条数据的原始内容摘要、问题类型标签、发生环节、频次 | 结构化表格（CSV 导出） | 项目完结后6个月 |
| 干系人识别表 | 姓名、角色、所属部门、与业务流程的关系、影响力评分、兴趣评分 | Excel + 矩阵可视化 | 项目完结后12个月 |
| 初步问题清单 | 问题描述、影响范围、疑似根因、数据佐证（引用数据编号）、验证状态 | Word 或 在线文档 | 项目完结后24个月 |
2.7 异常处理
| 异常情形 | 判定标准 | 处理措施 |
|---|---|---|
| 历史数据严重缺失 | 近3个月内有效数据记录 < 50条，或关键业务环节无数据覆盖 | 启动“快速访谈替代方案”：与接口人安排2~3次30分钟的快访，人工补充痛点描述 |
| 干系人识别困难 | 接口人无法明确推荐关键角色，或推荐的干系人超80%未直接参与业务 | 采用“组织架构 + 工单责任人”双路径交叉识别，扩大初筛范围至2~3轮 |
| 数据标签不一致 | 不同成员对同一数据的标签归类分歧率 > 30% | 立即召开15分钟对齐会，统一标签定义字典（Domain Dictionary），重新标注 |
| 业务方过度介入 | 业务方要求直接修改问题清单或删除某些痛点条目 | 明确预诊断阶段的“内部假设”定位，所有修改须以数据佐证为基础，拒绝无依据删改 |
| 时间窗口不足 | 预诊断可用工作日 < 2天 | 缩小数据采集范围至“工单+投诉”两类核心源，放弃运营月报和审计报告（优先级最低） |
2.8 验收标准
预诊断阶段结束后，由项目经理和业务接口人共同确认以下5项验收标准全部达标，方可进入第3章（访谈提纲设计）：
| 序号 | 验收条目 | 达标判定依据 |
|---|---|---|
| 1 | 数据收集完成度 ≥ 85% | 数据收集清单中“已得”占比 ≥ 85%，且覆盖所有核心业务环节 |
| 2 | 数据标签化一致性 ≥ 90% | 随机抽取20条数据，双人独立标注一致率 ≥ 90% |
| 3 | 关键干系人识别完整度 ≥ 90% | 干系人识别表中，被接口人认可的“必须访谈”角色占比 ≥ 90% |
| 4 | 初步问题清单条目 ≥ 5 条且 ≤ 15 条 | 清单覆盖至少3个业务环节，每条均包含“数据佐证”字段 |
| 5 | 预诊断报告已内部评审通过 | 项目团队完成内部评审，且无“数据不可信”或“逻辑矛盾”的未关闭意见 |
检查清单（Chapter 2 完成自查）：
- ☐ 已获取至少 3 类历史数据源并完成标注
- ☐ 干系人识别表已包含 5~8 位关键角色
- ☐ 初步问题清单已标记“待验证”和“可直接确认”两类
- ☐ 所有输出物已归档至项目共享空间
- ☐ 异常处理记录已更新（如遇异常情形）