3、需求分析与范围界定：如何与业务方沟通、识别关键指标、确定数据粒度与更新频率
说实话，我见过太多数据集市项目翻车，原因都不是技术不行，而是需求没聊透。
业务方说「我要看销售数据」，你吭哧吭哧建完了，他一看：「不对，我要的是按门店、按小时、含退货的实时数据。」——得，重来吧。
所以这一章，咱们就聊聊怎么把需求聊清楚，把范围定死，把坑提前踩平。
3.1 与业务方沟通：别聊技术，聊场景
我刚开始带项目时，特别喜欢跟业务方讲星型模型、讲缓慢变化维度。结果呢？对方一脸茫然，回去跟领导说「数据团队要做个很复杂的东西，可能要很久」。
后来我学乖了。沟通的核心就一句话：问场景，不问字段。
- 你每天打开电脑，第一个看的报表是什么？ —— 找到核心高频场景
- 哪个数据不准的时候，你会被老板骂？ —— 找到关键质量指标
- 如果这个数据晚一小时出来，会怎样？ —— 摸清时效底线
举个例子。有一次跟零售业务方聊，对方上来就说「我要一个全渠道销售分析」。我追问：「你平时最关注哪个渠道？」他说：「线上。因为线下有店长盯着，线上我看不到。」
好，那第一版就先做线上。线下数据后面再补。范围一下子就收窄了。
3.2 识别关键指标：从 KPI 到原子指标
业务方嘴里说的指标，往往是个「复合概念」。比如「客单价」，它其实是「总销售额 / 总订单数」。但如果你直接建一个「客单价」字段，后面想拆分子维度就麻烦了。
我的做法是：把指标拆成原子指标 + 维度 + 业务限定。
| 业务说法 | 原子指标 | 维度 | 业务限定 |
|---|---|---|---|
| 本月线上客单价 | 销售额、订单数 | 时间（月）、渠道（线上） | 已支付、非测试订单 |
| 华东区门店缺货率 | 缺货商品数、总商品数 | 区域（华东）、门店 | 只统计在售品 |
| 会员复购率 | 复购会员数、总会员数 | 时间（近30天） | 排除首单当天 |
你想想看，如果一开始就建了「客单价」这个字段，业务方突然说「我要看按品类的客单价」，你就得重新算。但如果你存了销售额和订单数两个原子指标，任何维度的客单价都能随时算出来。
3.3 确定数据粒度：越细越好？不一定
粒度，说白了就是「一行数据代表什么」。是每一笔交易？还是每天每个门店的汇总？
我见过一个团队，业务方说「我要看实时数据」，他们就按秒级粒度建了表。结果数据量暴增，查询慢得要命。业务方其实只是想要「每小时的销售趋势」，秒级数据根本用不上。
所以，粒度由查询场景决定。我一般这样判断：
- 如果业务方要「下钻」 —— 比如从全国看到门店，再看到收银员 —— 那粒度至少要到「单笔交易」甚至「单品」。
- 如果只看趋势 —— 比如月度同比、季度环比 —— 天级粒度就够了。
- 如果涉及库存、财务 —— 这些通常需要精确到「每一笔变动」，粒度要最细。
3.4 确定更新频率：别被「实时」忽悠了
业务方一说「我要实时数据」，很多技术同学就头大。其实你追问一句：「实时到什么程度？」答案往往是「别超过5分钟就行」或者「每小时更新一次也可以」。
更新频率的选择，本质上是在 时效性 和 成本 之间找平衡。
| 更新频率 | 适用场景 | 成本 | 我的建议 |
|---|---|---|---|
| T+1（天级） | 财务月报、年度分析、历史趋势 | 低 | 能用T+1就别用更高的 |
| 小时级 | 运营日报、库存监控、营销活动效果 | 中 | 大部分业务场景够用 |
| 分钟级 | 实时大屏、风控、异常告警 | 高 | 确认业务方真的需要 |
| 秒级/实时 | 交易系统、在线推荐、实时定价 | 极高 | 慎重，通常需要独立架构 |
3.5 需求文档怎么写：把「共识」变成「契约」
聊完了、定好了，一定要写文档。别信「我们都口头说好了」，两周后保证有人不认账。
我的需求文档模板长这样：
# 数据集市需求说明书
## 1. 业务场景
- 业务方：XXX部门
- 使用人：XXX
- 核心场景：每日查看各门店销售情况，支持按品类下钻
## 2. 指标清单
| 指标名称 | 原子指标 | 维度 | 业务限定 |
|---------|---------|------|---------|
| 销售额 | 订单金额 | 门店、品类、时间 | 已支付、非退货 |
## 3. 数据粒度
- 粒度：单笔交易（交易ID唯一）
- 原因：需要下钻到单品级别
## 4. 更新频率
- 主表：T+1，每日凌晨3点更新
- 聚合表：小时级，每小时更新一次
- 原因：源系统每日凌晨2点完成数据同步
## 5. 验收标准
- 数据准确率：与源系统对账一致
- 查询响应：单表查询 < 3秒
- 更新时效：每日8点前数据可用
## 6. 签字确认
- 业务方：______ 日期：______
- 数据团队：______ 日期：______
嗯，这里要注意：一定要让业务方签字。不是说要追责，而是让他意识到「这是我们共同确认的」。后面他再提新需求，你就可以说：「这个不在当前范围，我们排到下个迭代吧。」
3.6 知识体系总览
下面这张图，把需求分析与范围界定的核心流程串起来了。我每次做新项目都会先走一遍这个流程，基本不会跑偏。
你看，整个流程是环形的。需求文档签完字，不代表结束。业务方用起来之后，一定会冒出新的想法。这时候就回到第一步，重新沟通、重新界定范围。迭代几次之后，数据集市才会越来越贴合业务。