2、业务需求分析：如何与业务方沟通，梳理关键指标（KPI）与数据源
做数据看板，最怕什么？
怕业务方说「你看着办」，然后你吭哧吭哧做完了，对方来一句「这不是我要的」。
我早期就踩过这个坑。花了三周搭了一个主数据实时看板，自认为逻辑清晰、图表漂亮。结果业务负责人看了一眼，说：「这个指标我们早就不考核了，现在看的是另一个。」——嗯，从那以后，我再也不敢跳过需求分析这一步了。
2.1 沟通前的准备：别空着手去见业务方
我个人习惯，约业务方开会之前，先做三件事：
- 搞清楚业务方是谁——是运营总监？还是数据专员？不同角色关注点完全不同。
- 拉一份现有报表清单——他们现在用什么报表？Excel？BI工具？还是手工台账？
- 准备一个「指标初稿」——哪怕只是草稿，也能引导对方思考，而不是让对方从零开始想。
小技巧： 我通常会带一张白板纸去开会。聊到关键指标时，直接画出来给对方看。视觉化的东西，比口头描述更容易达成共识。
2.2 沟通的核心：问对问题
跟业务方聊指标，不能上来就问「你们要什么KPI」。这个问题太宽泛，对方往往答不上来。
我一般会按这个顺序问：
- 「你每天上班第一件事，看什么数据？」——找到最高频关注的指标。
- 「上个月哪个指标出了问题，导致你被老板叫去谈话？」——找到最敏感的指标。
- 「如果看板上只能放三个数字，你选哪三个？」——找到核心中的核心。
- 「这些数据现在从哪里来？准不准？」——提前摸清数据源质量。
说白了，业务方不是不想说，而是不知道怎么表达。你要帮他们把「模糊的感觉」变成「明确的指标」。
2.3 梳理KPI：从「想要」到「能做」
业务方提的需求，往往很美好。比如「我要实时看到全渠道的客户满意度」。但你一查数据源，满意度数据是T+1的，根本做不到实时。
这时候就需要做一件事：需求分级。
| 需求等级 | 定义 | 举例 | 处理方式 |
|---|---|---|---|
| P0（必须） | 没有这个指标，看板就没意义 | 主数据准确率、实时同步延迟 | 优先实现，数据源必须打通 |
| P1（重要） | 日常决策依赖，但可容忍短时延迟 | 日活用户数、订单量 | 争取实现，可接受准实时 |
| P2（加分） | 有更好，没有也不影响核心决策 | 趋势预测、同比环比 | 放在二期，或做成可切换视图 |
注意： 我曾经遇到一个项目，业务方一口气提了30多个指标。我全部接了下来，结果开发周期翻了三倍，上线后真正被使用的不到10个。所以，一定要做优先级排序。不是所有需求都值得做。
2.4 数据源梳理：指标背后的「水管」
指标定好了，接下来要看数据从哪里来。这一步很容易被忽视，但恰恰是看板能否「实时」的关键。
我习惯用一张表格来梳理数据源：
| 指标名称 | 数据源系统 | 数据更新频率 | 数据接口方式 | 数据质量风险 |
|---|---|---|---|---|
| 主数据准确率 | MDM系统 | 实时 | Kafka消息 | 偶有消息丢失 |
| 实时同步延迟 | 数据同步中间件 | 秒级 | API轮询 | 高峰期延迟增大 |
| 日活用户数 | 用户行为日志 | T+1 | 离线ETL | 数据稳定 |
你想想看，如果数据源本身是T+1的，你硬要做成实时看板，那不是给自己挖坑吗？所以，数据源的能力边界，决定了看板的上限。
2.5 沟通中的避坑指南
聊了这么多项目，我总结了几条经验：
- 不要承诺「实时」——除非你确认数据源支持。我一般会说「准实时，延迟在X秒以内」。
- 不要用技术术语——跟业务方说「API」「ETL」「Kafka」，对方大概率听不懂。换成「数据从哪里来」「多久更新一次」。
- 不要一次定稿——需求是聊出来的，不是一次会议就能确定的。我通常会留出2-3轮沟通。
- 不要忽略「数据责任人」——每个指标背后都得有一个人负责解释数据。否则出了问题，你连找谁问都不知道。
核心原则： 业务需求分析不是「记录需求」，而是「翻译需求」。把业务语言翻译成技术语言，再把技术能力翻译回业务预期。两边都对得上，看板才能落地。
2.6 一张图看懂：需求分析流程
下面这张图，是我每次做需求分析时都会画的。它帮我把整个流程串起来，也方便跟业务方对齐认知。
这张图从左到右、从上到下，把整个需求分析流程串起来了。每次跟业务方开会，我都会把这张图投在屏幕上，指着每个节点跟对方确认：「这一步我们聊清楚了没有？」
嗯，做到这一步，需求分析才算真正到位。接下来，你才能放心地进入设计阶段。