数据科学六大组织模型

数据科学六大组织模型

原文：towardsdatascience.com/six-organizational-models-for-data-science/

简介

数据科学团队可以在公司内部以多种方式运作。这些组织模型影响团队所做的工作类型，也影响团队的文化、目标、影响以及对公司整体价值的贡献。

采用错误组织模型可能会限制影响、造成延误并损害团队的士气。因此，领导层应该了解这些不同的组织模型，并明确选择与每个项目目标及其团队优势相一致的模式。

本文探讨了我们在众多组织中观察到的六个不同模型。这些模型主要区别在于谁发起工作，数据科学团队产生什么产出，以及如何评估数据科学团队。我们指出每个模型的常见陷阱、优点和缺点，以帮助您确定哪种模式可能最适合您的组织。

1. 科学家

典型场景

一位大学科学家研究海洋温度的变化，随后发表了同行评审的期刊文章，详细介绍了他们的发现。他们希望政策制定者有一天会认识到海洋温度变化的重要性，阅读他们的论文，并根据他们的研究采取行动。

谁是发起者

在这种模式下工作的数据科学家通常由他们的知识好奇心和希望在某个领域内推进知识的愿望来驱动他们自己的项目。

工作如何评判

科学家的工作产出通常通过他们的工作如何影响同行的思考来评估。例如，他们的工作是否引起了其他专家对某个研究领域的关注，是否解决了基本未解决的问题，是否促进了后续发现，或者为后续应用奠定了基础？

需要避免的常见陷阱

基础科学研究推动人类知识向前发展，提供基础性知识，这些知识能够促进长期的社会进步。然而，使用这种模式的数据科学项目可能会专注于那些具有长期重大影响但近期影响有限的问题。此外，该模型鼓励科学家与决策者脱钩，因此可能无法培养推动行动所需的共同背景、沟通风格或关系（例如，遗憾的是，气候变化的所有研究几乎没有导致任何行动）。

优点

• 在一个领域的最前沿发展深厚专业知识的机遇

• 具有突破性发现的潜力

• 吸引重视自主性的优秀人才

缺点

• 可能难以根据发现推动结果

• 可能与组织优先事项不一致

• 许多有趣的问题没有大的商业影响

2. 商业智能

典型场景

市场营销团队请求关于他们最后几封电子邮件的打开率和点击率的详细数据。商业智能团队以电子表格或仪表板的形式响应，显示所需的数据。

谁发起

运营（营销、销售等）或产品团队直接向数据科学团队成员提交工单或提出请求。

如何评判 DS 团队

BI 团队的贡献将根据他们服务入站请求的速度和准确性来评判。

避免的常见陷阱

BI 团队可以高效地执行对明确入站请求的响应。不幸的是，请求通常不会包含关于领域、正在做出的决策或公司更大目标的实质性背景信息。因此，BI 团队往往难以推动创新或具有战略意义的重大影响。在最糟糕的情况下，BI 团队的工作将被用来证明已经做出的决策。

优点

• 数据科学团队有明确的角色和责任

• 对特定请求的快速执行

• 直接满足利益相关者的需求（快乐的合作伙伴！）

缺点

• 很少利用数据科学家的非执行技能

• 很可能无法推动实质性的创新

• 顶尖人才通常会寻求更广泛且非执行性的范围

3. 分析师

典型场景

产品团队请求分析最近客户流失率激增的原因。数据科学团队研究流失率激增的原因以及可能驱动变化的因素。分析师在会议上展示他们的发现，并将分析结果保存在一个与所有与会者共享的幻灯片集中。

谁发起

与 BI 模型类似，分析师模型通常从运营或产品团队的需求开始。

如何评判 DS 团队

分析师的工作通常根据请求者是否觉得他们获得了有用的洞察力来评判。在最好的情况下，分析将指向随后采取的行动，并产生预期的结果（例如，分析表明客户流失率的激增与平台页面加载时间增加同时发生。随后降低页面加载时间的努力使流失率恢复正常水平）。

常见陷阱

分析师的洞察力可以指导关键的战略决策，同时帮助数据科学团队发展宝贵的领域专业知识和关系。然而，如果分析师对某个领域的运营约束理解不足，那么他们的分析可能无法直接执行。

优点

• 分析可以提供实质性和有影响力的学习成果

• 充分利用数据科学团队在解读数据方面的优势

• 有机会建立深厚的专业知识

缺点

• 洞察力可能并不总是可以直接执行的

• 可能无法看到分析的影响

• 分析师有成为“沙发评论员”的风险

4. 推荐者

典型场景

产品经理要求一个在网站上对产品进行排名的系统。推荐者开发了一个算法，并通过 A/B 测试来衡量其对销售、参与度等方面的影响。推荐者通过一系列 A/B 测试迭代改进他们的算法。

由谁发起

产品经理通常发起此类项目，认识到需要推荐引擎来改善用户体验或推动业务指标。

如何评估 DS 团队

推荐者理想情况下应通过其对关键绩效指标（如销售效率或转化率）的影响来评估。这种具体形式通常取决于推荐引擎是面向客户还是面向后台办公室（例如，销售团队的潜在客户评分）。

需要避免的常见陷阱

当推荐项目与高频决策对齐，每个决策的增量价值较低（例如，播放下一首歌曲）时，它们会蓬勃发展。对于低频决策，由于数据量低，培训和评估推荐可能具有挑战性。即使每个决策的增量价值很高，评估是否需要采用推荐也可能具有挑战性。例如，考虑开发并部署用于医疗诊断的计算机视觉系统。尽管它们的客观性能很强，但由于癌症诊断相对低频且增量价值很高，其采用速度缓慢。

优点

• 明确的目标和通过 A/B 测试实现可衡量影响的机遇

• 如果推荐系统成功，将有可能获得显著的回报率

• 与面向客户的成果和组织目标直接对齐

缺点

• 错误将直接损害客户或财务结果

• 面向内部的使用推荐引擎可能难以验证

• 算法偏差和负面外部性的可能性

5. 自动化者

典型场景

一辆自动驾驶汽车将车主带到机场。车主坐在驾驶座上，以防万一需要干预，但他们很少这么做。

由谁发起

运营、产品或数据科学团队可以看到自动化一项任务的机遇。

如何评估 DS 团队

自动化者被评估的是他们的系统是否比人类执行任务时产生更好的或更便宜的结果。

需要避免的常见陷阱

自动化可以提供超越人类的表现或消除大量成本。然而，自动化一个复杂的人类任务可能非常具有挑战性和昂贵，尤其是如果它嵌入在一个复杂的社会或法律体系中。此外，围绕自动化制定项目会鼓励团队模仿人类流程，这可能会因为人类与算法的独特优势和劣势而具有挑战性。

优点

• 可能带来显著的改进或成本节约

• 具有与人类决策固有的可变性无关的一致性能

• 释放人力资源，用于更高价值、更具战略性的活动

缺点

• 自动化复杂任务可能资源密集，因此回报率低

• 关于就业替代和责任问题的伦理考量

• 随着条件的演变，维护和更新具有挑战性。

6. 决策支持者

典型场景

一个终端用户打开 Google Maps 并输入目的地。Google Maps 展示了多条可能的路线，每条路线都针对不同的标准进行了优化，如旅行时间、避免高速公路或使用公共交通。用户审查这些选项，并在开车之前选择与他们偏好最一致的路线。

谁发起

数据科学团队经常认识到帮助决策者的机会，通过将大量可能的行为空间提炼成一小套高质量选项，每个选项都针对不同的结果进行优化（例如，最短路线与最快路线）。

如何评估 DS 团队

决策支持者根据其系统是否帮助用户选择好的选项并体验到承诺的结果（例如，旅行是否花费了预期的时间，用户是否避免了承诺的高速公路）来评估。

需要避免的常见陷阱

决策支持系统利用人类和算法各自的优势。该系统的成功将取决于人类和算法协作的好坏。如果人类不希望或信任算法系统的输入，那么这种项目就很难产生影响力。

优点

• 利用机器的优势在大规模上做出准确的预测，以及人类的优势做出战略性的权衡。

• 数据科学团队在项目启动和规划阶段的参与度提高，这将增加项目为公司产生创新和战略差异化能力的可能性。

• 提供决策过程的透明度。

缺点

• 需要大量努力来模拟和量化各种权衡。

• 用户可能难以理解或权衡所呈现的权衡。

• 验证预测结果与实际结果是否匹配复杂。

项目组合

过度或不足使用特定模型可能对团队的长期成功产生不利影响。例如，我们观察到一些团队避免 BI 项目，并因缺乏关于目标如何量化的共识而受到影响。或者，避免分析师项目的团队可能因为缺乏关键领域专业知识而陷入困境。

更频繁地，我们观察到团队过度使用模型的一个子集，并陷入其中。这个过程在一个案例研究中得到了说明，我们亲身体验了：

一个新的数据科学团队被创建，以与现有的运营团队合作。运营团队渴望成为“数据驱动”的，因此他们提交了许多关于数据和数据分析的请求。为了保持竞争力，数据科学团队过度使用了 BI 和分析模型。这强化了运营团队的一种隐性信念，即数据团队的存在是为了服务他们的请求。

最终，数据科学团队因无法推动创新或直接量化他们的影响而感到沮丧。他们努力争取时间和空间来构建一个创新的决策支持系统。但推出后，运营团队选择不大量使用它。

数据科学团队已经培训了跨职能合作伙伴，让他们将自己视为支持性组织，而不是决策的共同所有者。因此，他们的最新项目感觉像是一个“板凳上的四分卫”：它表达了强烈的观点，但没有分享执行或结果的所有权。

过度依赖 BI 和分析模型使团队陷入了困境。推出新的决策支持系统对各方来说都是一个耗时且令人沮丧的过程。最终需要自上而下的命令来推动足够的采用率以评估该系统。它成功了！

事后看来，更早采用更广泛的项目类型组合本可以防止这种情况发生。例如，一些分析项目本应产生关于特定行动的强烈建议，而不是以洞察力结束。而且数据科学团队应该与运营团队合作，确保这项工作从执行到最终评估的整个过程。

结论

数据科学领导者应根据每个项目的目标、限制和周围的组织动态，有意采用适合每个项目的组织模型。此外，他们应该注意构建不同项目类型的自我强化的投资组合。

要为项目选择一个模型，请考虑：

1. 您正在解决的问题的性质：激励问题是探索性的还是定义良好的？

2. 期望的结果：您是在寻求渐进式改进还是创新突破？

3. 组织需求：项目将获得多少来自相关运营团队的支持？

4. 您的团队技能和兴趣：您的团队在沟通和生产力编码技能方面有多强？

5. 可用资源：您是否有足够的带宽来永久维护和扩展一个系统？

6. 您是否准备好了：您的团队是否有足够的专长和关系来使特定类型的项目成功？