业务问题定义：问题陈述框架、痛点优先级矩阵、影响范围评估
在 PRD 到原型的映射过程中，业务问题定义是需求分析的起点。本章围绕三个核心工具展开：问题陈述框架（Problem Statement Framework）、痛点优先级矩阵（Pain Point Priority Matrix）和影响范围评估（Impact Scope Assessment）。三者共同构成从模糊用户反馈到可量化业务问题的结构化路径。
关键原则： 用统一的问题陈述结构锁定问题核心，用优先级矩阵筛选高价值痛点，再用影响范围评估确认改动边界。三个步骤缺一不可。
问题陈述框架
问题陈述框架将每次用户反馈或业务痛点转化为结构化的描述，避免“用户觉得不好用”这类模糊语言。推荐使用以下五要素模板：
| 要素 | 描述 | 示例 |
|---|---|---|
| 用户角色 | 明确执行该任务的具体用户类型 | 仓库拣货员 |
| 当前行为 | 用户为了解决需求正在做什么 | 用手持终端扫描每件货物并手动输入货架号 |
| 痛点 | 当前行为带来的直接损失或障碍 | 每日多出 45 分钟手动输入时间，出错率 8% |
| 期望 | 用户希望达到的理想状态 | 扫描后自动定位货架，无需手动录入 |
| 业务影响 | 该痛点对业务指标的可量化损害 | 每年多支出 1200 小时人力，退货率因错发增加 3% |
写作提示： 每个问题陈述应控制在 50 词以内，聚焦单一场景。多场景必须拆分成多个独立问题陈述。
痛点优先级矩阵
当收集到多个问题陈述后，需要使用优先级矩阵排序。矩阵的两个维度为：痛点严重度（用户主观感受 + 业务损失）和 发生频率（影响用户数 × 每日/周/月发生次数）。
典型评分标准（1～5 分制）：
| 维度 | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| 严重度 | 轻度不便，可绕行 | 明显阻碍工作效率，需手动补偿 | 导致关键业务中断或合规风险 |
| 频率 | 少于 3 次/月，影响 ≤ 5% 用户 | 每周约 5 次，影响 15%～30% 用户 | 每天多次，影响 ≥ 60% 用户 |
优先级分数 = 严重度 × 频率。分数 ≥ 16 为 P0（必须解决），8～15 为 P1（应当解决），4～7 为 P2（可以推迟），≤ 3 为 P3（暂不处理）。
避坑： 不要仅凭“用户投诉声量”定优先级。用交叉打分替换主观排序，避免产品经理或业务方少数人的直觉主导需求列表。
影响范围评估
确定高优先级痛点后，需要评估修改该痛点会波及哪些系统、角色、流程和数据。影响范围评估通常包含四个维度：
- 功能影响：涉及的前端、后端、第三方集成模块
- 用户影响：需要接受培训或改变操作习惯的用户分组
- 数据影响：新增/修改的数据字段、API 接口、数据库表
- 流程影响：需要同步修改的线下 SOP、审批链路、通知规则
评估结果可记录为影响范围清单，每个条目标记“高/中/低”风险。例如：
问题：仓库拣货时重复输入货架号
- 功能影响：移动端扫描模块（中）、后端货架映射服务（高）、WMS 接口（中）
- 用户影响：拣货员 43 人（高）、IT 运维 4 人（低）
- 数据影响：新增货架-位置映射表（中）、修改扫描结果解析字段（高）
- 流程影响：取消人工核对步骤（高）、打印标签流程不变（无）三者协同：问题定义工作流
下图为从用户场景到可交付业务问题定义的结构化路径。所有输出将直接输入需求拆解阶段。