3大领域,4大方向,做好数据分析岗位的职业规

3大领域,4大方向,做好数据分析岗位的职业规

时间:2020-02-13 12:24 作者:admin 点击:
阅读模式

俗话说,再优秀的产品经理也跑不过一半AB测试。此类数据产品经理,更多是注重数据分析能力,擅长用分析进行决策。数据是能力的一部分。

后者,是真正意义上的数据产品经理。在公司迈大迈强后,数据量与日俱增,此时会有不少数据相关的产品项目:包括大数据平台、埋点采集系统、BI、推荐系统、广告平台等。这些当然也是产品,自然需要提炼需求、设计、规划、项目排期,乃至落地。

我们不妨看几个数据产品经理要求:

负责大数据产品的设计,输出需求文档、产品原型;

负责推荐算法的产品策略,完成相关推荐及个性化推荐产品的需求分析;

负责分析和挖掘用户消费内容的行为数据,为改进算法策略提供依据;

负责客户端数据需求的对接,制定相关埋点规范及口径,相关业务指标验证;

报表展示工具的落地和应用;

和C端注重用户体验不同,数据产品,更注重整体的分析能力和逻辑。除了产品经理最基础的Axure、Visio、MindManager等工具。往往还需要很多技术型的能力。比如了解BI/DW原理和实施、了解常用的推荐算法、了解机器学习模型等。这也很容易理解,C端要求你了解用户需求,而在数据端,主要用户就是数据。

这当然不是说,用户体验不重要,拿推荐算法来说,除了满足用户最基本的感兴趣,也要考虑时效性,考虑新兴趣的挖掘,考虑无数据时的冷启动问题…这些一样是用户体验,只是解决方案也得从数据出发。再多思考一步,模型是离线还是实时,实时怎么实现它?技术细则不用多考虑,但你要知道会有这些坑。后端的数据产品,如报表,用户往往是你隔壁工位的小秦或小路,设计得丑一点不要紧,要是数据指标口径不统一,那才会分分钟骂街。

虽然数据PM需要熟悉各类数据模型、指标、数据挖掘和数据工程的实现,但是聚焦点是把它作为一个项目去实现,故而不用精通。

数据产品经理是一个比较新兴的岗位,所以有丰富经验的从业者并不多,我个人认为,还是存在比较大的职业缺口。当然也有其他问题,一是因为新兴,部门负责人本身也没有想好他们能干什么,不少数据PM还从事表哥的工作。二是数据产品本身可借鉴的经验不多,像APP产品,可以下载体验,总归有一个学习的过程。然而用户画像、BI、算法策略,都是其他公司的内部机密,无从参考,我就遇到不少对用户画像实现非常感兴趣的数据PM。

从职业发展上看,数据分析师做数据产品经理更合适。普通的产品经理,对前端、后端的技术栈尚未熟悉,何况日新月异的数据栈。这个岗位,适合对数据特别感兴趣,但是数理天赋不高的职场人,那么以沟通、项目管理和需求规划为能力,也不错。

学习资料:

数据产品经理,如果有数据挖掘经验,那么技术相关的书籍倒不重要,别落伍就行,更关注产品经理本身的能力,包括Axure,各类文档的编写、项目管理、需求整理等,市面上资料比较多。

这里再补充两本,「数据挖掘与数据化运营实战」,没啥高深技术,但是能够了解体系的初步建立。「数据挖掘技术—应用于市场营销、销售与客户关系管理」,这本书我推荐它是纠结的,它的知识点比较丰富,业务人员也能看懂,但是翻译的实在太糟糕了……

更多书籍参考其他岗位即可。

数据工程师

数据工程师其实更偏技术,从职业道路上看,程序员走这条路更开阔。

在很多中小型的公司,一方面数据是无序的、缺失的、原始的,另外一方面各种业务报表又嗷嗷待哺。没办法,分析师只能自己撸起袖子,一个人当三个人用。兼做数据清洗+ETL+BI。

经历过的大概都懂,数据分析踏上数据工程的不归路如下:

每天都要从五六张表上join,那么不妨加工成一张中间表;

ETL的依赖关系越来越复杂,尝试用kettle/airflow等框架搞定,弄个DAG美滋滋;

运营部门的周报次次都要这几个指标,看看能否做一个自动化BI;

数据量逐日增多,最近T+1的日报需要几个小时完成,研究下查询语句的优化;

查询语句的优化空间也不大了,开始迁移到Hadoop/Spark分布式平台,新技术栈的学习;

新平台,原有的工具也不管用了,某大牛说apache上有工具能解决这个问题,于是阅读文档;

公司部署了私有化的埋点采集,数据缺失比较厉害,业务部门天天骂娘,继续埋Flume/Kafka的坑;

等等…

如果分析师在技术方面的灵性不错,那么技能点会往技术栈方向迁移。从最初的SQL,到了解Hadoop集群、了解presto/impala/spark、了解ELK、了解分布式存储和NoSQL……

这也是一个不错的发展方向,因为数据挖掘需要了解算法/模型,理论知识要求过高,不少硕士和博士还过来抢饭碗,自己不擅长容易遇到天花板。选择更底层的工程实现和架构,也是出路,薪资也不会低于数据挖掘/算法专家。

部分归属到技术部的数据分析师,虽然Title叫数据分析(其实应该叫数据分析开发工程师),很多工作也是围绕ETL/DW/BI进行,那么这就是标准的数据工程路线。

部分公司会将机器学习模型的部署和实现交给数据工程团队,这要求数据工程师熟悉sparkMLlib、Mahout此类框架。

数据工程师,可以从数据分析师的SQL技能,往数据的底层收集、存储、计算、运维拓展。往后发展则是数据总监、或者数据架构师。因为数据分析出身,与纯技术栈的程序员比,思考会更贴合业务,比如指标背后的数据模型,但是技术底子的薄弱需要弥补。

另外,DBA、BI这些传统的数据库从业者,也是能按这条路线进阶,或者选择数据产品经理方向。

学习资料:

数据工程类的书籍,我看的不多,给不了建议。主要按各类名词搜索吧,什么linux、数据仓库、Hadoop、Spark、Storm、Elasticsearch等。这类岗位发展,技术更新速度比较快,所以需要保持吸收以及活用开源。

最后

以上四个岗位就是数据分析的发展方向,它们互有关联,如果从整个架构图来看(一篇历史旧文有更详细的描述:从零开始,构建数据化运营体系)。

我们可以将其划分为数据收集—数据加工—数据运营—数据触达。

数据收集负责收集各种各样的原始数据,比如用户何时何地做了什么事情。它依赖于埋点采集系统,而埋点采集,需要收集什么类型数据,往往由数据产品经理确定规范(还是看公司,数据运营和数据分析师也能负责)。

收集上来的数据需要存储,往往因为高吞吐量,需要保证数据和日志的稳定性,会采用Flume+Kafka,如果有实时统计要求,也得考虑流数据。这块则是数据工程的范畴,包括原始数据的再加工,数据清洗,都是专门的数据团队完成。

当获得数据后,首先第一点是讲各种明细数据加工业务指标,没有指标不成方圆,这里由数据分析师定义的。有了指标,配合各种数据产品输出,如用户画像用户标签、BI报表,这些数据产品都由数据PM统筹排期…另外一方面,数据挖掘工程师和算法专家则凭各种数据建立模型,进行实时或离线运算。

模型可能会预测用户会不会购买某个商品,可能是做出一系列的推荐,可能是判断用户属于哪个类型,不一而足。

更上面一层是业务相关,数据分析师会监控和分析BI上指标的波动、数据挖掘工程是通过用户反馈数据,衡量算法的优劣、数据PM按AB测试的结果改进产品。数据工程师保证系统的稳定。

所有层次一环扣一环,每个岗位在其中都发挥特有的作用。数据工程偏底层技术,数据分析偏上层业务,数据挖掘和数据产品处于中间形态。不同公司虽然业务形态不一致,架构会有差异,但是职责不会偏差太大。这也是数据分析为什么会有四个方向。

讲到这里,你大概对数据分析的职业规划有了明晰的了解。当然,它们彼此间并不完全独立,到后期,很多界限会变得模糊。所以规划是一方面,是否愿意执行、学习和吃透,才是职业真正的道路呀。