数据团队思考：小型数据团队发展的6大建议

0x00 前言

最近遇到了不少待在小型数据团队的朋友在吐槽自己的团队如何如何的坑，比如说：

  1. 基础建设特别差，用什么没什么！
  2. 人太少，每个人只能忙于提数，基本上没有成长！
  3. 数据没有体现价值，成就感很低！

总之，这个吐槽内容是挺多的，就不多写了，有过类似工作经历的朋友应该会有很多共鸣。鉴于这些吐槽的内容，居士将从如下几个方面来分享本篇的主题：小型数据团队发展的6大建议

  1. 为什么你的团队是一个小型的数据团队？
  2. 小团队会面临什么样的难题？

  3. 小团队该如何优雅地建设数据体系

    0x01 为什么你的团队是一个小型的数据团队？

    本来这一块是想深入分析一下的，因为背景尤其的重要，但是这一块的总结却又是一个很耗神的工作，因此，本文先简单地做一个分析，不深入写了。
    首先，小的数据团队是很多公司都会出现的情况，在早些年大部分公司都是没有专门的数据团队的，很多数据工作都是后台或者产品同学兼岗数据，特别是互联网公司，也是近些年才慢慢又了数据团队的概念。因此，如果你认为自己的团队很小，请先调整好姿势，这是很正常的。
    其次，小团队，不一定只出现在小公司里面。很多大公司的数据团队可能也是很少的几个人。这里面有两种可能：

  4. 公司本身并不需要特别强大的数据支撑，或者还没有重视。

  5. 另一种可能是一个大的公司的各个部门里面，都会有自己的小的数据团队。

    0x02 小团队会面临什么样的难题？

    既然要聊“小型数据团队该如何地优雅建设数据体系？”，那就要先说明为什么要聊这个话题，小团队有什么特点？有什么难题等着去解决？
    下面就简单总结一下几个核心的矛盾和难题：

  6. 快速发展的业务 VS 建设缓慢的基础设施：如何在进行业务支持的同时，兼顾基础设施的建设？

  7. 少人力 VS 多需求：如何有效地支持业务需求？
  8. 杂七杂八的需求 VS 团队的成长和价值体现：干着打杂的活，如何才能有提升，才能有数据的价值？

其实问题挺多的，先列这三个吧，有更多想讨论的欢迎留言评论。

0x03 小型数据团队发展的10大建议

步入正题。

一、前期发展，以经验丰富的员工为主

小团队的前期发展，以经验丰富的老司机快速搭建框架是最为稳妥的，要尽可能地减少试错成本。快速构建基础的数据体系，保证整体流程是可以跑通的。
有了经验丰富的老司机把底子都搞好了，后面再慢慢招一些应届生就可以。

二、以业务价值为核心

刚毕业的时候，居士一直以为基础建设是最重要的，大家做数据就应该先搞基础建设：从数据平台->数据仓库->数据管理平台->数据分析平台->机器学习平台。要稳扎稳打把各种底子都搞好才是真的好。
从现的角度来看，这个观点依旧不能算是错的。但是，我们更应该换位思考。
数据最终还是要服务于业务的，千万不要等你的数据基础设施都建设完成了，最终发现团队没有一个可以产生价值的业务，只能无奈地变成一个被边缘的服务方。
居士最怕的就是，当你把基础全部做好后发现，黄花菜都凉了。
一个可取的思路应该是：

  1. 以业务价值为核心
  2. 抽出少量的人力，完成最基本的基础设施

  3. 等有业务成果了，再投入一定的人力完善建设即可

    三、购买付费产品，云服务化

    很多公司都喜欢所有组件都自研，不喜欢花钱。其实，免费的，有事才是最贵的…
    比如说，为了维护一个Hadoop集群，可能要投入一两个同学专门来运维，还要有性能调优的，平台还不容易用，经常出问题……
    这在小团队里，是多大的成本啊。当然这个也要根据具体情况来评估，不是花钱就能解决问题。
    但是这一个观念要学会转变。

    四、重视流程和规范，提前打好基础

    虽然人少，但是流程和规范却是十分重要的，比如研发的规范，数据上线的流程，产品提需求的流程，需求管理的规范。
    这些看似不重要的东西，却能影响一个团队的地位。
    举一个例子：数据埋点。
    很多团队在最初都没有规划好数据埋点的规范，这就导致了大部分业务侧都自己随便上报数据，也没有人保证数据上报的正确性，时间一长。整个埋点就是一团乱麻，而且这个时候你想再来收回埋点上报的规划已经很难了，历史包袱和大家对这件事情的观念已经形成。
    其它场景也是类似，比如需求管理，如果没有需求管理，那么大家就很容易陷于无限需求循环的怪圈无法自拔，很坑。

    五、重视文档化，做好团队的技术沉淀

    文档化，其实是一件很简单，但是很重要的事情。
    基本上工作中可能被问到的，以及重复做过的内容都应该形成文档。比如说：

  4. 环境的安装笔记

  5. 一些权限申请的说明
  6. 数据分析的套路
  7. 一些关键表的汇总
  8. 表的开发流程
  9. 任务的配置方式
  10. ……

总之，就多写吧，这时候团队的负责人要有这方面的意识，因为写这些东西如果没有督促和认可，是很难有人去写的。
同时要多向大家灌输这方面的思想，要让大家意识到这是一件很重要的事情。
比如，之前就遇到一个朋友来找我吐槽：“居士，我们老大感觉很无聊，居然催着让我把公司本地配置spark环境这种事情写成文档。”这就是负责人没有把思想传达到位的表现。

六、重复工作自动化，自动功能产品化

直接举个例子吧：
重复工作自动化：比如说天天提数，那就把最常见的需求搞成模版，再来类似需求就输入几个参数直接解决喽。这也算是半自动化了吧，那么在此基础上，一些固定的需求就可以自动化到报表里面了。
自动功能产品化：报表毕竟不能解决所有需求，那么其余的临时需求该怎么解决。这就是产品化了，关于这个特定问题的产品化应该是两个部分：1. 数据中间表建设完善；2. 自助提数平台。两者结合，完成产品自助提数的工作。再深入做了就是自助提数平台转为自助分析平台。
整体来讲，就是抽出重复的工作，自动化+产品化，减少员工的重复工作。

0xFF 总结

看到这里，可能会有人来说，这文章是不是有点虚了，也没见一行代码。你不是以前那个实在的居士了。
这里简单聊一下，很多问题不是技术就能解决的，遇到问题了，能解决它，即使不写一行代码，那也是一种好的解决方案。这点其实不是变虚了，而是换了个解决方案而已。
当然，也可能会有人问：居士，你这听起来一点也不高打上呀，都是什么数据分析，数据埋点，也没见数据挖掘和机器学习之类的高新技术呀。
嗯，是这样的，数据团队呢，一个基本职责就是数据分析的能力，这是要帮助业务、产品和老板也做决策的，这个是一定要能支持到的， 如果这个基础能力都没有支持好，你的基本工作内容就会收到很大的挑战。
另外，数据挖掘本来也是数据团队的工作内容，这里的6个建议同样适用。
补充说明一点：本文是从团队的角度来考虑，并不是个人的角度。
最后，欢迎大家提出你的意见，批评也很欢迎，一起讨论才会有进步。