业务型 VS 技术型数据分析师,哪个更有前途?

简介: 业务型 VS 技术型数据分析师,哪个更有前途?

很多同学都听说过,数据分析有技术型/业务型的区别。到底这俩有啥差异?哪个更适合自己?今天详细讲解一下。

业务 VS技术,差异在哪里

技术型数据分析岗位特征如下:

1、任职部门在IT部,数据团队领导面试

2、岗位职责里,没有写具体做哪一块业务

3、岗位职责里,笼统地写:“满足运营、产品、销售等部门需求”

4、面试时一般会考SQL题,问一些笼统的“指标异动怎么分析”

5、入职以后接各个业务部门的需求,更新固定报表/临时取数

业务型数据分析岗位特征如下:

1、任职部门在业务部,有可能有业务领导面试

2、岗位职责里,明确写:“用户增长/门店分析/针对商户策略分析”

3、筛简历的时候,会挑有类似分析经验的优先面试

4、面试的时候,会直接问具体的增长/活动/门店问题如何分析

5、入职以后服务特定部门(运营/产品/销售),写PPT写得多

所以直观地看,其实就是“面试到底挑不挑业务经验”+“入职以后服务一个部门还是接各种需求”的区别。

因此同学们在面试的时候,不要光看招聘要求最下边的能力,得看一下上边的岗位职责,面试的时候记得问一下:

1、面试官是HR还是用人领导

2、这个岗位设在IT还是业务

3、这个岗位有没有团队,大概几个人

这样才方便自己判断形势。经常有同学没有认真看,准备不充分,去了被几个业务问题劈头盖脸问蒙圈了,这就太浪费机会了。有一种特殊情况,就是有些岗位在数据中心,但是挂的是类似“数据BP”还是服务业务的,这时候也会问很多业务型问题。

技术型数据分析来源

大企业里都有专门的数据团队,规模再大的还有独立的数据中心。这些组织一般设置在IT下边,是所谓技术型分析师的来源。至于具体工作的专业程度,主要看组织规模的大小。

一般独立的数据中心,会单独下设:数据治理、数仓开发、BI系统开发、数据分析、算法模型。其中数据分析团队专门陪着业务处理复杂的取数需求,固定的数据看板则交给BI开发来做。

当然,有的公司规模没这么大,因此会合并小组。还有的公司规模实在太小,就指望招一两个人过来“全栈数据分析”。在这种草台班子打工的体验是非常差的,经常是清洗垃圾数据就累得半死,还被嫌弃“分析不够深入”,所以找工作的时候要小心。

最关键的问题就俩:有没有自己的数仓/有没有数据团队。如果没人,没数仓,就得悠着点考虑。作为菜鸟去混混经验还行,老鸟都不推荐去。

业务型数据分析来源

很多常用数据的业务部门也会自己招人,这就是业务型分析师来源。常见的有三类:

第一类:战略发展部、集团市场部、业务管理部。这些部门是公司决策中枢,经常需要做数据报告,分析业务发展情况,制定经营计划,制定预算,跟踪业务发展,分析业务问题。因经常需要自己招人。招聘的岗位名字,可能叫“数据分析”也可能叫“经营分析”“商业分析”,但干的工作是差不多的。

第二类:用户运营、商品运营、策略运营、销售运营、风控与反欺诈部门。这些部门需要设计业务策略,跟踪业务执行效果,诊断业务问题,指导一线工作,对具体业务问题,比如用户分析、商品分析、策略分析、风险分析等有要求,因此经常招人,有的还配置了自己的分析小组。招聘的岗位名字,除了“数据分析”,也可能叫“数据运营”“用户分析”。

第三类:客服、销售、供应链。这些部门的人力使用多,负责事务多,日常处理客户咨询/投诉、原材料收货/发货、生产进度统计、销售进度追踪等等,因此经常招人。只不过这些部门更偏一线,招聘的岗位,一般都是“专员”,比如“销售统计专员”“客服统计专员”“采购统计专员”。

单纯从部门、岗位名字,大家也能看出来差别。实际上大部分基层的“XX数据专员”,他真的就是砖员,每天都在用Excel处理基础的统计表,没啥技术含量,工资也很低,前途也很渺茫。

虽然名为“销售分析专员”,可真去面试高级一些分析岗位,不是被嫌弃缺经验,就是被嫌弃思路不行。除非是0基础转行的想混点经验,否则都不推荐。

看到这,肯定有同学会问:那技术型/业务型分析,到底干哪个好?

业务 VS 技术,应该选哪个

对于在校生而言,强烈建议不要考虑啥业务型分析,就认认真真找一个写SQL的岗位实习仨月。也不用管它啥公司,只要能写SQL就行。

因为在校生对数据分析工作,经常叶龙好龙。觉得自己很适合干数据分析,可每天搓个200行SQL,核对一下数据,清洗一下数据,就觉得很枯燥,无聊,想跑。所以找个实习体验下真实感觉非常重要。

还有些在校生,把业务分析当成是逃避写SQL的退路,“我不想写SQL,我去干业务分析行不行?”额……问题是对在校生而言,你也不懂业务呀。抱着这种心态,很容易找一个砖员类工作,干了几个月发现自己就是个Excel搬运工,最后还是干不下去。

对于已经工作的同学而言,主要看自己更擅长哪个+想做哪个。

有些业务的同学想转数据,是因为厌烦事务型工作。比如做会员运营的,要去采购会员礼品,处理会员投诉,定SOP然后一轮轮去各地宣讲,真心烦,本身自己就熟悉会员制度、活动玩法,转数据也是很好的。这时候就可以转业务型数据分析,发挥自己懂业务的优势。

有些同学虽然是写SQL的,但是和业务混得熟,特别和产品/策略部门混得熟,参与多很多产品/算法类ABtest。这时候去面大厂的产品分析、用户分析、策略分析都很有优势。

相关文章
|
8月前
|
数据挖掘 机器人 程序员
什么是好的数据分析?化繁为简的力量
什么是好的数据分析?化繁为简的力量
|
10月前
|
数据采集 机器学习/深度学习 人工智能
成为数据驱动型公司的六大障碍
成为数据驱动型公司的六大障碍
|
11月前
|
存储 数据采集 运维
迈向数据驱动型组织:将简单给予客户,将复杂留给爱数
迈向数据驱动型组织:将简单给予客户,将复杂留给爱数
|
数据采集 存储 人工智能
数据价值有效发挥的障碍:高级数据分析常见的五种挑战
我们经常听到高级分析的成功案例。人们对人工智能的期望很高——据预测人工智能和人工智能的年经济价值将在9.5万亿到15.4万亿美元之间——因此,只要有可能,许多人都想把目光聚焦在数据分析技术的发展上。
|
设计模式 消息中间件 分布式计算
揭秘程序员在「外包」、「技术导向型」和「业务驱动型」公司的日常生活
揭秘程序员在「外包」、「技术导向型」和「业务驱动型」公司的日常生活
|
数据挖掘 算法 人工智能
带你读《增强型分析:AI驱动的数据分析、 业务决策与案例实践》之一:数据科学家的成长之路
本书“深入浅出的原理介绍 + 实际使用的案例”的内容安排能够使得数据分析建模人员从算法原理、数据挖掘知识结构、业务应用方法等方面得到提升,帮助数据分析建模人员开阔眼界、优化知识结构、提升实践技能。
|
SQL 关系型数据库 数据库
【沉淀】一张表的设计优化节省了两百万,客户不断盛誉……,这背后他究竟做对了什么?——记访谈阿里云汪建明
聊到对技术的理解,他说,不论是技术人,还是技术型公司,都需要对技术的执着追求、对任何问题死磕到底的工匠精神,戒骄戒躁;以技术解放生产力问题,用技术提高生产率,优化产品质量。
26995 0