3. 业务问题拆解
3.1 为什么要先拆解业务问题？
很多数据产品团队跳过问题拆解直接画原型，导致交付的功能与业务真实痛点脱节。业务问题拆解是将模糊的"业务诉求"转化为可被数据产品解决的"结构化问题"的关键步骤。本章核心任务：
- 从业务目标出发：明确组织期望达成的可量化结果（如：降低客户流失率 5%）
- 问题定义框架：用标准模板把"痛点"写成可验证的问题陈述
- 根因分析：通过 5-Why 或因果链找到问题背后真正的驱动因素
- 问题影响面评估：量化问题规模，确定优先级（影响范围 × 紧急程度）
讲师提示： 拆解不充分时，原型的每一次迭代都是在"猜"业务方想要的到底是什么。以下方法论帮你从源头降低返工率。
3.2 问题定义框架：五要素法
将口头描述的"业务痛点"转化为结构化问题，推荐使用以下五要素模板：
| 要素 | 说明 | 示例（电商场景：退款率高） |
|---|---|---|
| 谁 | 问题涉及的干系人/角色 | 售后客服主管、财务对账员 |
| 现状 | 当前客观量化表现 | 退款率从 8% 上升至 15%，售后客服日均工单量增长 40% |
| 差距 | 期望状态与现状之间的差值 | 目标退款率 ≤ 5%，当前 15%，缺口 10% |
| 影响 | 不解决的显性/隐性成本 | 每月多损失 ¥300,000 退款额；客服人力成本增加 ¥80,000 |
| 解空间限制 | 不可调整的约束条件 | 不能降低客单价；不能延长退款处理时效至 48h 以上 |
3.3 根因分析：从表面症状到深层驱动
直接写需求往往只治疗症状。使用因果链拆解与5-Why追问找到真正可干预的根节点。以下以"退货率过高"为例展示流程：
5-Why 实操片段（针对批量退款异常）：
① 为什么退货率骤升？ → 用户投诉"收到的商品与描述不符"占比最高（50%）。
② 为什么描述不符？ → 部分商品的详情页图片与实物差异大，且无客观尺码辅助表。
③ 为什么图片与实物差异大？ → 审核流程中未强制要求上传实拍视频，多数商家用效果图替代。
④ 为什么审核不强制视频？ → 审核系统缺乏视频识别能力，只做图片合规检测。
根因定位： SKU 上架审核对实物一致性校验不足（缺视频、缺AI比对）。
数仓动作： 上线商品实拍视频解析指标；构建"图片-实物差异评分"模型。
① 为什么退货率骤升？ → 用户投诉"收到的商品与描述不符"占比最高（50%）。
② 为什么描述不符？ → 部分商品的详情页图片与实物差异大，且无客观尺码辅助表。
③ 为什么图片与实物差异大？ → 审核流程中未强制要求上传实拍视频，多数商家用效果图替代。
④ 为什么审核不强制视频？ → 审核系统缺乏视频识别能力，只做图片合规检测。
根因定位： SKU 上架审核对实物一致性校验不足（缺视频、缺AI比对）。
数仓动作： 上线商品实拍视频解析指标；构建"图片-实物差异评分"模型。
3.4 问题影响面评估矩阵
在确认根因后，需要从影响范围与紧急程度两个维度给问题打分，决定数据产品原型的排期优先级。
| 维度 | 低（1分） | 中（3分） | 高（5分） |
|---|---|---|---|
| 影响范围 | 仅影响单个用户/偶尔发生 | 影响部分用户/每周影响 | 影响核心用户/每日影响 |
| 紧急程度 | 可延期到下季度 | 应在本月内解决 | 出现即造成重大损失或合规风险 |
| 综合评分 | 1~4 低优先级 | 5~12 中优先级 | 13~25 高优先级 |
避坑提醒： 根因分析不要止于“技术原因”（如系统卡顿），而要继续追问“为什么系统卡顿”背后是否存在数据量暴增、缓存未命中、索引缺失等真实可度量因素。只有根因是可被数据产品或数据治理动作直接干预的，才值得投入原型设计。
3.5 交付物模板：问题拆解文档
每次拆解产出应包含以下结构，以便后续访谈与需求拆解阶段复用：
# 问题拆解模板（Markdown 格式）
## 1. 业务目标
目标描述（含量化指标、时间窗口）
## 2. 问题定义（五要素）
- 谁：主要干系人
- 现状：当前数据
- 差距：期望-现状
- 影响：量化损失
- 解空间限制：不可变约束
## 3. 根因分析（因果链）
- 第一层症状
- 第二层直接原因
- 第三层深层原因
- 根因（可被数据系统干预的点）
## 4. 影响面评估
- 影响用户数/业务量
- 月度/年度损失预估
- 紧急度评级（P0/P1/P2）
- 建议优先级：高/中/低