前言
记得今年一月份在杭州和W君漫步钱塘江赏霾，畅谈了两个小时，除了聊了研发的两观，全局观和产品观, 也聊了数据部的组织架构。一个良好架构布局确实会让人受益良多。
架构布局
目前我司数据部分成了大体五条线：
- 数据研发团队
- 研发/执行
- 解决方案设计
- 分析师团队
- 搜索/推荐团队
- 知识库团队（‘人工’智能）
- 平台运维
数据研发团队
数据研发分成了两个小团队，执行和设计。本来这里应该是把设计叫做算法团队的，但其实叫做算法团队并不太合适。我们把设计定位在能够提供一整套解决方案的那一组人里。
比如来问团队需要一套指数的东西， 设计团队会根据要求，设计建模出一套解决方案，并且先进行Demo验证，这其中可能需要用到很多算法，统计类的知识。交付之后也没啥问题了，就会交给研发进行执行，从而完成工程化。为了方便理解，我们把设计称之为问题建模也是可以的。事实上，我发现效果还是不错的。设计团队正在努力朝深度学习发展，在加强Spark Mllib上的投入同时，也花了更多时间关注TensorFlow平台。
研发执行里面，我们也是有细分，虽然人少，角色会有重叠：
- 分析师辅助
- 工程化团队
- 突击团队
数据部其实常常面临较多的商务需求，通常我们会让突击团队以最快速度交付第一版，之后再让工程化团队完整的工程化，比如全部转化为我们Spark程序，提供标准的API等，设置定时等等。
突击团队和工程化团队其实还有一个职责，就是团队效率工具的开发。这个基本是以研发负责人为主导，定期根据现状，找到效率瓶颈点，然后抽象出工具，最后排期进行开发。
分析师辅助团队则承担了两个职责，一个是对接纯粹的技术需求。比如ETL之类的。第二个是为分析师做实施执行工作。
虽然研发团队在努力，但是其实不太容易有很明显直观的成果。而且存在感并不强。在解决方案设计团队获得影响力之前，我们还需要一个重要的团队： 分析师团队 去扩大数据部门在公司的影响力。
分析师团队
我经历过两种分析师团队。一种是为研发和公司做support的，一种就是将现在的将分析师打散到各个业务线的方式，团队自身只保留高级分析师做全公司的support。
目前从研发的角度来看，反而是第二种更好。研发工程师和业务线天然有种隔膜，而且很多数据研发并不太喜欢业务。喜欢专研技术，和人打交道并不是他们擅长的，包括和业务团队的工程师打交道。 但是现在有了下放到业务线的分析师后，就变得很便利了。
比如解决方案设计团队了解了需求后，就不用到处去找数据，找人理解数据的含义，他们只要和我们自己的对应的分析师沟通就好，数据分析师直接提取出来数据，解决方案设计团队拿着这些数据就可以建模计算了，部分沟通也可以透过分析师来完成，而且分析师也可以给出较好的反馈，因为他们对业务也是相当了解的，尤其是从数据层面来说。
现在整件事情变得很有趣，以前是分析师依赖于研发，但是现在是研发高度依赖于分析师。基本上我们研发做的大部分事情都离不开分析师。我现在很愁的是，如何给分析师提供更好的support 以作为回馈。
各个业务线的分析师核心是要能够理解业务线里的数据，了解业务规则，问题，结构化业务数据，了解业务痛点，并且能够快速提取出业务/高级分析师/研发想要的数据。高级分析师则会对各个业务进行Review，给出数据方面的建议，为业务Leader提供决策指导。
这里我大致画了个图：
