PDF数据科学管理之道
管理数据科学研究团队的经验教训
Kate Matsudaira，Popforms
“他们整天都在做什么？”
当我第一次接任一家从事数据挖掘和机器学习研究的初创公司的工程副总裁时，其他高管都想知道这个问题。
他们知道这个团队非常聪明，而且看起来工作非常努力，但高管们对工作本身有很多疑问。他们怎么知道他们正在做的工作是“正确”的工作？他们是否可以做其他项目？我们如何才能更快地将这项研究成果交付给我们的客户？
那是我的工作。除非你需要一位工程副总裁，否则你不会聘请一位工程副总裁。
在接下来的一年里，我们解决了所有这些问题，并将从想法到产品的时间框架从 6 个月缩短到 2-3 个月。在本文的其余部分，我想与您分享一些我们在管理与产品团队密切合作的数据科学研究团队中学到的经验教训。我希望它们能为您提供一些想法和见解，您可以将其融入到您自己的工作和流程中。
数据科学有所不同
当您有一个团队致力于解决棘手的数据科学问题时，在传统软件中有效的方法并不总是适用。当您进行研究和实验时，工作可能是模糊的、不可预测的，并且结果可能难以衡量。
作为一名来自标准软件开发流程的经理，我精通敏捷、Scrum 和其他流行的流程。然而，我们正在进行的研究工作并不完全适合这些框架。事情有点太混乱了。
我们正在提出想法、调查猜想和测试假设。这项工作非常难以估算，并且我们无法保证结果足够好以至于可以发布。因此，我们必须提出一个新的流程，以应对所有这些不确定性。
回到我们最初的问题：“他们整天都在做什么？”
我可以很容易地去问每个人并提供一份状态报告，但这并没有真正解决实际问题。
问题的核心是我们需要一个清晰的流程，该流程既能很好地适用于研究，又能使与我们产品团队的协作变得容易。我们需要一个流程，我们可以利用一群了解数据的人和一群了解我们客户的人的协同作用，让他们作为一个团队一起工作。
我们需要清晰的沟通渠道和一个能够支持我们未来工作的流程。考虑到这一点，我们专注于沟通和后勤的关键领域。
沟通：提高透明度
我们必须做的第一件事是改善我们的沟通。我们不同的团队没有使用相同的语言。
回答别人的问题不仅仅是解释正确的答案；而是要学习使用正确的词汇来达成真正的理解。沟通不仅仅是语言，而是语言背后的含义。
您如何沟通结果？
例如，总是让我们感到困惑的一件事是“完成”意味着什么？数据科学团队正在衡量他们的结果，我们会完成一个实验，但我们如何知道一个算法或模型何时足够好以至于可以集成到产品中？我们需要的不只是结果的衡量标准；我们需要成功标准。
当我们创建一个模型时，我们会衡量算法的精确率和召回率，并以这种方式沟通我们的结果。然而，并非所有高管都使用这些术语。因此，我们开始改变我们谈论实验结果的方式。我们不再用算法评估指标（如精确率和召回率）来表达，而是开始用客户体验和业务指标来沟通结果。
以前，我们会像这样沟通结果
精确率：80%
召回率 25%
之后，我们会以这种方式沟通结果
对于热门搜索词*，配件在首页上出现的频率为 25%。
对于热门搜索词，头部产品在排名前 3 的结果中出现的频率为 90%，在排名前 5 的结果中出现的频率为 98%。
*热门搜索词是过去 30 天内我们网站上最受欢迎的 1000 个查询。
第二种方式清楚地表明了这些衡量标准的含义。即使是不了解算法的人也能理解并询问有关结果的问题。
您如何衡量结果？
我们遇到的另一个问题是，我们使用随机抽样来衡量算法或模型的结果。虽然这当然是一种测试结果的方法，但它不一定能映射到网站上的体验。我们选择的算法表现良好，但随后完全错过了重要的产品。
因此，我们改变了评估结果的方式，通过实际客户使用情况对其进行加权。我们会选择头部产品或具有客户浏览量的产品，然后将这些产品用作样本来衡量我们的结果。这使我们更好地近似了真实的客户体验。
展示改进
当您进行实验以改进算法（如调整搜索结果）时，另一个关键是要展示改进前后的情况。实验改变了什么？有时某些结果会得到改善，而另一些结果会下降，因此同样重要的是要理解和沟通硬币的两面。有了所有信息，我们就可以就如何进行做出最佳决策。
解决难题
除了所有关于数据和结果沟通的问题外，当我们开始提出新想法时，似乎还会发生另一种沟通不畅的情况。对话会像这样进行
一位高管会说：“我有一个想法，要为某个产品创建一个模型谱系。然后我们可以向客户展示过去的产品，并使用我们的算法来预测何时发布新产品。”
一位数据科学家会接受需求并调查这个想法，工作一段时间后回来，说：“那将非常困难；我认为我们不应该做。”
但这些对话并不总是一致的。
很多事情都“非常困难”，有时功能仍然会被强行推进（让不得不从事这些工作的数据科学团队感到沮丧），但有时“非常困难”的事情会直接阻止这些功能的推进——导致错失机会。
由于没有办法跟进这些对话，或者作为一个小组解决问题，难题只会变得更加困难。
如果您从事数据挖掘和机器学习研究，那么大多数问题都很困难。问题是，有时它们困难的原因可以通过其他方式解决——例如更好/不同的数据、更改需求或添加特殊情况。因此，说一个问题“非常困难”并不是不尝试解决它的充分理由；然而，它一直被用作事情没有发生的理由。
关键是学习沟通事情困难的原因。
对我们来说，最有效的方法是使用类比和例子。通过具体说明为什么困难，人们很容易理解挑战。因此，对于模型谱系，我们使用了图 1 中的示例。
所有这些改变都只是关于思考我们如何沟通。这是为受众量身定制信息。如果您从事数据科学或研究工作，很容易忘记并非每个人都像您一样沉浸在细节中，并且您需要以稍微不同的方式沟通事情以确保理解。
后勤：建立清晰的流程
下一步是调整我们的工作方式。一旦我们解决了一些沟通问题，我记得有人问我，“我们如何才能为研究团队创造紧迫感？” 提出这个意见并不是因为工作没有完成，而仅仅是因为研究团队实际上没有截止日期。工作完成时就完成了。
但我们是一家初创公司；公司里的每个人都有截止日期，我们都在与时间赛跑，以便在我们有足够的时间时尽可能多地交付价值。
为研究增加截止日期
研究之所以称为研究是有原因的，即使我们想制定一个时间表并用漂亮的包装纸包裹交付成果，但这并不意味着世界会那样运转。但我们所做的是为我们的实验创建了一个积压工作列表，就像传统软件开发中的任务积压工作列表一样。这些都是我们想要尝试的所有事情，按优先级排序。
对于这些项目中的每一个，我们都能够定义成功标准、分配它们，甚至估算成本（这应该花费多长时间？）。
结果证明这对团队非常有益。我们不再是每个人都独自工作，而是成为一个团队，从同一个优先级列表中协同工作。
增加敏捷演示
我们做的另一件事是安排每月演示，研究团队的每位成员都会分享他们的进展。这些心跳会议有助于让每个人保持同步，并有助于展示正在取得的实际进展。
这些接触点也有助于创造紧迫感（因为演示创造了截止日期），突然之间，作为一个团队，我们行动得更快了。
由于我们仍在处理研究的不可预测性（谁知道实验是否会成功，或者可能需要多长时间才能运行和调整结果？），我们决定将重点放在速度上。
我们想要快速的概念验证原型和快速迭代。以前，我们可能会等到我们有具体结论才向产品团队展示结果，但在这种新模式下，我们会更轻松地共享数据和中间结果。我们只是会添加很多注意事项。
起初，这让团队感到不舒服；他们不想展示他们知道自己仍然可以改进的东西。然而，一旦我们开始更定期地这样做，我们就能够在流程的早期获得反馈。这种早期反馈甚至帮助我们沿途调整产品（因为我们能够看到结果的实际外观，有时这与我们预期的或在设计中模拟的差异很大）。
当产品团队开始看到结果时，他们会非常兴奋，这促使研究团队完成更多工作。
例如，我们想要研究的功能之一是价值评估，我们会分解产品的功能并为每个功能分配一个价值。目标是帮助用户根据功能比较不同的产品，以便他们可以了解他们真正为之付费的东西，并发现具有类似规格的更便宜的产品。
在做了大量工作之后，很明显这是一个非常困难的问题。然而，使用相同的数据和模型，我们能够构建一个功能，使他们能够实现相同的目标——比较产品，而不是功能。
喜欢它，讨厌它？请告诉我们
Kate Matsudaira 最近以她自己的公司 Popforms 的创始人的身份进入了新领域。在此之前，她曾在 Decide（被 eBay 收购）、Moz 和 Amazon 等公司担任工程领导职务。她的技术经验涵盖了广泛的领域，但她一直参与构建高性能分布式系统和处理数据收集和分析的系统。Kate 还以其博客 (katemats.com) 而闻名，该博客处理领导力和管理方面的问题。
© 2015 1542-7730/14/0300 $10.00
最初发表于 Queue vol. 13, no. 4—
在 数字图书馆 中评论这篇文章
更多相关文章
Ethan Miller, Achilles Benetopoulos, George Neville-Neil, Pankaj Mehra, Daniel Bittman - 远端内存中的指针
为了有效地利用新兴的远端内存技术，需要考虑在父进程上下文之外操作丰富连接的数据。正在开发的操作系统技术通过公开内存对象和全局不变指针等抽象概念来提供帮助，这些抽象概念可以由设备和新实例化的计算进行遍历。这些想法将允许在具有分离内存节点的未来异构分布式系统上运行的应用程序利用近内存处理来获得更高的性能，并独立扩展其内存和计算资源以降低成本。
Simson Garfinkel, Jon Stewart - 磨砺你的工具
本文介绍了我们更新高性能数字取证工具 BE (bulk_extractor) 的经验，该工具在其首次发布十年后进行了更新。在 2018 年至 2022 年期间，我们将该程序从 C++98 更新到 C++17。我们还进行了完整的代码重构并采用了单元测试框架。DF 工具必须经常更新，以跟上其使用方式的变化。对 bulk_extractor 工具更新的描述可以作为可以而且应该做什么的示例。
Pat Helland - 自主计算
自主计算是一种业务工作模式，它使用协作来连接领地及其特使。这种基于纸质表格的模式已经使用了几个世纪。在这里，我们解释了领地、协作和特使。我们研究了特使如何在自治边界之外工作，并且在保持局外人的同时很方便。我们还研究了如何在不同的领地之间启动工作、长时间运行并最终完成。
Archie L. Cobbs - 持久性编程
几年前，我的团队正在为一个增强型 911 (E911) 紧急呼叫中心进行一个商业 Java 开发项目。我们尝试使用基于 SQL 数据库的传统 Java 模型来满足该项目的数据存储需求，但感到很沮丧。在对项目的特定要求（和非要求）进行一些反思之后，我们深吸一口气，决定从头开始创建我们自己的自定义持久层。
© 保留所有权利。