数据团队规划布局感悟（一）

前言

记得今年一月份在杭州和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