第4章 业务问题建模：问题树拆解、根因分析、影响范围评估
业务问题建模是需求分析从「收集」走向「结构化」的关键转折点。未经建模的问题陈述往往停留在用户抱怨或表面现象层面——每个利益相关方都觉得自己描述的问题才是真相，但没有人能说清问题的边界、层级和根本原因。本章围绕三个核心方法展开：问题树拆解（让问题可枚举、可分层）、根因分析（穿透表象找到真因）、影响范围评估（量化问题波及面），帮助你把模糊的业务痛点转化为结构化的需求输入。
典型用户场景：你刚完成一轮用户访谈，笔记里记录了20多条用户抱怨，包括「系统太慢」「数据对不上」「审批流程卡住了」「权限不够用」……利益相关方催促你出PRD，但你连问题的边界都没摸清。此时你需要一套建模方法，把这些零散的痛点和诉求组织成可分析、可决策的结构化问题体系。
4.1 问题树拆解：MECE分层
问题树拆解的核心原则是 MECE（Mutually Exclusive, Collectively Exhaustive）——子问题之间相互独立、完全穷尽。这一步骤将模糊的根问题逐层分解为可分析、可行动的叶子节点，同时为后续的用户访谈提纲设计提供结构化框架。
标准拆解流程包含四个步骤：
- 定义根问题：用一句话说清「谁在什么场景下遇到了什么阻碍」，例如「运营人员在批量导出数据时频繁超时」。
- 识别拆解维度：按「用户流程」「数据交互」「权限策略」「系统性能」等维度划分第一层子问题。
- 逐层拆解至叶子节点：每个子问题继续向下拆解2-3层，直到节点可被单个团队/功能独立验证。
- 验证MECE完整性：检查是否有遗漏维度或子问题重叠，可通过反向测试（「如果不解决这个子问题，根问题是否仍存在？」）确认。
| 层级 | 问题描述 | 归属维度 | 可进一步拆解 |
|---|---|---|---|
| L1 | 导出操作步骤过多 | 用户流程 | 是 |
| L2 | 筛选条件设置繁琐 | 用户流程 | 否（叶子节点） |
| L2 | 导出格式不支持直接使用 | 用户流程 | 否（叶子节点） |
| L1 | 大数据量导出超时 | 系统性能 | 是 |
| L2 | 单次导出上限1000条 | 系统性能 | 否（叶子节点） |
| L1 | 导出字段与业务需求不匹配 | 数据交互 | 是 |
| L2 | 缺少自定义字段映射 | 数据交互 | 否（叶子节点） |
访谈驱动提示：问题树拆解完成后，可将叶子节点转化为下一轮用户访谈的 probing 问题。例如叶子节点「筛选条件设置繁琐」对应的访谈问题可以是：「您能演示一次完整的筛选操作吗？哪一步让您觉得最耗时？」
4.2 根因分析：5 Whys 与鱼骨图
问题树拆解得到的是问题「是什么」，但 PRD 需要回答「为什么」。根因分析通过追问链条或因果图，从表象问题逐级下钻，找到可消除的根本原因。常用的方法有 5 Whys（连续追问5个「为什么」）和 鱼骨图（从人、机、料、法、环等维度排查）。
5 Whys 的标准操作步骤：
- 明确表象问题：从问题树的叶子节点出发，例如「导出操作步骤过多」。
- 第一问：为什么步骤多？→ 因为用户需要先进入三个不同页面配置参数。
- 第二问：为什么参数配置分散在三个页面？→ 因为参数分属不同系统模块。
- 第三问：为什么不能聚合到同一个页面？→ 因为各模块数据表结构不统一。
- 第四问：为什么表结构不统一？→ 因为早期没有制定数据字典规范。
- 第五问：为什么没有数据字典规范？→ 因为项目初期未设数据治理角色。
当追问到达「组织角色缺失」「流程制度空白」「技术架构遗留」层面时，通常就找到了可行动的根本原因。
常见误区：5 Whys 不等于机械地追问5次，而是「一直追问到问题能被团队行动解决为止」。如果追问3次就找到了明确的修复方向（例如「更新前端校验库」），不需要强行凑够5次。反之，如果追问7次才触及制度层面，就继续追。
案例：从用户抱怨到根因
用户访谈摘录：「每次提加班审批都要等2-3天，很耽误事。」
→ 问题树叶子节点：审批流程耗时过长
→ 5 Whys 链条：审批流程长 → 需要三级审批 → 第三级审批人经常出差不看系统 → 审批人未收到移动端通知 → 系统未对接企业微信消息通道
→ 根本原因：审批通知渠道单一，缺少移动端实时推送。解决方向：接入企业微信审批提醒，或提供审批人临时委托功能。
用户访谈摘录：「每次提加班审批都要等2-3天，很耽误事。」
→ 问题树叶子节点：审批流程耗时过长
→ 5 Whys 链条：审批流程长 → 需要三级审批 → 第三级审批人经常出差不看系统 → 审批人未收到移动端通知 → 系统未对接企业微信消息通道
→ 根本原因：审批通知渠道单一，缺少移动端实时推送。解决方向：接入企业微信审批提醒，或提供审批人临时委托功能。
4.3 影响范围评估
根因分析找到了「为什么」，但产品经理还需要回答「影响有多大」——这决定了问题的优先级和投入产出比。影响范围评估从 用户量级、功能模块、业务流程 三个维度量化问题的波及面，为 PRD 中的需求优先级排序提供数据支撑。
| 评估维度 | 评估内容 | 数据来源 | 影响等级示例 |
|---|---|---|---|
| 用户量级 | 受影响用户数 / 月活占比 / 用户角色分布 | 用户访谈、数据分析平台、工单统计 | P0：影响核心用户 >30% |
| 功能模块 | 受影响功能数量 / 功能重要性 / 上下游依赖 | 系统架构图、功能清单、接口文档 | P1：影响 2-3 个核心模块 |
| 业务流程 | 影响业务环节数 / 流程关键程度 / 合规风险 | 业务流程图、SOP 文档、合规审计 | P2：影响非关键环节且可绕过 |
评估完成后，将每个根因问题按「用户量级 × 功能模块 × 业务流程」综合打分，产出 问题-影响矩阵，直接用于 PRD 中的需求优先级排序和版本规划。