关于「数据分析师」的一些理解

本文为数据茶水间群友原创，经授权在本公众号发表。

关于作者：我是Jing，茶水间非资深潜水员，一个快3岁的数据分析师；爱数据分析爱读书爱海贼，欢迎一起交流探讨~

因为个人从开始进入数据分析职业到现在，已经小三年了，故希望能总结下个人对「数据分析师」的理解，一来梳理自己的专业认知，二来可以进一步思考接下来的职业规划。
本文主要聊一下三个内容：

1. 为什么需要以及什么阶段需要数据分析师
   

2. 数据分析师的主要工作内容和工作流程
   

3. 数据分析师的能力模型拆解

所有回答均为个人现有知识储备、阅历和思考深度下的产出，水平有限，请多指教。

0x01 数据分析师的「出场场景」

数据分析师并不像产品和开发那样的岗位，从公司初创就是不可缺少的。数据分析师是在公司发展到一定程度才会有需要的岗位。

参考刘洋前辈（阿里巴巴，高级产品专家）在「数据产品经理生存指南第一条」的说法：

第一阶段：在公司（100人以下规模）或业务线初始阶段，数据比较少，数据分析一般也就是简单的描述统计分析，产品可以自己做数据分析的工作，或者招聘工作经验1-3年的数据分析师做数据分析的工作。
第二阶段：公司规模在200人左右，一般这时候公司的商业模式证实可行且具备一定量级客户，可以使用三方数据分析产品进行数据分析，并搭建内部数据处理系统，有意识地积累数据；从这个阶段开始，专职的数据分析是必不可少的。
第三阶段：当公司向着400人发展，产品类型越来越多，业务规则变得越来越复杂，用户量和数据量足够大，可以开始搭建公司级别的数据团队。

那为什么公司发展到第二类的阶段的时候，会需要专职的数据分析师了呢? 个人感受到的原因有如下三点：

1. 数据量级比较大，超出了产品能够处理分析的范畴；
   

2. 业务逻辑相对复杂，影响结果的因素多样化，需要专业的数据分析定量分析问题；
   

3. 用户量超过一定量级，单靠人的注意力是不能做到那么细致的运营，需要数据同学参与，精细化运营；

恰好公司业务模式转变，我得到一个机会可以亲自感受下对数据分析师从不需要到必不可少的过程。
在业务转型初期，整个业务流程可行但很粗糙，数据量也很小，工作的重点基本就在完善产品流程和产品逻辑。在这期间，数据分析工作基本都是服务端开发导数给产品，产品自己分析，然后进一步迭代产品。
之后随着客户量提升，订单量也快速提升，此时数据量级增大，也开始出现数据质量的问题，产品同学自己处理起来已经很吃力了，而且有些问题，也不再能够单纯靠业务逻辑推理可以定位到，所以数据分析同学（也就是我）被加入到履约小组中。
幸运的的我，在校招加入涌哥（前途家网BI总监，从0到1搭建起途家的数据团队）的团队后，见证了数据团队从0到1搭建的后半段，了解了公司级别数据团队的搭建过程。

0x02 数据分析师的主要职责内容和工作流程

在数据分析职位学习实践了小三年，基本也是把用到数据分析师的工作都全经历一遍了（但毕竟经历尚浅，如有错误之处，还望指正。）
加上收集了一些互联网公司数据分析师/商业分析师的JD描述，经过整合，总结数据分析师的主要职责内容大致有如下五类：

1. 构建全面的、准确的、能反映业务线特征的整体指标体系，并基于业务监控指标体系，及时发现与定位业务问题；
   

2. 通过专题分析，对业务问题进行深入分析，为公司运营决策、产品方向、销售策略提供数据支持；
   

3. 沉淀分析思路与框架，提炼数据产品需求，与相关团队（如技术开发团队）协作并推动数据产品的落地；
   

4. 与相关团队协作进行数据建模工作，推动业务部门的数据化运营
   

5. 与相关团队（如数据运营团队）组织数据技术与产品相关的理念、技能、工具的培训；
   

（注：JD收集时间在2018.01-2019.05，如JD后续产生大的变化，再次更新）

第一类职责

数据指标体系拆解和监控报表上线，这个工作在我第一份工作中，可能因为产品和BI比较远的原因，往往是业务上线了都没通知数据，那时候数据指标体系的监控报表一般是产品、运营和业务同学直接提过来，或者业务需求出现较多重复需求，BI部门的数据产品再去对接需求方和服务端开发了解新业务的字段逻辑，制定统一的数据指标口径，提供给报表开发同学，开发上线。在我第二份工作中，因为和业务比较近，所以可以直接从业务的开始阶段就参与进去，独立拆解数据指标体系，上线报表，在产品或运营活动上线后快速提供数据反馈和迭代决策依据。
数据指标体系的拆解、指标对齐和口径统一的工作基本上是比较日常的工作，经历多了也会有一些方法论沉淀下来，详见后续的数据分析方法论系列吧。

第二类职责

专题分析报告，这个大数据分析和传统分析比较像，是数据分析师工作中价值输出占比比较大的一部分工作，是最“数据分析”的一块工作。
一般来讲专题分析的工作分为3个阶段，6个步骤，具体如下：

• 第一阶段，问题识别与构建：
  

  • Step 1.识别问题；
    

  • Step 2. 回顾之前的发现；
    

• 第二阶段，定位问题，并给出解决方案：
  

  • Step 3. 建模（变量选择）;
    

  • Step 4. 收集数据；
    

  • Step 5. 分析数据；
    

• 第三阶段，传达结果并推动结果落地
  

  • Step 6. 传达给相关方数据分析结果，并采取行为；
    

每一个步骤都有对应要达成的小目标，任何一步的掉以轻心或者形式化，都有可能让分析结果最后无法落地，白白浪费了时间和精力。

第三类职责

数据分析思路和框架的沉淀并产品化。这个是我在人人车才深刻感受学习到的技能点。
人人车的产品思维很强，“数据产品化”的思维也是我在这慢慢培养起来的。似乎任何一个分析思路和分析框架固定，会造成重复性的工作都可以产品化。我们完成了零成本上线活动页和数据监控报表的配置功能，一起搭建了埋点管理平台，对埋点进行分角色分事件的管理，以及对埋点测试数据的自动化验收。和产品一起工作的这段日子还是受益良多的。

第四类职责

第四项职责是数据建模及数据化运营。这块话题下，我经历的有两个子项，一个是数仓建模，一个是配合算法同学进行算法模型的搭建。
在和一些数据分析沟通时，了解到有些数据分析师会把对于运营活动的数据分析支持工作，归类到这个类别下。但因为我经历过的这种需求，一般是以临时需求或者专题分析的需求形式提交结果的，所以我更倾向于把对于运营活动的数据分析支持工作归为专题分析中。而数仓建模后通过接口配置到运营后台中，可以赋能业务同学；算法模型上线后达成的效果确实是自动化精细化地服务用户；因为这一类的工作和分析报告的工作流程和落地方式差异很大，所以我个人倾向于数仓建模和算法模型搭建归于数据建模和数据化运营。

第五类职责

其实这种类型的工作，个人感觉其最终目的是为了公司文化观念上数据化驱动的转变。一开始我也是认为数据培训的意义在于，"能够让更多的同事了解数据的重要性，学会用数据去驱动业务，让大家有更多的数据思维。"

后来发现现实不是这样的，事实是，“大多数公司仍处于数据分析的发展初期”，大多数非数据岗同学对于数据分析的理解就是支持作用，是讲一个更好的故事的作用。而不少数据岗的同学，本身也不是相信数据的，或者说，不少数据岗同学在自以为是的职业优越感存在在的时候，相信数据的价值，在经历“幻灭”后，就不再相信数据了。但数据终归是有价值的，不然尝到甜头的谷歌、亚马逊、阿里们也不会投入很多发展大数据；而成功的数据变革，"走的都是自上而下的路子，无一例外"。

综上，我不相信几场数据培训就能让人了解数据多重要，让人具备数据思维；但我认为，数据培训是数据变革向下落地的一个很好的方法。

0x03 数据分析师的能力模型拆解

能力模型的拆解有助于我们确定学什么，结合现实对自己所在岗位的实际需求，可以给各个技能点设定一个一个的小阶段，分配优先级，然后制定出来一份好的学习路径来。
当你对于目标职位的能力模型、成长路径比较迷茫，不知道什么是”好”的时候，也就无法变得”更好”，就像你不知道哪个是重点，怎么跑都是迷途。
收益和原因阐释完了，接下简单说一下大数据时代数据分析师的能力模型，具体如下：

• 数据知识：包括统计学和概率论，常用的互联网数据分析方法（eg,AB测），数据挖掘和机器学习的部分知识，数据库原理和数仓的一些知识；
  

• 工具技能：SQL/HQL、excel 和 PPT 是必须的，进阶是 python 和 R 语言；
  

• 业务知识：包括商业和行业知识，市场营销，产品和运营的知识，再就是公司的业务流程、业务逻辑和业务路径；
  

• 项目管理能力：基础的是子项目拆解和关系分析，项目时间安排，项目跟进等，当然，良好的沟通是必不可少的；