【摘要】最近收到了不少数据分析朋友的吐槽和抱怨：Title 是数据分析，结果天天做着提数的工作，没有技术含量分析结论都是运营和产品向老板汇报，

最近收到了不少数据分析朋友的吐槽和抱怨：

Title 是数据分析，结果天天做着提数的工作，没有技术含量分析结论都是运营和产品向老板汇报，没自己什么事别人家的数据分析都是各种算法和模型，为什么到了自己就是提数和提数

上面这些情形不管是在大公司还是小公司都是很常遇见的，如果你经常处于类似的工作状态下，那么一定时间后，你将失去两项核心竞争力：技术深度和业务深度。

本文聊一下三个内容：

为什么数据分析会变成提数工程师

数据分析该如何改变提数工程师的命运，充分发挥数据分析的作用

聊一下其它岗位的类似情况

一、为什么成了提数工程师？

为什么做数据分析会变成提数工程师？我们来看一下数据分析的大致工作流程：

1. 问题提出；

2. 数据获取；

3. 数据处理；

4. 数据分析与建模；

5. 数据结论输出。

由于现在大部分互联网公司的产品和运营相对更靠近业务，因此这两个角色更容易发现和提出问题，如果数据分析师的主动性比较弱，那就会变成了如下这样的工作分工：

【产品或运营】问题提出【数据分析】数据获取【数据分析】数据处理【数据分析】数据分析与建模【产品或运营】数据结论输出

也就是说，问题提出 这个重要的环节不属于数据分析师负责，按照上面的模型运行的时间一长，数据分析基本就变成了帮助产品或运营验证想法的工具。

因此我们可以得到第一个原因：问题提出权不在数据分析师，数据分析只能去实现产品和运营的想法！

如果问题不是由数据分析师提出，再加上数据分析师的主动性差一些，那就会变成这种情况：产品或运营提一个需求，分析师就按需求实现一下，不需要思考太多，按需求做就好。这样的结果是，很多分析问题都会很简单，因为产品和运营并不太了解数据分析师能提供的能力。

我们得到第二个原因：产品和运营可能会提出相对简单的问题，数据分析机械去执行即可，不需要过多的技术深度。

在上述两种原因的影响下，数据分析也会逐渐失去主动性，最终沦为提数工具。

二、如何优雅地进行数据分析工作

前面抛出了问题和可能的原因，那么我们该如何去改进呢？毕竟没有谁愿意只做个机械的提数工具的。总的来讲，主观能动性是解决问题的最重要的因素。细分来讲，可以从下面几个角度来改变：

积极主动地发现和提出问题，如果产品或运营已经抛出了问题，那就去深入详细的了解问题的背景提供更多的分析思路和自己的见解，帮助产品和运营同学打开思路，让对方知道数据分析可以提供的能力持续跟进分析结论的效果和反馈，不断改进和优化优化数据分析的流程，加入数据分析师可以更多参与的环节

举个栗子

上面说的太虚，我们举个例子来说明：

需求：

假设运营同学提出了这样一个数据分析需求：最近我们网站的DAU降低了，麻烦你提个数据，看一下近30天我们各个模块的DAU是什么样子的。

解决方案一：

假设我只是想简单地完成这个需求，那么很简单，我只需要做这三件事即可：2. 数据获取；3. 数据处理；4. 数据分析与建模。到这个场景里面，可能就是从数据里面捞一下我们网站数据里面各个模块的DAU情况，提供给运营就行了，不需要多复杂的处理，甚至如果有现成的报表，简单导出来一个excel即可。

那么当运营拿到数据后，就可以看出哪一个模块的DAU降低，简单看一下原因后写在报告里面即可。

解决方案二：

我们当然不希望是上面这种解决方案这么低的参与感。那么，该如何做呢？

首先，我们可以改进我们的分析流程：

问题提出：通过监控或者主观的数据敏感度，提前来发现相应的数据问题，比如DAU下降，是可以通过监控平台来提前发现DAU的下降确定分析目标和产品诉求：需求中只是要看各模块的DAU趋势，但运营同学更想要的是找到为什么整体DAU会下降，找到原因并优化该问题。我们需要和运营童鞋沟通并get相应的点收集假设：运营同学提出要看各模块的DAU，这只是运营提出的一种猜测，让我们提相应的数据去验证该猜测。我们既然知道了运营童鞋的诉求，在盲目地直接捞数据之前，可以提出一些假设，比如说：是不是某种浏览器的兼容出现了问题，是不是某种类型的用户对我们的网站感兴趣度降低了，是不是某个模块出现了问题，等等。设计指标：有了假设，我们就可以根据相应的假设设计一些统计指标或者相应的分析方法，比如看不同用户画像的用户近期的访问情况、不同浏览器用户的访问情况、不同模块的访问情况。设计验证方法和建模：有了假设，有了指标，我们就可以设计相应的方案来验证我们的假设是否正确，这时就可以用到相应统计学和机器学习的方法，当然用户画像也是很重要的一环。确定分析结论和运营策略：最终，根据前面的步骤，我们再提供相应的分析结论给到运营侧，此时，我们提供的就不是简单的一个数据，而是一整套的数据分析报告。效果验证和改进：一定要关注数据分析的效果，比如你的报告中提出了DAU降低是由于18-25岁年龄的用户大量流失，相应的运营策略是增加年轻化的内容，那你就要关注该策略上线前后的数据变化，数据是否按照你们假象的方向来发展，如果不符合预期就要相应的做调整。

如此，这才是相对优雅的数据分析流程。

在改进分析流程之外，我们可以提供更多的自助分析工具，比如BI工具。让产品和运营能够更多地自助验证自己的想法，将数据分析师的工作从提数中解脱。这一块，我之前写过不少用BI工具来做分析的方案，就不再展开细讲。

三、思考

其实，除了数据分析师之外，数据仓库和数据开发同学都会面临类似的困境，在很多分工不明确的公司中，这种提数需求是可以落在任意的数据同学身上，不同的是各个角色解决该问题的角度是不同的。简单来讲：

数据分析师：更多地要去深入到业务的需求中去，帮助产品、运营或者老板思考，通过更多的思考来帮助需求方设计更好的分析思路数据仓库工程师：数仓同学的侧重点更多地在数据模型的设计，设计出更灵活的数据模型来支持多样性的分析提取需求数据开发工程师：开发同学呢，则可以更多地侧重于工具的建设，比如OLAP系统的建设，自助分析工具的建设等等。总结

总结一下本文的内容：本文通过【数据分析师做成了提数工程师，该如何改变这种现状？】 这一个问题，引出了造成这种现象的两大原因：

问题提出权不在数据分析师，数据分析只能去实现产品和运营的想法！产品和运营可能会提出相对简单的问题，数据分析机械去执行即可，不需要过多的技术深度。

针对这两个原因，我们提出了两个解决方法：

改进分析流程提供更多的自助分析工具