我们要的不是数据记录，而是能够产生业务价值的数据记录；

我们要的不是数据看板，而是能够产生业务价值的数据看板；

我们要的不是数据中台，而是能够产生业务价值的数据中台；

我们要的不是数据闭环，而是能够产生业务价值的数据闭环；

……

为了传达文章的核心观点，我将不再啰嗦各种引言各种背景，而是更加开门见山地叙述我想表达的内容。

本文以一个业务系统开发负责人的视角来叙述，所以优先采用开发视角，同时也会采用产品、数据、业务人员的视角。

杭研天问老师写的《从数据中台到全链路数据生产力》里，提到了数据生产力的概念。的确，作为严选的业务系统开发人员，也总会思考如何通过数据帮助业务发展，即如何建设业务系统的数据生产力。但是在这个过程中，其实遇到了不少的问题。我们希望能够建设业务系统的数据闭环，即数据采集、加工和分析，并通过分析结果指引业务发展。但这方面最终产生了多少业务价值，投入产出比如何，往往并不容易说清楚。甚至出现过辛辛苦苦埋点收集数据，最终的数据看板也几乎无人关注的问题。

总结来说：我们要的不是数据记录，而是能够产生业务价值的数据记录；我们要的不是数据看板，而是能够产生业务价值的数据看板；我们要的不是数据中台，而是能够产生业务价值的数据中台；我们要的不是数据闭环，而是能够产生业务价值的数据闭环……

这篇文章是想要讨论，打造业务系统的数据生产力，应该采用什么方法和行动路径，才会尽量不走弯路少掉坑。

即使没有足够的系统支持，业务在最初的实践中依然会形成数据生产力闭环，如下图所示：

在这个阶段：

• 业务执行可能只是部分线上甚至完全线下的

• 数据收集可能没有系统支持，数据可能散落在邮件中、Excel表格中等

• 数据分析可能采用“非常原始”的方式，即直接在Excel里计算

但需要说明的是，即使各个环节都显得简陋，但这个数据生产力闭环依然形成了。数据分析的结果可以指导下一轮的业务执行，进而可以不断优化业务执行链路。

随着系统化建设的进行，这个闭环链路的各个环节都变得专业化，数据之间的流动更加顺畅，如下图所示：

可以看到，整个“业务执行→数据收集→数据分析→结果反馈”链路上各个节点都变得更加强大，数据处理的能力也变得更强。但这里的核心始终是，有一个数据生产力的闭环，能够围绕着业务优化进行数据收集、分析等工作。一旦这个闭环被打破，不管收集分析多少数据，生产多少看板，都只是徒劳。

可偏偏现实中，我们一不小心就会去干这种，闭环还不清晰，却已经在拼命收集数据分析数据的事。

上文已知，要数据真正发挥价值，必须形成业务数据闭环。那么，作为技术开发团队，在承接业务侧的数据需求时，应该做些什么来防止开发资源浪费呢？

3.1 先线下，再线上

所谓“线下”，指的是业务同学进行的手工数据分析（基于Excel），或者业务同学和数据分析师一起进行的数据分析（基于数仓和SparkSQL）。线下分析的特点是灵活好调整，但是相对耗时耗力。线下分析环节主要是由业务和数据分析师负责推进。

所谓“线上”，指的是基于大数据任务或者业务系统实现的数据分析逻辑。线上分析的特点是高效自动化，但是调整会比较复杂（涉及到测试、联调和上线等）。线上分析主要由产品和开发负责推进。

基于线下线上的特点，可以得出以下结论：对于线下比较常见的数据分析需求，如果需求明确，流程相对固化，就有了线上化的需求，这可以帮助业务侧提升效率。更重要的是，当我们要对一个数据分析需求进行线上化的时候，应该首先明确这个需求已经完成了线下的“数据生产力闭环”。这个过程如下图所示：

这里的一个可能的“坑”是，有时产技团队接到的数据需求，其实并没有在线下完成闭环，这时就需要非常小心了。仅仅线上化本身，是无法实现数据价值的，即使数据线上化，依然无法完成业务侧的生产力闭环。

有一个特别的判断标准：在数据收集-分析链路还未线上化时，如果业务依然“不辞辛苦”地获取数据、分析数据，那大概率在将收集-分析链路线上化之后，很有可能就是有价值的。当然，实际工作往往有很多中间地带，所以我们需要有一些思考工具，来对数据需求进行分析。

3.2 数据需求分析

举一个例子：

我们去医院看病的时候，医生会先问我们一些基本情况，哪儿不舒服。然后根据我们反馈的信息，让我们去检查化验一些生理指标，如验血、拍片等等。最后根据检查化验的结果，再给我们诊断，或者提出下一步更详细的检查建议。

但如果医生一开始什么都不了解，便先让我们去做详尽的检查：身高体重，验血验尿，X光B超心电图等等，一大圈折腾下来，才发觉我们只是得了普通的感冒，回家多喝水多休息就好了。

这就是没有从需求出发的数据收集和分析。

因此当业务侧提出希望将某些数据进行线上化，并对某些数据进行分析，甚至清楚地给出了具体的数据分析逻辑时，我们首先应该了解的是，业务侧需要解决的问题是什么？

业务侧需要解决的问题不同，我们选择实现的方式也不同。有些简单的需求，可能只需要协助业务方取数即可完成；而有些复杂的需求，可能需要更加系统化的实现方式，不是简单的把某些数据线上化就可以实现。

因此数据需求分析的第一步是：要求业务方完整的描述业务的需求，帮助完成 “业务执行→数据收集→数据分析” 闭环。

说明：这里说的“要求业务方完整描述……”，在实际中，产技团队也应该更进一步，和业务侧一起梳理需求。所以更准确的描述应该是 “各方就业务的需求进行深入讨论并达成一致，进一步就 ‘业务执行→数据收集→数据分析’ 闭环达成共识”。

所以，最终的需求描述不应该是：

“我们要求把A、B、C数据线上化，并且展示B和C过去1个月的波动情况。”

而更应该是：

“我们需要分析过去一个月的用户流失情况。而A、B、C是衡量这个指标的关键，因此我们需要把这些数据线上化。如果我们发现B最近下降很快，那么很有可能是XXX问题，我们就需要采取方案一；如果C最近下降很快，那很有可能就是YYY问题，我们就需要采取方案二。”

甚至是：

“我们需要分析过去一个月的用户流失情况，而A、B、C是衡量这个指标的关键。我们需要快速决策，所以只需要取数线下分析即可。如果我们发现B最近下降很快，那么很有可能是XXX问题，我们就需要采取方案一；如果C最近下降很快，那很有可能就是YYY问题，我们就需要采取方案二。”

让业务提需求，而不是直接提方案。

有一种忌讳的情况是：（如前面的例子）在不知道业务需求的情况下，已经花了大量精力将数据线上化，甚至想当然地实现了一些数据分析、展示的功能。这些工作没有促成数据生产力闭环建设，只是徒劳......

3.3 低成本验证

不管是业务侧还是产技侧，都没有办法一步到位，所以需求是变化的，如何满足需求也是变化的。为了能够更好的应对方方面面的变化，就需要尽可能延迟做不可调整的决策的时间。

对于业务侧的需求，需要经过层层筛选，最终才需要考虑进行系统化实现：

• 如果能够证明需求是伪需求，那么什么都不需要做；

• 如果需求只需要定性分析，那么不需要依赖数据；

• 如果需求只是偶发的、临时的，那么可以采用线下分析的方式来实现；

• 如果需求的分析方法还未成型，那么可以先用线下分析的方式来摸索；

• 如果需求的分析方法已经基本成型，但不经常使用，那么可以固化线下的分析流程；

• 如果需求的分析方法已经成型，且需要经常依赖分析进行决策，才需要考虑将整个数据分析流程线上化。

可见，当我们能够采用更低成本的方案来解决问题时，就不必要用成本更高的方式来解决。

我们在进行数据生产力闭环建设的过程中，会沉淀一些业务侧数据，如下所示：

如果不进行合理的规划，这些线上化沉淀的数据是没有进行过标准化和体系化的建设的，每一个新来的数据分析需求，都会以自己的方式收集数据：没有的数据就临时要求业务系统存下来，已有的数据就直接使用，甚至不去考虑数据的统计口径是不是跟自己期望的一致。待若干个需求做下来，就出现了下面的局面：

每个业务数据闭环都有自己线上化的数据，这些数据有各自的口径，有各自的组织方式，有存在互相依赖，重复使用等情况。当有新的业务数据需求时，会出现不知道需要的数据是否已经存在，口径是否符合需求，如果想要新收集数据的话，数据应该放在哪张表里等等问题。

所以，当业务系统发展到某个阶段，就需要考虑对业务沉淀的数据进行标准化和体系化建设了：要收集哪些数据？指标口径是什么？沉淀的数据如何组织等等。理想情况如下所示，当完成了若干个数据闭环需求后，就可以根据数据沉淀的经验，开始对数据进行标准化和体系化建设了。

具体的数据标准化和体系化建设方法，后期可以再用一篇文章来介绍。

数据生产力闭环是一个值得追求的目标，但这件事情不能着急推进。只有当业务发展到一定的成熟阶段，才真正到了推进这件事情的时间。作为产品开发团队，还是需要更多的贴近业务，去仔细了解业务已经在实践中形成的数据闭环，或者即将形成的数据闭环，并积极推进这些闭环的系统化落地。

绝不要做闭门造车的事儿。