业务分析第一课：如何读懂业务方真正的痛点？需求访谈与业务事件风暴
做数据模型这么多年，我踩过最大的坑是什么？
不是技术选型，不是性能调优，而是——需求理解错了。
你辛辛苦苦建好的模型，业务方看了一眼说：“这不是我要的。” 那种感觉，真的挺崩溃的。后来我慢慢明白，问题出在沟通方式上。我们太习惯用技术语言去问问题，而业务方呢，他们描述的是现象，不是本质。
这一章，我们就聊聊怎么把业务方真正的痛点挖出来。核心就两招：需求访谈和业务事件风暴。
为什么业务方说的“痛点”往往不是真痛点？
先讲个我自己的经历。
几年前，我给一家零售企业做数据中台。业务负责人上来就说：“我们的库存周转太慢了，给我做个实时库存看板。” 听起来很合理对吧？
我多问了一句：“您觉得周转慢，具体是哪个环节卡住了？”
他愣了一下，说：“嗯……好像是仓库发货和门店收货之间对不上。”
你看，真正的痛点不是“库存周转慢”这个结果，而是“发货与收货数据不一致”这个根因。如果我只做个看板，那只是把错误的数据展示得更快而已。
核心观点：业务方描述的“痛点”通常是症状，不是病因。我们的任务是通过追问，把症状背后的根因挖出来。
需求访谈：别急着记笔记，先学会听
很多人做需求访谈，上来就问：“你们有什么需求？” 然后业务方开始说，他就开始记。记完回去一整理，发现全是功能清单，跟数据模型半毛钱关系没有。
我个人习惯，访谈分三步走：
- 先聊场景，再聊痛点——让业务方描述他一天的工作流程，哪个环节最让他头疼。
- 追问“为什么”——他说“数据不准”，你就问“怎么个不准法？是多了还是少了？偏差有多大？”
- 反向验证——把你理解的意思复述一遍，问他“是不是这个意思？”
举个例子，有一次访谈一个运营总监。他说：“我们的用户流失率太高了，需要做个预警模型。”
我追问：“您说的流失，是指多久没登录？还是没下单？”
他说：“一个月没下单就算流失。”
我又问：“那您觉得流失率高，是因为我们没及时触达，还是产品本身的问题？”
他想了想：“其实是我们根本不知道哪些用户快流失了，等发现的时候已经晚了。”
嗯，到这里我才明白，他真正需要的是流失概率预测，而不是一个简单的流失统计报表。
小技巧：访谈时多用开放式问题，少用“是不是”“对不对”这种封闭式问题。开放式问题才能引出真实场景。
业务事件风暴：把模糊的需求变成清晰的流程
需求访谈挖出了痛点，但痛点还是散的。怎么把这些痛点串起来，变成可落地的数据模型？
我推荐用业务事件风暴（Event Storming）。
说白了，就是让业务方和技术方坐在一起，用便利贴把业务过程中发生的所有“事件”都贴出来。比如“订单已创建”“库存已扣减”“物流已发货”。
为什么要这么做？因为事件是客观的，不会撒谎。业务方可能会说错需求，但事件不会。
事件风暴的四个核心元素
| 元素 | 颜色 | 含义 | 示例 |
|---|---|---|---|
| 领域事件 | 橙色 | 业务中已经发生的事实 | “订单已支付” |
| 命令 | 蓝色 | 触发事件的操作 | “用户点击支付按钮” |
| 聚合 | 黄色 | 承载业务逻辑的核心对象 | “订单”“用户”“商品” |
| 外部系统 | 粉色 | 与系统交互的第三方 | “支付网关”“物流系统” |
我曾经在一个项目中，业务方坚持说“退货流程很简单”。结果一搞事件风暴，贴出来 30 多个事件，包括“质检不合格”“退款到账延迟”“库存回库失败”等等。业务方自己都看傻了。
事件风暴的标准流程
- 准备阶段：准备好便利贴、马克笔、一面足够大的墙。参与人员包括业务专家、产品经理、开发、测试。
- 发散阶段：所有人自由地贴事件，不用管顺序。目标是穷举，不是整理。
- 整理阶段：按时间轴把事件从左到右排好，找出事件之间的因果关系。
- 聚焦阶段：圈出核心流程，标记出痛点事件（比如经常出错的环节）。
注意：事件风暴最忌讳的是“技术主导”。如果开发人员一直在说“这个实现不了”，业务方就不敢说话了。我的建议是：前 30 分钟，技术人员只许听，不许反驳。
从事件风暴到数据模型：一个真实案例
我们用一个电商场景来演示。假设业务方说：“我们的订单履约率太低了，需要优化。”
通过事件风暴，我们贴出了这样一串事件：
- “订单已创建” → “库存已预占” → “支付已完成” → “仓库已接单” → “商品已拣货” → “包裹已发货” → “客户已签收”
然后我们问业务方：“哪个环节最常出问题？”
他说：“仓库接单之后，经常发现库存不够，然后订单就被卡住了。”
你看，真正的痛点不是“履约率低”，而是“库存预占和实际库存不一致”。
基于这个发现，我们设计的数据模型里，专门加了一个“库存预占校验表”，每次预占前先校验实际库存，不够的直接拦截，不让订单流到仓库。
关键结论：事件风暴产出的不是流程图，而是数据模型的“原材料”。每个事件背后，都对应着一条数据记录、一个状态变更、一个业务规则。
本章知识体系：一张图看懂
下面这张图，把需求访谈和事件风暴的关系梳理清楚了。你可以把它当作一个检查清单，每次做业务分析时对照着走一遍。
避坑指南：我踩过的几个坑
最后分享几个我亲身踩过的坑，希望能帮你少走弯路。
- 坑一：只访谈一个人。 我曾经只跟业务负责人聊，结果模型做出来，一线操作员说根本没法用。后来我学乖了，至少访谈三个不同角色的人：决策者、执行者、数据使用者。
- 坑二：事件风暴搞成了技术评审。 有一次，开发人员一直在争论“这个事件用 Kafka 还是用 API 实现”，业务方全程插不上嘴。嗯，那次风暴基本白做了。记住，事件风暴只关心“发生了什么”，不关心“怎么实现”。
- 坑三：忽略异常事件。 业务方通常只描述正常流程，但数据模型最怕的就是异常。比如“订单已取消”“支付已退款”“库存已回滚”。一定要让业务方把异常事件也贴出来，这些才是数据模型里最容易出 bug 的地方。
我的习惯：每次事件风暴结束后，我会把所有的“异常事件”单独列一张表，跟业务方逐条确认。确认完再开始建模。这一步虽然花时间，但能省掉后面 80% 的返工。
好了，这一章的内容就到这里。记住一句话：业务分析不是问“你要什么”，而是问“你遇到了什么”。把痛点挖透了，数据模型自然就有了方向。