数据科学管理之道 关于管理数据科研团队的经验和教训

当我初次到一家研究数据挖掘和机器学习的创业公司担任工程部副总裁时，其他高管都对这个问题感到好奇。他们知道，这是一支天赋异禀的团队，看上去也工作得十分卖力，但诸位高管对这项工作本身仍然充满了疑问。他们怎么知道自己正在做的事情就是“正确”的？他们还能改做其他项目吗？另外，我们怎么才能更快地将研究成果交到顾客手中？

这就是我的工作。聘请的工程部副总裁绝不是拿来当摆设的。

在接下来的一年中，我们解开了以上所有疑团，并且成功地将从创意到产品的时间从半年缩短到了两三个月。在本文，我将围绕如何管理一支与产品团队密切合作的数据科研团队这个主题，与大家分享一些经验和教训。希望能给大家的工作和管理流程能有所启发。

如果你领导的是一支处理复杂数据科学问题的团队，那么传统软件中的常用方法就未必行得通了。开展研究和实验时，工作内容或许是模糊不清、不可预测的，结果也可能难以测量。

作为一名熟悉标准软件开发流程的经理，我对如今的敏捷开发、Scrum 和其他相关流程了如指掌。然而，这些框架与我们当时从事的研究工作并不贴合。实际情况有些过于凌乱。

我们忙于提出创意、调查设想和检验假设。工作量非常难以估计，而且我们也无法保证成果能达到交付标准。所以我们必须制定一套新流程，来应对所有这些不确定性。

现在回到最初的问题：“他们究竟整天在忙些什么？”

我当然可以直接去询问每个人，然后提供一份状态报告，但这样的答案无异于隔靴搔痒。

问题的核心在于，我们需要一套适合研究工作的清晰流程，同时要简化我们与产品团队的合作。我们需要的流程，必须能帮助我们充分利用一群精通数据的人和一群熟知顾客的人之间产生的合力，并能让他们齐心协力地工作。

我们需要通畅的沟通渠道，和一套能够支持将来工作的流程。怀着这样的初衷，我们将改革之箭瞄准了沟通和后勤的关键领域。

通信 : 保持透明

当务之急是改善沟通效果。不同团队都有各自不同的话语体系。

解答他人的问题并不像阐述正确答案这么简单，你还要学会运用适当的词汇来让对方真正地理解。沟通不能停留于表面的词汇，更重要的是背后的含义。

你们是怎么沟通结果的？ 譬如，有一个问题总会让我们犯难：“怎么样才叫完成？”数据科学团队会测量结果，我们的实验也总归会结束，但我们怎么知道一个算法或模型是否已经达到与产品集成的标准呢？我们需要的不仅是测量结果，还有成功标准。

创建模型时，我们可以通过测量模型的准确率、查全率，但并非所有高管都懂得那些术语。所以我们换了一种方式来谈论实验结果。我们不再用算法评估指标（例如准确率和召回率）来表达观点，而是用顾客体验和商务指标来沟通结果。

以前，我们会这样沟通结果：

精度： 80%
召回率 25%

而以后我们会这样沟通结果：对于热门搜索词 *，附件出现在第一页的几率为 25%。对于热门搜索词，初代产品出现在前 3 条结果中的几率为 90%，出 现 在 前 5 条 结 果 中 的 几 率 为98%。

* 热门搜索词是指我们的网站在最近 30 天内出现次数最多的1000 个查询词。

第二种表达方式清晰地诠释了测量结果的含义。即使不理解算法，也能听懂这些结果并就此发问。

你们是怎么测量这些结果？我们遇到的另一个问题是，我们一直在用随机采样的办法来测量算法或模型的结果。尽管这无疑是测试结果的一种方法，但它却未必能和网站使用体验挂钩。我们精挑细选的算法也许在采样测试中效果很好，但在重要产品中的效果却可能谬以千里。

因此我们抛弃了原来评估结果的方式，改为以顾客实际使用来衡量。我们会用初代产品或有顾客浏览的产品作为测量结果的示例。这让我们更加贴近了真实的顾客体验。

展现进步。 通过实验改进算法时，例如调整搜索结果，展现前后对比也很关键。实验中改变了哪些条件？有时，有些结果可以得到改善，有些结果甚至还不如从前，因此了解这两个对立面和就此进行沟通缺一不可。有了这些信息后，我们就能作出关于下一步行动的最佳
决定。

攻克难题。 除了数据和结果的沟通问题外，我们探讨新创意时似乎也会产生误解。譬如，可能会有这样的对话：

一位高管说：“我有个想法，想创建一个产品型号谱系。然后我们可以给顾客展示过去的产品，并使用我们的算法来预测新产品什么时候发布。”

数据科学家会听取需求、分析创意、研究一番，然后带着这样的消息回来：“那会非常困难；我认为我们不应该做这件事。”

但类似这样的对话并不总是带来一样的结果。

很多工作都“非常困难”，有时候某些功能还是要千方百计地实现（这让不得不开展相关工作的数据科学团队很头疼），但也有些情况下，“非常困难”的工作会让某项功能的开发戛然而止，导致错失良机。

鉴于我们缺乏跟进这类对话或团队集体解决问题的机制，难题只会变得更难。

对于数据挖掘和机器学习领域的研究人员而言，大多数问题都不简单。但关键在于，难以攻克的难题有时候可以用其他方式来化解，例如使用质量更好的数据或其他数据、变更需求或添加特殊条件。所以把一个问题形容为“非常困难”不能作为不尽力解决的充分理由；
然而，大家始终都把这句话当做停滞不前的借口。

解决问题的关键在于学着沟通导致工作困难的原因。

对我们来说，效果最好的方法是打比方和举例子。把工作困难的原因层层剥开后，他人就容易理解困难所在了。针对型号谱系，我们结合插图中的例子来讲。

唯一的改变是反思我们的沟通方式。我们需要向受众传达有针对性的信息。对数据科学或研究领域的工作人员而言，以下这一点很容易忽视：并非所有人都和你一样熟悉具体情况，因此我们需要变通沟通方式，确保达成共识。

后勤：建立清晰流程

下一步要做的是调整工作方式。解决了部分沟通问题后，我记得有人会问我：“我们怎么为研究团队营造紧迫感？”有这样的疑问产生，并不是因为工作没有完成，只是因为研究团队的工作一般没有截止日期。一项工作什么时候完成，全凭负责人说了算。

但我们是创业公司；公司其他所有员工都有截止日期，大家都在和时间赛跑，在时间允许的范围内尽可能创造更多的价值。

为研究工作定下截止日期。

研 究 之 所 以 叫 做 研 究 是 有 原 因的，即便我们希望制定时间表，届时把产品包好再打个蝴蝶结，也不代表一切就会如愿。但是，我们为实验创建了需求列表，就像为传统软件开发工作创建的需求列表一样。列表上列出了所有我们希望达到的目标，按优先级
排序。

对于列表中的每个条目，我们都可以定义成功标准、分配出去乃至放弃（这要花多长时间？）。

这项举措让团队受益匪浅。以前，大家是各人自扫门前雪，如今，我们作为一个团队，共同处理同一份重点工作列表中的事项。

增加敏捷演示。 我们的另一项措施是每个月安排一次演示，让研究团队的每位成员分享各自的进度。这些“心跳会议”有助于大家知己知彼，了解真实的工作进展情况。

还有助于营造紧迫感（因为演示中定下了截止日期），结果我们突然开始作为一支团队快速行动起来了。

鉴于我们无法抹除研究工作的不可预测性（没人知道实验能否成功、运行和调整结果需要多长时间），我们决定着眼于速度。

我们追求迅速的验证概念的原型和快速迭代。若是以前，我们可能会等到有明确结论后再向产品团队展示结果，但在这个新模型中，我们会更频繁地分享数据和中间结果。我们会增加很多警告。

最初，这让团队所有成员都不适应；他们不想展示自己明知道还有改进空间的半成品。然而，自从更频繁地这样做之后，我们能在流程中更早获得反馈了。这种早期反馈甚至促进了我们在整个过程中对产品的调整（因为我们可以看到结果的真实状况，要知道，有时候结
果与我们的预期或在设计稿中的模型相去甚远）。

而当产品团队也能看到结果后，他们会充满激情，反过来也为研究团队取得更多成果增添了动力。

例如，我们曾希望推出的功能之中有一项是估值，也就是要将产品的所有功能分开，并逐一赋予数值。这样做的目标是帮助用户按照功能来对比产品，让他们清楚地知道自己的钱究竟花在哪里，还可以帮助他们寻找规格相似但价格更优惠的产品。

做了很多工作之后，我们发现这个问题非常复杂。然而，用同样的数据和模型，我们实现了另一项功能，可以帮助用户达成同样的目标，但对比的是产品而非功能。