本文首发于作者个人博客，经原作者Erik Bernhardsson授权翻译并分享到InfoQ中文站。
这篇文章背后的故事是在一家中期初创公司（年收入约 1000 万美元）组建一个小型数据团队（约 4 人），尽管这个故事可能发生在许多不同的公司身上。这个故事是根据第 n (n≤3) 手的经验编造的，关注的是团队和组织，而不是技术本身。为了准确起见，我特意用“数据科学家”这个词来表示非常广泛的概念。
新鲜又硬
这是您在一家大型公司担任数据团队负责人的第一天，在您的面试过程中，CEO 反应迅速且充满热情 整个执行团队都对世界正在发生的变化以及公司为什么需要跟上数据的增长。
在最初的几个小时内，您可以访问所有主要系统。您开始浏览 Git 存储库并发现了一些有趣的代码。这看起来像一个用于预测客户流失的神经网络。您开始分析代码，但您被日历通知打断，提醒您联系首席营销官进行 30 分钟的对话。
CMO 充满热情。 “我们很高兴有你在这里。我最近与 HyperCorp 的销售合作伙伴进行了交谈，他正在与供应商合作，使用人工智能来细分用户。太好了！我等不及你低头了。”聊了几句，就开始看营销团队的数据操作了。你问：“客户获取成本是多少？CMO 回答：“嗯……其实还不错。数据科学家计算了这些数字，我们的在线广告 CPC 正在下降。”
您有点困惑，因为您被告知所有数据科学家都向数据团队报告，但显然其他部门也有自己的数据科学家？为了跟进，你做了笔记。
CMO 继续说道，“真正的问题是，增长团队并没有转化我们为网站带来的所有流量。”
所以你问是否有一个查看转化漏斗的仪表板，但 CMO 说，转化销售漏斗是增长团队的工作。
那天晚些时候，您与产品经理交谈。主页刚刚大修，负责这件事的产品经理非常兴奋，因为用户注册量增加了 14%。当你问这个差异在统计上是否显着时，你会得到一片空白。 “做对了，这不是我的工作，而是你们团队的工作，”产品经理说。“上次我们问他们时，他们说他们没有数据，这需要几个月的时间。”
不管什么原因，你会发现产品经理有话要说，所以你让她继续。
“此外，令人惊讶的事情不是基于增量变化。我们决定不做 A/B 测试，因为有时你需要下很大的赌注，这会将你推离榜首。乔布斯没有做 A/在他发布 iPhone 时进行 B 测试！我们的团队在截止日期前两天完成了这个构建，这就是重点！”
你在笔记本上乱写笔记，看起来很忙。
其余时间都花在与新团队聊天上。这是一个由三个小团队组成的团队，但您听说到今年年底将其扩大到 10 个。你的团队成员显然很高兴有你在这里。他们告诉你到目前为止你已经建立的一切。这是您之前看到的预测客户流失的神经网络。还有一个完整实施推荐系统的笔记本，可帮助您找到相关购买。还有很多，一些很酷的。
您会注意到很多代码都经过了非常复杂的预处理步骤，其中数据必须从许多不同的系统中提取。看起来有几个脚本要运行，必须以正确的顺序手动运行才能顺利启动。
你问为什么团队还没有投入生产。数据团队似乎很沮丧：“当我们与工程师交谈时，他们说要让这个项目达到生产水平需要做很多工作。产品经理已经将它包含在待处理的项目中，但他们一直在推迟，因为其他事情正在发生。对于这个项目，我们需要管理支持。“
稍后，您将与供应链负责人交谈。看起来他不像 CMO 那样兴奋。他说：“老实说，我不知道我是否需要数据团队的帮助。我们没有这类问题。我们需要的是业务分析师。我们有一个团队每天花费数小时处理复杂的模型。他们甚至没有时间回答我的基本问题。我有一个完整的电子表格，里面满是我渴望得到答案的问题。”
如果您查看电子表格，您会发现如下内容：提交支持请求并在 1 小时内得到解决的客户和在 1 小时内得到解决的客户的转化率是多少？订单价值以 100 美元为间隔进行细分。
询问“模型”，你会发现在 Google Sheets 中，这是一个非常复杂的东西，有很多 VLOOKUP 和数据必须以正确的格式显示，然后复制粘贴到正确的标签上。这些数据每天更新，模型的输出决定了团队当天的工作重点。不仅如此，他们还依赖电子表格来计算对供应商的付款。
这基本上是很多公司在数据成熟的早期阶段会发生的事情：
该产品的仪器仪表非常差，因此数据通常一开始就不存在。
数据系统是碎片化的，数据分布在许多不同的系统中。
由数据驱动且几乎没有自动化的脆弱业务流程。
聘请数据科学家进行研发，想出了一些其他部署 AI 的方法，结果发现没有任何明确的业务目标。
数据团队抱怨机器学习很难产生，但看起来产品团队并不关心该功能。
需要“英文到SQL翻译”的人。
产品经理不会将数据视为构建更好功能的工具。
产品团队想要构建的内容与团队拥有的数据之间缺乏一致性。
庆祝交付文化，而不是可衡量的进步和学习文化。
在团队实际使用指标的情况下，指标不一致、衡量不当，并且在某些情况下与其他团队发生冲突。
一个分散的数据组织，不同的数据人员向其他职能领域报告。
其他部门没有得到他们需要的帮助，所以他们围绕着数据团队，聘请了很多分析师。
缺乏标准化的工具链和最佳实践。
下面让我们谈谈如何才能真正摆脱困境。
开始为您的团队设定方向
在接下来的一周，您将为数据团队设定新的方向。其中一个人对基础设施有更多的经验，所以你让他负责建立一个中央数据仓库。目前您只需要以最快的方式将数据发送到一个位置。计划基本上是每小时发送一次生产数据库表转储到数据仓库中。
事实证明，您在前端用于广告跟踪的框架可以轻松地将大量事件日志导出到数据仓库，因此您也可以进行设置。
请记住这一点，这是您以后需要重新考虑的技术债务。
图 1：数据如何进入数据仓库的极其粗略的概述
您与招聘团队合作，为常见的数据角色定义个人资料，强调核心软件技能，但态度一般，对业务需求有深刻的理解。现在，您从招聘广告中删除所有提及人工智能和机器学习的内容。
您会花更多时间与不向您报告的各种数据人员打交道。营销团队的数据科学家很年轻，你可以看出她很高兴能和你交谈。 “我一直想成为一名数据科学家，我迫不及待想向你学习，”她说。
当天晚些时候，您打电话给运行编码训练营的朋友，询问他们是否接受过 SQL 好课程的培训。他们说是的，所以那个月晚些时候，你做了一些安排。
您开始为产品团队制作一份关于 A/B 测试及其工作原理的演示文稿 PPT。您提供了许多测试示例，这些示例具有从以前的经验得出的意外结果，并使演示文稿的某些部分具有交互性以供观众选择。
您跟踪 CEO 的行政助理，并在她那周晚些时候的日历上安排一些安排。您的目标是弄清楚她每周将通过自动电子邮件向哪些指标报告。
那周晚些时候，您与供应链团队的几位业务分析师交谈，您意识到他们也很合理，但他们似乎因之前与数据团队的互动而受到伤害。
其中一人在过去的工作中具有 SQL 经验。他有一个关于转换率的问题，你意识到应该用一些已经复制到数据仓库的表来回答这个问题，所以你允许他尝试一下。你真的不知道会发生什么，但你认为值得一试。
您每周与整个组织内需要数据的关键员工建立一对一的关系。关键是要识别数据差距和机会，然后将它们交给数据科学家。一些数据科学家对他们研究工作的优先顺序感到失望。您说：“我们需要专注于尽快交付业务价值”，但您补充说：“我们可能很快就会回到机器学习领域……让我们来看看”。
三个月后：陷入无休止的沟通和协调
三个月过去了，但您觉得自己在某些方面开始有所进步。每周与客户的一对一会议继续发现巨大的盲点和数据发挥作用的机会。您将这些作为许多核心平台工作的必备功能。特别是，需要构建许多管道来生成“派生”数据集。这些分析的前期成本非常高昂，但一旦建立了正确的数据集，后续分析就会变得更加容易。
您已开始向其他部门的其他团队开放对数据仓库的访问权限。有些人开始学习SQL，自己做很多基础分析。一位初级产品经理发现 iOS Safari 的转化率很低，很早就成功了。原来是本地存储有一个前端bug，一行代码就可以修复。
在考虑所有进展时，您突然被供应链主管的一封电子邮件打断了。他非常生气。显然他们的模型都不起作用，这对他们来说是个大问题。
您立即向那里认识的人发送 Slack 消息。他是一名业务分析师，当您允许他时，他就急切地开始编写 SQL。压力超级大。 “数据库中的表发生了变化，我们用来填充电子表格的 SQL 查询突然产生了无意义的输出”。
当您看到这个 500 行长的 SQL 查询时，您几乎崩溃了，查询的作者有点生气。他说：“我们来找你很多次，请你帮忙解决这些问题，但你说我们没有资源，所以我们自己建立了。”
您团队中的数据科学家被分配到大型 SQL 查询中，他们非常不高兴。 “那个团队写这些查询是愚蠢的，我们告诉他们这将会发生，”他说。 “这种 MBA 类型的人用处不大。另外，我被雇来做机器学习，而不是调试 SQL 查询。”你绝望了，你试图向他做出物质承诺。你说：“请尽力而为，我保证在本月晚些时候为你找到一些很酷的机器学习问题。”
那天晚些时候，您正在开会讨论最新版本。计费团队的产品经理对信用卡流程进行了大修。但是当你问他他们是否看到相关指标有所改善时，他感到困惑。 “我们还没有时间研究这个，”他说。你很失望，因为作为一名数据科学家，做粗略的分析仍然很容易。
至少那天晚些时候你会感觉好些。营销团队的数据科学家给你发电子邮件，让你知道她已经和她的经理谈过了。首席营销官对她向您报告绝对没有问题，但明确表示：“我需要她 100% 的时间进行营销。”您联系 HR 并要求他们更新其内部系统以进行管理变更。虽然她的资历显然有限博客大巴发表日志要通过管理员审核么，但她对复杂商业问题的把握会给您留下深刻印象。
晚上 9 点那天晚上，你完成了工作。
开始改革
您已经开始为最紧迫的需求奠定最基本的基础：您的所有重要数据都集中在一个地方并且易于查询。公开 SQL 访问权限并培训其他团队使用 SQL 意味着很多“SQL 翻译”将消失。
另一方面，有些团队会因为他们新获得的自由而走得太远。对数据访问设置严格的“护栏”以防止这种情况发生是很诱人的，但这通常会带来更多的缺点。一般来说，人们是理性的，会做一些能给企业带来积极投资回报的事情，但他们可能不明白数据团队能为他们做些什么。你的工作就是证明它！
同样，在解决团队中，您会看到类似的情况：有一个简单的分析，您的团队本可以做，但没有做，因为团队不知道该问谁。
这主要是一个组织挑战。团队不知道如何与数据团队合作。即使没有意识到，也可能成为瓶颈。其他团队将围绕数据团队工作。许多“简单”的分析没有完成。
在我看来，最重要的是要推动一个集中的报告结构，但同时保持工作管理分散。
为什么？很大程度上是因为它在数据和决策之间建立了更紧密的反馈循环。如果每个问题都必须通过一个中心瓶颈，那么交易成本将非常高。而且你不想分散管理。有能力的数据人员希望向了解数据的经理报告，而不是向业务人员报告。
图 2：集中积压和集中管理的数据团队
相反，将资源管理推给其他团队。给他们一小群数据人，让他们一起工作。这些数据人员将能够更快地迭代并开发有价值的领域技能。这减少了其他团队对数据团队工作的依赖，可以形成自己的资源。
图 3：数据团队，积压分散但集中管理
一件好事是，在某种程度上，你的结果本身推动了整个组织的集中化：营销团队的初级数据科学家因为想为你工作而加入你的团队。
团队扩大了
此时，您的数据团队已经发展到六人。其中一位忙于与数据仓库相关的基础设施。对于其他五个，您将每个人分配到一个团队：
您向一大群人发送一封电子邮件，概述更改并明确应与谁合作以满足他们的数据需求。当您雇用人员时，您计划将他们分配到公司内的不同团队。大多数是产品/工程团队，但在某些情况下还有其他团队。
团队变动
您从一封令人沮丧的电子邮件开始新的一天。您的一位数据科学家决定离开并写道：“我要去 XXX 加入他们的新机器学习团队。”你不想说服他留下来。老实说，他有一段时间看起来并不开心，你也没有太多工作可以让他兴奋。
相反，您的团队中有一群令人兴奋的新人。他们中的大多数人都知道一点软件工程，一点点SQL，但最重要的是从数据中找到有趣的见解。您将他们视为“数据记者”，因为他们的目标是从数据中发现“启示”。
您团队的一名特殊成员直接与业务团队合作。她几乎每天都与产品经理交谈，团队喜欢她，因为她带来了很多见解。例如，当前业务中的一个很大障碍是需要向客户询问地址，尽管在计算中实际上并没有要求。在随后的 A/B 测试中，移除此步骤可将转化率提高 21%。这个问题一开始很难发现，因为数据库中的数据模型非常复杂，必须设置一组 ETL 作业，以便将数据“扁平化”成易于查询的表。但是，一组 Python 作业的组合可以解决问题。
当天晚些时候，所有重大项目都进行了季度审查。这是一件大事，首席执行官在场，她对正在发生的一切感到兴奋。
到了制定增长计划的时候，首席产品经理介绍了他们新的引人入胜的着陆页。产品经理一再指出，20名工程师的团队正在加班加点赶工期，她向设计师介绍了工作。 CMO 太投入了，她沉默了片刻，说道：“目前的指标是什么？我们知道获客成本是否下降了吗？”
产品经理回复说已经A/B测试了，demo的附录里有数字。它显示了一张杂乱无章的图片。一些指标上升，一些下降。没有显示出明显的结果。有一张表格总结了早期获客成本数据，但数据看起来很糟糕。首席营销官强调，数据“仍在发酵”，处理此类行为可能需要数月时间。
你给数据团队的人发消息，告诉他们下次应该绘制数据图表。
这是怎么回事？
谢天谢地，产品团队开始了 A/B 测试。坏消息是它忽略了结果，项目似乎主要由里程碑和人为的截止日期驱动。好消息是 CEO 鼓励团队将数据视为事实。
随着组织承受越来越大的数据驱动压力，是时候加快数据团队与其他团队的协作了。特别是，高层人员将开始关注指标，与他们合作是您的工作。一件可以大有帮助的简单事情是与每个团队合作，以确保他们拥有自己的仪表板，其中包含他们关心的最重要的一组指标。
图 4：在组织的不同级别，不同的服务推动了最大的进步
除了一个例外，数据团队过去所做的几乎所有机器学习工作都没有结果。在库存产品团队工作的一位数据科学家对早期推荐很感兴趣。她是你的新员工之一，而且她的背景更全面。她在 Notebook 上找到了推荐系统，并能够在本地将其变成一个小型 Flask 应用程序。
库存组的产品经理看到后欣喜若狂。 “我们如何交付？”她问。团队跟踪的指标之一是平均订单价值，她认为这可以显着提高订单。
快速评估表明博客大巴发表日志要通过管理员审核么，大规模使用它仍然是一个问题。但是你的数据科学家有一个想法。 “如果我们只推出 1% 的客户怎么办？我们可以让它由 cron 作业驱动，并在数据库中预先生成所有建议。我想几天后我就能完成工作， “ 她说。每个人都很兴奋，所以她开始工作了。
您在供应链团队上花费了大量时间，并发现了更多针对各种业务关键型应用程序的大型 SQL 查询。它们破坏了很多，但是您的团队正在重写代码以使其成为正常运行的管道。供应链领导者希望与您的团队密切合作。他说，“一旦你开始参与，我的业务分析师团队会做得更好。为了支持你，我愿意为你做任何事情，并聘请更多的数据科学家！”
今天，一些很酷的机器学习工作带来了希望。看起来产品团队终于对推荐系统的小测试感到兴奋。之前卡住的原因是产品工程团队无法评估工作，不想投入，而数据团队没有实际的软件技能将其带入生产业务。
数据团队更深入地解决了这个问题，以真正构建演示。这样一来，不仅离生产更近了，潜力也更加清晰。当这些项目停滞不前时，数据团队很容易感到失败，就像他们被雇用来做人工智能工作，但现在没有管理层的支持。随着时间的推移，我认为他们没有主动让工作变得有价值和更容易交付的情况越来越普遍。
另一件事是关注供应链团队在做什么。这个过程是这样的：
请注意，当您开始将生产数据库表直接转储到数据仓库时，您会承担大量“技术债务”。下游数据消费者将有很多损坏的 SQL 查询。随着时间的推移，您必须在两者之间添加某种层，从生产数据库中提取元数据并将其转换为各种派生数据集，使其更稳定且更易于查询。从安全角度来看，这是必要的：您需要从生产数据中分离出大量 PII。
终于迎来了转机
这是第三季度计划会议。在此之前，这些会议经常变成关于公司未来几个季度重要方向的大辩论。这一次，您首先浏览了公司高层的关键成果。每个团队都有子级指标，从而对高级指标进行更细化的划分。
显然，您的工作和产品管理团队取得了成效。产品经理经常提供证据，证明他们对各种项目的投资是合理的，因为他们在运行测试时学到或在数据中发现了什么。
一项重要成就是，您的一位数据科学家与结帐团队合作发现了一个严重错误，即用户单击确认页面上的“返回”按钮，最终导致购物车对象出现问题。解决了这个问题后，转化率有了很大的提升。
另一个见解是，来自不同广告系列的流量在登陆网站后可能会导致非常不同的转化。事实证明，有些网站的点击价格低，但转化率低。有些广告系列很昂贵，但这些用户的转化率很高。
由于您现在正在跟踪 UTM 参数并将其与帐户创建相关联，因此您现在可以衡量广告点击购买转化率。除非所有数据都进入同一个数据仓库并进行规范化以便您可以轻松查询，否则这是无法做到的。目前，主要的 KPI 是与营销团队合作的端到端客户获取成本，而不是每次点击成本。
另一个令人振奋的消息是，推荐系统的 1% 测试非常好。虽然将其扩展到 100% 的用户是一个非常重要的项目，但 CEO 为该项目开了绿灯。
当然，并非所有结果都是阳性的，也有一些不成功的测试不成功，但总体情况是阳性的。
经过这么长时间，您已经将您的组织转变为真正的数据原生架构。数据团队与许多不同的利益相关者进行跨职能合作。数据和洞察力用于规划，使用数据来推动业务价值，而不是目标不明确的独立研讨会。该公司以迭代的方式工作，而不是一个大型的“瀑布”计划，具有快速的数据驱动反馈周期。度量的定义让人觉得产生商业价值是一种责任。数据文化由上层（CEO 驱动）和下层（基层员工）共同推动。失败并没有错，至少你可以从中吸取教训。
关于作者：
Better 的前首席技术官 Erik Bernhardsson 目前正在研究数据领域的一些创业想法。他写了很多代码，其中一些最终是开源的，比如 Luigi 和 Annoy。他还共同组织了纽约市机器学习聚会。
原文链接：
