觉得数据科学团队不给力？不该数据科学家背锅，是组织架构惹的祸-CSDN博客

▼

更多精彩推荐，请关注我们

▼

大数据文摘出品

来源：medium

编译：一一、青柠、夏雅薇

从21世纪的第一个十年开始，互联网公司开始有能力通过使用在表格和关系型数据库时代无法想象的方式获取对业务的洞察。他们不再需要等季度末的结果来衡量产品的表现，也不再需要依靠样本推断来全面了解什么是对所有用户有效的。除了提高对业务状态的可见性，新的数据存储和整合能力也使得公司能够做出很多数据类的产品，比如搜索、排名和推荐系统等。

那么如何能有效且有效率地来实现这些想法呢？组建一个数据科学团队不是一件简单的事，更别说定义数据科学家如何与公司其他业务协作。

组建一个数据科学团队不仅仅只是招一些人，更重要的是你要去设定好新的工作流程，告诉大家这个团队如何与其他团队有机地互动，产生价值。

在这篇文章中，作者对比了一些现在比较流行的整合数据团队的模式。来一起看看吧~

黑色小圆动图分割线

在决定哪个模式最优之前，我会考虑以下几个因素：

协同效率：每个部门都会自己部门所特有的信息和专业知识，如何将这些信息高效地运用到公司业务中需要一个好的组织架构，不然信息分享和整合就会很低效。

工作的目的是为了产生成果——一个策略、产品、市场推广方案、预算、客户计划、销售、新功能等。沟通是为了让相关人员都能理解并赞同这个目标，如果沟通得太晚，一开始大家各做各的，再来协调，有些就已经来不及再改了，或者改的成本太高了。

成功的管理：不同的组织结构有不同的管理需求。这些需求可以通过扩大管理层的人数规模或者增加现有管理层的技能和责任来满足。对管理需求的疏忽将会使管理者和被管理者都遭殃。

员工幸福感：当我们讨论组织结构时，如果不考虑员工的幸福感、激励机制和成长因素，这样的讨论是不完整的。减少员工流失从而达到节约招聘成本只是其中一个正面影响，为员工提供空间，让他们在任职期能够尽情做一些创造性的高质量工作更是增加公司生命力的关键。忽视员工幸福感是短视的，且长期来看公司往往要付出很高的代价。

成功的产品：要让数据科学家有机会验证新想法，定义实验和指标，设计和训练模型，他们是能够推动数据在公司内部用起来的人。如果一个新产品在发布前，没人测评过一些重要数据，一般来说这个产品会出问题，还可能跟公司的战略规划和用户需求脱钩。

我做了一些假设。这个组织是一个单一战略业务单元。这个单一战略业务单元按照任务和责任被划分进独立的产品线。一个产品组是一个对一个单一产品负责的跨职能的组（包括工程师、设计师等）。一个数据科学家是一个具有数据处理、分析和模式搭建能力的工程师，数据科学是他们的工作。一个数据科学组是由数据科学家和他们的管理者组成的。

中心驱动模式

我们从集中程度最高的模式开始。中心驱动模式（也被称为研究模式）对据科学团队的设定是能独立运作，挖掘重大潜力，提出初始模型。在这一模式下，数据科学团队被视作公司的创新来源。

有人对中心驱动模式有一些误解，然后他们把这种模式强加到数据科学团队上。

博士毕业生是招来做研究的。数据科学团队会招聘许多博士和硕士毕业生。一般来说博士和硕士项目聚焦于研究，所以大家的误解就是这些项目的毕业生就应该招来做研究。但其实他们搞错了，数据科学家常常会从事一些工程、统计分析和模型构建的工作，因为他们之前在数学和统计领域已经有多年的学习，所以他们更能对提供高质量的分析和新的分析方法创造价值。

创新是在实验室里诞生的。公司期待数据科学团队成为创新思维的源泉这个没有问题，但是有一个误解是因为创新部门需要很多自由，所以他们不需要接触公司的日常业务需求。如果数据团队脱离公司的业务模式和基础设施而运作，他们的研发成果将很难落地。这也是为什么即使有很多成功案例，并且在条件允许的情况下，许多公司在这方面的投资仍然很谨慎的原因。

缺点

用中心驱动模式来运营数据科学团队有一些问题：

缺少业务背景：如果对决策层日常做决策所遇到的挑战不够了解的话，一个纯粹的数据科学团队很难定位到最需要解决的问题。所以有时候当数据团队在天马行空地想新点子的时候，产品却遇到了很大的问题。

闭环困难：即使他们能够成功定位并提出解决方案，中心化的研究团队发现要让产品团队采纳他们的想法也并不容易。如果产品团队要采纳数据团队提出的方案，就有可能会影响到他们现有的战略计划—因为这两个团队之前没有经常沟通达成一致。解决这一矛盾通常需要高层管理人员的介入，但这又会让团队现有的路线图被迫打乱。如果更高层管理人员不介入，研究团队的积极性又会受到影响。

我觉得每个人都应该在同一个节奏上。如果节奏不同，就应该按照不同的节奏来划分资源（所有资源）。不在同一节奏上的团队是没法合作的。

成本高昂：如果不想打乱现有产品团队的计划，另一个方法是创建一个新的跨部门产品团队专门来实施数据团队的点子方案。这样做虽然很贵，但是实现数据团队想法的有效途径。一个想法到底好不好，需要从各部门的角度来评估，缺一不可。一个新的功能需要设计、开发、测试和评估，市场和销售共同推进来实现其潜在价值。

如果新的产品团队和现有产品团队不能有效区分工作内容，那么组建这个全新产品团队的成本就很高，因为计划和职责范围会有很多重叠。这对新团队的存在价值会造成威胁，在他们试图搞清楚自己的使命前，其他团队会很困惑。

不可复现的产出：在研究模式下，产品团队也许会发现并认可数据科学团队某个产出的价值。但是不确定如果他们接受了提议并进行了改变，是否会有后续的跟踪反馈。

优势

值得注意的是，中心驱动模式对很多类型的团队都有用。中心化的决策模式方便设立专一的目标和统一管理。你应该集中化管理那些对所有其他团队都明确的工作。当团队间的依赖关系比较少，且跨部门间的会议比较少的时候，中心驱动的管理模式会很有效。

例如开发工具的工程师团队。一旦公司决定采用某种技术或编程语言，这个团队可以进行开发，且不怎么受其他d产品开发周期的限制。

另一个中心驱动团队的成功案例是微软研究院（这个部门成立于1991年）。刚成立时微软并没有期待这个部门会驱动微软核心产品的提升。但后来微软在人工智能领域的专利竞赛遥遥领先要归功于这个部门。

会计模式

在会计模式（也叫商业智能模式）中，数据科学团队定期（通常每月和每季度）做报告，向公司管理层展示哪些重要性指标发生改变。每次发现一个有趣或者令人担忧的趋势，数据团队会和产品团队一起进行深入分析找出根源。通常在会计模式下数据团队会扮演侦探的角色。

缺点

这种模式主要有三个缺点：

归因和闭环困难：如上所述，几乎不可能根据整体趋势进行推理。当有很多产品团队，涉及到很多人员和变化时，这个缺点非常明显。

小虎队的出现（小虎队特指某个领域的专家组成一个团队来执行某个特定任务）：每个产品团队都应该有相关的分析和指标来衡量他们的工作成果，这样出了问题，他们可以快速发现并修复。当数据团队不能通过数据及时发现问题，产品团队又无法定位问题的优先级时，就会出现专家救火队。小虎队跟现有产品团队并没有明确的职能区分，因此也就破坏了现有的组织架构。小虎队的出现是中心驱动模式下的必然结果。

技术利用不够：数据科学团队如果只是每个月或每个季度产出一个报告的话，将会造成很多产品质量监测的空缺。如果新版本发布导致某个市场的使用量下降，这个影响在发布的那一刻就会发生，而不是每个季度发生一次。多次产品迭代后再要去识别是哪个版本发布导致产品使用度下降，或导致用户恶意滥用的行为，几乎是不可能的。

低质量和过时的数据：每个项目的启动都会产生新的数据源，这些数据应该被整合进已有的指标中用于以后的分析。会计型数据科学家将会错过所有重要的更新，并且常常依赖过时的数据进行分析。这样数据团队就会被边缘化，很难发挥主要作用。

好处

报告公司关键指标的季度趋势是很有价值的。商业智能团队能以全局观的视角来看待整体的数据，平衡各个因素，最终作出比局部决策更优的整体化决策。不管团队目前处于哪种模式，数据科学团队都应把这作为一项重要职责。

顾问模式

顾问模式以邮件的形式把需要解决的问题发送给数据科学团队。然后，数据科学经理对问题进行优先级排序，并分配给数据科学家。

优点

这种模式下，数据科学经理会从现有优先级出发，改变数据科学现有的工作安排。因为这个方法对每个数据科学家都是一视同仁，所以管理一个数据科学团队变得很简单也很便宜。

缺点

这个模式有很多缺点:

a.沟通成本。处于咨询角色的数据科学家通常缺乏解决问题的背景信息。要熟悉数据源及其创建过程都需要沟通。此外，如果需要进行后续的分析工作，但原来的顾问数据科学家正在做其他项目，那么工作就会被分配给另一个数据科学家，这就需要再次投入时间进行沟通——这个过程可能会一直循环。

b.完成期限不明确。问题相关人员很难知道什么时候他们的工作何时会被优先考虑并分配给数据科学家顾问。到底什么因素会影响提出请求的流程也不是很透明。即使在分配了工作确定了优先级之后，数据科学家也很难估算出解决问题所需的时间，因为他们并不熟悉这个新数据源的局限和细微差别，何况数据还可能一直在变。

c.临时所有权。创新更容易在人们在一个项目上工作了几年后发生，而不是工作了几天或几周后。当数据科学家充当临时顾问，他们很难进行创新，因为创新需要复杂深入的思考。

d.所有权不明确。当数据科学家对一个项目只是临时负责，就会变得所有权不明确。因为这样的权责分配多是一次性也是随机的，大家好像都有责任，也就变成了谁都不用负责。这样的结果虽然是无意的，但造成了很严重的效率低下。

e.工作缺乏动力和成就感。这种模式下工作的数据科学家通常缺乏动力，因为他们很少参与产品的决策过程。他们通常也发现工作没有成就感，因为他们很少看到工作的成果和影响力。

f.数据质量低下和反复出现的突发情况。如果不维护良好的数据流程，依赖数据作为输入的产品就会遭殃，会经常出现bug。这种模式下，数据科学家常会被拉到一个项目中，扮演侦探的角色来侦查错误的来源。

当数据科学家对数据产生的过程或产品不够了解的时候，数据抓取容易有疏漏，但还有一个原因也可能导致数据抓取的失误，也就是缺少协调。当数据收集的流程没有协调好，想要在大海里捞针几乎是不可能的，如果涉及到抓取历史数据，更是难上加难。

在这些情况下，找到罪魁祸首几乎是不可能的。正如在会计模式的缺点中所讨论的，组织通常通过组建一个老虎团队来应对，从而导致进一步的破坏和成本。

g.产品领域互相重叠。这个模式有许多责任分配和优先级的挑战。数据科学经理如何确定工作的优先级?哪个产品团队最受关注? 哪些决策是在考虑数据的情况下做出的，哪些决策是在没有数据的情况下做出的，谁来做决定？

h.没有明确的规模和分配策略。与任何集中化管理的模式一样，到底需要多少数据科学家是很难界定的。数据科学团队的规模是随着公司的规模增长而增长？还是随着内部需求的数量增长而增长?如果是后者，如何估计需求的数量和总体范围?要回答这些问题，并没有一个简单的策略来决定到底需要多少人的数据科学团队来支持。

嵌入模式

这种模式下，产品团队招了自己的数据科学家。程序员经理决定数据科学家的人数、招聘和工作分配。每个产品团队中的数据科学家与工程师团队一起协作。

好处

该模式为团队带来了独立性，减轻了每个业务组对集中式数据科学团队的管理需求。它解决了团队规模和沟通方面的问题，也避免了去中心化模型中的所有权和主动性问题。

缺点

虽然这个模式可以有效降低数据科学的管理成本，但仍存在一些重要缺陷:

a.管理的复杂性。同一团队下角色的多样性给管理带来了麻烦。对于一个工程师经理来说，要兼顾到数据科学家和软件工程师的职业晋升道路是有挑战的，因为侧重点很不一样，需要用不同的标准来衡量两者的价值，如果采用单一的标准对任何一方都是欠妥的。通常，工程师经理会在无意中倾向于用工程师的标准来评估数据科学家的工作，这无形中给了数据科学家压力，让他们承担起与团队中其他工程师类似的角色，这其实违背了雇佣数据科学家的初衷。在这种模式下如何招聘数据科学家、设置合理的面试考评标准都是一个挑战。

b.缺乏指导，难以维持统一的数据标准和最佳工作方式。数据科学家可以从与工程师的密切合作中获益和学习，尤其是在分析回顾期间。但嵌入模式很难为跨团队的数据科学家间的交流提供有效途径。此外，每个团队的独立数据科学家都会有自己的流程和标准。

c.技术和数据科学利用不充分。一些团队可能会因为项目时间紧或者预算问题而推迟雇佣数据科学家。在缺乏良好数据的情况下，有些产品依然会被推出。这会导致数据质量和数据产品有明显缺陷，这些缺陷在日后很难修复。

d.局部优化而不是全局优化。当没有统一的衡量标准和目标时，各团队只会专注于局部优化。在这个模式中，团队间会互相竞争，有时候会导致内耗。

民主模式

在这个模式下，如果产品经理、设计师、工程经理和工程师可以很简单地获取数据，对数据科学家的需求就会减弱。许多人认为，我们之所以需要数据科学家，是因为缺乏合适的基础设施来快速、简单地获取可视化的数据。

好处

投资数据基础设施和工具，使每个人都能访问、处理和可视化数据。对于数据科学家来说，这种投资尤其有价值，因为它解放了数据科学家，让他们有更多时间来进行前瞻性的机会挖掘、实验设计、指标设计、模型设计和方法论的整体改进。

缺点

虽然每个人都能直接、方便地访问数据是一个很理想的目标，但这种模式也存在一些缺陷:

a.难以掌握一切并规范数据相关的操作。通常，人们可以在特定的任务上做得很专业，能够熟练掌握工程技术已经很了不起了，想要减轻设计，产品和数据科学的工作负担是好的初衷，但数据科学家的可以对数据相关的操作和决策起到很好的规范类作用。

b.数据可视化不是数据科学。

产品数据科学模型

在完全集中模式（CoE模式）和完全分散模式（嵌入模式）的两个极端之间，存在一系列混合模式，具有上述每个模式的特征。充分利用两种模式的优势，并积极弥补它们的不足，这是混合模式取得成功的关键。

产品数据科学(PDS)模型的灵感部分来自矩阵结构。个人同时是数据科学职能部门和产品团队的成员。数据科学家（尽管每个人都是产品团队的一员）向中心化数据科学团队汇报。因此，与矩阵结构不同，这个模式下数据科学家还受到数据科学家团队目标的影响。

好处

a.明确的所有权和可以落地的策略。该模型的一个重要好处是，由于数据科学家属于各个产品团队，因此他们明确拥有项目的所有权。成为每个产品团队的成员可以让数据科学家对该产品、其局限性和潜力有透彻的了解。这样可以直接将分析结果转化为可实施的建议。如果想法不能转化为行动，就很难快速前进。

b.高质d饿量数据和数据产品。数据科学家与产品团队密切合作可以提高数据质量。每一次产品迭代都有可能会改变数据，所以数据追踪也要要协调好，跟上产品的变化。

c.标准化的数据科学流程。在不同的产品团队工作的数据科学同事们齐心协力，在数据科学团队中建立起最佳操作流程。他们可以彼此检查代码并进行分析。受益于统一的职业规划，管理者可以评估他们的影响力并推动他们的成长。

d.全局优化。来自不同产品团队的数据科学同行的直接和多次协作还有其他好处。基于他们对企业业务的整体看法，他们能够连接各个点，识别不一致的地方并进行全局优化。这与设计团队运作方式的方法论很相似。

e.清晰的规划和分配。这个模型的另一个好处是，它让确定数据科学团队规模变得很容易。因为一旦确定了如何将各职能部门划分为多少产品团队，确定了每个产品的工程师人数，就可以轻松确定数据科学家的分配比例了。我在下述链接有更详细的解释：

https://medium.com/@djpardis/recommendations-for-data-science-team-sizing-and-allocation-strategy-a38f943638e5。

缺点

没有一种模式是完美的，每种模式都有其缺点。正如西诺夫斯基所言：

既然没有最佳或完美的组织结构……那么最重要的事情就是了解你的组织结构的弱点，并弥补它们。

以下是该模型的一些缺点。

a.成本。反对该模型的一个主要论点是为每个产品团队雇佣数据科学家的成本；以及集中管理团队的相关成本。该评估未考虑因数据和产品质量的提高以及企业更有效地使用数据而节省的成本。话虽如此，每个公司要量力而行。一个创业公司刚开始的时候，每个人要很全能，既要负责编程，又要负责设计、数据需求类的工作。随着业务组的发展，然后每个部门的分工会越来越明确。

b.由于缺乏同等权力而经常发生冲突。为了在跨职能团队中取得成功，所有职能的领导应具有相似程度的影响力和话语权。在权力不均等的情况下，跨职能协作的好处会因不断发生的冲突、延迟交付和结果欠佳而减弱。

c.信息超载和管理挑战。要了解数据科学团队支持的所有产品的正确信息并不简单。然而数据科学团队的管理人员需要足够了解他们下属职权范围内的领域，以便能够有效地评估每个人的贡献。他们还要不断地在数据科学团队和业务团队间沟通协调，达成最佳的团队资源分配。

对于这个模型的缺点，有一个相对简单的解决方案。在以后的文章中，我将讨论如何使用这个模型的成功秘诀。

结论

在开发单个产品时，我认为产品数据模型在为业务方提供价值方面效果最佳，且最高效。

PDS模型符合格罗夫定律，所有大型商业组织最终都会采用混合型组织架构。

这也与哈耶克（Hayek）关于在社会上使用知识的观点相一致，他鼓励在组织和决策中采用混合方法，因为这两种极端都不能充分满足社会决策中对于速度和准确性的要求。

我们不能指望先把所有的知识传达给中心化的董事会，然后等中心化的董事会整合所有知识后发布命令来解决问题。我们必须通过某种形式的权力下放来解决这个问题。但这只能部分解决我们的问题。我们需要权力下放，因为只有这样我们才能确保特殊情境下的知识能够得到及时的利用。但是，“在场的人”不能仅仅根据他对周围环境有限而的了解来作出决定。需要帮助他看到更全局的情况，因为他需要让自己的决定与更大的经济体系的整体变化相契合。