### 第4章：业务问题定义：问题描述模板、影响范围、数据佐证、干系人确认
#### 4.1 为什么需要“问题定义”？
在产品需求分析中，最容易犯的错误是“跳过定义直接给方案”。业务问题定义的目的，是把一个模糊的“不爽”或“痛点”，转化为结构化的、可量化、可共识的**业务问题陈述**。
未经定义的问题，会导致：
- 产品经理和业务方各说各话
- 需求方案上线后发现解决的是“假问题”
- 资源投入无法回溯验证
本章将提供一套**四要素问题定义模板**，并通过影响范围评估、数据佐证、干系人确认三个环节，让“问题”变成“可执行的输入”。
#### 4.2 问题描述模板（四要素）
任何业务问题，都必须用以下四个部分完整描述：
| 要素 | 说明 | 示例 |
|------|------|------|
| **痛点陈述** | 当前状态下的具体困难或障碍 | “客服无法在3分钟内定位用户历史订单” |
| **场景还原** | 问题发生在什么角色/环节/时机 | “每日10:00-12:00高峰时段，在线客服处理售后” |
| **现有应对** | 用户当前如何绕开问题 | “客服手动翻查5个后台页面，或转接给其他部门” |
| **期望效果** | 解决后应达到的可观测状态 | “客服在1次会话内，10秒内获取完整订单快照” |
**避坑提示**：痛点陈述不要写成“缺少某个功能”，而要写成“因为缺少某功能，导致用户需要做某件额外的事”。
#### 4.3 影响范围评估
问题定义的第二环，是回答“这个问题影响多大”。可以按三个维度量化：
1. **广度**：受影响用户/角色的数量或百分比
2. **频度**：问题每天/每周/每月发生的次数
3. **严重度**：单次问题造成的损失（时间、金钱、用户体验）
推荐使用 **P0-P4 分级** 界定优先级：
| 字段 | 描述 |
|------|------|
| P0 - 阻断 | 核心业务流程无法执行 |
| P1 - 严重 | 功能可用但导致大量用户流失或关键数据错误 |
| P2 - 中等 | 体验受损，有临时绕行方案 |
| P3 - 低 | 偶发或仅影响非关键路径 |
| P4 - 建议 | 未来优化空间，当前无明确影响 |
#### 4.4 数据佐证
“感觉有问题”不能作为决策依据。每个业务问题都必须附带至少一项可验证的数据。
数据来源类型：
- **日志/埋点数据**（如接口耗时、错误率、跳出率）
- **工单/提报记录**（如客服电话量、售后投诉分类）
- **人工抽样统计**（如用户操作耗时手工计时）
- **用户访谈/问卷**（如NPS评分、满意度分项）
> **数据佐证实例**
> 过去一个月，售后客服平均每次处理“订单查询”耗时 **4分18秒**，其中 **72%** 的时间花在页面间切换和数据拼合上。同一时段，用户因等待挂断的会话占比 **13%**。
#### 4.5 干系人确认
问题定义完成后，必须让受影响方和决策方达成一致。确认动作包括：
**干系人确认清单**
1. **问题真实存在**：受影响角色代表签字或邮件确认“描述符合实际”
2. **影响范围认可**：业务负责人同意所评估的广度/频度/严重度
3. **数据可信**：数据负责人确认样本量、口径、时间区间合理
4. **优先级共识**：决策者给出P级，或同意排期纳入后续规划
**典型干系人角色列表**
| 角色 | 关注点 |
|------|--------|
| 业务方（用户代表） | 痛点和场景是否真实，解决后是否真有用 |
| 数据产品/BI | 数据来源是否可靠，口径是否统一 |
| 开发负责人 | 是否存在技术约束或隐形成本 |
| 产品Leader | 优先级是否与业务目标对齐 |
模板核心实践： 每次问题定义会议结束后，输出一份 《业务问题定义归档表》，包含：问题ID、四要素描述、影响范围量化、数据佐证截图、干系人确认签名。后续需求拆解和验收都以此表为基准。
#### 4.6 业务问题定义四维模型
下图展示了业务问题定义的完整结构：从痛点出发，通过影响广度、频度、严重度三个维度量化定级，用数据佐证支撑判断，最后经干系人确认形成可执行的任务。