需求调研方法论：业务调研的步骤、访谈技巧、如何识别关键业务指标（KPI）、需求文档的编写规范

很多刚入行的朋友问我：“数据仓库建模最难的是哪一步？”
我每次都回答：不是建模，不是ETL，是需求调研。
你想想看，模型建得再漂亮，如果业务方说“这不是我要的”，那一切归零。
我个人习惯把需求调研比作“打地基”——地基歪了，楼盖得再高也得塌。

一、业务调研的四个步骤

调研不是聊天，得有章法。我总结了一套四步法，这些年一直在用：

1. 明确调研范围：先搞清楚我们要看哪个业务域。是销售？是财务？还是供应链？范围定太大，调研会失控；定太小，又怕遗漏关键需求。
2. 梳理业务流程：让业务方把“从开始到结束”的流程走一遍。我习惯让他们在白板上画，边画边问“这一步谁做的？数据从哪来？”
3. 识别数据触点：每个业务环节都会产生数据。比如下单环节有订单表、支付环节有支付流水。把这些触点列出来，就是未来的数据源清单。
4. 确认核心诉求：最后问一句“你最想从数据里看到什么？”——这句话往往能挖出真正的KPI。

二、访谈技巧：别让业务方觉得你在“审问”

访谈是门手艺活。我记得刚入行时，有一次把业务经理问烦了，人家直接说“你回去看文档吧”。
后来我慢慢摸索出几个技巧：

• 先聊业务，再聊数据：开场别问“你们有哪些表”，先问“你们平时怎么工作的”。业务方聊得舒服了，数据的事自然就带出来了。
• 用业务语言提问：别说“事实表”、“维度表”，要说“订单”、“客户”、“产品”。我见过太多技术出身的同事，一开口就把天聊死了。
• 多问“为什么”：业务方说“我要看销售额”，你得追问“销售额怎么定义的？含不含税？退单算不算？”——这些细节不搞清楚，模型建出来也是错的。
• 带个“翻译”：如果业务方有IT对接人，最好拉上他一起。他能帮你把业务需求“翻译”成技术语言，效率翻倍。

三、如何识别关键业务指标（KPI）

业务方通常会给你一堆指标，但真正核心的往往只有3-5个。
怎么识别？我一般用“三问法”：

• 一问：这个指标谁在看？——如果是老板或高层看，那基本是核心KPI。
• 二问：这个指标影响决策吗？——比如“日活用户数”下降，产品团队会立刻调整策略，这就是核心指标。
• 三问：这个指标能拆解吗？——核心KPI通常可以向下拆解成多个子指标。比如“销售额”可以拆成“订单量×客单价”。

下面这张图是我常用的KPI识别流程：

举个例子。我在做零售项目时，业务方列了20多个指标。我用三问法筛了一遍，最后只保留了“销售额”、“毛利率”、“库存周转率”和“客户复购率”四个核心KPI。剩下的都作为子指标，挂在核心KPI下面。这样模型结构清晰，业务方也满意。

四、需求文档的编写规范

需求文档是调研的最终交付物。写得好不好，直接影响后续建模质量。
我见过最糟糕的文档——只有三行字：“我要看销售数据，按时间统计。”——这种文档没法干活。

一份合格的需求文档，至少包含以下内容：

模块	内容	示例
业务背景	为什么要做这个需求？解决什么问题？	“销售部需要按区域分析月度销售额，以优化促销策略”
指标定义	每个指标的名称、口径、计算公式	“销售额 = 订单金额 - 退款金额，不含税”
维度说明	分析维度有哪些？层级关系？	“区域（省→市→区）、时间（年→季→月→日）”
数据来源	数据从哪个系统来？表名？字段？	“来源：ERP系统，表名：t_order，字段：order_id, amount”
更新频率	数据多久更新一次？实时还是T+1？	“每日凌晨2点增量更新”
验收标准	怎么验证数据是对的？	“与业务报表核对，误差不超过0.1%”

另外，我建议需求文档要经过三方确认：业务方确认业务逻辑、数据团队确认技术可行性、项目经理确认交付时间。签字确认后，再开始建模。这一步能省掉后期80%的返工。

嗯，需求调研这块就聊这么多。说白了，调研做得好不好，决定了你后面是“一路顺风”还是“一路填坑”。我个人觉得，花在调研上的时间，永远值得。