建立大数据业务的全局观,了解大数据项目上下游

很多大数据的从业者,都清楚的知道,在大数据公司里,或者是大数据的项目里,都设有独立的数据部门,而且如果部门内的的人员规模足够大的话,还会进一步考虑划分成几个小组,比如BI、大数据、数据产品和UED,甚至还可能会有数据挖掘组、爬虫组。大家各尽其责,在自己的岗位上相互独立的去工作,虽然经常会遇到「数据项目」需要大家一起协作完成,但却很少有人彻头彻尾的去了解整个项目中的数据迁移,顶多也只是任务之间的对接而已。

如果每个人都只扮演着流水线上的一颗螺丝钉,那这种半封闭式的工作流程到底好不好呢?

我认为,如果站在「数据项目」敏捷开发的角度,让所有人都只专注自己熟悉的技术领域,短期内这或许是一件好事。但是长期下来,从项目的质量和创新来说,不见得是一件好事,因为认知的局限性,很难有人去全方位把控「数据项目」的方向和深度,从而导致同质化的数据产品一大堆,但都普遍缺乏创新性,也谈不上价值。同时从个人的成长进阶来看,弊肯定大于利。

别让「局限」蒙蔽了你的双眼,让你失去了无限的想象空间,也让你很难去最大化输出个人价值。

如果ETL工程师不懂业务的话,那么他就只是一个工具罢了,由业务人员提供需求和逻辑,他只负责加工数据,但却很难去验证数据的准确性,更别谈理解数据质量。

如果数据分析师不懂技术的话,那么他就只是在玩转小数据,由业务人员提供需求和表源,他就负责写SQL去分析数据。但他常常会把简单的SQL语句写得巨耗时,也不懂得去挖掘数据背后的意义,更别谈去做深度分析。

如果数据产品经理不懂的数据和技术的话,那么他就只是在天马行空,一切的构思都源于竞品分析,他就负责去完成功能堆积。但他却不理解功能背后的技术细节,也不懂得数据价值如何去落地,更别谈去推动产品运营。

而这些「如果」,并不是「假设」,而是实际发生在我们身边,无时无刻不引起注意的案例。

自从部门对外开放了「数据查询平台」给业务运营人员和数据分析人员使用以后,总是会在后台看到几百~上千行的SQL语句,先不谈运行效率,这语法逻辑跑出来的数据,其准确性都值得质疑,还如何谈后续的深度分析工作。

曾经还有一位数据产品经理在规划智能营销产品时,凭空堆积了很多无脑的功能,不去解决「效果跟踪分析」,反倒是列举了一些没价值的数据指标做大屏展示。还有所谓的「数据管理」、「模型训练」,都让你无法直视。根本不知道他在解决什么痛点需求,所以后续就不带一起玩了。

所以说,我一直在提倡大家要致力成为「综合性数据人才」,这也是未来市场上最紧缺的数据人才。而所谓的「综合」,并不是要求你在每一个数据环节都要专研很深,而是要让你在数据认知的广度上打破盲区,这样才能更好的服务于你所扮演的数据角色,更全面去理解数据的价值。

就像数据挖掘工程师一样,你不能只关注数据建模的环节,如果你只把精力全放在「算法专研」和「算法调优」上,不亲自去了解底层数据,也不结合业务去做用户分析和数据清洗,甚至不去思考模型结果后的业务运营以及产品包装,那你就不能说是在探索「数据价值」了。

总而言之,数据没有边界,你也不应该闭门造车,数据认知的广度和深度也是相辅相成的。

你可能感兴趣的:(建立大数据业务的全局观,了解大数据项目上下游)