康威定律说：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。这个定律是比较靠谱的。我给你举个自己的例子。
笔者在相当长的时间在做报表取数，那个时候为了凸显价值，其实我们也很想做一些高端的数据工作，比如数据分析和挖掘，但受限于当时的组织架构，公司并没有明确数据团队在这方面的职责，因此我们最终未能把一个个分析和挖掘的亮点转化成真正的生产力。
报表取数始终是我们工作的基本面，而数据分析和挖掘对于这个团队其实是可有可无的，在资源冲突的情况下，必然是优先满足报表取数这个基本职能。
如果当时让我们全力做数据分析和挖掘，也会有一种不务正业的感觉，毕竟名不正则言不顺。况且公司不给你匹配所需的资源，你也发展壮大不了，别的组织也不会认可。
很多企业想往大数据转型，但对于大数据缺乏认识，相关组织和职能未能同比完成调整，比如要求现有的数据团队既要做好报表取数，也要做好挖掘分析，却没有配备相关的资源，很多人还身兼数职，这种模式基本上是很难成功的。
任何一个有志气的数据从业者都不希望仅限于做报表和取数，但实际上是企业赋予你团队的职能决定了你实际工作的天花板。在一支报表取数为核心的团队，你的挖掘分析的成果很难转化为生产力。
下面以笔者的实践跟你讲讲一支大数据团队的构成，它可能适用于对于数字化转型有一定认识、并在资源上能给予足够的支持的企业。
当然这里的数据团队是狭义的概念（不包括基础平台、应用产品和商务运营），主要包括五个组：汇通保障组、平台工具组、报表取数组、挖掘服务组及对外变现组。
1、汇通保障组
负责企业级大数据统一采集（含集中数据交换）、大数据统一建模（基础和融合模型）、大数据运维及优化及企业级大数据标准及治理等职能。可以看到，汇通保证组是以提升数据本身的效率为核心的。
大数据统一采集：很多企业大数据设立了运维组，但大数据采集规划和推动的职能并没有实质性的落地，基本上是靠一次性项目或需求管理的方式来进行大数据采集，这种模式的弊端是只看重眼前，缺乏长远规划，导致大数据平台在建设了多年后却发现大数据资产的增值有限，这让大数据团队丧失核心竞争力。
做数据的人都知道，数据是建模的天花板，但我们平时似乎更热衷于用建模的方法去化腐朽为神奇，而忘了最本质的东西。
大数据采集规划需要与运维生产的职能去融合，将主动采集作为运维团队的核心职能，这代表了数据运维团队的一个未来方向，企业如果设立统一的数据采集组织，办事处应该设在这里。
大数据统一建模：数据仓库建模的职能到底应该放在哪里备受争议，我们以前只有报表取数组，因此曾经把这个职能放在报表取数组，后来发现屁股决定脑袋的事情太多了，报表取数组基本没有精力去做什么仓库模型优化。
随着企业级中台概念的提出，数据仓库建模肯定要进一步下沉成为企业的公共服务，要致力于去满足企业各个部门的数据诉求，因此统一建模跟运维组的整合也是很自然的。
大数据运维及优化：跟OLTP可以将开发和运维完全分开不同，OLAP系统的开发（采集、建模及优化）跟运维整合是必然的，我们自己经历了分离，整合再分离的过程，最终整合的理念经受住了实践的检验。
大数据标准及治理：大数据标准都是针对具备共性的东西制定的，企业不要搞个单独的组织去做什么标准和治理，在初期应以效率为先，尽快的让这些标准在生产中发挥作用才是当务之急。
2、平台工具组
负责数据中台工具建设及优化，数据开发及挖掘服务环境建设及优化，数据中台新技术的落地。工欲善其事必，先利其器，平台工具组是以提升数据使用效能为核心的。
企业完成了大数据平台建设和数据汇聚其实只是走出了第一步，而如何将这些数据对外开放是巨大的挑战，笔者认为，以下这些平台和工具是需要组建团队长期建设和运营的：
数据开发管理平台：提供跨平台一站式可视化数据开发生产环境，这代表了一种数据技术趋势，可以参考阿里的DataPhin智能数据平台。
这个平台直接面向开发和业务人员，提供了标准化的开发方法，能有效降低开发门槛，当然对于体验的要求非常高。但这种平台是真正的五年磨一剑，需要专门的产品团队长期运营。
比如我们以前的DM只支持离线数据开发，现在既要支持流式的编排开发，也要支持SQL，还要对外部客户开放等等。
数据挖掘管理平台：以交互式、分布式及可视化的方式提供机器学习训练、发布及预测的一站式服务，具体可以参考阿里的PAI。
这种平台直接面向开发和业务人员，能有效降低数据挖掘门槛，建设的难度也是相当高的。
比如最近我们就在自己的敏捷挖掘平台上添加AutoML、AB test等功能来提升能力，同时不断的推进数据挖掘平台与数据开发平台的双向集成融合。
数据资产管理平台：提供从元数据管理、数据质量管理、数据资产评估、数据与系统运维监控的一体化管理平台。
数据资产管理平台现在是个逻辑的概念，它的各种功能模块通过组合的方式去为各类平台赋能，比如元数据管理的数据字典功能是直接与数据开发平台进行无缝集成的。
其他还有标签库管理平台、营销管理平台、数据采集管理平台、报表可视化平台等等。
我们以前的数据没人用，一个很大的原因是工具太差了，而这些工具往往又不是现成能买到的，需要企业下大功夫去做运营，而大多企业通过项目化的方式去打造的这种平台和工具往往水土不服。
3、报表取数组
为公司提供及时、准确的数据是报表取数团队的使命，报表取数是一只数据团队最为核心的职能，报表取数有个好听的别名:BI组，但BI起码到现在还是以展现数据为核心的。
有些报表取数团队还演化出了一些分析职能，但我其实蛮反对在现有报表取数团队额外增加这种职能，因为完全是两个专业。
数据分析和挖掘太多的探索性跟报表取数保守严谨的工作方式是不一致的，你不能让现有的报表取数人员去做兼职，你得额外增加组织和人员。
报表取数团队可以培养基础的数据和业务能力，也是新人的试金石，做不好报表取数，基本也很难胜任其他数据专业的工作，很多人通过报表取数的历练成为专家，笔者也是这么过来的。
4、挖掘服务组
企业一般不会把数据团队的名字叫做报表取数组，虽然它干的事情就是报表取数，但领导不会满足于数据团队只干报表取数的事情，特别是在大数据的背景下。
OLTP的团队可以说保障稳定性、连续性是最大的业绩，但报表取数团队是说不出口的，大多数时候报表延迟几个小时不是问题，这其实也很公平。
既然这样，数据团队索性跟公司争取一些资源，成立独立的挖掘服务（分析也可以）这种组织，对企业有所承诺，专注的去干这种事情，做到责权利统一。
但正如笔者以前在文章中所提的，数据挖掘这种服务的探索性太强了，导致可能你先期投入的人员翻不起一点点浪花。
因此，企业有多大的决心，你有多大的能力决定着在这条路上能走多远，否则，最多也就PPT上show一下而已。
5、对外变现组
无论是报表取数组，还是挖掘服务组，其实他们服务的对象都是内部客户，服务内部客户的一个问题是很难客观评估数据团队的价值，你拼命满足业务部门需求的结果并不一定换来好的满意度，这是数据团队郁闷的一个原因。
设立对外变现组是每个数据团队的理想，在充分竞争的市场能帮助公司赚到钱是最能体现自身价值的地方，也是最具挑战的，当然这还需要天时地利人和的配合。
随着对外业务的开展，应用产品组、商务运营组等组织也会伴随着产生，它反过来能更好的驱动其他数据组织的优化和完善，这也正是我们希望走的道路。
虽然笔者只提了以上五个组，但其实已经包含了大量的内容，每个企业可以基于需要自由组合，从而打造出适合自己的数据团队。
希望我的分享于你有所启示。
