数据科学团队领导指南-全-

数据科学团队领导指南（全）

原文：zh.annas-archive.org/md5/0049e7ab941adb9b191a34ead7211805

译者：飞龙

协议：CC BY-NC-SA 4.0

第一章：介绍

领导一个数据科学团队面临许多挑战。与组织的其他职能相比，数据科学往往具有高度的投机性。一个数据科学团队的领导者在项目进行到中途之前不会知道项目的结果如何。数据可能丢失，数据中可能没有信号，或者模型可能不切实际。有时候领导者不得不让他们的数据科学团队在项目定义清晰之前就开始工作。例如，一个项目将开始使用数据来找出“最佳”客户，而数据科学家还没有时间定义什么是最好的。一旦工作开始，领导者必须管理数据科学家，确保他们保持在正确的轨道上，并在出现意外情况时管理利益相关者关系。总之，数据科学团队不断被赋予更多的任务，并且常常需要超出他们处理能力的最后一刻必须交付的内容。这些问题只是数据科学领导者需要考虑的问题的冰山一角。

这份报告是一个思考数据科学领导者在运行团队时面临的问题的手册。它是一个参考，帮助思考团队当前的挑战或对未来情景保持积极的态度。它也是一个指南，适合那些尚未有机会领导团队但希望为将来可能领导团队做好准备的人。阅读这份报告应该能让你更好地理解团队可能面临的挑战类型，以及思考这些挑战所需的工具。

遗憾的是，这份报告并没有提供一个简单的清单，告诉你如何成功地领导一个数据科学团队，因为没有简单的答案。正如你在整份报告中会注意到的，大部分评论都会在某个时候说：“这取决于你的公司和团队。” 但是通过指出挑战，你应该能更好地为团队遇到这些问题做好准备。

第一章 讨论了谁应该加入数据科学团队。第二章 探讨了如何有效地管理团队的工作流程，以便处理数据科学团队可能处理的许多任务。第三章 讨论了数据科学领导必须考虑的一些技术基础设施决策。最后，第四章 讲述了如何帮助数据科学家提供价值。我们希望这个参考资料能帮助你有效管理当前团队或将来可能管理的团队。

第一章：选择您的数据科学团队

数据科学团队可以做的事情种类繁多，这既因为“数据科学”这个术语非常广泛，也因为不同的公司有非常不同的需求。数据科学可以意味着一个公司只有一个分析师为高管制作数据仪表板，也可以意味着一个团队为生产就绪的机器学习 API 创建。一个公司可能需要帮助使用数据来定义业务策略，为客户提供定制体验，预测投资，或者完全不同的其他事情！由于数据科学团队可能做的工作类型如此之多，因此有许多不同的方式来组建团队，以满足业务需求。本章介绍了如何思考您应该为团队招聘谁。

每个数据科学团队自然会有数据科学家，但除了数据科学家本身之外，团队还可以包括许多潜在的支持角色。在团队中增加更多职位可以使您拥有更广泛的能力范围，但也需要管理更多类型的工作。考虑到数据科学团队需要有效地工作，需要考虑以下所有事项：

制定一个愿景

设计一个策略，通过与利益相关者沟通他们的需求并评估团队的能力，确定数据科学家将要处理的工作。

项目管理

跟踪正在进行的工作并在时间线问题出现时进行沟通。

利益相关者管理

与利益相关者合作，帮助他们理解数据科学的能力，并找出数据科学的机会。

人员管理

通过绩效评估、反馈、支持和其他管理任务来帮助团队。

技术指导

帮助更年轻的数据科学家解决问题并解决技术障碍。

数据工程（可选）

将数据存放在数据科学家可以清理和使用的位置，并为模型和分析的输出存储位置。

软件工程（可选）

如有必要，编写调用数据科学家构建的模型的代码，例如显示模型结果给客户的用户界面和后端。

数据科学工作本身

这也确实很重要。

除了实际数据科学工作之外，还有很多任务——几乎没有工作是可选的！不仅如此，还有很多这些任务可以由不同角色的人完成。这为如何设计团队带来了数学匹配问题，如图 1-1 所示。

从图 1-1 我们可以看到如何满足数据科学团队的需求有许多可能性。例如，您可以选择雇用一位数据工程师来进行任何数据工程，或者让一位软件工程师既做软件工程，又做数据工程（后者可能会有些困难）。问题的复杂性增加了，因为不需要覆盖所有这些任务，您可以忽略一些任务，并希望您的团队能正常运行。总之，有许多可行的解决方案。因此，除了您的数据科学团队将拥有数据科学家之外，根据一些关键决策，如谁将领导团队，谁将管理项目，团队将有什么样的技术角色，以及您将有多少专业化，您可以选择多种不同的结构。

图 1-1. 设计数据科学团队的数学匹配问题示例。这是一个二部图，但组合数量留给读者作为练习。

您将如何分配领导风格的任务？

一个数据科学团队确实需要两种不同类型的领导——管理和技术。管理任务包括您通常与经理相关的任务。例如为团队创建战略，与利益相关者讨论需求，决定谁来雇用和晋升等等。技术领导则做出重大的技术决策，并帮助初级数据科学家。这些任务包括决定在重大项目中使用何种模型架构或指导初级数据科学家完成他们的第一个分析。

一个管理团队的选择是尝试让单个人承担这两种类型的领导工作。然而，通常很少有人具备同时胜任管理领导任务和技术领导任务的资质。即使数据科学团队确实有一个具备这两种技能的人，他们可能也会因为忙碌而无法完美地完成这两项任务。因此，让一个人承担所有任务是有风险的。

因此，一个团队的另一种选择是分为两个不同的角色，一个是经理，另一个是技术领导。经理负责所有管理任务，包括与利益相关者保持联系。技术领导提出最佳的技术解决方案供团队实施，并帮助指导团队。有两个高级人员是昂贵的，如果他们之间合作不好，可能会带来一系列问题，但如果能够协调一致，这是一个让两位领导者各展所长的好选择。

最后，数据科学团队可以选择只有一种类型的领导，并接受在管理方面会有所不足。一个有经理但没有技术领导的数据科学团队需要团队中的数据科学家能够在没有太多指导的情况下工作，这通常意味着需要雇佣更资深的数据科学家。一个有技术领导但没有经理的数据科学团队则需要相信公司其他领导仍在战略上有效地定位他们的团队。这两种选择都是可能的，但并非理想。如果数据科学团队规模较小，你可能需要选择这种选项，然后希望团队的其他成员填补空白。

如果你是一位领导正在阅读本报告，了解你的优势和劣势以及支持团队的最佳方式非常重要。如果你来自技术背景，并且真希望你的领导工作的一部分让你保持编码能力，那么请确保在管理组件上有强有力的支持。如果你在数据科学领域没有技术背景，请确保在雇佣数据科学家时，你的团队里有资深的人并且倾听他们的意见。在本报告的几乎任何其他部分中，问题“你将如何进行领导风格的任务？”都需要深入反省和愿意分享权力并进行协作。

你如何进行项目管理？

项目管理（组织团队需要完成的任务并确保按时完成）对于确保团队实际完成任务至关重要。除了保持工作本身的组织外，所有相关方必须随时了解和更新变更情况。无论是否有专人被明确指派为项目管理人员，总会有人在某种方式上做这件事。也许你有一个专门负责项目管理的人，或者一个数据科学家会创建一个任务的 Excel 表格，但团队中总会有人在做项目管理。

通常情况下，项目管理由同一人负责人员管理的人来完成。这是有道理的：负责团队管理和与利益相关者会面的人很适合同时跟踪任务完成情况并与他人沟通。不幸的是，经理通常会因为会议和自己的工作而非常忙碌，因此项目管理可能会因为忙碌而搁置，对整个团队都是不利的。让团队经理负责项目管理需要经理有很强的自律性，并且在团队规模较小时效果最好。

或者，您可以雇用一个人来负责项目管理（一个恰如其名的项目经理）。这样可以让经理专注于其他任务。项目经理可能有也可能没有技术背景。有技术背景使他们更容易理解数据科学任务和障碍，但非技术人员仍应能够与数据科学家进行足够的沟通，理解情况并提供帮助。

如果项目经理在团队中是一个完全独立的角色，那么项目经理具有组织影响力至关重要。项目经理将经常需要帮助数据科学家，例如前往组织的其他部门解决数据访问不足等障碍。项目经理还可能需要对数据科学家采取坚定的态度——比如告诉他们停止进行有趣但非关键的任务，而是完成当天需要的工作。如果项目经理在组织中具有影响力，这类情况将能够得到处理（虽然仍然很困难）。如果项目经理没有影响力，这是不可能的。一个有专门项目经理的团队可以做的最好的事情是支持项目经理，并尽可能听取他们的意见。

作为一个大团队的领导者，大约八人或更多，您几乎肯定需要雇佣一个单独的项目经理。作为一个小团队的领导者，少于五人，您可能没有预算，需要自己动手。如果您有一个项目经理，对团队来说最好的事情就是雇用合适的人，并赋予他们做好工作的能力。如果您自己负责，对团队来说最好的事情就是确保您始终保持与项目管理的步调。

第二章专注于团队数据科学工作的管理方法，这是做项目管理的人的主要关注点。该章节将更详细地讨论与利益相关者合作以及如何推动工作的进行。第三章讲述如何帮助数据科学家发挥最佳表现，包括帮助他们承担自己的项目管理工作。强大的项目管理对于成功运行团队非常重要。

您的数据科学团队是否有非数据科学技术角色？

在一些组织中，在数据科学团队中拥有非数据科学角色（如软件工程师或数据工程师）是有道理的。他们可以帮助为数据科学家组织数据，编写作为模型周围包装的代码等。通过在实际数据科学团队中拥有这些类型的人员，数据科学家将得到良好支持。在团队中拥有其他工程角色的缺点是可能需要做不一致的工作量。例如，有些周可能不需要任何数据工程工作，这些周内不清楚数据工程师应该做什么。还可能存在组织上的冗余。例如，如果数据科学团队有数据工程师，而数据工程团队有数据科学家，那么谁来做什么？

这种决定在很大程度上超出了数据科学团队本身的范围。如果您在一个以项目为中心的组织中，您的团队很可能会拥有多个角色。这些组织往往充满了许多不同专业的团队，他们紧密合作进行项目。如果您在一个以角色为中心的组织中，一个纯粹的数据科学团队更合理。以角色为基础的组织倾向于拥有像工程部门、数据科学部门等类型工作者的部门。

数据工程对于在团队中有非数据科学技术人员的情况尤为常见。在一些组织中，有专门负责存储数据并使其对其他团队可访问的整个数据工程团队，这种情况下，您的数据科学团队就不需要数据工程师了。在其他组织中，通常是规模较小的组织，没有专门的团队负责此事，因此维护数据库并保持其最新的责任可能会落在其他地方，比如可能是您的数据科学团队。但特别值得思考的是数据工程，因为如果没有某种数据后端，您的数据科学家将无法工作。有很多关于在公司雇用数据科学家后才意识到公司没有任何数据可供他们使用的故事。如果您选择在团队中没有数据工程师，请确保有一个基础设施供您的数据科学家获取所需的数据。

团队中的数据科学家是否应该专业化？

如果您的数据科学家们专注于特定领域，例如预测、实验和优化，理论上您应该能够作为一个团队实现更多，因为您将涵盖更多的知识领域。另一方面，如果您团队中的每个人都是数据科学通才，那么分配给数据科学团队的任何工作都可以由团队的任何成员完成，您将拥有一个更强大的团队。通才团队将能够更好地审查彼此的工作，处理队友休假或离职，并在项目需要额外帮助时提供支持。这样一来，就在专业化团队能够完成更多任务与通才团队运行更加顺畅之间形成了一种博弈关系。

还有不同类型的专业化：

• 如预测、实验和优化等技术主题

• 如欺诈、营销和物流等领域

• 公司的特定部分，例如特定数据集

根据组织的情况，某些类型的专业化可能几乎没有风险。对于营销公司来说，拥有专家级别的数据科学家可能没问题。但是，在业务内的特定技术主题或数据集上进行专业化可能会导致更多情况下数据科学家没有足够的工作可做。

作为一种实践，其他条件相同的情况下，泛化可能更好。在日常运作中，您的数据科学团队成功与否取决于其运行的顺畅程度，而不是团队了解多少不常见的技术（详见第四章对此的更深入讨论）。此外，您的数据科学家们会自然而然地专注于自己的领域。数据科学家们喜欢学习新事物，因此，如果项目需要数据科学家们不熟悉的概念和方法，他们会去学习。您不需要整个团队都围绕只有某些人知道如何做某些事情来进行组织。

话虽如此，有些情况需要如此精细的技巧，您将希望专家来完成。一个典型的例子是优化和强化学习，这通常不包括在标准数据科学课程中，并且需要一段时间学习。随着数据科学团队规模的扩大，您会发现越来越多的情况下，您会感到有义务组织团队，以使一些人在他们的专业领域担任角色。但尽可能地避免这种情况，并且如果您雇佣了某个领域的专家，请不要只雇佣一个。一个单一的专家没有人可以讨论他们的想法，更糟的是，没有人可以检查他们所做的是否符合他们所说的。

如你所见，有无数种方法可以组织数据科学团队。并没有一种通用正确的方式；这在很大程度上取决于公司环境的具体情况。有些情况可能需要一个大型的专家团队为整个公司服务，而其他情况则要求数据科学家分散在各处。数据科学团队可能很大，拥有许多角色，如经理、项目经理和数据工程师，或者可能很小，只有几名数据科学家和一个技术领导者。一个优秀的数据科学领导者的角色是理解组织的背景，并为团队在其中做出最佳决策。

有了一个设计良好的数据科学团队，数据科学家们应该准备好处理来自利益相关者的工作。不幸的是，对于大多数数据科学团队来说，他们要完成的可交付工作的需求量远远超出了团队的能力。在下一章中，我们将讨论数据科学团队如何管理他们的工作流程，并战略性地考虑要做的工作类型。

第二章：管理工作。

数据科学团队非常忙碌。不断有新报告、新模型和以新数据重做的过去分析的请求。对于大多数数据科学领导者来说，这意味着必须要做出周到的决策，决定实际工作和次要工作或完全不做的事情。这也使得管理任务完成所需时间非常重要，因为如果某个任务花费的时间超出预期，其他事情就不得不推迟。

要成功管理您团队的工作量，首先需要非常清晰地了解您团队的目标是什么。您是通过机器学习帮助改进产品，还是向特定部门提供数据策略建议，亦或是其他？然后，您需要一个清晰的项目管理流程来跟踪工作进展，虽然数据科学与软件工程相似，但是某些软件工程原则，比如敏捷开发，并不总是直接适用于数据科学。您还需要与利益相关者进行清晰的沟通，这样当新的进展出现时，每个人都有所需的信息。

管理数据科学团队工作的任务必须成为各种规模团队中数据科学领导者关注的问题。在较小的团队中，领导者可能直接负责项目管理任务。在较大的团队中，会有一个项目经理负责管理任务。但作为数据科学领导者，您仍然负责确保工作得以完成，一旦出现问题，解决责任也将落在您身上。因此，本章阐述了如何考虑管理数据科学团队任务以及保持团队顺利运行的最佳实践。

您团队的目标是什么？

在您能有效地优先处理要做的工作之前，您需要充分理解您团队的目标。由于您将会收到来自多个方向的许多请求，因此您需要专注于与您的目标一致的内容，并且放弃其他请求。数据科学团队的目标通常可以分为三类：

帮助组织利用数据做出决策。

当团队的目标是这个时，将会对数据进行大量分析，并将其呈现给利益相关者。

将数据作为产品的一部分来改进它。

这些数据科学团队帮助训练机器学习模型并投入生产。

保持组织内部数据流动。

为了达到这个目标，数据科学团队帮助将数据从数据库移动到报告、仪表板和其他业务可以使用的地方。

每一个这些目标都需要非常不同类型的工作：决策科学、机器学习和数据工程，分别来解决。数据科学团队的最佳情况是他们专注于这些目标中的一个，并在组织的一个特定部分（如营销）提供帮助。实际上，您会发现您的团队经常被吸引去完成多个目标，无论是来自外部利益相关者的未满足需求，还是出于您希望团队在新的领域带来数据的愿望。但是除非您的数据科学团队非常庞大，拥有许多数据科学家和经理，否则您可能无法做到这一点。

作为领导者，您的责任是使团队专注于一个非常具体的目标，并避免分散注意力。通过有效地说不，您可以避免让数据科学家因无法有效完成各种不同类型的工作而不知所措。

优先考虑数据科学工作

作为数据科学负责人，很难平衡要处理的工作，不仅因为不是所有的工作都与您的目标一致，而且因为每个任务的努力程度、范围和有助益的利益相关者可能都非常不同。在优先考虑每项任务时，一个有用的框架是考虑这三个问题：

这项工作的结果可能会对业务产生多大影响？

某些任务可能会极大地改变业务，比如将机器学习应用于产品，以便客户可以以新方式与产品交互。某些任务可能不会对业务产生太大影响。即使您能够完美地预测市场渠道的收入，这种预测也不太可能显著改变您的业务。有趣的是，关于工作的价值将带来多少这个问题并不是一个数据科学问题——它与您如何从产品角度思考任务无关。相反，思考价值将需要您作为数据科学负责人可能要走出舒适区并从产品的角度进行思考。

数据科学团队能够完成这项工作的可能性有多大？

本报告中反复提到的一个主题是，数据科学项目存在很大风险，并且在很多方面都会失败。在启动项目之前，作为数据科学负责人，您认为项目成功的可能性有多大非常重要。最好是与首席数据科学家共同合作进行这样的猜测。对项目可能运行得如何有一个相对合理的想法将有助于您决定是否值得进行。不同的数据科学项目面临的风险范围可能非常广泛：更新现有报告可能成功的机会很高，而在新数据上构建全新的机器学习模型以用于新产品则可能成功的机会较小。

这将给您的数据科学家带来多少快乐？

作为数据科学领导者，您是为了长远游戏，有些任务对数据科学家来说比其他任务更有趣（一般来说，使用全新方法构建新模型比第一百次重新训练同一模型更有趣）。在理想情况下，您团队正在处理的任务与数据科学家特别被聘用来做的工作类型及其特别的兴趣相匹配。并非所有工作都会成为数据科学家的梦想，但如果没有一项工作能够满足他们，那么您就可能面临人员流失的风险。

参见表 2-1，了解不同项目可能得分的一些示例。有趣的是，这三个问题通常高度相关（或者反相关）。在某些情况下，某件事对业务的影响可能与其实现的可能性呈现反向相关。例如，许多利益相关者向数据科学团队提出了一些不切实际的项目（比如使用机器学习预测顾客走进店铺前会点什么口味的冰淇淋！），这些项目可能具有潜在价值，但很可能无法实现。那些很可能会成功的任务可能并不具备价值。这通常是因为大多数可以轻松完成并具有巨大影响的任务已经被尝试过了！

表 2-1. 数据科学项目示例及其优先考虑因素

项目	对业务的影响	实现的可能性	数据科学团队的喜悦
构建一个新的复杂异常检测模型，以发现顾客行为中任何微小的趋势	高：可以降低客户支持成本	低：具有微小信号的异常检测模型通常太嘈杂而无法正常工作	高：构建复杂模型既有趣又具有挑战性
自动化业务使用的手动报告到仪表板	低：由于报告已存在，主要价值在于节省员工时间	高：由于报告中已有数据，仪表板不工作的风险较低	低：需要重新做现有工作，且长期维护成本高
将自然语言处理添加到产品的现有部分，以便分类客户输入	中等：分类输入可能有所帮助，但不会立即改变整个产品	中等：如果您能成功设计一个相关的分类集，NLP 分类模型通常效果很好	中等：需要开发新模型，尽管是相当直接的模型

同样，对于数据科学家来说，通常全新的项目最有趣，但成功的机会最小。全新的项目如果足够有趣，甚至可以后续做一个会议发言！然而，仅仅尝试“月球登陆”项目可能并不适合商业发展。

因此，当任务进来时，请尽可能选择那些符合这些条件的任务，并避免过长时间没有能推动业务前进、成功机会较高并使员工满意的任务。

管理工作队列

任务进来时，您需要深思熟虑地跟踪工作队列及当前处理的事务。如果幸运的话，您的团队可能会有一个专人负责管理这个队列——即来自第一章的项目经理。否则，这可能会成为您作为团队领导的职责。

您的组织很可能已经选择了诸如 Jira、ClickUp 或 Trello 等项目管理工具。这些工具能跟踪当前正在进行的工作、即将进行的工作以及任务完成情况。如果您的组织尚未选择预设工具，您应该迅速选择一款，并让整个团队习惯于审查和更新任务板。虽然项目经理（或您）可能负责维护，但整个团队仍需要编辑每个任务的状态，以便在处理任务时进行更新。数据科学团队常常会遇到个别数据科学家分心，未能认真更新项目管理工具中的信息的问题。然而，您可以建立重视工具使用的文化。每次开始、完成或遇到障碍时，都应更新工具。如果能在任务开始、结束等讨论中保留所有信息，效果会更好。

您的数据科学家也会收到您可能不知道的任务，例如利益相关者直接提出的最后一分钟的新分析请求。他们还可能收到修复先前交付工作中问题的任务，例如在生产模型中发现的错误。如果您已经建立了与项目管理工具保持组织有序的文化，那么该工具将成为记录正在进行的工作（以及为何其他任务未被处理）的工具。这对于利益相关者询问为何任务未完成以及为您的数据科学家提供工作凭据将是有价值的。

与利益相关者沟通

管理来自利益相关者的工作的一部分是管理与他们自身的关系。数据科学团队通常与公司许多其他部门有联系：负责实施数据科学模型的工程师、利用数据运行广告系列的营销人员、为团队设置数据库的数据管理员等。负责数据科学团队的人必须确保这些人对团队的表现感到满意（或多或少）。

当你负责一个数据科学团队时，利益相关者会带着各种请求、信息和需求来找你。重要的不仅仅是有效地优先考虑这些请求，正如前面讨论的那样，还要确保数据科学团队的成员获得适当的信息。在一个成功的数据科学团队中，利益相关者会感到与数据科学家直接联系，并且在有问题时感到可以直接找你，就像数据科学家在与利益相关者有问题时找你一样。

如果利益相关者和数据科学家之间没有健康的沟通，可能会出现几种情况。首先，利益相关者可能决定不再与团队中的数据科学家交流，而直接与你作为领导者交流。作为领导者，这可能会让你感觉很好 —— 经常听取利益相关者的意见，了解他们的需求。但这会导致你成为信息的瓶颈，因为只有你掌握了整个团队所需的信息。

举个例子，一个利益相关者需要一个机器学习模型来预测哪些客户可能会取消订阅服务。这个利益相关者可能对模型有非常精确的要求 —— 它需要有多准确、需要处理哪些类型的客户等等。这些要求需要转化为数据科学的概念；比如，“必须始终给客户正确的答案”转化为特定的准确度指标。如果利益相关者只是告诉你这些，那么你作为领导者将很难向团队解释这个想法，并回答团队可能有的具体问题。在这种情况下，你成了信息的瓶颈，或者用一个类比来说，你成了电话游戏中的一个连接，而你的团队是最后一个人。

这会导致数据科学团队出现沟通问题的另一种情况。如果数据科学家或利益相关者觉得你是一个瓶颈，他们可能会绕过你，不告知你。在前面的例子中，如果利益相关者和数据科学家意识到直接交流更为方便，他们可能会开始这样做，你可能会发现决策被做出而不知情。虽然赋予数据科学家权力通常是好事，但作为领导者，你对整个团队如何运作有最佳的视角，你需要了解正在发生的事情。这两种情况都在图 2-1 中显示。

图 2-1. 与利益相关者的沟通可能出现的几种情况示例。

当你与利益相关者合作并满足他们的需求时，请确保在你自己、你的团队和利益相关者之间保持良好的沟通。当你注意到有人缺少他们应该拥有的信息（而你可能拥有），请努力加强与特定利益相关者以及与他们合作的团队成员的关系。

在你制定管理团队工作负载的方法时，你需要确保你的数据科学家们能够产生价值并成功完成你分配的任务。本报告的下一章将详细介绍如何与你需要完成的工作对齐你的数据科学家，并领导他们执行工作的最佳实践。

第三章：运行一个提供价值的团队

虽然这几乎是老生常谈，但是你的数据科学团队的成功完全取决于团队成员能够多好地履行他们的角色。你的团队成员有清晰、可实现的目标和执行这些目标所需的资源，这比你选择用什么技术执行代码或选择训练什么类型的模型更重要。数据科学家有各种不同的背景和思维方式。作为领导者，你的工作是创造一个数据科学家可以成功的环境。世界上有成千上万本关于如何管理人员的书籍，因此，本章将侧重于具体领导数据科学家的细节，而不仅仅提供管理的指导。

作为数据科学的领导者，你希望你的数据科学家能为团队和组织贡献价值。价值是一个难以定义的术语，因为在数据科学中它可能是如此抽象并且与投入的工作量毫无关联。一个花费五分钟制作的数据汇总图表，可能比一个团队花几个月开发的复杂机器学习模型对组织更有价值。因此，让我们明确定义贡献价值。

如果一个数据科学家正在创建和完成代码、报告或其他交付物，那么他们就为团队贡献了价值：

• 解决请求的任务

• 易于维护

• 开发速度快

在这样做的同时，数据科学家应该：

• 在问题出现时及时沟通问题和关注点

• 促进一个健康的工作环境

在这个贡献的定义中包含了很多内容，但它相当全面：任何符合这些标准的数据科学家大概率上都在完成他们的工作。但是这个定义想要达到却是异常困难的！在本章中，我们将其分解为其核心组成部分，并讨论作为数据科学领导者你可以做些什么来帮助你的团队贡献价值。

解决请求的任务是很难的

通常，数据科学家会收到抽象的业务目标，例如“使用数据找出为何新客户增长下降”或“使用机器学习预测客户是否会使用优惠券”。这些都是业务目标，完成这些任务将有助于业务发展，但它们并未提供明确的数据科学步骤来实现。在第一个示例中，“新客户增长”可能有很多不同的定义方式——您可以使用注册新账户的人数或者第一次购买作为定义。在这些数据上进行分析的方法也有更多种。对于数据科学家来说，哪种方法最佳并不明显，而不同类型的分析对业务都有利弊。例如，时间序列分析方法可能能更准确地理解新客户增长何时下降，但对导致新客户增长减少的因素理解则较少。

没有整体业务的背景信息，对于数据科学家来说，如何将模糊的业务请求转化为可解决的数据科学问题是困难的，进而向业务提供答案。在第二个示例中，当数据科学家被告知“使用机器学习预测客户是否会使用优惠券”时，可能甚至不能有效地使用机器学习。公司对客户的数据，如过往购买记录和人口统计信息，可能无法预测他们是否会使用优惠券。或者可能是数据分布在太多不同的 IT 系统上，无法创建训练数据。在这些情况下，困难的不是请求的模糊性，而是请求本身可能无法解决。

有很多原因可能导致数据科学家无法按要求完成请求，包括：

• 利益相关者不理解自己的需求，因此请求定义不明确。

• 利益相关者的请求定义明确，但无法通过数据解决。

• 请求可以通过数据解决，但组织中没有可用的数据。

• 数据太嘈杂，无法派上用场。

• 数据提供的答案与组织内政治趋势相悖，分享可能会带来灾难。

作为领导者，解决这些情况是您的工作。您是在请求模糊询问和数据科学家实际能够实现之间架起桥梁的人。您应确保数据科学家充分了解利益相关者真正需要什么，同时您应了解数据科学团队能够处理的范围。

当遇到不明确或无法解决的任务时，您可以采取一些特定措施。在利益相关者的任务不明确或定义不清的情况下，您可以直接与利益相关者合作，更好地定义任务，同时保持数据科学家的参与。团队的领导通常比个人贡献者更适合进行这些对话，因为领导更了解组织的整体目标和可以进行调整的地方。确保您还包括正在进行工作的数据科学家在讨论中，因为您最不希望的是与利益相关者谈判任务，结果发现您提出的解决方案对数据科学家仍然过于模糊。

同样，在任务定义明确但数据科学家发现无法执行因为数据不可用、过于嘈杂或模型没有信号的情况下，您可以与数据科学家合作，尝试和他们共同探讨替代解决方案。有时，领导与数据科学家的对话有助于您决定其他数据集是否足够好，替代建模方法是否可行，甚至是否可以通过执行其他类型的数据科学任务（例如，从使用机器学习模型切换到简单的基于规则的方法）完全绕过任务。您的视角在这里可能非常有帮助，因为您可以帮助数据科学家超越他们当前的视角。

通过帮助数据科学家迅速应对这些情况，并决定正确的解决方案，您可以避免做出不提供价值的事情。

让交付物易于维护很难

当数据科学家创建分析、机器学习模型、仪表板、代码包或几乎任何东西时，他们正在创建一个交付物。作为工作的一部分，有一种理解：这个交付物将存在于被创建的那一刻之后。有时这是明确的：期望仪表板被持续查看，期望机器学习模型以类似的准确性重新运行。有时这是隐含的：可能高管曾要求一次性的分析，但高管可能会定期审查结果，甚至要求使用新数据进行更新。

因此，交付物本身必须被维护（仪表板始终保持运行状态，模型必须保持一致的准确性），创建交付物的方法也必须被维护（分析的代码需要保存，以防有人对其运行方式有疑问）。数据科学家有责任确保他们创建的交付物能够由未来的人维护和调整（这可能包括但不限于数据科学家自己）。

还有许多简单的步骤可以帮助解决这个问题，比如编写良好的文档、将代码保存在具有版本控制的共享位置而不仅仅是在数据科学家的笔记本上，并创建一个集中的目录，用于存放不同的交付物。这些特定的例子通常需要比较少的时间就可以完成，并且可以在不改变交付物创建方式的情况下完成。然而，数据科学家经常会在这些地方取捷径，以便更快地完成交付物。作为领导者，您的工作是帮助数据科学家平衡快速完成任务和确保可维护性之间的需要。

还有许多非常重要的步骤可以使交付物易于维护，但并不容易实现。例如，编写有逻辑结构的代码，每个段落都封装了工作的一小部分，这样可以使未来的数据科学家更容易维护。模块化的代码还可以更容易地在其他情况下重复使用。代码还应该具有清晰的日志记录和输出，以便在运行时明确发生了什么。编写清晰和逻辑结构的代码是一种需要多年实践的技能，因此这并不容易实现。数据科学领导者要求“写出更好的代码”的命令不会帮助数据科学家；相反，这需要技术指导和一个数据科学家相互审阅代码并提供有意义反馈的文化。

另一种交付物难以维护的方式是数据科学家用来创建它的技术工具。一个由多个 GPU 组成的集群训练复杂的神经网络可能比在笔记本上运行简单的逻辑回归模型提供更准确的模型，但是对于下一个数据科学家来说，重新创建用于训练神经网络的 GPU 集群将会比仅仅导入一个回归库要困难得多。数据科学家有责任在使用最强大（和有趣！）的工具与能以更简单方式获得结果的工具之间取得平衡。不幸的是，数据科学家经常不能完全理解为何要创建模型的全部背景，尤其是如果那位数据科学家正在 Twitter 上阅读关于新酷高级技术的文章时，更是如此。作为数据科学的领导者，您有责任引导数据科学家朝着可维护的解决方案前进，并在最先进解决方案和最易维护解决方案之间取得平衡。

无论是好是坏，最终受到不可维护交付成果影响最大的是你，数据科学的领导者。如果数据科学家没有努力确保他们的代码和输出易于维护，随着时间的推移，您会发现团队的输出变得越来越慢。如果大部分先前的工作必须完全重做，那么诸如使用新数据重新运行过去分析这样的请求将会比您预期的花费更长时间。不可维护的代码和交付成果是技术债务的一种形式，作为领导者，您需要密切关注这一点。

快速交付成果很难

相较于其他领域，如软件工程，在数据科学中很难确定什么时候算是“完成”。在大多数情况下，“完成”没有明确的定义：模型中的特征总是可以进一步调整，分析可以以新的方式切片数据，总是有另一个可能的机器学习框架可以尝试。尽管如此，为了使数据科学工作有用，必须将其交付给利益相关者使用，而且越快越好。数据科学家必须负责平衡完成任务的速度和完成任务的质量。

更糟糕的是，利益相关者希望的结果可能不明确且难以实现。如果数据科学家的任务是创建一个预测客户是否会使用优惠券的模型，而数据科学家尝试过的每个模型都无法工作，那么数据科学家如何知道再试一次是否有效，或者任何模型是否永远不会在这些数据上工作？数据科学家的工作就是不断尝试各种方法，但他们无法知道哪种方法会有效。

因此，数据科学家必须在“让我们尝试更多方法”和“这已经足够了，让我们快速交付”之间取得平衡，尽管他们并不知道更多的尝试是否会更好，甚至不知道什么是足够好。这真的很难！

有几个核心教训可以帮助数据科学家解决这种紧张局势，并在合理的时间内实际交付结果。首先，诸如直接回归之类的简单技术迭代速度要快得多，并且可以迅速地得到结果。此外，如果像回归这样的简单技术不起作用，那么复杂的方法（如在一组 GPU 上训练的神经网络）也不太可能起作用。因此，对于数据科学家来说，最佳实践是从简单技术开始，如果有效，则交付给利益相关者；如果不起作用，则考虑尝试更复杂的方法。此外，简单的方法更容易维护。请注意，在某些情况下，例如图像处理，可能需要更复杂的方法，这时您的团队强大的技术堆栈可以帮助更快地交付结果（参见第四章）。

下一课，我们已经讨论过的，是如果您对目标有清晰的理解，那么快速完成数据科学工作就会更容易。如果数据科学家不清楚工作的目标是什么，那么他们可能会花费数周的时间来切分和分析数据，寻找任何洞察或模型。业务目标对数据科学家的清晰度以及他们的目标越明确，数据科学家就越有可能遵循时间表，不会浪费时间在没有价值的工作上。

另一个教训是沟通越多，按时交付工作就越容易。如果数据科学工作花费的时间比预期的长，与利益相关者就时间表意味着什么进行的对话，可以帮助利益相关者决定是否应继续或更改工作。这避免了利益相关者对事情花费的时间感到措手不及或感觉被排除在外的情况。

注

这一部分特别涉及到最小可行产品（MVP）的概念——完成所需任务的最简单方法。通过创建一个 MVP，您可以快速推出产品并根据接收到的反馈进行迭代。一个好的数据科学成果应该是 MVP 的一种形式：它应该按照要求完成，而不要过多地添加。这很重要，因为在进行数据科学工作时很容易增加范围，试图挤入新的分析或模型工作方式的属性。

作为数据科学领导者，您的工作是确保数据科学家根据项目的时间表交付工作。这意味着在时间表面临风险时与数据科学家和利益相关者进行沟通，以及帮助决定在项目中投资时间的地方，而不是决定停止部分工作。

实际上，数据科学领导者应该不断监控工作的进展方式。由于数据科学项目的短暂性质，这可能相当困难。例如，您可能会遇到每天早晨问数据科学家工作进展如何，而每天早晨他们都会说，“我还在为模型选择特征。”很难知道在哪一点上，这种特征选择的接受程度从一个可接受的程度变成了项目无法按时完成的一个迹象。鉴于这些情况，领导者可以通过与数据科学家合作帮助他们充分了解时间表，以便他们自己知道何时似乎事情进行得太慢。作为领导者，您必须找到一个平衡点，在这个平衡点上，数据科学家感觉他们理解了可用的时间量以及您对他们的期望，而不会感觉您在告诉他们如何完成工作。这在很大程度上是建立在彼此之间持续沟通的信任基础上的功能。

数据科学家应该沟通问题和关注点。

要让数据科学团队成功，数据科学家需要在问题出现时能够进行有效沟通。数据科学项目经常出现问题——从小问题如库不兼容到重要数据缺失等。数据科学家需要能够有效地标记这些情况，并告知利益相关者和领导层。同样，如果领导层或利益相关者发现问题正在出现，他们也应该能够有效地传达这一点。

数据科学家和利益相关者经常因为人们倾向于“踩界”而在沟通问题上遇到麻烦。如果利益相关者感觉自己应该提供技术指导，比如要求数据科学团队使用特定类型的模型，那么他们对项目可能构成危险。数据科学家几乎总是技术解决方案的专家，一个过于具体的利益相关者提出技术要求会限制数据科学家能够提供的解决方案。另一方面，数据科学家可能会对业务运营方式的观点过于具体。数据科学家应该提供技术专业知识和业务的一般建议，但最终选择如何处理数据科学家应由利益相关者负责。数据科学家和利益相关者需要共同努力解决问题，而不是试图控制其中的一组人。

这个问题的出现是因为利益相关者忽视了数据科学家的顾虑，反之亦然。一个利益相关者可能会轻易地忽视数据科学家的担忧，即利益相关者对于数据科学产品的想法不可行，因为数学或数据无法支持。另一方面，数据科学团队可能会花几个月时间构建一个复杂模型，而没有与利益相关者核对业务是否有用。

所有这些的重点是，无论你的数据科学团队技术上有多么熟练，他们与涉及的利益相关者沟通问题的能力对于提供有价值的工作至关重要。作为领导者，培养健康的沟通可能非常具有挑战性。你需要向数据科学家表明，当问题被提出时，他们不会受到负面惩罚，并且你需要创造一个团队成员感到心理安全的文化。一个创建这种文化的好例子是无责后事审查会议；也就是说，发生问题后开会，可以公开讨论问题而不归咎于人。另一个有用的方法是展示自己的脆弱性——如果作为领导者展示自己的脆弱性，那么其他人通常也会开始展示脆弱性。

促进健康的工作环境

数据科学家不仅需要持续交付成功的工作，还需要帮助创造一个让团队成员能够茁壮成长并鼓励利益相关者与他们合作的文化。没有健康的工作环境和以团队为中心的文化，即使是一个完美的机器学习模型或出色的分析也无法获得周围生态系统的支持。这意味着：

数据科学团队应该互相支持

数据科学家应该共同参与项目，审核彼此的代码，并听取反馈。资深数据科学家应该花时间指导初级数据科学家。与此同时，资深数据科学家也应该对反馈保持开放，并倾听初级数据科学家的意见。

数据科学家应该与您交谈

数据科学家应该能够向他们的领导表达关注和机会，并使他们的关注得到重视。在组织中担任数据科学领导者可以让您看到更大的画面并为您提供比个人贡献者更多的背景信息，但每个数据科学家都在实际工作中，并能看到您可能会忽视的细节。

数据科学家有责任帮助整个团队取得成功，而不仅仅是他们自己。作为数据科学领导者，您有责任为团队成员提供支持，不要强迫他们过于专注于个人交付任务，从而忽视这些任务的完成。您还有责任管理外部利益相关者和数据科学团队之外的人，利用您作为领导者的影响力。

综合起来

因此，正如您所见，让您的数据科学团队提供实际价值涉及许多不同的因素。作为数据科学领导者，密切关注提供价值的各个组成部分并为团队提供所需的支持很可能是您日常工作中的主要任务！作为领导者，您有能力创建一种文化，保持利益相关者的信息流并促进以最小的技术债务创建有价值的交付物，以便让数据科学家感到可以沟通。实现这一目标的最佳方式是通过专注于团队，注意到数据科学家何时面临困难和繁荣，并在适当时介入。如果您发现您的数据科学团队目前存在忽视这些原则的文化，而是遵循“只做您被告知的事情并保持安静”的文化，通过自己树立榜样仍然有可能扭转局面。

拥有强大文化和执行能力的数据科学团队的下一步考虑是如何管理团队与利益相关者的关系。在下一章中，我们将讨论作为数据科学领导者如何与多种类型的利益相关者合作。

第四章：选择技术基础设施

因此，您的团队在组织中位置良好，并且有合适的人员。您正在努力创建提供价值的强大文化，并且有管理任务的方法。但是，这些任务要求您的数据科学家进行技术工作，这意味着他们需要相应的工具。这些工具包括如何选择编程语言（R、Python 或其他语言）；选择存储信息的数据库类型；模型是否应由工程团队部署为 API 或由数据科学团队作为批处理脚本运行；等等。数据科学领导者必须在选择团队应使用的技术和决定何时在它们之间切换方面发挥重要作用。

如何在技术基础设施上做出决策

关于团队技术基础设施做出决策的实际过程和实际决策同样重要。数据科学团队的领导者可以直接做出这些决策，或者可能是团队中的某个人，如技术负责人或主要数据科学家最终决定。在任何这些决策中，都存在决策方式的各种选择（见图 4-1）。在谱系的一端是专制主义，即团队内所有决策完全由负责人做出。在另一端是无政府主义，即团队中的任何人可以做出他们个人认为最好的决策的想法。

图 4-1. 每个数据科学团队所处的决策谱系。

数据科学家通常喜欢做决策，因为他们会选择他们个人最喜欢的东西。在无政府状态的环境中，数据科学家将精确选择他们喜欢的工具，因此您可能会最终拥有一个由五个人组成的数据科学团队和一个使用六种编程语言编写的代码库（其中两种语言已经不再使用）。每个数据科学家都会对他们的工具集感到满意，但数据科学家们无法共同工作。如果一个代码库在 AWS EC2 实例上使用 Python，而另一个在 Windows 笔记本电脑上使用 MATLAB，那么当数据科学家切换项目或离开团队时，您将陷入困境。但只要每个数据科学家只在自己的项目上工作，他们就会足够满意。

另一方面，在专制环境中所有决策都由领导层做出。编程语言、平台、架构以及其他技术决策都由领导层统一团队内的情况。例如，每个人使用 R，致力于非常具体格式的 GitHub 存储库，以相同的风格编写他们的代码，并以相同方式执行项目。在这些情况下，数据科学团队变动很少。每个人都可以在其他人的项目上工作，并且由于一切都是一致的，维护的基础设施更少。

问题在于，无论领导选择了什么团队范围的工具，总会有一些情况它们效果不佳。有时候在 R 中很难做到的事情，在 Python 中很容易，或者在虚拟机上进行数据科学时很困难，但在使用 Docker 时很简单。在这些情况下，如果不允许你的数据科学家使用合适的工具来处理问题，他们可能会在手头的任务上花费更多的时间和精力。更糟糕的是，他们会很快失去斗志，可能会离开团队。详见 表 4-1 中关于技术决策的一些示例。

表 4-1. 技术决策示例情景

情景	风格
数据科学家被提供笔记本电脑，可以使用他们想要的任何工具集和编程语言，只要他们完成了分配的工作。	极端无政府主义
数据科学家可以在他们的笔记本电脑上使用他们想要的编程语言和库，但鼓励他们尽可能使用与现有云平台对齐的工具。	倾向于无政府主义
数据科学家需要使用云基础设施、Python 和一组特定的机器学习库。其他工具可以使用，但需要首先得到技术领导的批准。	倾向于专制主义
数据科学家必须仅使用技术领导、经理和 DevOps 批准的确切工具集。	极端专制主义

因此，无政府主义和专制主义的两个极端都不是数据科学团队应该处于的良好位置。健康的状态应该在中间某处，在这里，数据科学领导与数据科学家合作，确保在工作中使用合适的工具，同时尽量减少使用不同工具和不兼容系统的数量。最佳位置确切地在哪里取决于特定的组织及其目标。它也很大程度上取决于特定的行业。例如，做许多一次性项目的咨询公司应该有较少的严格结构，而像金融这样受到严格监管的行业则应该有更多的防护措施。

作为数据科学领导者，你很容易看到这种情况的各个方面并指出你希望达到的位置。作为领导者，你可以更轻松地通过更多的权威来管理团队，因此你可能希望团队轻微地威权化。但值得反思的是，要考虑团队中具体数据科学家的优势和劣势，并尽可能给予他们足够的自主权。

数据科学团队基础设施的组成部分

数据科学团队需要大量不同的基础设施系统，其中一些是专门为他们建造或购买的，比如数据库解决方案，另一些则是团队自行决定的，比如使用特定编程语言和一组库建立 Git 仓库。本节涵盖了几个重要的基础设施领域需要考虑的内容。

数据存储

大多数数据科学团队不需要担心从哪里存储原始数据，因为他们可以从组织的其他部门获取。其他部门创建包含营销信息、销售和收入数据以及产品直接数据的数据，并且工程师将其存储在数据库中供数据科学家使用。数据科学团队可能能够影响一些数据存储的决策，比如要求包含某些列，但很少负责实际的存储工作。

然而，数据科学团队确实需要存储中间或输出数据——已经清理或从模型输出且由数据科学团队自己拥有的数据。中间数据的一个例子是在字符串列格式化后生成的大型数据表，或者要添加到模型中的新特征。输出数据的一个例子是数据集中每个客户的模型预测。这些类型的数据集往往没有固定的模式，并且可能非常庞大。大多数情况下，数据科学团队并没有数据服务器的所有权，因此他们可能无法自己获取存储位置，需要其他团队的帮助。

在理想情况下，数据科学团队的中间和输出数据应该与输入数据存储在相近的位置。如果所有数据存储在单一位置，那么很容易将其联合起来进行进一步分析并跟踪变更。但实际操作中，有时这是不可能的；例如，如果输入数据是需要存储在数据科学家无法写入的安全服务器上的生产数据。在这些情况下，你需要设置一个不同的位置来存储数据，并创建管理这些数据的流程。

作为中间和输出数据的创建者，您将负责跟踪它。这就是数据治理实践的重要性所在。您需要制定一种结构来决定存储哪些数据以及如何一致地存储它们。您需要以一种方式做到这一点，以便将来人们能够理解所做的工作。一个完整的数据工程团队可能会为他们的数据建立数据仓库或数据集市，但由于这不是您的主要关注点，您可能不需要走得那么远。

作为团队领导，您需要深思熟虑如何最好地存储这些数据以及如何随着时间跟踪它。如果您没有仔细考虑，那么数据可能会分散在许多位置，例如多个数据库服务器、共享网络驱动器和文件存储系统，并且您将无法跟踪它。更糟糕的是，随着时间的推移，其他系统将开始依赖这些数据——例如，使用模型的客户预测来调整电子邮件活动的过程——如果数据没有被正确存储，那么在使用它时可能会产生技术债务。

运行分析和训练模型的工作空间

数据科学家的日常工作主要包括清洗数据、进行分析、训练模型等各种工作，这些都发生在同一个地方。这些数据科学工作场所的形式各异，取决于数据科学团队的设置：

每个数据科学家都在公司拥有的笔记本电脑上工作

对于许多公司来说，数据科学家在公司拥有的笔记本电脑上进行日常工作，使用他们选择的集成开发环境，如 RStudio 或 JupyterLab。数据科学家会将数据下载到这台机器上，进行工作，然后将结果上传到共享位置。使用笔记本电脑的好处在于它们几乎不需要协作设置——每个数据科学家可以独立安装他们想要的任何东西，并使用。但也存在标准化的问题：任何人都可以做任何他们想做的事情，因此对于一个数据科学家可以运行的代码，可能在另一个队友的笔记本电脑上无法运行。由于每台机器的设置都不同，通常团队中的高级员工必须在初级员工因其不寻常的设置而导致问题时提供帮助。数据科学家在硬件方面也受到机器规格的限制，因此如果特定的分析需要不同的东西，那么这种分析就无法完成。此外，笔记本电脑被物理盗窃的安全风险也存在。

数据科学家在云中的虚拟机上工作

一些数据科学团队通过将笔记本电脑替换为像 AWS EC2 实例或 Google Cloud Platform VMs 这样的虚拟机来改进第一种情况。这使得数据科学家可以根据不同的硬件需求更改实例大小，并消除了笔记本电脑被盗的可能性。不足之处在于机器的标准化仍可能完全缺失，所以就像笔记本电脑一样，在一个虚拟机上有效的东西可能在另一个上无法运行。此外，虚拟机开放在网络外也存在安全风险：因为每个数据科学家都设置他们的机器，有相当大的机会有人设置错误。

共享云工作平台

最近，数据科学团队开始采用专为数据科学家量身定制的云平台。这些平台，如 AWS SageMaker、Saturn Cloud 和 DataBricks，旨在提供一个数据科学家可以完成所有工作的地方。通过使用标准平台，数据科学代码更容易在不同团队成员之间传递，减少了设置和维护工作空间的时间，代码通常更容易部署。它们还具有较少的安全风险，因为内置了用于监督的管理工具。每个平台都有其优势和劣势，因此如果你在考虑其中一个平台，值得让你的数据科学家们试用并看看他们喜欢哪个。

注意，一些数据科学团队拥有的数据集非常庞大，不可能在单台机器上进行分析。在这些情况下，必须使用分布式集群跑计算。集群必须连接到数据科学工作空间，以便团队可以进一步获取并分析结果。Spark 是这些计算的流行技术，而 DataBricks 平台内置了 Spark。Dask 是一个较新的基于 Python 的分布式计算框架，它内置在 Saturn Cloud 平台中，或者可以通过 Coiled 提供的服务单独使用。尽管如此，对于大多数数据科学团队来说，没有必要使用分布式计算。通常数据集足够小，可以在单台机器上运行，或者如果需要的话可以在单个大型虚拟机上运行。如果你的团队不需要维护分布式系统，那么维护这种系统的开销可能是一个巨大的负担。

分享报告和分析

如果你的团队专注于利用数据来推动业务策略，你将会创建大量的报告和分析。如果你的团队更专注于创建机器学习模型，你仍然需要分析来指导使用哪些模型以及如何使用。几乎没有情况是你的团队不需要创建需要保存和与他人分享的信息的情况，因此你需要有支持这一点的基础设施。你还希望能够将分析与生成它的代码连接起来，以防需要重新运行它。

如果您没有明确选择一种存储和分享分析结果的方法，那么您的“基础设施”最终将只是用于分享信息的电子邮件和 Slack 消息。实际操作中，这非常难以维护。虽然通过这种方式很容易与他人分享结果，但几乎无法找到旧分析或追踪生成分析结果的代码。

更为复杂的方法是创建一个共享位置来保存分析结果，例如 AWS S3 存储桶、Dropbox 文件夹或可能是 GitHub 代码库。在这些方法中，数据科学团队必须严格执行标准结构，以便可以在共享位置中找到特定的分析结果并追踪到生成它们的代码。理想情况下，结果应该对数据科学家和非数据科学家都可见。与需要技术知识才能查看的 AWS S3 存储桶等相比，Dropbox 文件夹这样的工具更易于非技术人员导航。无论采用何种方法，您仍然需要制定数据治理政策，以确保这些内容得到有效组织。

像知识库这样的项目，由 Airbnb 推出的开源工具，或者RStudio Connect，一个用于分享 R Markdown 报告和 R Shiny 仪表板等内容的平台，正在建设以解决这一问题。通过提供一个平台，可以轻松上传并直接查看分析结果，同时还可以存储分析代码，数据科学团队能够更好地对工作进行分类和长期维护。

部署代码

如果您的数据科学团队正在创建定期运行的代码，无论是批处理计划还是作为 API 持续运行，那么您将需要一个可以运行该代码的平台。通常情况下，您的团队可能会落入两种可能的情况之一。一种情况是有一个支持工程团队来维护代码，另一种情况是您的数据科学团队独立操作：

您有一个工程团队的支持

如果您的数据科学工作直接构建到产品中，那么您可能已经有一个工程团队来帮助您。工程团队负责将您的模型和工作连接到产品；他们是调用您的 API 或使用批处理脚本输出的人员。由于这一点，他们几乎总是已经为部署所有软件工程代码设置了自己的平台，最好的做法是让数据科学代码与之融合。您的数据科学团队不必担心维护平台，而只需交付 Docker 容器、Python 库或某种标准格式的代码即可运行。然而，您的团队需要确保代码符合标准，作为团队的领导者，您应该检查数据科学家是否遵循这些标准。

您的数据科学团队独立操作

有许多数据科学团队与工程组没有直接联系，比如为业务单元生成洞察的数据科学团队。尽管如此，这类团队仍可能希望部署代码。例如，他们可能希望每月对每位客户进行评分，并预测其未来价值。包括 Algorithmia、RStudio Connect 和 Saturn Cloud 在内的许多公司提供了数据科学家部署模型的平台，而无需成为工程专家。

在这两种情况下，您仍然希望拥有强大的流程和基础设施：在部署之前确保代码经过测试的系统，监控模型维持准确性的方法等。建立这些系统将需要结合数据科学和工程专业知识，并且顺利运行所需的努力不应被低估。

当您的团队成员与您的基础设施不匹配时

随着团队成熟，您的基础设施决策将变得更加稳固。越来越多的流程将围绕您特定的数据库和工作场所构建，并且您的团队会对其更加熟悉。总体而言，这是一个积极的事情！这意味着您的团队正在解决问题，并变得更快更有经验。然而，在引入新成员时，您可能会发现一些差异。在招聘新人时，您需要评估候选人必须具备多少基础设施经验。这可以通过明确地考虑具有必要技能集的简历或通过面试问题来隐式决定。

多年来（并且可能会继续如此），数据科学领域的有经验的候选人并不多。虽然普遍存在想要成为数据科学家的人，但具有丰富经验且积极寻找工作的人数却很少。在某些技术堆栈领域，市场上有经验的人可能很少，而且肯定没有人已经对所有技术都有经验。

好消息是，数据科学家通常都非常喜欢学习——这是一个建立在探索新事物基础上的职业。在招聘时，如果候选人没有你特定技术栈的经验，不要担心：他们可以在工作中学习。尽可能放松对候选人应该掌握的技术限制，允许尽可能多的替代方案。例如，如果你的团队使用 Python，但候选人只懂 R，那说明他们加入后仍可以学习 Python。此外，通过从更多不同技术背景的人中招聘，你增加了有人会以比你团队当前实践更好的方式做事的机会。在这里真的值得打长期的算盘，招聘那些在稍加培训后能成为优秀人才的人，而不是仅仅在第一天就知道所有东西的人。

下一步怎么办

阅读完本报告后，希望你已经考虑过以新的方式领导数据科学团队。虽然报告涵盖了许多领域，但我们可以用几个关键概念来总结它：

思考团队如何整合和沟通是很重要的。

数据科学团队的成功往往取决于利益相关者和团队之间如何进行清晰沟通，以及数据科学团队的目标如何与更广泛组织的目标整合。数据科学团队领导的工作是监督这一点，并在问题出现时立即解决。领导者还需要关注数据科学团队内部的沟通方式——数据科学家之间的沟通，独立贡献者和管理者之间的沟通，以及数据科学家与利益相关者之间的沟通方式。

领导者负责确保数据科学工作能够顺利完成，无论有多复杂。

数据科学团队不断有新任务涌现，每个任务都可能存在风险，因为你不知道是否有数据或信号来实际执行它。领导者需要跟踪这些工作，基于风险级别和重要性进行优先排序，并确保数据科学家专注于完成工作，不要被分心。这是需要跟踪的许多不同组成部分。

团队的技术支持至关重要，决策过程同样如此。

你的团队将需要做出许多技术决策，而市面上有很多企业试图向你销售你不需要的技术。你希望你的团队能够深思熟虑地决定使用不同平台的平衡方式，以确保每个人都满意。领导者需要找到自己的平衡点，是选择每个人都必须使用的技术，还是让团队中的每个人自行决定。决定决策方式与选择技术本身同样重要。

如果你想获取更多关于成为数据科学领导的信息和讨论，这里有一些资源：

• 如何在数据科学中领导，作者是 Jike Chong 和 Yue Cathy Chang（Manning），深入探讨了本报告中讨论的许多主题。

• 对于更广泛的工程领导思考，请查看管理者之路，作者是卡米尔·富尔尼尔（O’Reilly）。

• 像 Twitter 和 LinkedIn 这样的社交媒体平台，经常会有数据科学专业人士和领导者之间关于他们所面临挑战和找到的解决方案的深入讨论。

在你继续作为数据科学领导者的旅程中祝你好运！

第六章：关于作者

Dr. Jacqueline Nolis 是一位数据科学领袖，拥有超过 15 年的数据科学团队和项目管理经验，曾在从 DSW 到 Airbnb 等公司任职。她目前是 Saturn Cloud 的数据科学负责人，帮助设计数据科学家的产品。Jacqueline 拥有工业工程博士学位，并且是《Build a Career in Data Science》（Manning）的共同作者。