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

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

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

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

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

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

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

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

而这些「如果」，并不是「假