业务问题定义
在需求探索早期，团队常面临“用户说痛、但说不清痛在哪”的困境。业务问题定义的作用是将模糊的痛点转化为可定性、可定量的业务问题，为后续需求拆解和机会评分提供一致的基准。定义结果需包含三大要素：问题陈述（表述结构）、影响范围（谁受影响、影响什么）、定量与定性描述（如何衡量、如何感知）。
问题陈述
问题陈述采用“谁 + 在什么场景下 + 无法做什么 + 导致什么负面结果”的结构。例如：“内容运营人员在跨平台发布图文时，无法一键同步格式与标签，导致每天手动调整耗时超过2小时，错误率高达8%。” 避免使用技术方案措辞，聚焦业务痛点和可观察的后果。
- 主体：具体用户角色或业务单元（如“B端采购经理”）
- 场景：触发条件或时间窗口（如“每月库存盘点时”）
- 障碍：无法完成的关键任务（如“无法自动匹配供应商报价”）
- 后果：业务损失或体验劣化（如“采购周期延长40%，资金周转率下降”）
影响范围
清晰划定问题波及的边界，可从三个维度展开：
| 维度 | 典型问题 | 波及对象 |
|---|---|---|
| 用户 | 操作效率低、学习成本高 | 一线执行岗、管理者 |
| 业务 | 流程断裂、资源浪费 | 财务、运营、客服等部门 |
| 系统 | 数据孤岛、接口不可用 | IT运维、数据团队 |
影响范围应避免模糊表述（如“全员受影响”），需细化到具体角色、部门、系统模块，并标注当前与潜在影响的时间范围（如“自2024Q1起每月发生”）。
定量与定性描述
定量描述提供可衡量、可验证的基线；定性描述补充用户情感、品牌体验等难以数字化的维度。二者结合才能完整定义问题严重性。
| 类型 | 示例指标/描述 | 数据来源 |
|---|---|---|
| 定量 | 每日平均耗时 2.3 小时，操作失败率 12%，用户流失率 5% | 系统日志、埋点、客诉系统 |
| 定性 | 用户反馈“复制粘贴多次仍出错”、“担心数据丢失” | 用户访谈、NPS评论、客服录音 |
避坑指南： 定量指标必须包含当前基线（如“当前耗时”），定性描述需引用3条以上真实用户原话，避免主观推测。若量化数据缺失，可用估算范围并标注置信度。
业务问题定义框架
下图展示问题陈述、影响范围、定量/定性描述如何共同收敛为清晰的业务问题定义，为后续拆解与评分提供输入。
在课程实战案例中（某海外电商平台客服工单系统优化），问题定义颗粒度如下：
- 问题陈述：客服人员在处理售后维权工单时，无法在30秒内调取该用户最近3笔订单的完整物流与支付记录，导致平均处理时长延长至8.5分钟，客户满意度下降12个百分点。
- 影响范围：直接涉及客服代表、质检团队、物流查询接口；间接影响客服团队人员储备、供应商考核指标。
- 定量描述：当前MTR（平均处理时长）为8.5分钟，目标4.5分钟；工单转派率高达35%。
- 定性描述：客服反馈“需要切换3个系统才能找全信息，忙起来经常漏看环节”；用户抱怨“同一个订单问题要解释两遍”。