业务痛点定义
核心框架
有效的痛点描述必须包含四个核心要素，形成完整逻辑链条：
谁（角色） 在 什么场景下 遇到了 什么问题，导致了 什么样的负面后果（成本/风险）
四要素详解
1. 明确角色
痛点依附于"人"。明确指出是谁在经历痛苦。
- ❌ 错误："用户觉得慢。"
- ✅ 正确："一线销售人员……" 或 "财务部门的月末结算专员……"
2. 具体场景
痛点在特定时间、地点或业务流程中出现。
- ❌ 错误："在使用系统的时候。"
- ✅ 正确："在没有网络信号的仓库区域，试图录入库存数据时……"
3. 核心问题
描述当前阻碍、缺陷或低效环节，不是解决方案。
- ❌ 错误："我们需要一个离线版APP。"（这是方案，不是痛点）
- ✅ 正确："系统强制要求实时联网才能提交表单，导致数据无法暂存……"
4. 量化后果
说明痛点给业务带来的具体损失（时间、金钱、客户流失、合规风险等）。
- ❌ 错误："这很麻烦，效率很低。"
- ✅ 正确："导致每天平均浪费2小时进行二次手工录入，且数据错误率高达15%，造成库存盘点差异。"
标准描述模板
作为 [角色]，在 [具体场景/业务环节] 中，由于 [当前的问题/限制]，导致了 [量化的负面后果/成本]。
工作流程
当用户需要定义痛点时，按以下步骤执行：
- 收集信息：向用户询问四个要素的具体内容
- 识别缺口：检查哪些要素缺失或模糊
- 引导完善：针对缺失要素提出具体问题，帮助用户补充
- 生成描述：使用标准模板整合成完整的痛点描述
- 验证有效性：用三个标准检验痛点描述
检验标准
完成痛点描述后，用以下三个问题验证：
| 标准 | 检验问题 |
|---|---|
| 可验证 | 能通过数据证明痛点存在吗？（日志、加班记录等） |
| 痛得够深 | 是"不方便"的痒点，还是"业务停摆/亏损"的痛点？解决后能带来显著ROI吗？ |
| 聚焦问题 | 描述是否限制团队思路？好的描述应让团队思考"如何解决离线数据暂存"，而非局限于"换个ERP" |
案例对比
❌ 无效描述（模糊、主观、像解决方案）
> "我们的库存系统太烂了，经常对不上数。仓库管理员抱怨很难用，我们需要上一套新的ERP系统来解决这个问题。"
为什么无效？
- 角色不清："仓库管理员"太宽泛
- 场景缺失：什么时候对不上数？
- 后果模糊："很难用"无法衡量
- 预设方案：直接跳到"上新ERP"
✅ 有效描述（具体、客观、可衡量）
> "作为负责月末盘点的仓库管理员，在手持PDA扫描货物进行盘点时，由于系统不支持批量离线暂存，必须逐件等待服务器响应，导致盘点效率极低（每小时仅能盘点50件），且经常因网络波动导致数据丢失，每月需花费额外2天时间进行人工复核。"
为什么有效？
- 角色明确：负责月末盘点的仓库管理员
- 场景具体：手持PDA扫描、网络环境不佳
- 问题清晰：不支持离线批量暂存，必须逐件等待
- 后果量化：效率低（50件/小时）、数据丢失、每月浪费2天
常见问题引导
当用户描述模糊时，使用以下问题引导：
关于角色：
- 具体是哪个岗位/部门的人在经历这个问题？
- 这个人的日常工作职责是什么？
关于场景：
- 这个问题通常在什么时候/什么环节发生？
- 当时的环境条件是什么？（网络、设备、地点等）
关于问题：
- 当前系统/流程具体做了什么限制？
- 如果不解决这个问题，用户现在是怎么 workaround 的？
关于后果：
- 这个问题造成了多少时间/金钱损失？
- 有具体的数字吗？（错误率、耗时、客户流失数等）
- 如果不解决，最坏的情况是什么？
