数据分析师做成了提数工程师，该如何破局？

0x00 前言

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

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

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

本文聊一下三个内容：

1. 为什么数据分析会变成提数工程师
2. 数据分析该如何改变提数工程师的命运，充分发挥数据分析的作用
3. 聊一下其它岗位的类似情况

0x01 为什么成了提数工程师？

为什么做数据分析会变成提数工程师？我们来看一下数据分析的大致工作流程：1. 问题提出；2. 数据获取；3. 数据处理；4. 数据分析与建模；5. 数据结论输出。

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

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

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

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

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

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

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

0x02 如何优雅地进行数据分析工作

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

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

一、举个栗子

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

需求：

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

解决方案一：

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

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

解决方案二：

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

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

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

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

在改进分析流程之外，我们可以提供更多的自助分析工具，让产品和运营能够更多地自助验证自己的想法，将数据分析师的工作从提数中解脱。这一块就不再展开细讲。以后有机会再做分享。

0x03 思考

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

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

0xFF 总结

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

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

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

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