阿里的数据分析师也得天天跑数?教你三句话,从此远离取数机( 二 )


业务的需求永远是模糊的 , 这个问题是我老生常谈的问题了
比如说想让你改进一下某个流程 , 当他提出这个问题的时候 , 其实他也不知道究竟应该怎么改进流程、改到什么程度才算是好、具体需要改什么
这个时候如果我们不问清楚就做了 , 最后往往是得不到业务部门的认同的
所以我们需要形成文字 , 并且要让我们的需求方认同 , 比如说我们形成文字制度 , 将什么样的需求我们做、什么样的需求我们考虑之后做、什么样的需求我们不做 , 然后找到业务部门协商 , 落地之后我们都认同这个制度 , 就不会出现奇葩需求的出现了
我比较常用的方法就是需求可行性验证表 , 是我现在一直在用的表 , 大家可以参考一下:
阿里的数据分析师也得天天跑数?教你三句话,从此远离取数机文章插图
这样我们可以在事先就避免业务的不认同 , 因为业务已认可了你的可行性方案后我们再去做分析 , 其实是比较稳妥的
第三句话“你这个需求太小太窄 , 完全可以自己做 , 如果有困难的话我们会帮你做 , 但不会有很多时间 。 ”
如果前面两句话都没有堵住业务的嘴 , 而你又觉得整个需求没什么必要 , 那么就不妨让他们自己去做
当然这种方法属于后招 , 一般情况下也很难实现 , 因为让业务去学习一门新技术 , 还不如直接提高数据分析部门的取数效率来得快
但是也有很多小需求 , 比如业务经常想要查看销售数据 , 时不时就要提临时的数据需求 , 看完之后就再也不用了
这个时候长痛不如短痛 , 让他们去找IT部门搞数据权限 , 自己顶多帮他们设计一个取数面板 , 就OK了
至于能不能要到数据权限 , 这也是业务与IT的任务 , 不是数据分析的
总结 不论是在业务部门还是在技术部门 , 分析师最终分析的落脚点还是业务价值
因此我们首先应当做的是用上面的方法先将自己从取数的泥潭里解救出来 , 然后专注于提升自己分析的价值 , 让业务愿意带你一块玩
当你被分析需求占满以后 , 自然就不会有取数的烦恼啦