当前位置:首页 > HTML5

数据驱动时代的岗位要求转变

栏目分类:HTML5 发布日期:2018-08-22 12:00:21 浏览次数:
岗位在变,岗位要求也在变,没有东西是恒定不变的。随着数据驱动时代的到来,对各种岗位的要求,也在悄然变化,我这里探讨一下在互联网领域,对这种岗位在数据能力要求上的转变,包括产品经理、研发工程师、运营经理、市场经理、数据分析师、管理者等。

在 19 世纪下叶,有类岗位非常吃香,就是电报员。当时年轻的爱迪生最早就是干着电报员的工作,敲动按键收发电报,就像今天的程序员。可遗憾的是这种职业持续了几十年,随着电话的出现,逐步被淘汰了。在十年之前,春节回家买票是很困难的,黄牛可谓很吃香,可后来有了 12306 和实名制,断了黄牛们的财路,有了灭顶之灾。

 

我在最早参加工作时,还觉得做程序员挺悲剧,需要天天对着电脑,现在放眼望过去,有多少白领工作是不用整天对着电脑的?岗位在变,岗位要求也在变,没有东西是恒定不变的。随着数据驱动时代的到来,对各种岗位的要求,也在悄然变化,我这里探讨一下在互联网领域,对这种岗位在数据能力要求上的转变,包括产品经理、研发工程师、运营经理、市场经理、数据分析师、管理者等。

 

1 产品经理

2010 年,一本《人人都是产品经理》在互联网圈子吹了个遍,一下子给许多人带来了希望,原来还有产品经理这么一个岗位,看起来很不错啊,纷纷要决定当产品经理。在这之前,产品经理这个岗位在几家大的互联网公司存在已久,但也不过是 2000 年之后的事情,之前更是没有这个岗位。如何成为一名优秀的产品经理,相关的培训和书籍也已经比较多了,网上更是很多类似的文章。可在数据驱动时代,对产品经理又有什么要求呢?那就是用数据说话的能力。

 

我在 2007 年入职百度知道做研发工程师,刚入职第一天,就发现邮箱里收到了几十封报表邮件,包括百度知道的提问量、回答量、Session 数、检索量等。我心想这样的核心数据怎么连我这样的刚入职的新人都能看到,后来才知道原来“用数据说话”就是百度的文化。一个产品功能要不要做,一个软件模块性能如何,都是要用数据说话。我曾经有几个月时间就为了将百度知道用户提交失败的次数从 100 降低到个位数费尽周折。

 

产品经理在进行需求评审时,都会有专门的一块内容,就是“统计需求”,在评审会上,产品经历和研发工程师会讨论需要有什么数据做支撑,统计的口径是什么,等到项目上线之后,就开始分析实际数据是否和预期相符,如果不相符,问题出在哪里?并且通过分析出的问题进行改进,然后再进行数据验证。可以说不只是要有数据意识,还要在工作中形成数据驱动的流程。我这两年接触的产品经理中,许多都给我反馈数据采集需求推不动研发工程师,我一问详情,才知道往往是产品上线以后,产品经理才提出了数据采集和分析的需求,这个时候工程师早就把要做的工作做完了,这个时候再提出,就感觉是在打补丁,配合的不好。

 

这其实反映一个问题,就是产品经理在提出产品需求时,并没有做足够的数据需求梳理,而是把这放在业务上线之后,这个工作要提前,不能懒惰。当然,肯定有许多数据需求是事先想不清楚的,这种不可避免,但如果前期数据需求沟通在产品需求解决都沟通的比较好,两边配合也要好很多。

 

有本书叫《精益创业》,我是推荐每个产品经理都要读一读的,它里面核心讲了两个概念,一个是 MVP,做最小可用产品,另一个就是把数据分析引入到产品迭代中,形成点子 - 产品研发 - 数据分析 - 点子的循环。

 

2 研发工程师

产品经理和研发工程师是一对共同体,不可割舍但又矛盾重重。前面说了产品经理的问题,这里反过来看工程师的问题。许多时候产品经理提出数据需求时,工程师会反映很忙,再忙着迭代功能,得晚一点再做。

 

可是如果开发的功能不能够用数据做验证,那开发本身又有多少意义呢?我曾经看过一篇文章对比硅谷和北京,里面提到北京的创业氛围要比硅谷拼的多,但是也提到一个问题,就是光忙着开发功能了,却没有做必要的数据收集。这是个基本的问题,就是数据驱动时代,对工程师的要求也变了。

 

我当时刚入职百度时,会有专门的一块培训,就是教你如何打日志。所谓日志,就是用户做的每一个请求,后台都要记录下来,什么时间来自什么 IP 地址的用户访问了什么页面,类似这样的记录。这些日志有两个作用,一是当服务出现故障时,可以通过日志分析请求参数是什么,导致了后来出现了什么异常,二是用于用户使用情况统计。我在学校时总觉得类似这样的处理会极大的降低服务器的性能,可实际工作中发现完全不是这个样子。并且发现日志真是一个伟大的存在,我自己在百度的工作也是一直围绕日志处理的,只是最开始主要用于开发调 Bug,后来变成了分析业务情况。

 

在信息化建设时期,我们开发一个软件模块,主要为了解决业务流程的一个需求,通过人和软件模块结合,形成了整个业务流程。可在数据化建设时代,我们可以理解为软件模块都是为了服务数据流,所有的开发工作都是在建设沟渠,为了让数据之流能够顺畅流通。

 

这是一种巨大的思维转变。许多公司的软件系统也会产生数据,但更多的是为了支撑业务运转,所谓的数据打通不过是在长江黄河之间,加了一条直径 10 厘米的管子,以此就说长江黄河已经打通,这是不对的。一名优秀的软件工程师,要把数据收集和模块开发看做同等重要的事,要锻炼自己的数据思维。

 

3 运营经理 & 市场经理

广义的运营是无所不包的,拉新、留存、变现等都是运营要做的事情,COO 的职责更是大管家,让一切有序运行。许多公司是把拉新放在第一位的,所以都会有专门的市场部门,服务于品牌和拉新。而运营经理侧重于盘活已有用户。我当时所在的百度新产品部,像知道、百科这样的产品,直到 2009 年左右,才有专门的运营岗位,之前都是产品经理兼任的。

 

市场投放效果如何?不是看着是否花哨,还是要看实际带来的效果如何,需要计算 ROI(投入产出比)。在 To B 领域,往往市场团队和销售团队容易有矛盾,市场抱怨销售浪费了线索,而销售抱怨市场拿来的线索质量不行。这里核心的问题在于没有将两者的工作都数据化,并且形成反馈机制。市场效果的考核不是以下载量或留下联系方式这样的基础触达指标,而是要以销售团队的确认为标准。销售团队最终转化的情况,要及时的反馈到市场团队,这样市场团队及时对活动、渠道做出调整,这样形成有效的联动。

 

用户的盘活,核心在于对不同人群采用不同策略,极端情况是针对每个用户都能够个性化策略。这个过程,运营经理就要对用户根据一些维度进行划分,采用不同策略。并且在采用动作后,还要收集数据反馈,确认之前的划分标准和策略是否有效,及时做出调整。这里面都是需要数据做支撑的,需要善于利用数据。

 

4 数据分析师

作为数据分析师,在这个时代是幸运的,以后没有公司不需要数据分析师。但与此同时,对数据分析师的要求也在提升。过去的定位往往是“取数”,就是业务人员有了数据需求,提交给分析师,然后分析师把结果返回过来。这样的事情,应该用工具来替代。数据分析师的工作决不能停留于此,而是要更进一步,每次收到一个数据需求时,多问一句,背后的“业务需求”是什么?

 

因为每个数据需求都是一个点,就像产品经理出了一次拳,背后是为了达到某个目的。如果获取到这背后的目的信息,数据分析师就会发挥自己对数据理解和敏感的优势,不只是局限在业务人员的单一取数需求,可以提供更多维度的数据,来帮助业务人员做出判断。并且了解了业务需求,可以做出预判,在工作中提前做好准备,而不是经常加班来满足一些意想不到的需求。

 

5 管理者

最后,要形成数据驱动的文化和氛围,老板是具有决定性的影响的。可以设想下面的人废了很大功夫做了一份数据报告,可老板看了之后还是凭个人感觉做出了决策,下面的人还会再好好准备数据吗?相反,如果每次开会讨论,都是先问数据情况是怎么样的?基于数据我们能做出什么样的判断,整个公司上下都会很容易形成数据驱动的氛围。这里说来就一句话,但做起来却是最难的。

 

通过以上的探讨,希望能够激发你重新思考自己的岗位要求,是不是要做出什么样的变化了?

 

本文仅为提供更多信息,不代表AAA教育同意其观点或描述,如需转载请注明出处。
标签