数据团队规划布局感悟(一)

字数 1292阅读 3367

前言

记得今年一月份在杭州和W君漫步钱塘江赏霾,畅谈了两个小时,除了聊了研发的两观,全局观和产品观, 也聊了数据部的组织架构。一个良好架构布局确实会让人受益良多。

架构布局

目前我司数据部分成了大体五条线:

  1. 数据研发团队
    • 研发/执行
    • 解决方案设计
  2. 分析师团队
  3. 搜索/推荐团队
  4. 知识库团队(‘人工’智能)
  5. 平台运维

数据研发团队

数据研发分成了两个小团队,执行和设计。本来这里应该是把设计叫做算法团队的,但其实叫做算法团队并不太合适。我们把设计定位在能够提供一整套解决方案的那一组人里。

比如来问团队需要一套指数的东西, 设计团队会根据要求,设计建模出一套解决方案,并且先进行Demo验证,这其中可能需要用到很多算法,统计类的知识。交付之后也没啥问题了,就会交给研发进行执行,从而完成工程化。为了方便理解,我们把设计称之为问题建模也是可以的。事实上,我发现效果还是不错的。设计团队正在努力朝深度学习发展,在加强Spark Mllib上的投入同时,也花了更多时间关注TensorFlow平台。

研发执行里面,我们也是有细分,虽然人少,角色会有重叠:

  1. 分析师辅助
  2. 工程化团队
  3. 突击团队

数据部其实常常面临较多的商务需求,通常我们会让突击团队以最快速度交付第一版,之后再让工程化团队完整的工程化,比如全部转化为我们Spark程序,提供标准的API等,设置定时等等。

突击团队和工程化团队其实还有一个职责,就是团队效率工具的开发。这个基本是以研发负责人为主导,定期根据现状,找到效率瓶颈点,然后抽象出工具,最后排期进行开发。

分析师辅助团队则承担了两个职责,一个是对接纯粹的技术需求。比如ETL之类的。第二个是为分析师做实施执行工作。

虽然研发团队在努力,但是其实不太容易有很明显直观的成果。而且存在感并不强。在解决方案设计团队获得影响力之前,我们还需要一个重要的团队: 分析师团队 去扩大数据部门在公司的影响力。

分析师团队

我经历过两种分析师团队。一种是为研发和公司做support的,一种就是将现在的将分析师打散到各个业务线的方式,团队自身只保留高级分析师做全公司的support。

目前从研发的角度来看,反而是第二种更好。研发工程师和业务线天然有种隔膜,而且很多数据研发并不太喜欢业务。喜欢专研技术,和人打交道并不是他们擅长的,包括和业务团队的工程师打交道。 但是现在有了下放到业务线的分析师后,就变得很便利了。

比如解决方案设计团队了解了需求后,就不用到处去找数据,找人理解数据的含义,他们只要和我们自己的对应的分析师沟通就好,数据分析师直接提取出来数据,解决方案设计团队拿着这些数据就可以建模计算了,部分沟通也可以透过分析师来完成,而且分析师也可以给出较好的反馈,因为他们对业务也是相当了解的,尤其是从数据层面来说。

现在整件事情变得很有趣,以前是分析师依赖于研发,但是现在是研发高度依赖于分析师。基本上我们研发做的大部分事情都离不开分析师。我现在很愁的是,如何给分析师提供更好的support 以作为回馈。

各个业务线的分析师核心是要能够理解业务线里的数据,了解业务规则,问题,结构化业务数据,了解业务痛点,并且能够快速提取出业务/高级分析师/研发想要的数据。高级分析师则会对各个业务进行Review,给出数据方面的建议,为业务Leader提供决策指导。

这里我大致画了个图:

WX20170428-110852@2x.png

推荐阅读更多精彩内容