采用将数据视为产品的组织方法不仅仅是数据行业的流行趋势，也是有意识的思维方式转变，可以提高数据*化和自助服务的能力，提高数据质量，从而可以准确地做出决策，并扩大数据在整个组织中的整体影响。
在过去的几十年里，大多数企业都将数据保存在孤岛中。数据分析团队为业务部门服务，即使数据对决策变得越来越重要，数据团队依然像是提供服务的角色，而不是合作伙伴。在数字经济时代，数据对企业来说不再是次要角色。凭借更好的工具、更多样化的角色以及对数据潜力的更清晰理解，许多企业已经开始将整个数据生态系统视为公司技术堆栈中必要的元素。最具前瞻性的团队正在采用一种新范式：将数据视为产品。这是目前数据社区的热门话题，几位行业领导者讨论了数据即产品并揭示了他们在现实世界中对数据的看法并将这种新方法带入日常工作。
行业领导者如何将数据定义为产品
西雅图的货运市场 Convoy 的数据平台产品负责人查德·桑德森：
围绕将数据视为产品的定义，有两种方法：第一种方法，有一个外部或内部的产品或服务来生成数据，这意味着数据包括整个管道是产品的一部分。因此它必须遵守与应用程序代码相同的严格级别。它需要 SLA，需要良好的测试，需要良好的监控和文档等等。第二种方法，可以将任何为客户提供服务的代码库的输出视为产品。例如，数据仓库实际上只是一个代码库，主要由 SQL 组成，为使用该数据做出业务决策的其他分析师、数据科学家和产品经理等内部客户提供服务。因此，任何被推送到公司可以访问的“生产数据环境”的都是产品。因此，如果正在使用像 Mode 或 Metabase 这样的仪表板工具，并且正在编写 SQL 并将该仪表板推送到其他人可以访问的公共环境，那么这也是一种产品。因此，它也必须受到与任何其他产品相同的严格程度。这两种方法都与过去 10 年或 20 年前对数据的思考方式截然不同。
Uber 数据平台团队前产品经理Atul Gupte对数据产品经理的定义：
“数据产品经理是专门负责回答以下问题的角色：
存在哪些数据?
谁需要这些数据?
这些数据流向哪里/从哪里流出?
这些数据有什么用?
有没有一种方法可以更轻松地使用/访问这些数据?
该数据是否合规和/或可操作?
我们如何才能更快地让数据对公司的更多人更有用?
数据产品经理通过为员工构建内部工具和平台来回答这些问题。
一些数据产品经理支持数据分析师和数据科学家，另一些则支持运营团队、软件团队或者高管。他们通常来自传统 B2B 产品管理、内部工具产品管理、数据分析或后端工程等背景。但是，不是在与我们传统上定义为“客户”的人打交道，而是在与“数据消费者”打交道——换句话说，员工使用的产品可以理解公司的数据。
Retool 的数据负责人Justin Gage：
数据作为产品的概念可以帮助澄清数据团队做什么以及他们应该专注于执行什么任务的问题。“数据即产品 (DaaP) 是最容易理解的模型：数据团队的工作是提供公司所需的数据，无论出于何种目的，无论是制定决策、构建个性化产品还是检测欺诈。这听起来像是数据工程，但事实并非如此：数据科学家还提供数据作为产品，只是以不同的方式打包。
在 DaaP 模型中，公司数据被视为一种产品，数据团队的作用是以促进良好决策和应用程序构建的方式向公司提供该数据。该模型的一些重要特征：
-
数据具有来自整个数据团队的 SLA
-
数据流是单向的，从数据团队到公司
-
领域专业知识对数据团队成员的作用
虽然这些定义中的每一个都有其自身的细微差别，但显然有一些关键要点：将数据视为产品涉及服务内部“客户”(数据消费者)，支持决策制定和其他关键功能，以及应用 SLA 等严格标准。
实现数据即产品方法的 5 种方法
从这些数据领导者和其他人的对话中，可以确定现代数据团队可以将这种方法应用于他们自己的组织的五种关键方式。
1) 与利益相关者保持一致
当数据是产品时，内部客户也是利益相关者。在制定数据产品路线图、制定 SLA 并开始将数据视为产品时，优先与关键数据消费者合作。
这意味着产品经理将作为企业专门负责数据产品管理的角色——以充分了解内部客户的需求、关注点和动机。
需要清楚地了解谁在使用数据、如何使用以及出于什么目的。这将帮助了解需要构建哪些类型的数据产品来满足这些需求。
这种理解还可以帮助我们采用数据讲故事。软件、产品和用户体验团队使用讲故事的做法，通过不同的视角来分享他们的工作背景，这将帮助利益相关者根据对他们最重要的事情来理解其价值。利益相关者数据应该被优先考虑，并证明将数据视为产品所需的投资是合理的。
例如，查德·桑德森 (Chad Sanderson) 将讲故事描述为一种非常宝贵的工具，可以说服利益相关者投资于数据基础设施，而不是更华丽的机器学习模型或有望产生数百万美元的新功能。
“要扭转这种说法并将数据质量置于同等地位需要做很多工作……在某些情况下，我通过关注我们公司的故事以及我们的数据科学家和分析师的故事来解决这个问题。当他们建立模型时，这些模型真的值得信赖吗?我们在多大程度上信任构成驱动我们业务决策的机器学习基础的数据?所以我试着讲一个非常好的故事，一个紧凑的叙述，并附有来自公司的明确例子，这些例子实际上与产生收入有关。所以最终我们可以说，看，提高我们的数据质量可能对收入产生可观察、直接、可衡量的影响。
2)应用产品管理思维
将产品管理思维应用于构建、监控和衡量数据产品的方式。因此，在构建管道和系统时，请使用与生产软件相同的经过验证的流程，例如创建范围文档并将项目分解。
Ironclad 的首席数据分析师Jessica Cherny描述了她公司的敏捷工作流程。
“我们在内部将数据视为一种产品，这意味着将产品管理原则应用于数据和数据团队。因此，当我们有一个需要数据的大型战略项目时，我们会创建数据范围文档，就像产品经理会创建规范一样，并与合适的利益相关者一起。我们不断与工程师和产品经理进行迭代，以确保它是跨职能的、与利益相关者保持一致的输出——而不是让数据人员在孤岛中工作而不与任何人互动。”
与工程流程类似，数据团队在构建管道时应考虑可扩展性和未来用例。根据 Chad 的说法，这可能代表着数据团队过去处理工作方式的重大转变。
“通常情况下，实际进入生产数据库的数据只是工程师在没有真正考虑的情况下抛出的服务级别事件。因此，随着公司的发展，数据模型变得如此混乱的一个重要原因是，我们通常首先专注于快速构建服务，然后批判性地思考数据。这种将数据作为产品的想法是一种开始改变这种状况的持续转变。”
SeatGeek 的高级数据和分析工程师Kyle Shannon说：由于数据团队的快速增长，他的公司正专注于可扩展性。
“我们真的在努力了解如何更好地吸引新人加入，并制定更好的流程，使数据更容易被发现和访问。在一家公司工作了很长时间的人知道去哪里寻找信息，但如果你一年雇用 20 或 30 名数据团队成员，真的很难说。因此，在构建数据产品时，必须记录所有内容并确保非常清楚——正在删除冗余或可能在此过程中发现的任何问题。”
要采用的另一种产品思维方式是在开始构建任何新数据产品之前设置与业务目标一致的 KPI。正如 Chad 之前所述，讲故事有助于说明投资数据质量的潜在好处，但大多数组织仍希望成熟的团队能够衡量其计划的财务影响。
许多数据团队正在采用与数据质量相关的 KPI，例如计算数据停机的成本，数据不完整、错误、丢失或其他不准确的时间，或者通过衡量数据团队成员花费在故障排除或修复数据质量上的时间问题，而不是专注于创新或构建新的数据产品。
为数据设置基线指标将有助于量化数据计划随时间的影响。只需确保这些指标在所有用例中一致应用，尤其是拥有*数据平台的情况下。
3) 投资自助服务工具
为了让数据脱离孤岛并作为有价值的产品来处理，业务用户需要能够自助服务并满足他们自己的数据需求。使非技术团队能够访问数据的自助服务工具使数据团队能够专注于增加价值的创新项目，而不是作为满足临时请求的按需服务。
自助工具也是数据网格概念的主要原则之一——一种去中心化数据架构的新方法。Mammad Zadeh是 Intuit 数据平台团队的前工程副总裁认为自助服务工具是数据架构和数据产品不可或缺的一部分。如他所建议的那样，“我们在*数据团队中，应该确保数据的生产者和消费者都可以使用正确的自助服务基础设施和工具，以便他们可以轻松地完成工作。为他们配备合适的工具，让他们直接互动。”
4)优先考虑数据质量
将数据作为产品处理的一个关键组成部分是将严格的标准应用于整个生态系统，从摄取到面向消费者的数据交付。正如我们之前在讲故事的背景下所讨论的那样，这意味着在整个数据生命周期中优先考虑数据质量和可靠性。
公司可以通过根据数据可靠性成熟度曲线映射他们的进度来评估当前的数据质量状态。简而言之，该模型表明数据可靠性有四个主要阶段：
#1 反应型，团队将大部分时间花在响应消防演习和分类数据问题上——导致重要计划缺乏进展，组织难以在其产品、机器学习算法或业务决策中有效使用数据。
#2 主动型，团队在工程、数据工程、数据分析师和数据科学家之间积极协作，开发手动检查和自定义 QA 查询以验证他们的工作。例如可能包括在管道的关键阶段验证行计数或跟踪时间戳以确保数据新鲜。当出现问题时，消息或电子邮件警报仍然会弹出，但这些团队确实通过他们的主动测试发现了许多问题。
#3 自动化，在这个级别，团队通过提供更广泛的管道覆盖范围的计划验证查询来优先考虑可靠、准确的数据。团队使用数据健康仪表板来查看问题、排除故障并向组织中的其他人提供状态更新。例如跟踪和存储有关维度和度量的指标以观察趋势和变化，或者在摄取阶段监控和执行模式。
#4 可扩展，这些团队利用经过验证的 Dev Ops 概念来建立暂存环境、用于验证的可重用组件或针对数据错误的硬警报和软警报。通过大量覆盖关键任务数据，团队可以在影响下游用户之前解决大多数问题。例如跨所有关键指标和工具的异常检测，监控和跟踪每个作业和表的质量。
达到数据成熟度并非一蹴而就。但是，通过开始设置衡量质量的明确数据 SLA、SLI 和 SLO，可以开始展示投资于自动化、可扩展的数据可靠性的价值。常见数据健康指标的包括特定资产的数据事件数量、检测时间和解决时间。
如前所述，在设置 SLA 时让数据利益相关者保持一致至关重要 — 确保“可靠性”对数据消费者意味着什么、哪些资产最重要以及哪些潜在问题需要最直接的关注达成共识。
5)建立合适的团队结构
当然，团队结构会对组织日常与数据交互的方式产生巨大影响。是否有一个集中的数据团队来处理数据管理和应用的各个方面;还是跨业务部门的分析师，满足特定需求并获得领域专业知识 –这种模式将遭受缺乏凝聚力治理的困扰。
不同的公司将根据其规模和业务需求需要不同的方法，但许多数据领导者已经通过联邦模型找到了最佳结果。在这种结构中，一个集中的数据平台团队处理基础设施和数据质量，而分散的嵌入式分析师和工程师处理语义层并将数据应用于业务。如果组织正在快速发展并需要快速行动，则此模型很有效，但也可能会导致嵌入式分析师部分重复和重复工作，而无法与集中数据团队保持一致。
软件 Toast 的商业智能高级总监Greg Waldman带领他的团队完成了为期五年的组织演变，其中包括从集中式到分散式再到联邦式模型的转变。他建议成长型公司的数据领导者遵循产品管理的一个关键原则——保持敏捷。
“简而言之，我对数据团队的看法是，希望每个人都尽可能多地增加商业价值。我们一直非常乐于改变并尝试不同的事情，并且理解什么适用于 200 人、500 人和 1000 人是不同的答案，这没关系。当达到这些拐点并需要尝试新事物时，这可能会有些明显。”
对于 Jessica Cherny 来说，分散的分析师和工程师的优势在于他们能够理解数据请求背后的真正业务需求。
“我想了解如何设计真正满足他们需求的可交付成果。这是最近发生的，当时有人要求我在一项战略计划中立即获取一组特定的数据。我说，‘等等，等等。我真的需要使用这种复杂的聚类方法来回答这个问题吗?这样做的实际需要是什么——这样我就不必放弃手头的所有工作，并且可以及时有效地为您服务?我们最终完全重组了她的问题，因为我更好地理解了她问题背后的业务需求，以及如何以简单易懂的方式回答这个问题。”
同样，每家公司都有自己的文化背景和需要应对的挑战，但联邦式模型可以帮助成长中的团队快速行动以满足业务需求，而无需放弃数据质量和治理的所有权。
小结
采用将数据视为产品的组织方法不仅仅是数据行业的流行趋势，也是有意识的思维方式转变，可以提高数据*化和自助服务的能力，提高数据质量，从而可以准确地做出决策，并扩大数据在整个组织中的整体影响。