查看原文
其他

谈谈DataOps数据运营的四大核心思想及关键实施步骤

晓晓 数据驱动智能
2024-09-16

数据变得越来越多,传统的数据管理已经力不从心。数据运营正在兴起,有望解决当今的混乱和环境挑战。

让我们面对现实吧——传统的数据管理不起作用。如今,75%的高管不信任自己的数据,只有27%的数据项目是成功的,在所谓的“数据黄金时代”,这些数字令人沮丧。

随着数据的规模和复杂性不断增长,我们正在努力控制它。更糟糕的是,数据团队及其成员、工具、基础设施和用例同时变得更加多样化。结果是我们以前从未见过的数据混乱。

DataOps已经存在好几年了,但现在它很火,因为它可以解决这个问题。

自2015年以来“DataOps”全球搜索的Google趋势数据。横向显示“随时间变化的兴趣”,或搜索兴趣的标准化版本。纵向代表该术语在给定时间和地区的最高流行度。

但数据运营的兴起不仅仅来自分析师。我个人见证了DataOps从未知变成了必备,有些公司甚至围绕DataOps构建了整个战略、功能甚至角色。虽然结果各不相同,但我看到数据团队的敏捷性、速度和成果取得了很大的进步。

一 什么是数据运营

关于DataOps,首先,也许也是最重要的一点是,它不是一个产品,它不是一个工具。事实上,这不是你能买到的任何东西,任何试图告诉你其他情况的人都是在欺骗你。

相反,DataOps是一种心态或文化—一种帮助数据团队和人员更好地协作的方式。

DataOps可能有点难以掌握,所以让我们从一些众所周知的定义开始。

“DataOps是一种协作数据管理实践,专注于改善整个组织内数据管理者和数据消费者之间数据流的通信、集成和自动化。”
—Gartner

“DataOps是指在从基础设施到体验的所有技术层中启用解决方案、开发数据产品和激活数据以实现业务价值的能力。”
—福雷斯特

“DataOps是一种数据管理方法,强调数据工程师、数据科学家和其他数据专业人员之间的沟通、协作、集成、自动化和合作衡量。”
—安迪·帕尔默

正如您所知,DataOps没有标准定义。然而,您会发现每个人谈论DataOps时都超出了技术或工具的范畴。相反,他们关注诸如沟通、协作、合作.、经验、整合。

在我看来,DataOps实际上是将当今日益多样化的数据团队聚集在一起,并帮助他们跨同样多样化的工具和流程进行工作。其原则和流程可帮助团队推动更好的数据管理、节省时间并减少浪费的精力。

二 DataOps背后的四个基本思想

有人喜欢说数据团队就像软件团队一样,他们试图将软件原理直接应用到数据工作中。但现实是,它们截然不同。

在软件中,您可以对所使用的代码进行一定程度的控制。毕竟,是有人在某个地方写的。但在数据团队中,您通常无法控制数据,因为它来自不同的源系统,并且格式不断变化。如果有的话,数据团队更像是一个制造团队,将一堆不守规矩的原材料转化为成品。或者,数据团队可能更像是产品团队,将产品提供给各种内部和外部最终消费者。

我喜欢思考DataOps的方式是,我们如何从其他团队中汲取最佳经验并应用它们来帮助数据团队更好地合作?DataOps结合了精益、产品思维、敏捷和DevOps的最佳部分,并将其应用到数据管理领域。

1.精益

核心思想:通过价值流图减少浪费。

虽然精益的根源可以追溯到本杰明·富兰克林(BenjaminFranklin)1730年的著作,但精益却源自丰田1950年的工作。在第二次世界大战的阴影下,汽车工业以及整个世界正在重新站稳脚跟。对于世界各地的汽车制造商来说,员工过度劳累、订单延迟、成本高昂、客户不满意。

为了解决这个问题,丰田创建了丰田生产系统,这是一个通过消除浪费来节约资源的框架。它试图回答这样一个问题:如何在最短的时间内以最低的成本交付最高质量的产品?其关键理念之一是尽可能消除制造业中的八种浪费——生产过剩、等待时间、运输、工人利用率不足等——而不牺牲质量。

TPS是精益的前身,由JohnKrafcik于1988年提出,并于1996年由研究人员JamesWomack和DanielJones推广。精益专注于价值流图的理念。就像您使用TPS绘制生产线一样,需要详细地绘制业务活动、识别浪费并优化流程以在消除浪费的同时保持质量。如果流程的一部分不能为客户增加价值,那就是浪费——所有浪费都应该消除。

价值流图实际上是什么样的?让我们从现实世界中的一个例子开始。

假设您拥有一家咖啡馆,并且想要改进顾客点咖啡的方式。第一步是规划出顾客点咖啡时发生的所有事情:接受订单、接受付款、煮咖啡、将咖啡递给顾客等。然后,对于每个步骤,您都需要解释什么可以出错以及该步骤可能需要多长时间-例如,客户无法找到他们应该在哪里订购,然后在到达那里后花费长达7分钟的排队时间。

这个想法如何应用于数据团队?数据团队类似于制造团队。他们都使用原材料(即源数据),直到其成为产品(即“数据产品”)并到达客户(即数据消费者或最终用户)。

那么,如果供应链有自己的价值流,那么数据价值流会是什么样子呢?我们如何将这些相同的原则应用于数据价值流图?我们如何优化它们以消除浪费并提高数据团队的效率?

2.产品思维

核心思想:检查您的产品通过“待完成的工作”框架真正完成了哪些工作。

产品思维的核心概念是待完成工作(JTBD)框架,由安东尼·乌尔威克,2005年。

理解这一想法的最简单方法是通过克莱顿·克里斯滕森(ClaytonChristensen)的故事奶昔理论。一家快餐店想要增加奶昔的销量,因此他们尝试了很多不同的改变,例如使奶昔比竞争对手更具巧克力味、更有嚼劲和更便宜。然而,没有任何效果,销售额保持不变。

接下来,他们派人在餐厅里站了几个小时,收集购买奶昔的顾客的数据。这让他们意识到,他们近一半的奶昔在早上8点之前就卖给了单身顾客。但为什么?当他们第二天早上回来与这些人交谈时,他们了解到这些人开车去上班的时间又长又无聊,需要一份可以在开车时在车上吃的早餐。百吉饼太干,甜甜圈太乱,香蕉太快吃不下去……但奶昔正好,因为它们需要一段时间才能喝完,让人们整个早上都饱。

一旦他们意识到,对于这些顾客来说,奶昔的目的或“工作”是在通勤期间提供令人满意、方便的早餐,他们就知道需要让奶昔变得更方便、更饱腹——销量就会增加。

JTBD框架可帮助您构建人们喜爱的产品,无论是奶昔还是仪表板。例如,产品经理的JTBD可能是优先考虑不同的产品功能以实现业务成果。

这个想法如何应用于数据团队?在数据世界中,有两种主要类型的客户:需要更有效地处理数据的“内部”数据团队成员,以及来自较大组织的使用数据团队创建的产品的“外部”数据消费者。

您可以使用JTBD框架来了解这些客户的工作。例如,分析师的JTBD可能是为这些产品优先级决策提供分析和见解。然后,一旦您创建了JTBD,您就可以创建实现该任务所需的任务列表—每个任务都是一个数据价值流,并且可以使用上面的价值流图流程进行绘制和优化。

3.敏捷

关键思想:通过Scrum提高速度,并优先考虑MVP而非成品。

如果您曾在科技公司或任何“现代”公司工作过,您可能使用过敏捷。敏捷于2001年根据敏捷软件开发宣言创建,是一个框架供软件团队规划和跟踪他们的工作。

敏捷的核心思想是Scrum,这是一个基于创建迭代思想的迭代产品管理框架MVP,或最小可行产品。

举个例子:如果你想造一辆汽车,你应该从哪里开始?你可以从进行采访、寻找供应商、构建和测试原型等等开始……但这将需要很长时间,在此期间市场和世界会发生变化,你最终可能会创造出人们实际上并不喜欢的东西。

MVP旨在缩短开发过程。要创建MVP,您需要问JTBD是什么-它真的是关于制造汽车,还是关于提供交通?解决这项工作的第一个、最快的产品可能是自行车而不是汽车。

Scrum的目标是尽快创建可推向市场并用于收集用户反馈的产品。如果您专注于寻找最小解决方案,而不是创建理想或梦想的解决方案,那么您可以了解用户在测试您的MVP时真正想要什么-因为他们通常无法表达他们的实际需求。

这个想法如何应用于数据团队?许多数据团队与组织其他部门分开工作。当他们被分配一个项目时,他们通常会花费数月的时间来研究解决方案并将其推广给公司,结果却发现他们的解决方案是错误的。也许他们得到的问题陈述不正确,或者他们没有设计正确解决方案所需的背景,或者组织的需求在他们构建解决方案时发生了变化。

数据团队如何使用MVP方法来减少这个时间并更快地得出答案?他们如何才能建立运营思维并从利益相关者那里获得早期、频繁的反馈?

敏捷可用于开放孤立的数据团队,并改善他们与最终数据消费者的合作方式。它可以帮助数据团队找到正确的数据,将数据模型投入生产并更快地发布数据产品,使他们能够获得业务用户的反馈,并随着业务需求的变化迭代地改进和调整他们的工作。

4.开发运营

关键思想:改善与发布管理、CI/CD和监控的协作。

DevOps诞生于2009年的VelocityConferenceMovement,会上工程师JohnAllspaw和PaulHammond介绍了如何改进“dev&DevOps运营合作”。当时的传统思维是软件以线性流程移动——开发团队的工作是添加新功能,然后运营团队的工作是保持功能和软件稳定。然而,这次演讲引入了一个新想法:开发人员和运维人员的工作都是支持业务。

DevOps将线性开发流程转变为循环、相互关联的流程,打破了两个团队之间的孤岛。它帮助团队通过一套流程跨两个不同的职能部门协同工作。诸如发布管理(执行设定的“运营标准”以确保质量)、运营和监控(创建监控系统以在出现问题时发出警报)以及CI/CD。

这个想法如何应用于数据团队?在数据世界中,数据工程师和分析师很容易独立运作——例如工程师管理数据管道,而分析师则构建模型——当事情不可避免地出现问题时,他们会互相指责。这不但不能解决问题,反而会导致争吵和怨恨。相反,重要的是让他们在一个共同的目标下聚集在一起——让业务更加由数据驱动。

例如,您的数据科学家现在可能依赖工程或IT来部署他们的模型-从探索性数据分析到部署机器学习算法。借助DataOps,他们可以自行部署模型并快速执行分析-不再有依赖关系。

DataOps解决复杂的问题,帮助日益多样化的技术和业务团队创建复杂的数据产品,从管道到仪表板或文档。

三 如何实际实施DataOps

如今,所有其他领域都有一个集中的支持功能。例如,销售运营和销售支持专注于提高销售团队的生产力、提升时间和成功。DevOps和开发人员生产力工程团队专注于改善软件团队之间的协作和开发人员的生产力。为什么我们没有为数据团队提供类似的功能?数据运营就是答案。以下是如何开始实施它。

1.识别最终消费者

DataOps团队或职能部门不是执行数据项目,而是帮助组织的其他部门从数据中实现价值。它专注于创建正确的工具、流程和文化来帮助其他人在工作中取得成功。

2.创建专用的DataOps策略

当数据运营策略背后有专门的团队或职能部门时,它才是最有效的。该功能中有两个关键角色:

  • 数据运营支持主管:他们了解数据和用户,并且擅长跨团队协作和将人们聚集在一起。数据运营支持主管通常来自信息架构师、数据治理经理、图书馆学、数据策略师、数据传播者,甚至外向的数据分析师和工程师等背景。

  • DataOps支持工程师:他们是DataOps团队中的自动化大脑。他们的关键优势是对数据及其在系统/团队之间如何流动的深入了解,充当自动化的顾问和执行者。他们通常是前开发人员、数据架构师、数据工程师和分析工程师。

3.规划价值流、减少浪费并改善协作

在公司DataOps开始的时候,DataOps领导者可以使用JBTD框架来识别常见的数据“工作”或任务,也称为数据价值流。然后,通过精益,他们可以进行价值流图练习,以识别并消除这些流程中浪费的时间和精力。

同时,敏捷的Scrum理念帮助数据团队了解如何更高效地构建数据产品,而DevOps的想法则展示了他们如何在这些数据产品上与组织的其他部门更好地协作。

创建专用的DataOps策略和功能绝非易事。但如果做得正确,DataOps就能解决当今一些最大的数据挑战,节省整个组织的时间和资源,并增加从数据中获得的价值。

往期推荐

谈谈现代组织如何构建数据治理

从工程视角看迈向数据网格架构的六大问题

大型集团如何构建数据网格架构

对待数据质量的28个原则

数据仓库、DataVault、DataLake、DeltaLake、DataFabric、DataMesh的特点和典型应用场景

一文读懂数据资产目录的典型应用场景和价值|值得收藏


继续滑动看下一个
数据驱动智能
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存