大多数公司将他们的数据科学部门分为3组：
- 数据科学家：那些“比统计学家更好的工程师和比工程师更好的统计学家”的人。“思想家”。
- 数据工程师：这些人构建管道，为数据科学家提供数据，并从数据科学家那里获取想法并实施它们。“实干家”。
- 基础设施工程师：是维护Hadoop集群/大数据基础架构的人。“水管工”。
数据科学家经常感到沮丧的是，工程师将他们的想法投入生产的速度很慢，工作周期，路线图和动机都不一致。代表他们的想法的第1版才进入A / B测试时，他们更进一步想法的版本2和3还在排队，数据科学家的沮丧是完全合理的。
数据工程师经常感到沮丧的是数据科学家生成效率低下且写得不好的代码，几乎没有考虑生产想法的维护成本，总是需要一些不切实际的功能，这些功能实现起来麻烦但是收益却微乎其微......这种情况可以列表很长。
基础设施工程师因为超载群集和填满磁盘空间而感到沮丧。他们与科学家和工程师保持着一定的距离，这意味着他们无法获得有关基础设施的使用方式或需要用于解决的业务和技术问题方面实实在在的应用背景。他们也无力改善这种状况。相反，他们通过增加基础设施限制性来对应用做出反应。这样，每个人更对他们感到沮丧。
这是一个恶性循环。
什么地方出了错？
1. 你可能没有大数据
在过去五年中，数据处理工具和技术已经发生了巨大变化。除非您需要处理超过数PB的数据，或者您每天要摄取数千亿个事件，否则大多数技术已经发展到可以轻松扩展到您的需求的程度。
除非您需要突破这些技术的能力范围，否则您可能不需要高度专业化的专业工程师团队来构建解决方案。如果你设法雇佣他们，他们会感到无聊。如果他们感到无聊，他们会离开你去谷歌，Facebook，LinkedIn，Twitter，... - 实际需要他们的专业知识的地方。如果他们不感到无聊，他们很可能是相当平庸的。平庸的工程师真的擅长于复杂，糟糕的工作 - 他们会把问题搞复杂和混乱。
2.每个人都想成为“思想家”
因为它听起来像是一个很酷的角色！你可以整天坐着，想出更好的办法，然后把你的想法交给那些热切地投入生产的人。数据科学家，特别是那些对行业更新并且不了解更多的人，特别想要这样一个角色。
传统的商业智能部门由三个角色组成：ETL工程师，报表开发人员和DBA。ETL工程师将数据移动到数据仓库中。他们沉迷于Kimball和他的维度建模指南。另一方面，报表开发人员是那些在特定工具中设计报表的人（例如Microstrategy等）。他们是专家。DBA（以及其他工具管理员团队）尽力保持运行。
ETL工程师，报告开发人员和DBA都是“实干家”，当大数据和数据科学开始成为流行语时，有很多成熟的BI部门拥有大量的实干家而没有足够的思想家。因此，他们使“思想家”成为一个角色。我们将数据科学家与已建立的BI部门相结合，承诺他们能够摆弄数据并改变业务过程。
这个角色听起来真的很棒，并且很容易招募。因此诞生了传统的，现代的数据科学部门：数据科学家（报告开发人员又名“思想家”），数据工程师（ETL工程师又称“实干家”）和基础设施工程师（DBA又名“管道工”）。
似乎商业智能部门从未真正改变过，我们只是添加了一个Hadoop集群并开始用新名称调用它。
一种不同的数据科学系
几年前，我因为这个原因搬到了Stitch Fix。在Stitch Fix，我们致力于生产出世界上最好的的算法和分析方法。我们努力通过我们的产出来领导业务，而不是通知它。除非你愿意大胆挑战并重新思考你认为不合格的事情，否则这是一个难以置信的难题。
在看到该部门在过去两年中成长和发展之后，我有信心分享我们的目标。
鉴于目标是领导而不是通知，我想向您提出我认为构建数据科学部门的更好方法。一种允许角色自主权，真正所有权一直进入生产的方式，以及对产出的责任。这种方式非常适合具有快速发展的业务（和数据）模型的公司。
接下来是构建数据科学团队的蓝图，该团队可以快速调整和反应，通过思想领导力，API和代码的生成来引导和创新，而不是对变化作出反应并将一些PowerPoint演示文稿放在一起。不顾一切地试图重新定位直觉和错觉。
让每个人都成为世界上最好的
无论角色如何，充足和伟大的人之间的根本区别在于他们的创造欲望和才能。伟大的人能够识别和创造性地解决那些一直困扰平庸人的问题。他们擅长并渴望拥有自主权，所有权和专注的环境。
从科学家到工程师的装配线切换创造了极端相反的环境。（事实是，即使是思想者也不得不依赖实干家）。诀窍是创建一个环境，允许每个人参与自治，所有权和关注。
但是，重要的是要认识到工程师和数据科学家对非常不同的任务充满激情：
数据科学家：
数据科学家喜欢处理与业务垂直对齐的问题，并通过他们的努力对项目/组织的成功产生重大影响。他们着手优化某个事物或过程或从头开始创造一些东西。这些都是面向点的问题，他们的解决方案往往也是如此。它们通常涉及大量业务逻辑，重新构想事物的方式以及健康的创造力。因此，他们需要深入了解业务的特定部分如何运作以及与业务垂直部门的高度合作。
工程师：
工程师擅长抽象，概括，并在需要的地方寻找有效的解决方案。这些问题通常是横向导向的。当广泛应用时，它们可能是最具影响力的。他们需要对业务运营方式有一个全面的了解，但解决方案的抽象性意味着他们对业务逻辑很轻松，并且不需要与业务中的垂直行业建立沉重的伙伴关系或深刻理解。
混合思想家：
数据空间中对工程师的共同担忧是，无论您的工作描述或招聘广告如何，您都在秘密搜索ETL工程师。
如果你没有意识到，没有人喜欢编写和维护数据管道或ETL。它是业界最终的烫手山芋。ETL工程角色是平庸的典型繁殖地，真的不应该让人感到意外。
工程师不应该写ETL。
没有什么比编写，维护，修改和支持ETL以产生工程师自己永远不会使用或消费的数据更令人痛苦的了。
相反，让人们对他们所制作的作品（自治）进行端到端的所有权。就数据科学家而言，这意味着ETL的所有权。它还意味着对数据分析和数据科学结果的所有权。数据科学家的许多努力的最佳结果是用于机器消费者而非人类消费者的工件。它不是报表，仪表板或PowerPoint演示文稿，而是集成到工程堆栈中的某种算法或API - 从根本上改变了业务的运作。自治意味着数据科学家也拥有该代码。一路投入生产。 他们应该能够开发和部署它，而无需征得工程师的许可，对支持负责，遵守性能，延迟和SLA要求等。
这将垂直责任和重点放在数据科学家手中。但是，数据科学家通常不是经过专业培训或技能娴熟的软件工程师。你可以说它们滥竽充数，所以你认为他们会创造一个大混乱。
这就是为什么ETL和API /生产算法开发通常以流水线方式传递给工程师的原因之一。但是，所有这些任务本质上都是垂直（点）重点。数据领域的优秀工程师几乎总是最专注于水平应用。
那么，工程师在这个新的横向世界中扮演的角色是什么？总而言之，工程师必须部署平台，服务，抽象和框架，使数据科学家能够设想，开发和部署他们的自主思想（例如用于构建，安排和使用的工具，框架或服务）。执行ETL）。我喜欢用乐高积木来思考它。工程师设计新的乐高积木，数据科学家以创造性的方式组装，以创建新的数据科学。这说起来容易做起来难，但是：
- 工程师的工作本质上可以是完全水平的。这使他们能够专注于构建广泛适用于多种数据科学问题的技术。这最大化了工程输出的杠杆作用。这很好，因为您可能拥有的数据科学家远远多于数据科学部门的工程师。
- 工程师可以专注于他们最擅长的事项：抽象，概括，并在需要时创建高效，可扩展的解决方案。
- 工程师可以自主运作。以这种方式部署的工程团队的生产应该看起来像“神奇”。对于数据科学家而言，事情应该“落实到位”，因为他们的需求是预期的，并且扩展和弹性将由他们正在使用的平台，服务和框架来处理。
- 为了使其工作良好，大多数时候工程师需要预测数据科学家的需求。他们应该提前制定多个步骤。
- 对于才华横溢，富有创造力的工程师和数据科学家来说，这是一个非常有趣的地狱。
让数据科学家们做所有工作吗？
不要期望数据科学家突然变成有才华的工程师。工程师也不会忽视所有业务逻辑和垂直计划。事实上，伙伴关系是这种模式成功的关键。
在缺乏推出解决方案的抽象和框架的情况下，工程师与科学家合作创建解决方案。但是，不是以手工的形式。相反，工程挑战变成了构建自助服务组件之一，以便数据科学家可以自主地迭代业务逻辑和算法，从而将他们的想法传递给业务。在最初推出解决方案后，很明显谁拥有什么。工程师拥有他们构建的基础架构，数据科学家拥有他们提供的业务逻辑和算法实现。迭代不需要任何形式的紧耦合。
平台工程师必须始终领先于数据科学团队。您需要非常敏锐的平台工程师，他们可以在迫切需要之前就哪些服务，框架和功能做出直观决策。缺乏从科学家到工程师的交接意味着工程师无法对科学家提出的要求作出反应。
请记住，工程师正在创建乐高积木，数据科学团队正在组装它们。如果数据科学团队没有合适的块来组装，他们也会继续前进以创建解决方案。他们就通过组装错误的块（圆孔中的方形钉）或创建自己的块来解决问题。通常，他们会创造一个大混乱，一旦创建就很难撤消。