作者简介：桑文锋，神策数据创始人兼 CEO。
在 19 世纪下叶，有种岗位非常吃香，就是电报员。
年轻的爱迪生就做过电报员的工作，敲动按键收发电报，仿佛今天的程序员。可遗憾的是，这种职业持续了几十年，随着电话的出现，逐步被淘汰了。
在 10 年之前，春节回家买票是很困难的，黄牛很吃香，可后来有了 12306 和实名制，断了黄牛们的财路，“职业黄牛”逐渐下岗。
我最早参加工作时，觉得做程序员挺悲剧的，需要天天对着电脑，可是现在放眼望过去，又有多少白领的工作是不用整天对着电脑的呢？
图 1 图片来源于网络
岗位在变，岗位要求也在变，没有东西是恒定不变的。
随着数据驱动时代的到来，对各种岗位的要求，也在悄然变化。我这里探讨的是互联网领域中，岗位在数据能力要求上的转变，包括产品经理、研发工程师、运营经理、市场经理、数据分析师、管理者等。
一、产品经理
年，一本《人人都是产品经理》在互联网圈子吹了个遍，一下子给许多人带来了希望，原来还有产品经理这么一个岗位，看起来很不错啊，纷纷决定当产品经理。
在这之前，产品经理这个岗位在几家大的互联网公司存在已久，但也不过是 2000 年之后的事情，之前更是没有这个岗位。如何成为一名优秀的产品经理，相关的培训和书籍也已经比较多了，网上更是很多类似的文章。
图 2《人人都是产品经理》
可在数据驱动时代，对产品经理又有什么要求呢？那就是用数据说话的能力。
我在 年入职百度知道做研发工程师，入职第一天，就发现邮箱里收到了几十封报表邮件，包括百度知道的提问量、回答量、Session 数、检索量等。我心想：这样的核心数据怎么连我这种刚入职的新人就能看到？后来才知道，原来“用数据说话”就是百度的文化。
一个产品功能要不要做，一个软件模块性能如何，都要用数据说话。
曾经有几个月时间，我只为了将百度知道用户提交失败的次数从 100 降低到个位数费尽周折。
产品经理在进行需求评审时，都会有专门的一块内容，就是“统计需求”。在评审会上，产品经理和研发工程师会讨论需要用什么数据做支撑，以及统计的口径是什么。
等项目上线之后，就开始分析实际数据是否和预期相符，如果不相符，就要寻找问题出在哪里，并且通过分析出的问题进行改进，然后再进行数据验证。
可以说，不只是要有数据意识，还要在工作中形成数据驱动的流程。
我这两年接触的产品经理中，许多都向我反馈——数据采集需求推不动研发工程师，我一问详情，才知道往往是产品上线以后，产品经理才提出了数据采集和分析的需求，而这个时候工程师早就把要做的工作做完了。
在这种时间点提出需求，感觉是在打补丁，配合的不好。
这其实反映一个问题，就是产品经理在提出产品需求时，并没有做足够的数据需求梳理。相当一部分同学是把这件事放在业务上线之后，可偏偏这个工作要提前做，不能懒惰。
当然，肯定有许多数据需求是事先想不清楚的，这种不可避免，但如果前期数据需求在产品需求解决中沟通得比较好，两边配合也要好很多。
有本书叫《精益创业》，我推荐每个产品经理都读一读，它里面核心讲解了两个概念，一个是 MVP，做最小可用产品，另一个就是把数据分析引入到产品迭代中，形成点子 - 产品研发 - 数据分析 - 点子的循环。
二、研发工程师
产品经理和研发工程师是一对共同体，不可割舍但又矛盾重重。前面说了产品经理的问题，这里反过来看工程师的问题。
许多时候，产品经理提出数据需求时，工程师反馈的内容是——很忙，比如正忙着迭代功能，产品经理的需求要晚一点再做。可是如果开发的功能不能够用数据做验证，那开发本身又有多少意义呢？
我曾经看过一篇文章对比硅谷和北京，里面提到北京的创业氛围要比硅谷拼得多。但是也提到一个问题，很多同学只忙着开发功能了，却没有做必要的数据收集。这同样也是个基本的问题，就是数据驱动时代，对工程师的要求变了。
我刚入职百度时，会有一项培训，就是教你如何打日志。所谓日志，就是用户做的每一个请求，后台都要记录下来，比如什么时间来自什么 IP 地址的用户访问了什么页面，类似这样的记录。
这些日志有两个作用，一是当服务出现故障时，可以通过日志分析请求参数是什么，导致了后来出现了什么异常，二是用于用户使用情况统计。
我在学校时总觉得类似这样的处理会极大的降低服务器的性能，可实际工作中发现完全不是这样，并且发现日志真是一个伟大的存在。我自己在百度的工作也是一直围绕日志处理的，最开始主要用于开发调 Bug，后来变成了分析业务情况。
在信息化建设时期，我们开发一个软件模块，主要为了解决业务流程的一个需求，通过人和软件模块结合，形成整个业务流程。可在数据化建设时代，我们可以理解为软件模块都是为了服务数据流，所有的开发工作都是在建设沟渠，为了让数据之流能够顺畅流通。
这是一种巨大的思维转变。
许多公司的软件系统也会产生数据，但更多的是为了支撑业务运转。所谓的数据打通不过是在长江黄河之间，加了一条直径 10 厘米的管子，以此就说长江黄河已经打通，这是不对的。
一名优秀的软件工程师，要把数据收集和模块开发看做同等重要的事，要锻炼自己的数据思维。
三、运营经理 & 市场经理
广义的运营是无所不包的，拉新、留存、变现等都是运营要做的事情，COO 的职责更是大管家，让一切有序运行。许多公司是把拉新放在第一位的，所以都会有专门的市场部门，服务于品牌和拉新。而运营经理侧重于盘活已有用户。
我当时所在的百度新产品部，像知道、百科这样的产品，直到 年左右才有专门的运营岗位，之前都是产品经理兼任的。
市场投放效果如何？不是看着是否花哨，还是要看实际带来的效果如何，需要计算 ROI（投入产出比）。在 To B 领域，往往市场团队和销售团队容易有矛盾，市场抱怨销售浪费了线索，而销售抱怨市场拿来的线索质量不行。
图 3 图片来源于网络
这里核心的问题在于没有将两者的工作都数据化，并且形成反馈机制。
市场效果的考核不是以下载量或留下联系方式这样的基础触达指标，而是要以销售团队的确认为标准。销售团队最终转化的情况，要及时反馈到市场团队，这样市场团队及时对活动、渠道做出调整，这样形成有效的联动。
用户的盘活，核心在于对不同人群采用不同策略，极端情况是针对每个用户都能够个性化策略。
这个过程，运营经理就要对用户根据一些维度进行划分，采用不同策略，并且在采用动作后，还要收集数据反馈，确认之前的划分标准和策略是否有效，及时做出调整。这里面都是需要数据做支撑的，需要善于利用数据。
四、数据分析师
作为数据分析师，在这个时代是幸运的，以后没有公司不需要数据分析师。
但与此同时，对数据分析师的要求也在提升。过去的定位往往是“取数”，就是业务人员有了数据需求，提交给分析师，然后分析师把结果返回过来。这样的事情，应该用工具来替代。
数据分析师的工作决不能停留于此，而是要更进一步，每次收到一个数据需求时，多问一句，背后的“业务需求”是什么？
因为每个数据需求都是一个点，就像产品经理出了一次拳，背后是为了达到某个目的。如何获取到这背后的目的信息，数据分析师就会发挥自己对数据理解和敏感的优势，不只是局限在业务人员的单一取数需求，可以提供更多维度的数据，来帮助业务人员做出判断。
并且了解了业务需求，可以做出预判，在工作中提前做好准备，而不是经常加班来满足一些意想不到的需求。
五、管理者
要形成数据驱动的文化和氛围，老板具有决定性的影响。
可以设想，一线员工废了很大功夫做出一份数据报告，可老板看了之后还是凭个人感觉做出了决策，员工还会再好好准备数据吗？相反，如果每次开会讨论，都是先问数据情况怎么样、基于数据我们能做出什么样的判断，整个公司上下都会很容易形成数据驱动的氛围。
这里说来就一句话，但做起来却是最难的。
通过以上的探讨，希望能够激发你重新思考自己的岗位需求，到底是否能符合日益变化的职位要求。如果现在的你就是 19 世纪下叶电报员，那么你是不是要开始做出什么变化了。
号外！更多精彩声音，可关注
神策 FM
『点击图片，解锁更多精彩』
▼▼▼
↙↙↙点击“阅读原文”，立即进行体验
内容不错，记得戳好看哦?↓↓↓
