数据分析师天天跑数？教你三句话，远离取数机

小提示：您能找到这篇{数据分析师天天跑数？教你三句话，远离取数机}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的数据分析师天天跑数？教你三句话，远离取数机内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

编辑导读：数据分析的重要性不言而喻，然而在实际工作中，数据分析性师最后只沦为取数的工具：业务方提需求，数据分析师取数，中间几乎没有什么分析环节，而且经常面临被老板质疑没有价值的困境。面对这种情况应该如何破局呢？本文作者基于自己的思考，为我们做出了解答。

老李有位朋友前不久去了阿里做BI，这几天总是跟我吐槽说“天下的乌鸦一般黑啊”！到底怎么回事呢？

其实，这位朋友之前经常混迹于BAT、TMD这些一线大厂，本来打算去了阿里，想着终于可以在数据分析上大展身手了

结果没想到现在的状态就是天天加班，被业务缠着要数据，折磨地叫苦不迭。

这件事就好比去了米其林餐厅当厨师，结果每天的工作却是剥蒜。

后来朋友提了几次意见，表示不想整天做跑数的需求，结果上面打下来的反馈却是：

“取数能帮助BI快速了解业务场景，公司里的数据平台和数据仓库都非常庞大，数据结构的复杂程度也非常高，业务那边的技术不够，有数据的需求很正常，这不就是你们做数据分析的价值吗？”

有一说一，这位上级说得似乎也没错，业务人员了解具体的场景需求和指标体系，数据分析人具有跑数取数的技术，似乎技术和业务结合在一起，才能解决实际问题。

业务与数据分析，好像本就是天造地设的一对，这估计也是很多人忽悠小白去做取数工作的说辞之一。

但根据我的经验，SQL取数、跑数、满足业务数据需求这些事情，固然是数据分析师的必备工作，也是每个数据分析师成长必须经历的一段时期。

但是这绝不是数据分析岗位的价值，也不应该成为数据分析师的核心任务！

国内很多公司对于数据分析存在着偏见，这一点我们后面有时间可以开个专栏好好说一说，下面就先聊一聊取数的那些事。

为什么你不能一直取数？

首先，取数工作是肯定要做的，因为数据分析最重要的是保证数据源的准确性，防止数据出现谬误，比如数据口径、数据指标、数据表等等。

所以业务人员搞不定，就算是数据分析放权让他们自己去跑数，他们也基本实现不了，因为经常要重复跑数、重复分析，效率非常低。

所以就需要数据分析人来做，学会SQL取数也有利于新人对数据底层的熟悉，尤其是对业务层的认知是很有帮助的（那位阿里的leader说得确实有道理）。

但是问题往往就出现在半年到一年之后，数据分析师的第一个瓶颈就到来了！

这个时候你已经对数据底层有了很详细的了解，如果一直忙着处理业务的需求跑数、取数，老板会觉得你没什么实际价值，找个新人一样可以做。

如果对于业务的需求直接拒绝，老板又会觉得没有及时响应业务方，不能给业务赋能增值，甚至连数据分析的价值都会产生怀疑；

这时候你就陷入了取数的死亡循环里，再也跳不出来了，离职、转岗、转行也就出现了。

本质原因很简单，跑数、取数的工作太枯燥、太机械、没有任何的上升空间。

那么怎么应对业务人员的取数需求，避免一直做取数机器呢？

其实只要坚持住一个核心思想——“该做的应当要做，不该做的坚决不做，实在内容营销 网络不想做的让他们自己做”

根据不同的场景有三种不同的应对方式：

第一句话：“你这个需求有没有人看？老板会不会看？”

当你接受了业务的需求之后，千万不要立刻就埋头去处理，等你把业务所有的需求都完成之后，你会发现很多需求最后都成了一堆废纸，根本无人问津。

这是业务人员的毛病，遇到一些小事情就喜欢提个需求，比如一些临时性的报表，但是往往应用范围很小。

判断方法的微商引流事什么意思很简单，就是对所有的需求进行优先级排序。

数据分析师一定要优先满足领导和老板的需求，大老板们的需求是必须快速响应并且仔细产出不能出错的

其次是部门级的需求，比如说电商公司里涉及销售成本的数据，往往需要贯穿财务、销售、仓储等数个部门，这种跨部门级的需求是第二层次要满足的

最后才是个人级和小部门级的需求，比如业务想为自己部门做个运营仪表板，提了个需求到数据分析部门，这种属于最次要满足的

第二句话：“你这个需求是不是已经是最详细、最完全的版本了？确定不改了？”

比如说想让你改进一下某个流程，当他提出这个问题的时候，其实他也不知道究竟应该怎么改进流程、改到什么程度才算是好、具体需要改什么。

这个时候如果我们不问清楚就做了，最后往往是得不到业做网络商城怎么样务部门的认同的。

所以我们需要形成文字，并且要让我们的需求方认同，比如说我们形成文字制度，将什么样的需求我们做、什么样的需求我们考虑之后做、什么样的需求我们不做，然后找到业务部门协商，落地之后我们都认同这个制度，就不会出现奇葩需求的出现了。

我比较常用的方法就是需求可行性验证表，是我现在一直在用的表，大家可以参考一下：

这样我们可以在事先就避免业务的不认同，因为业务已认可了你的可行性方案后我们再去做分析，其实是比较稳妥的

第三句话：“你这个需求太小太窄，完全可以自己做，如果有困难的话我们会帮你做，但不会有很多时间。”

如果前面两句话都没有堵住业务的嘴，而你又觉得整个需求没什么必要，那么就不妨让他们自己去做

当然这种方法属于后招，一般情况下也很难实现，因为让业务去学习一门新技术，还不如直接提高数据分析部门的取数效率来得快

但是也有很多小需求，比如业务经常想要查看销售数据，时不时就要提临时的数据需求，看完之后就再也不用了

这个时候长痛不如短痛，让他们去找IT部门搞数据权限，自己顶多帮他们设计一个取数面板，就OK了

至于能不能要到数据权限，这也是业务与IT的任务，不是数据分析的

总结

不论是在业务部门还是在技术部门，分析师最终分析的落脚点还是业务价值

因此我们首先应当做的是用上面的方法先将自己从取数的泥潭里解救出来，然后专注于提升自己分析的价值，让业务愿意带你一块玩

当你被分析需求占满以后，自然就不会有取数的烦恼啦。

作者：李启方，专注数据分析和企业数据化管理；公众号：数据分析不是个事儿

本文由 @李启方 于。，

，基于CC0协议