导读：当下，数据在业务中扮演着越来越重要的角色，没有数据不知道业务进展如何，没有数据不知道如何决策，企业将数据视为风向标，也将数据视为源动力。在企业内部数据的流动环节，最为频繁的就是不同角色表达对数据的需求。本文将分享一个数据需求表达的范式，通过这个范式将自己的数据需求或者协助数据需求者明确、精准、快速地表达自己的想法。

01 对范式的思考

如果功能性产品，我一般会按照业务模型、业务逻辑、用户交互三个层面思考，如何理解业务方的产品诉求，也会用它来在检视自己的产品需求是否完善、逻辑是否无暇。

这三层思考正是映射到软件开发领域的经典 MVC 框架，从需求层面到执行开发层面能够找到一一对应的参照，这在软件工程中特别重要，极大减少了沟通成本和设计成本。

由此引发，对于数据需求，我想到我们在执行数据需求时，不论数据开发还是数据分析师，抑或是自己，都会用 SQL 去操作，这让我不可避免地想到能不能用 SQL 的语法结构来做为数据需求表达范式。

事实是可以的。

02 对 SQL 表达的剖析

无论一个数据需要多么复杂，关联多少张表，做多少运算，只要库表是齐备的，理论上都可以得到我们想要的数据。你看，在 SQL 数据查询中往往是这样的一个结构：

SELECT a,

b,

c,

count(a) AS i,

count(DISTINCT b) AS h,

max(c) AS t

FROM tab

WHERE day > 20211101

AND b = ‘x’

GROUP BY a,

b,

c

这里边有三个关键的子句需要我们关注：

WHERE/FROM

GROUP BY

SELECT

显然，FROM 和 WHERE 确定了我们要查询的数据范围，GROUP BY 给出了我们对数据的分组依据，SELECT 最终产出想要的数据。

在 SQL 的语法结构中，已经非常清晰地告诉我们数据的逻辑，我们要做的就是参照它，准确地表达我们的数据诉求。

03 SQL 的启示

在对 SQL 结构的分析后，我们可以得到这样的一个需求表达范式三要素，这个范式能保证我们正确地表达数据需求和顺畅地沟通数据需求。这三个要素是：

1）统计范围

这部分对应 WHERE 和 FROM，需要知道需求中所涉及的统计领域以及限定条件。

如你要统计商品的数据，需要确定是所有商品还是当前在上架状态的商品；统计用户的信息，是否只包含付费用户；统计流量数据是否只包含手机端的流量等等。

时间的范围是必须的，即使是统计所有历史数据也需要明确出来。当然时间也可以是动态的，如最近 7 天，近一个月等，这和数据的操作执行时间有关。

数据的统计范围的确定有助了我们将问题限制在一定的界限内，减少了对数据范围认知不一致而导致的沟通障碍。

2） 统计维度

统计维度就是 SQL 中 GROUP BY 的部分，利用 GROUP BY 对明细数据进行分组，数据分析时以这些分组的视角对数据表现进行评估。所有的数据无论是单一的分组还是多重分组，都会有相应的维度表示。

在一个时间范围内，维度可以按照年、月、周、日、时、分等粒度划分难度，前提是有相应更小粒度的细节数据。

统计学意义上的分类数据、离散数据都可以做为维度，如针对性别，可以按男、女维度来分析数据。连续数据通过分箱等手段也可以进行维度划分。

维度的确定，明晰了数据分析的角度，对分析结果至关重要。当然，多维分析也是一种数据搜索的常用手段，在需求确认时，需要明确是否需要多维分析以及有哪些维度组合。

3） 统计指标

统计指标是 SQL 的 SELECT 数据输出部分，就是最终看到的数据形式。一般情况下所有维度会输出并作为指标的指示。

指标即口径，也就是针对前述维度的计算方法，维度一般会参与计算，但有时也不参与计算。计算方法一般会是计数、去重计数、求极值、平均数、标准差等聚合运算。

统计指标是需求方最终看到的结果，从范围到维度，到最终的指标数据输出，指标的计算方法是最为重要的一个环节。

以上三个元素，能够比较准确地描述一个数据需求，让需求执行者明确地进行数据执行操作。

04 最终我们如何做

由于需求方一般不具备 SQL 技能，不能理解以上相关概念，但我们确实需要这些信息，可以平时做一些引导和培训，让其按这种范式提出需求。如果无法抽象理解这些概念，可引导需求方画出数据样例，并对所有列一一指明逻辑。

另外，一些其他信息或者对我们也有帮助：

需求方的身份背景：帮助我们判断需求提出者的动机及分析思路；

需求背景：了解提出此数据需求的业务背景；

需求的频率：如果是周期性数据可以考虑产品化；

需求的期望完成时间：方便对需求进行排期，确定优先级。