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

数据分析师天天跑数？教你三句话，远离取数机 / 老李有位朋友前不久去了阿里做BI，这几天总是跟我吐槽说“天下的乌鸦一般黑啊”！到底怎么回事呢？ 其实，这位朋友之前经常混迹于BAT、TMD这些一线大厂，本来打算去了阿里，想着终于可以在数据分析上大展身手了 结果没想到现在的状态就是天天加班，被业务缠着要数据，折磨地叫苦不迭。 这件事就好比去了米其林餐厅当厨师，结果每天的工作却是剥蒜。 后来朋友提了几次意见，表示不想整天做跑数的需求，结果上面打下来的反馈却是： “取数能帮助BI快速了解业务场景，公司里的数据平台和数据仓库都非常庞大，数据结构的复杂程度也非常高，业务那边的技术不够，有数据的需求很正常，这不就是你们做数据分析的价值吗？” 有一说一，这位上级说得似乎也没错，业务人员了解具体的场景需求和指标体系，数据分析人具有跑数取数的技术，似乎技术和业务结合在一起，才能解决实际问题。 业务与数据分析，好像本就是天造地设的一对，这估计也是很多人忽悠小白去做取数工作的说辞之一。 但根据我的经验，SQL取数、跑数、满足业务数据需求这些事情，固然是数据分析师的必备工作，也是每个数据分析师成长必须经历的一段时期。 但是这绝不是数据分析岗位的价值，也不应该成为数据分析师的核心任务！ 国内很多公司对于数据分析存在着偏见，这一点我们后面有时间可以开个专栏好好说一说，下面就先聊一聊取数的那些事。 为什么你不能一直取数？ 首先，取数工作是肯定要做的，因为数据分析最重要的是保证数据源的准确性，防止数据出现谬误，比如数据口径、数据指标、数据表等等。 所以业务人员搞不定，就算是数据分析放权让他们自己去跑数，他们也基本实现不了，因为经常要重复跑数、重复分析，效率非常低。 所以就需要数据分析人来做，学会SQL取数也有利于新人对数据底层的熟悉，尤其是对业务层的认知是很有帮助的（那位阿里的leader说得确实有道理）。 但是问题往往就出现在半年到一年之后，数据分析师的第一个瓶颈就到来了！ 这个时候你已经对数据底层有了很详细的了解，如果一直忙着处理业务的需求跑数、取数，老板会觉得你没什么实际价值，找个新人一样可以做。 如果对于业务的需求直接拒绝，老板又会觉得没有及时响应业务方，不能给业务赋能增值，甚至连数据分析的价值都会产生怀疑； 这时候你就陷入了取数的死亡循环里，再也跳不出来了，离职、转岗、转行也就出现了。 本质原因很简单，跑数、取数的工作太枯燥、太机械、没有任何的上升空间。 那么怎么应对业务人员的取数需求，避免一直做取数机器呢？ 其实只要坚持住一个核心思想——“该做的应当要做，不该做的坚决不做，实在不想做的让他们自己做” 根据不同的场景有三种不同的应对方式： 第一句话：“你这个需求有没有人看？老板会不会看？” 当你接受了业务的需求之后，千万不要立刻就埋头去处理，等你把业务所有的需求都完成之后，你会发现很多需求最后都成了一堆废纸，根本无人问津。 这是业务人员的毛病，遇到一些小事情就喜欢提个需求，比如一些临时性的报表，但是往往应用范围很小。 判断方法的很简单，就是对所有的需求进行优先级排序。 数据分析师一定要优先满足领导和老板的需求，大老板们的需求是必须快速响应并且仔细产出不能出错的 其次是部门级的需求，比如说电商公司里涉及销售成本的数据，往往需要贯穿财务、销售、仓储等数个部门，这种跨部门级的需求是第二层次要满足的 最后才是个人级和小部门级的需求，比如业务想为自己部门做个运营仪表板，提了个需求到数据分析部门，这种属于最次要满足的 第二句话：“你这个需求是不是已经是最详细、最完全的版本了？确定不改了？” 业务的需求永远是模糊的，这个问题是我老生常谈的问题了。 比如说想让你改进一下某个流程，当他提出这个问题的时候，其实他也不知道究竟应该怎么改进流程、改到什么程度才算是好、具体需要改什么。 这个时候如果我们不问清楚就做了，最后往往是得不到业务部门的认同的。 所以我们需要形成文字，并且要让我们的需求方认同，比如说我们形成文字制度，将什么样的需求我们做、什么样的需求我们考虑之后做、什么样的需求我们不做，然后找到业务部门协商，落地之后我们都认同这个制度，就不会出现奇葩需求的出现了。 我比较常用的方法就是需求可行性验证表，是我现在一直在用的表，大家可以参考一下： 这样我们可以在事先就避免业务的不认同，因为业务已认可了你的可行性方案后我们再去做分析，其实是比较稳妥的 第三句话：“你这个需求太小太窄，完全可以自己做，如果有困难的话我们会帮你做，但不会有很多时间。” 如果前面两句话都没有堵住业务的嘴，而你又觉得整个需求没什么必要，那么就不妨让他们自己去做 当然这种方法属于后招，一般情况下也很难实现，因为让业务去学习一门新技术，还不如直接提高数据分析部门的取数效率来得快 但是也有很多小需求，