从入职到放弃再到改革成功：我是如何从0到1建立数据团队的？

本文最初发表于作者个人博客，经原作者 Erik Bernhardsson 授权，InfoQ 中文站翻译并分享。

这篇文章所提及的故事背景是在一家处于创业中期阶段的初创企业（年收入约 1000 万美元）组建了一支小型数据团队（大约 4 人），尽管这个故事可能发生在很多不同的公司。这个故事是根据第 n (n≤3) 手经验编造的，侧重于团队和组织，而非技术本身。为了表示准确，我特意使用了“数据科学家”这一术语来代表非常宽泛的概念。

初出茅庐，困难重重

这是你成为超级大公司数据团队负责人的第一天，在你的面试过程中，首席执行官迅速而充满激情地介绍了世界正在发生的变化，以及公司为什么需要跟上数据增长的趋势，整个执行团队都很兴奋。

在最初几个小时内，你可以访问所有的主要系统。你开始在 Git repo 中浏览，并发现了一些有趣的代码。这看上去像是一个用于预测流失率的神经网络。你开始分析这些代码，但是你被日历通知打断了，提醒你要与首席营销官进行 30 分钟的对话。

首席营销官充满激情。“我们对你的到来感到很兴奋。近期，我与 HyperCorp 公司的销售伙伴谈过，他们正在与一家供应商合作，利用人工智能对用户进行细分。太好了！我已经等不及要你沉下心来。” 在闲聊了几句之后，你开始研究营销团队的数据操作。你问：“客户获取成本如何？”首席营销官回答说：“嗯……其实还不错。数据科学家们计算了这些数字，我们的在线广告每次点击成本都在下降。”

你有点困惑，因为你被告知所有的数据科学家都会向数据团队报告，但是显然其他部门也有自己的数据科学家？为了后续行动，你做了笔记。

首席营销官继续说道：“真正的问题是，增长团队并没有把我们带来的所有流量都转化到网站上。”

所以你会问是否有一个能查看转化漏斗（conversion funnel）的仪表盘，但是首席营销官却说，转化销售渠道是增长团队的工作。

那天晚些时候，你与产品经理进行交谈。刚刚对首页进行了大改版，负责此项工作的产品经理非常激动，因为用户注册量增加了 14%。当你询问这种差别是否有统计意义时，你得到的却是茫然的目光。“搞清楚，这不是我的工作，而是你们团队的工作”，这位产品经理说。“上次我们问他们时，他们说他们没有数据，这需要几个月的时间。”

无论什么原因，你会发现产品经理有更多的话要说，所以你让她继续。

“此外，令人惊讶的事情并不是基于增量变化。我们决定不做 A/B 测试，因为有时你需要下很大的赌注，这会使你偏离最高值。乔布斯在发布 iPhone 时并没有做 A/B 测试！我们团队在最后期限的前两天完成了这个版本，这才是关键！”

你在笔记本上潦草地记下笔记，以显得很忙碌的样子。

剩下的时间就是和新团队聊天。这是一支只有三个人的小团队，但你得到的消息是在年底前将其扩大到 10 人。你的团队成员显然为你的到来而激动。他们向你介绍了迄今为止所建立的一切。这里有你之前见过的用于预测流失率的神经网络。还有一个 Notebook，里面有完整的推荐系统实现，可以帮助你找到相关购买项目。还有很多东西，有些还很酷。

你会注意到，很多代码要经过非常复杂的预处理步骤，其中的数据必须从许多不同的系统中提取。看起来好像要运行几个脚本，必须按照正确的顺序手动运行，才可以顺利启动。

你询问为什么团队还没有投入生产。数据团队似乎感到沮丧：“当我们和工程师交谈时，他们说要将这个项目达到生产级别是一项很大的工程。产品经理已经将其纳入待处理项目中，但是由于其他事情不断，他们一直在推诿。对于这个项目，我们需要管理方面的支持。”

当天晚些时候，你要和供应链负责人谈话。看来他并不像首席营销官那么激动。他说：“老实说，我不知道我是否需要数据团队的帮助。我们没有这类问题。我们需要的是业务分析师。我们有一支团队，他们每天都要花上好几个小时做一个复杂的模型。他们连回答我基本问题的时间都没有。我有一整张电子表格，里面都是我渴望得到答案的问题。”

你看一下电子表格，就会发现如下内容：提交支持请求并在 1 小时内得到解决的客户转化率和 1 小时之外得到解决的客户转化率分别是多少？以 100 美元为间隔对订单价值进行细分。

问起“模型”，你会发现在谷歌表格中，这是一个非常复杂的东西，有很多 VLOOKUP 和数据，必须以正确的格式复制粘贴到正确的标签。这些数据每天都会更新，模型的输出决定了团队当天的工作重点。不仅仅是这样，他们还依赖电子表格来计算支付给供应商。

这基本上是很多公司在数据成熟的早期阶段可能发生的事情：

• 缺乏数据，数据碎片化。

该产品的仪表化非常糟糕，所以数据通常一开始就没有。

数据系统碎片化，并且数据分布在许多不同的系统中。

脆弱的业务流，虽由数据驱动，但很少或者没有自动化。

• 对数据团队的工作内容期望不明确。

雇佣数据科学家是为了进行研发，找出一些部署人工智能的其他方法，结果是没有任何明确的业务目标。

数据团队抱怨机器学习难以生产，但是看起来产品团队并不关心这个功能。

需要“英语到 SQL 翻译”的人。

• 未经过数据驱动培训的产品团队。

产品经理没有把数据作为构建更好功能的工具来考虑。

在产品团队想要构建的东西与数据团队所拥有的之间缺乏一致性。

• 从根本上说，一种与数据驱动相冲突的文化。

庆祝交付的文化，而不是庆祝可以衡量的进展和学习文化。

在团队实际使用指标的情况下，它们是不一致的，衡量标准不高，而且在某些情况下与其他团队有冲突。

• 没有数据领导力。

一个分裂的数据组织，不同的数据人员向其他职能领域报告。

其他部门没有得到所需的帮助，因此他们围绕着数据团队，并雇佣了很多分析师。

缺乏标准化的工具链和最佳实践。

下面我们来谈谈如何才能真正摆脱这种困境。

开始为团队制定方向

在接下来的一周，你将为数据团队确定新的方向。数据团队中的一个人在基础设施方面有较多的经验，因此你让他负责建立一个中央数据仓库。目前你只需以最快的方式将数据发送到一个位置。计划基本上就是每小时将生产数据库的表转储到数据仓库中。

结果表明，你在前端用于广告跟踪的框架能够轻松地将大量事件日志导出到数据仓库中，因此你也可以进行设置。

你将这些记在心里，这是你以后要重新考虑的技术债务。

图 1：对数据如何进入数据仓库的极其粗略的概括

你与招聘团队合作，为通用数据角色定义简介，强调核心软件技能，但应具有通用的态度，并深入了解业务需求。现在，你将所有涉及人工智能和机器学习的内容从招聘广告中删除。

你花更多时间与不向你报告的各种数据人员接触。营销团队中的数据科学家是个年轻人，你可以看得出来，她和你交谈非常兴奋。她说：“我一直想成为数据科学家，我等不及要向你学习。”

当天晚些时候，你打电话给经营编码训练营的朋友，询问他们是否有 SQL 培训方面的好课程。他们说有，所以在那个月的晚些时候，你做了一些安排。

你开始为产品团队做一个关于 A/B 测试及其工作原理的演讲 PPT。你提供了很多从以前的经验中获得意想不到结果的测试实例，并使演示的部分内容具有互动性，让观众去选择。

你跟踪首席执行官的执行助理，并在那一周晚些时候在她的日历上得到了一些安排。你的目标是弄清楚她每周要通过自动电子邮件汇报的指标。

那周晚些时候，你和供应链团队的几个业务分析师交谈，你意识到他们也很通情达理，但是他们似乎在与数据团队之前的互动中受到了伤害。

他们中的一位在过去的工作中有过 SQL 经验。他有一个关于转化率的问题，你意识到应该用一些已经复制到数据仓库的表来回答这个问题，所以你给他权限，让他试试。你真的不知道会发生什么，但是你觉得这值得一试。

你每周都会和整个组织中需要数据的关键员工建立一对一的关系。重点是发现数据差距和机会，然后把它们交给数据科学家。有些数据科学家对研究工作的轻重缓急感到失望。你说：“我们需要集中精力尽快实现业务价值”，但你补充道：“我们也许很快又回到机器学习的领域……让我们来看一看”。

三个月之后：陷入无尽的沟通和协调

已经过去三个月了，但是你感觉自己开始在某些方面有所进步。每星期与客户进行一对一的会谈，都会不断发现巨大的盲点和数据发挥作用的机会。你使用这些内容作为许多核心平台工作的强制功能。特别是，需要建立许多管道来生成“衍生”数据集。这些分析的前期成本非常昂贵，但是一旦建立正确的数据集，后续的分析就会更容易。

你已经开始将访问数据仓库的权限向其他部门的其他团队开放。有些人开始学习 SQL，自己做很多基础分析。一位初级产品经理发现 iOS Safari 的转化率很低，这是一个早期的成功。结果发现在本地存储中出现了前端错误，并且只需一行代码就可以修复。

在思考自己所有进步时，你突然被一封来自供应链主管的邮件打断。他非常生气。很明显，他们的模型都不管用，这是他们的一个大问题。

你立即给你在那里认识的人发了一条 Slack 消息。他是业务分析师，当你给他权限时，他急切地开始写 SQL。压力超级大。“数据库中的表发生了变化，我们用来填充电子表格的 SQL 查询突然产生了无意义的输出”。

看到这个 SQL 查询的时候，你差点崩溃，这个查询长达 500 行，查询的作者也有些生气。他说：“我们曾多次来找你们，请你们帮忙解决这些问题，但是你们说没资源，所以我们就自己建造。”

你团队中的数据科学家被指派负责大型 SQL 查询，他们很不开心。他说：“那个团队写这些查询很傻，我们告诉他们，这种情况将会发生。这种 MBA 类型的人没有什么用处。另外，我受雇研究机器学习，而非调试 SQL 查询。”你很绝望，你试着给他许下物质承诺。你说：“请尽力而为，我保证本月晚些时候给你找到一些很酷的机器学习问题。”

当天晚些时候，你正在参加一个会议，讨论最近的版本。结算团队的产品经理对信用卡流程进行了重大改革。但是当你问他，他们是否看到了相关指标的改进，他却感到困惑。他说：“我们还没有时间去研究这个问题。”你很失望，因为作为一个数据科学家，只进行一项粗略的分析还是很容易的。

最起码，那天晚些时候你感觉好些了。营销团队中的数据科学家发邮件告诉你，她已经跟她的经理谈过了。首席营销官对她向你汇报完全没有意见，但明确表示：“我需要她 100% 的时间来做营销。”你联系人力资源部门，要求他们对内部系统进行更新，以便作出管理方面的改变。虽然她的资历显然很浅，但她对复杂业务问题的把握能力令你印象深刻。

那天晚上 9 点，你结束了工作。

开始改革

你已经开始为最紧迫的需求打下最基本的基础：所有重要的数据都在同一个位置，查询起来很容易。公开 SQL 访问和培训其他团队使用 SQL，意味着很多“SQL 翻译”将消失。

而另一方面，有些团队将会用他们新获得的自由走得太远。为数据访问设置严格的“护栏”来防止这种情况的发生是很有诱惑力的，但这常常带来更多的弊端。一般而言，人们都是理性的，做一些能给企业带来正面投资回报的事，但是他们可能不明白数据团队能为他们做什么。你的工作就是为了证明！

同样，在结算团队中，你也会看到类似的情况：有一个简单的分析，你的团队本可以完成，但并没有，因为团队不知道该问谁。

这主要是组织方面的挑战。团队不知道如何与数据团队合作。即使你没有意识到，你也可能成为瓶颈。其他团队将围绕数据团队开展工作。许多“简单的”分析都没有完成。

在我看来，最应该推动的是集中的报告结构，但同时保持工作管理的分散。

为什么？很大程度上是因为它在数据和决策之间形成了一个更加紧密的反馈循环。若每一个问题都要通过中心瓶颈，则交易成本将非常高。而你又不想把管理权力下放。有能力的数据人员希望向了解数据的经理报告，而非业务人员。

图 2：拥有集中积压和集中管理的数据团队

取而代之，将资源管理工作推给其他团队。给他们一小撮数据人员，让他们一起工作。这些数据人员将能够更快地完成迭代，而且还可以开发宝贵的领域技能。这样可以减少其他团队对数据团队工作的依赖，并且可以形成自己的资源。

图 3：数据团队，积压分散但管理集中

一个好的方面是，在某种程度上，你的结果本身会推动整个组织的集中化：营销团队中的初级数据科学家转到你的团队中，因为她想为你工作。

团队扩大了

此时，你的数据团队已经扩大到六人。其中一人忙于处理与数据仓库有关的基础设施。对于其他五人，你将他们每人都分配到一个团队：

• 一个被分配到产品团队。
• 一个被分配到供应链团队。
• 一个被分配到结算团队。
• 你已经有来自营销团队的数据科学家在从事营销工作。
• 最后一个人被分配服务于首席执行官和投资者 / 董事会。

你向一大群人发送了一封电子邮件，概述了这一变化，并且清楚说明了人们应该与谁合作以满足他们的数据需求。当你雇用员工时，你计划在公司内将他们分配到不同的团队。大部分都是产品 / 工程团队，但是在某些情况下还有其他团队。

团队人员出现变动

你以一封令人沮丧的电子邮件开始一天的工作。你的一位数据科学家决定离开，他写道：“我要去 XXX 公司，加入他们新的机器学习团队。”你不想说服他留下。老实说，有一阵子他看起来并不高兴，而且你也没有什么工作能使他兴奋。

相反，你的团队里有一群兴奋的新人。他们中的大多数人都懂得一点软件工程，一点 SQL，但是最重要的是要从数据中发现有趣的洞察力。你认为他们是“数据记者”，因为他们的目标是从数据中发现“爆料”。

你的团队中有一位特殊成员直接与业务团队合作。她几乎每天都和产品经理谈话，团队也很喜欢她，因为她提出了很多见解。举例来说，当前业务中有一个很大的阻碍是需要问客户要地址，尽管其实运算中并不需要。在随后的 A/B 测试中，除去这一步骤，转化率增加了 21%。在一开始就很难发现这个问题，因为数据库中的数据模型非常复杂，必须建立一套 ETL 作业，以便数据“扁平化”成表格，才可以便于查询。然而，一组 Python 作业的组合，就能发挥作用。

那天晚些时候，所有主要项目都进行了季度回顾。这是件大事儿，首席执行官也在场，一切进展都让她感到兴奋。

轮到增长计划时，主要的产品经理介绍了他们推出的新的引人注目的登录页面。产品经理多次指出，由 20 名工程师组成的团队正在加班加点地赶着最后期限，她把设计师们的工作介绍给大家。首席营销官对此参与度极高，她沉默了片刻，说道：“迄今为止的指标是什么？我们知道客户获取成本是否已经下降了吗？”

产品经理回答道，已经做过 A/B 测试，并且在演示的附录中有数字。它显示了一个杂乱无章的画面。有些指标上升，有些下降。并未表明有什么明显的结果。有一张表格，是对早期客户获取成本数据的总结，但是这个数据看上去很糟糕。首席营销官强调，这些数据“还在发酵”，对于这类行为，可能要花费数月时间来处理。

你给数据团队的人员发消息，并告诉他们下一次应该将这些数据做成队列图。

这是怎么回事？

值得庆幸的是，产品团队开始了 A/B 测试。坏消息是，它忽视了结果，项目看起来主要受里程碑事件和人为截止日期的驱动。好消息是，首席执行官鼓励团队将数据当作事实。

当组织的压力越来越大，要求更多的数据驱动时，就应该加快数据团队与其他团队的合作。特别是，最高层的人会开始把注意力集中在指标上，而与他们合作是你的职责。做一件简单的事儿能起到很大的作用，那就是和每一个团队合作，确保他们都有自己的仪表盘，其中包含他们关心的最重要的一组指标。

图 4：在组织的不同级别上，不同的服务推动了最大的进展

除了一个例外，几乎所有数据团队过去做的机器学习工作都是毫无结果的。在库存产品团队工作的数据科学家中有一位对早期推荐很有兴趣。她是你雇佣的新成员之一，而且她有的背景更加全面。她在 Notebook 上找到推荐系统，并能够将其转变为内部部署的小型 Flask 应用程序。

库存团队的产品经理看到它时欣喜若狂。“我们如何交付？”她问道。该团队跟踪的指标之一是平均订单值，她认为这能推动订单显著提高。

一项快速评估表明，要大规模使用它仍然是个问题。但是你的数据科学家有一个想法。她说：“如果我们只为所有客户中的 1% 推出会怎么样？我们可以让它被 cron job 驱动，并在数据库中预先生成所有建议。我认为几天之内我就能搞定事情。”大家都很兴奋，于是她开始工作。

你已经在供应链团队中花费了很多时间，并且发现了更多大型 SQL 查询，用于各种关键业务。它们中断了很多，但是你的团队正在重新编写代码，使之成为合适的运行管道。供应链负责人希望可以和你的团队深入合作。他说：“一旦你开始参与进来，我的业务分析师团队将会做得更好。为了支持你，我愿意为你们做任何事，雇佣更多的数据科学家！”

如今，一些很酷的机器学习工作带来了希望。看起来产品团队终于因为推荐系统的小型测试而兴奋不已。它之前被卡住了，因为产品工程团队不能评估工作，也不想承诺，数据团队又没有实际的软件技能，不能将其带到生产业务中。

数据团队更深入地解决了这个问题，真正建立了演示。这样做，不但使其接近于生产，而且潜力也更加清晰。在这些项目停滞不前时，数据团队很容易感到失败，就像他们被雇来做人工智能的工作一样，但是现在没有了管理支持。在时间中，我认为更普遍的情况是，他们并不主动将工作做得有价值和更容易交付。

另外一件事是关注供应链团队在做什么。这个过程大致如下：

• 在开始的时候，团队有自己的“业务分析师”（数据团队之外），但是需要数据团队为他们运行查询来获取数据。
• 在数据团队的帮助下，这些业务分析师开始自己运行查询。
• 他们开始积聚“影子技术债务”（在本例中是一个大型 SQL 查询），这首先会引起大量与数据团队的摩擦。
• 数据团队开始嵌入到业务中，帮助他们进入更好的位置。
• 因为嵌入，业务分析师的需求下降，对数据科学家的需求上升。

请注意，在你开始直接将生产数据库表转储到数据仓库时，你需要承担大量的“技术债务”。下游的数据消费者会有很多中断的 SQL 查询。久而久之，你就必须在两者之间添加某种层，从生产数据库中提取元数据，并将它们转换成各种派生数据集，使之更稳定，更易于查询。从安全角度来看，这很有必要：你需要从生产数据中分离出大量 PII。

终于迎来转机

这是第三季度的计划会议。在此之前，这些会议常常变成一场关于公司在未来几个季度重要方向的大辩论。这次，你首先浏览了公司的高级关键结果。每个团队都有子级指标，从而形成更细化的高层指标划分。

显然，你和产品管理团队的工作得到了回报。对于他们在运行测试时所学到的或在数据中发现的东西，产品经理们常常为他们对各种项目的投资是合理的提供证据。

一项重要的成就是，你的一位数据科学家和结算团队一起发现了一个严重的错误，即用户在确认页面点击“返回”按钮，最终会导致购物车对象出现问题。解决了这个问题之后，转化率就大大提高了。

另外一种见解是，不同广告活动所带来的流量一登陆网站，就会产生截然不同的转化情况。结果发现，一些网站的点击价格低廉，但是转化率并不高。有些广告活动价格很高，但是这些用户的转化率很高。

因为现在你跟踪 UTM 参数并将它与账户创建联系起来，你现在就可以衡量广告点击到购买的转化率。除非所有数据都进入相同的数据仓库并进行归一化，否则无法做到这一点，因此你可以轻松查询。目前，主要的 KPI 是与营销团队合作，以端到端获取客户的成本，而非每次点击成本。

另外一个令人振奋的消息是，推荐系统的 1% 测试表现非常出色。虽然把它扩展到 100% 的用户是一个非常重要的项目，但是首席执行官还是给这个项目开了绿灯。

当然，并非所有结果都是正面的，也有一些不成功的测试都不成功，但整体是向好的。

经过了这么长时间的磨练，你已经将组织转变为真正的数据原生型架构。数据团队与许多不同的利益相关者进行跨职能的合作。数据和见解被用于规划，使用数据推动业务价值，而非目标不明确的独立作坊。公司采用迭代的方式工作，而非大型的“瀑布”式规划，具有快速数据驱动的反馈周期。衡量标准的定义让人们觉得产生业务价值是一种责任。数据文化由上面（首席执行官推动）和下面（基层员工）共同推动。失败并没有什么，至少你可以从中吸取教训。

作者介绍：

Erik Bernhardsson，Better 的前首席技术官，目前正在从事数据领域的一些创业想法。他写了很多代码，其中一些最终被开源了，如 Luigi 和 Annoy。他还共同组织了纽约市机器学习聚会。

原文链接：

https://erikbern.com/2021/07/07/the-data-team-a-short-story.html