Jimmy那些事儿

数据分析工作梯度与团队建设

发表 | 更新 | 分类 | 阅读次数

数据分析工作梯度与团队建设；

why ：建立整体、全局的概念，目的是了解当前的自己处在什么阶段，并由此得出应该努力的方向。

数据分析工作的各个梯度1

​ From 知乎 《数据分析团队如何给自己找活干?》 何明科

改变一个人的习惯是很难的，而改变认知比改变习惯更要难上一个或几个数量级。因此可以把我想做的事情分为如下几类，从易到难。

初做咨询的时候，有一个项目是帮助某国际手机品牌在中国做新渠道模式的试点及铺开。因为我们团队没有任何实操经验，一开始的过程就是帮人跑跑数据和写写报告，颇不受待见。后来因为搞出了一套周报自动生成器，才赢得客户团队的超级认可，顺利过关。

1. 满足缺失需求而不改变习惯，提升效率

数据团队为业务团队提供的服务或者产品，完全没有改变业务团队的工作流，无非是补足其缺失的需求，让其查看数据、清理数据和分析数据大为简单方便，所以接受起来毫无难度。最重要的是，【对业务团队没有替代关系，同时也不指责业务团队之前做的不好。】

比如大公司往往因为业务众多而BI系统分散，这时候为团队一个整合的BI平台，绝对是加分项。

2. 改变工作流程，提升效率

业务人员、运维人员、运营人员及产品人员平时会花费大量时间阅读数据、理解数据、建立假设、证明证伪假设和形成结论。数据工程师或者分析师完全可以在这些方面为业务方提供增值和提升其效率。

1. 找规律找异常

观察数据趋势以及寻找异常，是非常重要的部分。

  • 传统的做法：人脑形成经验，肉眼观察和肉脑判断；或者设定阈值，超过一定范围自动报警（常见于运维）；或者简单的四则运算判断，根据各种环比、同比或者平滑移动平均等等。
  • 数据分析团队其实是应该可以利用傅里叶分析将周期性的变动和异动大部分区隔出来的，让这种分析和查找异常的过程升级，更精准的同时也提升效率。

2. 做分类提方案

业务团队时常需要针对业务情况做各种分类，然后对症下药提供解决方案。这在销售团队里尤其常见，尤其是互联网公司的销售业务，每个城市的产出是销售业绩，有各种中间的过程变量：销售数量、销售人效、销售出勤率及成单率、销售流失率、当地流量（UV）数量、流量（UV）质量、商户续费率、新增商户数等等。

  • 传统操作中，都是依靠运营人员或者BI人员根据人肉经验或者常用而简单的分析框架，对各城市的销售情况进行分类，找问题出方案。
  • 数据分析人员完全可以利用更高阶的机器学习，针对业务情况进行更多维度和更实时的分类，然后将业务情况与方案进行匹配。
    • 以上方案存在如下优势：高维会创造更精细的分类，有可能捕捉到以前被忽略的业务问题；高频（机器的高效率按天分析数据）会创造更实时的反馈

3. AI写报告

BI部门每月或者每周都要撰写报告发给管理层阅读，这个工作完全是可以开发一套AI系统来自动完成的。

以上想法都是在【略微改变业务人员工作流程的情况下，为其带来更高效和更精准的结果，可以说是给业务人员赋能，简化其重复性劳东】，帮助其成功。但一方面因为稍微替代了其人脑的价值，招当事人反感；另一方面在初期的磨合过程中，机器肯定有不少犯错的机会招人类嫌弃，所以初期的磨合阶段可能会略有阻力。

3. 提供新思路，看到新世界

数据分析人员还可以利用新技术、新算法或者新数据，帮助业务方找到剖析问题的新角度并证明其行之有效，也会对业务部门大有帮助，只不过因为其需要改变传统的思维习惯，更需要普及教育甚至是耐心。

​ ——2017.04.21


数据分析工作的各个梯度2

​ From 知乎 《数据分析团队如何给自己找活干?》 孙文亮

临时需求

临时需求是了解业务，收集反馈，优化数据产品的最佳途径。

  1. 初始阶段，处理各部门踢过来的临时需求，并以各种形式的报表反馈回去。
  2. 效率提升期，通过数据分析库的建设、自动化及半自动化开发，提升数据获取效率；通过站会+看板方式加强协作，提升全流程效率。关键指标是响应速度，如90%临时需求在24小时内完成。
  3. 稳定期，临时需求量短期随业务波动，长期稳定。开始出现主动型临时需求，即数据组主动提出的临时需求。
  4. 衰减期，随数据自动化程度变高，业务逐渐稳定，商业模式逐渐清晰，临时需求开始衰减，但永远不会消失。

报表自动化

  1. 架构阶段；搭建自动化报表的基本框架，包括数据字典、数据管道、Email、Dashboard、数据中间层等基础建设。
  2. 报表增长期，针对周期性查看的报表建立自动化展示。此阶段主要看报表覆盖率，一般来说不同的职能不同业务方向，都会有3-5支报表。报表数量也能反映此阶段的发展情况。
  3. 分析系统建设，针对分析型需求，往往是各个维度细分查看，每次查看的维度都有差异，不适合做自动报表，适合建模之后做成分析系统，业务组成员或分析师，可以通过不同维度不同变量的筛选来完成分析需求。 关键指标是分析系统访问量。
  4. 报表整合期。接入一切可能的数据源，例如：接入worktile数据可以看团队开发节奏、接入sonar数据可以监控代码质量、接入jira可以监控bug数据、接入内网知识库可以看知识沉淀速度和个人影响力、接入后台录入数据可以极大补充数据灵活性。
  5. 报表设计期。用产品思想重新设计报表，定义角色、场景、需求，精简报表内容；下线无用报表，迭代高频报表，将自动化报表平台当作创业项目来建设，持续提升人均访问量和访问频次。

数据建模

  1. 让事与事之间具有数据上的可比性。评估指标是模型覆盖度，我们的大致顺序为产品功能建模、产品迭代建模、运营日常工作建模、运营活动建模、内容发布建模、传播建模、技术迭代管理建模、技术代码质量建模、技术响应速度建模、技术稳定性建模。
  2. 投入、产出关联。建立成本意识，在评估效果之外还需要评估成本。
  3. 工作与核心指标关联。要从商业模式的核心指标，逐渐分解到各个工作中去。针对工作中为核心指标贡献的项目，建立从局部指标到核心指标的关联关系，确定相关度，可大致评估贡献度，并让工作价值可评估。

分析报告

  1. 初始阶段，定义分析报告类型、格式，定义什么才叫Insight，通过反复迭代打磨，做出第一份理想的分析报告。
  2. 稳定产出期，分析师可持续产出分析报告，并且分析报告被业务组频繁引用。
  3. 数据探索期，主动发掘数据价值，为业务中遇到的Why和How的问题提供数据支持、建议。

数字建模

  1. 预测问题建模；最早可以从自动化的数据监控切入，根据预测数据正常值设定异常区间。后续逐渐会用到各种回归模型，为管理计划的定义和分解、产品决策、渠道监控、技术预警等提供数学模型。
  2. 归因问题建模；针对影响核心数据的变量，找出相关度，计算权重系数。为各种开放式问题提供原因解答。


数据分析团队的搭建和思考

​ From 知乎 《数据分析团队如何给自己找活干?》张溪梦

以前说到数据驱动业务增长，我们第一个想到的可能是数据分析的方法。但就目前来看，数据驱动业务的增长已经成为一个不仅仅是分析方法和模型，而是包括了数据人才培养、数据架构的设计，甚至整个公司组织架构设计的企业治理问题。

数据分析团队发展的5个阶段

我们途家网成立五年以来，整个数据团队的成长也是经历了五个阶段。

  1. 缺少专业的数据分析师
  2. 拥有专职的数据分析人员
  3. 成立了专门的BI团队； 更多的精力放在原始数据的收集、数据工具的优化上面。
  4. 业务井喷的阶段； 让每一个业务的负责方及时地看到自己的数据，会做一些数据可视化的工作
  5. 开始做一些自助式的分析； BI 团队负责制定标准的数据，让业务的人去自己去做分析。

BI 团队组成

  1. 务必能够保证用数据讲清楚每一个业务的状况
  2. 辅助公司做决策，用数据去告诉大家未来怎么样做更有效率，如何去达到公司最大的目标。

为了承担这两个责任，我们成立了四个团队。商业分析团队，BI报表团队，数据仓库团队和市场竞争分析团队。

商业分析团队

  1. 分析一些非固定的专项问题
  2. 负责一些分析工具的培训
  • 首席分析师的培养

让一个熟悉业务的老员工转岗去做数据分析；或者说让一个熟悉技术，又懂业务的人去转岗，避免沟通上的低效。同时使用成熟的数据分析工具，避免在数据质量、以及重复性工作上浪费大量的时间精力。通过这样的方式，这个人会很快地把整个数据分析的框架搭建起来。最后你会发现，在公司成立四年到五年之后，这个人就是整个公司通过数据去驱动业务增长的灵魂。

  • 业务和财务的互动

每周都会固定地去看一下，业务上的动作在财务报表上的表现。

为什么要做这件事情？因为通常来讲，从业务前端到最后财务数字的整个链条里，业务分析人员很难掌握财务收入的确认规则，财务人员又需要更多时间去学习掌握不停变化的业务逻辑。通过财务分析人员和业务分析人员深度的互补和互动，能够做到驱动一个企业尽快地盈利。至少这个过程会让我们知道，盈利的来源是什么，哪怕目前是亏损，你也能知道为什么是亏的，以及怎么能做到止损。

  • 大胆假设，小心求证的分析思维

当业务人员来找分析师要一个数据的时候，负责任的数据分析师需要帮业务人员梳理分析的逻辑。 比如业务人员问你要一个APP订单变化的数据，但其实他想看的东西，或者应该看的东西，远不止这些。这时候再回过头去问他，你到底要干什么？这个时候你会发现，有可能是老板发现昨天的订单比前天的订单突然增长了50%，超出了他的预期，但是他又不知道为什么发生了这些增长。业务人员在做分析的时候，经常提出来的是一个点。但是对于一个数据分析师来说，你需要帮业务人员具体理这些分析的框架，最终找到数据变化的原因。

数据分析的几个步骤

  1. 定义问题；首先你想清楚，你在数据分析的时候你到底要分析什么题目？
  2. 大胆假设；思考出现这个数据变化所有可能的原因。
  3. 小心求证；在小心求证完之后，才能得到比较客观的结论。


BI报表团队

  1. 将业务方常规需要查看的数据沉淀为 BI 报表
  2. 帮助业务人员实现可视化的自助式数据分析； 让业务人员能够通过一些拖拉拽的钻取操作，快速的看到问题的所在，找到问题的原因。
  3. 分析师自己沉淀一些主动分析的数据结果给大家看；传统的报表制作流程是，需求方把需求提出来，然后工程师来负责把报表做出来。但是我们会更强调商业分析师的主动性。
    • 第一个主动性的要求是因为商业分析师在看过海量的数据之后需要产生自己的一些想法。从不同的维度上去分析数据，可能会对业务有额外的帮助。
    • 第二个是因为，对于一个业务人员来讲，每天只看自己业务范围内的数据即可，但是跨业务之间的数据产生的价值大部分时候是被忽略的。所以商业分析师需要主动的去思考跨业务之间的逻辑，然后固化在报表上面，给业务人员提供更多的价值。

数据仓库团队

在更大的公司，或者说在 BAT ，数据仓库应该是被放在技术部，而不是 BI 部门。我们把数据分析团队放在BI团队，因为这样能让分析师知道每一个指标，在数据库里是怎么被算出来的。数据的标准性和严谨性会有很大程度上的提升。

数据仓库的主要 4 个职能

  1. 负责整个原始数据的收集和清洗
  2. 负责数据报表的抽取；让数据仓库团队做一些数据指标的抽取工作，就可以让分析师直接去分析已经抽取过的统计表，大量地节省分析师在原始代码上的精力。
  3. 负责各个系统之间的数据规整；各个系统都会展示一些数据，但是每个系统展示的数据可能都不太一样。为了解决这个问题，我们会让数据仓库的工程师去做统一数据的输出，务必保证每一个人在每一个平台上看到的数据都是一致的。
  4. 负责一部分分析的职能

市场竞争分析团队

整个企业内部的数据和企业外部的信息，才能组成一个企业数据完整的图谱，这样才能在一个完整的生态中找到企业增长之道。

经验与思考

  • 六个经验
  1. 分析师一定要足够地了解业务。对于一个分析师来讲，商业敏感度是第一位的。
  2. 分析师一定要主动地梳理业务问题框架，而不是被动地接受业务方提上来的每一个小问题。
  3. BI 报表团队要保证每个人都有数据可看，而且务必要通过一些可视化的手段提升业务人员阅读数据的效率，让他们能迅速地提取关键的信息。
  4. 在企业从小到大的过程中，推动一些自助式的分析，因为自助式的分析能够解决分析师的瓶颈问题。
  5. 善用工具。
  6. 数据分析视野问题，内部的数据一定要分析的非常透彻。但是每一个分析师的眼界不仅仅如此，更要有整个行业的宏观数据，这样才能找到企业的增长之道。
  • 六个思考
  1. 我们对数据的要求是讲清楚业务，还是通过数据变现？ 我们对数据的要求又是什么？
  2. 在什么阶段应该成立 BI 团队？
  3. 数据分析师是不是有足够的权威？
  4. 在特定的阶段，是研发一个工具，还是采买一个工具？ 这是一个效率提升的问题，要综合考虑公司目前的数据、人员等等情况。
  5. 业务方是否会主动看数据？ BI 团队会把数据梳理清楚，但是我们有没有做好日常的驱动工作，让每一个业务人员去看这些数据？
  6. 集中式分析还是自助式分析？


数据分析团队的组建

团队成员

  1. 基础平台团队：主要负责搭建稳定、可靠的大数据存储和计算平台。

    • 数据开发工程师：负责Hadoop、Spark、Hbase和Storm等系统的搭建、调优、维护和升级等工作，保证平台的稳定。
    • 数据平台架构师：负责大数据底层平台整体架构设计、技术路线规划等工作，确保系统能支持业务不断发展过程中对数据存储和计算的高要求。
    • 运维工程师

  2. 数据平台团队：负责数据的清洗、加工、分类和管理等工作，构建企业的数据中心，为上层数据应用提供可靠的数据。

    • 数据开发工程师：负责数据清洗、加工、分类等开发工作，并能响应数据分析师对数据提取的需求。
    • 数据挖掘工程师：负责从数据中挖掘出有价值的数据，把这些数据录入到数据中心，为各类应用提供高质量、有深度的数据。
    • 数据仓库架构师：负责数据仓库整体架构设计和数据业务规划工作。

  3. 数据分析团队：主要负责为改善产品体验设计和商业决策提供数据支持。

    • 业务分析师：主要负责深入业务线，制定业务指标，反馈业务问题，为业务发展提供决策支持。
    • 建模分析师：主要负责数据建模，基于业务规律和数据探索构建数据模型，提升数据利用效率和价值。

    ​

工作方式

数据团队的工作可以分成两大部分:

  1. 建设数据存储和计算平台
  2. 基于数据平台提供数据产品和数据服务。

平台的建设者包括三种人群：

  1. 基础平台团队对hadoop、spark、storm等各类大数据技术都非常熟悉，负责搭建稳定、可靠的大数据存储和计算平台。
  2. 数据平台团队主要负责各类业务数据进行清洗、加工、分类以及挖掘分析，然后把数据有组织地存储到数据平台当中，形成公司的数据中心，需要团队具有强大的数据建模和数据管理能力。
  3. 数据产品经理团队主要是分析挖掘用户需求，构建数据产品为开发者、分析师和业务人员提供数据可视化展示。

平台的使用者也可以包括三种人群：

  1. 数据分析团队通过分析挖掘数据，为改善产品体验设计和商业决策提供数据支持。
  2. 运营、市场和管理层可以通过数据分析师获得有建设性的分析报告或结论，也可以直接访问数据产品获得他们感兴趣的数据，方便利用数据做决策。
  3. 数据应用团队利用数据平台团队提供的数据开展推荐、个性化广告等工作。

分析团队的组织架构

在整个大数据平台体系中的团队：基础平台、数据平台、数据应用和数据产品经理团队都可以保持独立的运作，只有数据分析团队的组织架构争议比较大。数据分析团队一方面要对业务比较敏感，另一方面又需要与数据平台技术团队有深度融合，以便能获得他们感兴趣的数据以及在数据平台上尝试实验复杂建模的可能。

  1. 外包：公司自身不设立数据分析部门，将数据分析业务外包给第三方公司
  2. 分散式：每个产品部门独立成立数据分析团队，负责响应自己产品的数据需求，为业务发展提供决策支持。
    • 优势：数据分析团队与开发团队、设计团队以及策划团队具有共同的目标，团队整体归属感强，绩效考核与产品发展直接挂钩，有利于业务的发展。
    • 劣势：在业务规模比较小的情况下，数据分析师比较少，交流的空间也比较小。因为身边的同事都不是该领域的人才，无法进行学习交流，所以成长空间会比较小，分析师的流失也会比较严重，最终陷入招募新人——成长受限——离职——招募新人的恶性循环。另一方面，每个产品团队都零星地招募几个分析师，整体来看给员工的感觉是公司并不是特别重视数据化运营的文化，对数据的认同感会被削弱，不利于公司建立数据分析平台体系。
  3. 集中式：数据分析团队与产品团队、运营团队各自独立，团队的负责人具有直接向分管数据的副总裁或CEO直接汇报的权限，团队负责响应各业务部门的数据需求。
    • 优势：分析团队具有充分的自主权，可以专心建设好公司级别的数据平台体系，研究数据最具有价值的那些问题，有权平衡业务短期需求和平台长期需求直接的关系。另一方面，这种自上而下建立起来组织架构，可以向全体员工传达数据在公司的重要位置，有利于建立数据化运营的文化。
    • 劣势：产品业务团队会觉得他们对数据的掌控权比较弱，一些业务数据需求得不到快速响应，认为分析团队的反应太慢无法满足业务发展的需要。随着业务发展越来越大，产品团队会自己招募分析师来响应数据需求，逐渐替代分析团队的工作，这样势必会导致分析团队的工作被边缘化。
  4. 嵌入式：数据分析团队同样独立于产品团队存在，但只保留部分资深数据专家，负责招聘、培训数据分析师，然后把这些人派遣到各产品团队内部，来响应各类业务数据需求。
    • 优势：团队的灵活性比较好，可以根据公司各业务线的发展情况合理调配人力资源，重点发展的项目投入优秀的人才，一些需要关闭的项目人才可以转移到其他项目中去。
    • 劣势：分析师被嵌入到产品团队内部，受产品团队主管的领导，从而失去了自主权，导致沦落为二等公民。人事关系在公司数据分析团队中，却要被业务团队主管考核，但业务团队主管并不关心他们的职业发展，导致分析师的职业发展受到限制。


大数据的基本框架

客户是大数据的来源也是大数据最终要服务的终点。在这套框架中，数据分析的基本框架向下延伸，最基础从Customers(用户)开始，也在用户结束。

  1. 大数据框架

  1. 统一的大数据平台

“现在最缺乏的，是统一的大数据采集平台”。大数据已布满在企业的各个地方各个角落，“我们现在最缺乏的，不是数据，是一个统一的数据采集平台(Data Collection)。在一个企业的大数据框架中，最重要的部分是大数据的原始数据采集层。这基本包括三个层次：

  • 最外层是用户；
  • 其次是公司运营中各种会产生数据的业务应用系统(如ERP、CRM、SCM、OA等各种企业应用软件)、网站、APP、社交网络、电商平台等
  • 之上是各种数据的采集平台。
  1. 从ETL到ELT

在数据采集上来之后，接下来便要对海量的数据进行所谓的抽取、转换、加载，即ETL。

传统的数据分析认为，数据收集之后是ETL，但现在变成了ELT，未来有可能只有EL没有T，甚至到最后全部将EL结合到一起，不再有功能性的划分。

为什么会有这种变化呢？这主要是因为以前的存储、计算、传输成本都很高，数据处理要用时间来换取空间。因此，当时的重点技术是要将原来非结构化的数据进行结构化转化，把数据压缩变小、节约存储空间，从而形成所谓的ETL模式。但很显然，这种模式存在一个无法避免的问题，即ETL过程是需要花费很多时间的。互联网时代是快鱼吃慢鱼的时代，企业需要实时了解各种数据，需要实时进行响应。费时的ETL模式显然完全不能适应当前的时代潮流。

  1. 是先BI后分析，还是先分析后BI?

数据仓库之上，便到了我们经常所说的BI了。

BI其实包括两个层次，即Analysis(分析)和 BI，其中分析主要为对数据进行高维度分析，BI则主要提供数据透视和展现

在大数据时代，这两个层次也有一个巨大的变化。是先BI再分析，还是先分析再BI呢？

以往的做法基本上是先BI，而后在其上进行Analysis(分析)。目前国内绝大部分企业就是这么做的。大部分企业把BI与数据仓库中存储的数据相结合，用于报表分析、报表制作等。更重要的是，这类工作一般交由IT部门负责，使得BI变成了技术性工作。因此，现在很多企业中有大量的IT研发人员在开发报表。这种做法带来了“先BI再分析”的最大问题，即用数据的人不是做数据的人，做数据的人不是用数据的人。现在的先进做法是，将BI与分析进行对调，即先分析再BI，并且分析工作要由熟悉业务的数据科学家来承担。

把数据仓库的数据和分析直接结合，通过相关的分析技术和工具，直接挑选出具有商业价值的数据，之后通过BI迅速将其商业价值扩大化。

  1. “输出洞察、输出决策、输出价值”

在分析、BI之后，便到了如何将数据价值发挥出来的环节。张溪梦认为，这主要包括DM(数据挖掘)、AI(人工智能)、洞察、决策、行动、价值等几个阶段。

  1. “底层频次高价值低，顶层频次低价值高”

从客户、业务系统、数据采集、数据仓库、分析、BI、DM、AI、洞察、决策、行为、价值，再最终回到客户


其他摘抄

  1. 数据看板并不是终点，而是新的一次的起点。
  2. 大多数情况下能把一个部门的各个细节弄清楚就已经很不容易了。对业务细节的了解是做出深层次分析的前提。
  3. 靠数据报表提高公司运营效率不太现实。实际上业务部门很清楚影响效率的问题，只是没有技术，手段，设备去解决。用图表展示他们早就知道的问题没有帮助。
  4. 大家讲大数据，数据是从数据标签的采集开始的，一般都由前端工程人员实施，然后数据传输的工作由IT来管理，ETL一般由企业内部的数据仓库或者数据平台的团队负责，BI（商业智能）部门在分析部或者存在于业务部门之中，然后我们还有各种商业分析师，统计学家参与其中，这个运行框架体系因为各个部门参与的人非常多，流程很长