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

前言

记得今年一月份在杭州和W君漫步钱塘江赏霾，畅谈了两个小时，除了聊了[研发的两观，全局观和产品观](http://www.jianshu.com/p/339278c26f71), 也聊了数据部的组织架构。一个良好架构布局确实会让人受益良多。

架构布局

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

1. 数据研发团队

2. 分析师团队
   

3. 搜索/推荐团队

4. 知识库团队（‘人工’智能）

5. 平台运维

数据研发团队

数据研发分成了两个小团队：

1.   研发/执行

2.   解决方案设计

本来这里应该是把设计叫做算法团队的，但其实叫做算法团队并不太合适。我们把设计定位在能够提供一条解决方案的那一组人里。

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

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

1.  分析师辅助

2.  工程化团队

3.  突击团队 

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

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

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

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

分析师团队

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

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

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

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

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

这里我大致画了个图：

热门文章

直戳泪点！数据从业者权威嘲讽指南！

数据分析师做成了提数工程师，该如何破局？

全栈型VS专精型，团队到底需要什么样的人？

数据驱动业务，比技术更重要的是思维的转变

最近面了十多个数据分析师，聊一聊我发现的一些问题

你也「在看」吗？????