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

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

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

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

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

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

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

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

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

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

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

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

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

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