很多人谈论数据的未来将以产品为中心。
这意味着将数据视为产品——使其与业务价值保持一致，使其可访问，提高可用性，确保安全性以及人们在谈论产品管理时提到的所有其他事项。
无论你将数据产品定义为分析解决方案(经典定义)还是可访问数据集(数据网格方法)，你都会关注这些维度。但问题是数据产品交付很难。以最近的人工智能热潮为例。每个有一定预算的大型组织都成立了一个团队来交付人工智能产品，以为他们会成为下一个 OpenAI。一年后，许多团队解散了，大量项目结束，大多数产品没有展现出承诺或预期的价值。
问题并不局限于人工智能。作为一名顾问，我公司很大一部分收入来自为无法自己做数据产品的客户构建数据产品。这些产品包括仪表板、报告工具、机器学习算法和其他分析解决方案。
无法内部交付的原因是什么?
公司尚未找到正确的交付运营模式。他们的瀑布式流程不符合业务需求，一遍又一遍地喊着敏捷却没有正确实施，这是行不通的。此外，他们缺乏构建数据产品所需的基础要素。
因此，今天我们将对此进行分解，并解释如何通过正确的运营模式和交付流程构建可用于生产的数据产品。
什么是数据产品在深入研究之前，我们必须简单解释一下我们正在构建什么。
正如我所提到的，数据是一个动态的生态系统，其中每个领域都对整体做出贡献，并受到整体的影响。这个生态系统包含不同类型的参与者和利益相关者，以与数据和彼此之间的复杂关系为标志。
因此，您必须采取一种涵盖数据格局和更大业务环境的整体方法。因此，从最纯粹的意义上讲，数据产品必须是一种工具或解决方案，最终业务用户可以从中获取见解并做出决策。
为了解释这一点，我定义了六种最受欢迎的数据产品类别：
您可以将不同的数据产品映射到四个分析级别。
仪表板
可视化界面，实时整合并显示关键绩效指标 (KPI)、指标和数据趋势。
报告工具
生成结构化报告的技术，通常总结历史数据并根据业务需求提供分析。
自助分析平台
使非技术用户能够独立探索、分析、可视化和使用数据的工具。
预测模型
使用历史数据和机器学习算法来预测未来结果、趋势或行为的分析工具。
自动决策引擎
这些自动化算法解决方案通常利用预测模型，并与技术相结合，无需依赖人工干预即可做出决策。
人工智能产品
基于机器学习/人工智能技术(例如自然语言处理、计算机视觉、大型语言模型等)构建的应用程序或系统，用于解决复杂问题、增强用户体验或自动执行任务。这些产品从数据中学习并适应新信息，从而为用户提供更好的结果。
与数据即产品的观点相反，我将这些解决方案视为产品，将为这些解决方案提供数据视为原材料。这些原材料经过加工和整理，可提高业务利益相关者使用的最终产品的价值。
📝编者注：
数据产品不同于传统的可消费数据，因为它是数据基础设施的垂直部分，横跨整个堆栈，从摄取点和基础设施资源到最终消费端口。这是为了实现互操作性和可重用性。正如 Dylan 所强调的那样，原始数据类似于该产品的原材料。
示例：作为数据产品的仪表板是与
(1)基础设施
(2)运行仪表板的代码
(3)可供使用的数据 + 元数据
(4)输出端口(其中所述仪表板等于 o/p 端口)相结合的仪表板。
基础数据产品组件
既然我们已经定义了什么是数据产品，我们就可以去构建它们了，对吗?大多数人会理所当然地说：“不，你不能。”不幸的是，这些人还是会这么做，因为领导层想要“证明价值”和“成为数据驱动型”。
因此，团队不能直接开发数据产品，而是需要确保基础到位，以便以可扩展且有影响力的方式进行构建。
在谈论数据产品交付时，在设计、构建和生产阶段之前您应该具备四项基础能力：
(1)战略协调
第一步是了解更广泛的业务目标、支撑该目标的数据策略以及业务利益相关者的需求。通过从一开始就与业务领导者和利益相关者进行访谈和研讨，您可以确保产品在战略上保持一致。这不会随着发现阶段而结束;与这些利益相关者预约签到和更新，以促进认同和用户接受。
(2)基础设施、建筑和工程
下一步是数据产品下面的基础工具。团队需要按顺序考虑四件事。首先，组织内的整体企业和技术架构是什么?希望组织已经战略性地构建了其技术堆栈，并且拥有从源头到消费端的清晰数据流，并拥有正确的工具来满足业务需求。其次，构建一些与业务模型或已识别数据产品的最相关业务流程相关的概念、逻辑和物理数据模型……第三，考虑解决方案架构，将业务需求转化为技术规范和功能需求，特别是数据产品设计/构建如何与组织的基础架构保持一致。第四，工程。利用数据建模和解决方案架构中的设计，工程团队应该能够设计和构建可根据数据产品要求扩展的高质量数据资产。
(3)数据与产品治理
治理可确保您的数据和底层产品在构建时充分考虑质量、安全性、可扩展性和可用性。框架应概述产品的所有权，并将其与相关数据所有者和管理员联系起来。将此所有权与整体数据模型和解决方案架构相结合有助于在数据沿袭映射中实现透明度，并为正确的文档提供基础。
(4)数据管理
建立治理后，需要进行数据管理以保持输入产品的数据质量。很多事情都属于这一类(尤其是因为数据管理是一个模糊的术语)。不过，在这种情况下，重点应该放在主数据管理、数据质量标准化和可观察性上。如果没有这个组件，您将得到经典的“垃圾进，垃圾出”结果。
数据产品运营交付模型
因此，在正确定义数据产品并建立基础组件之后，就该深入研究数据产品运营交付模型了。
这是数据产品交付的高层视图，但它解决了最佳实践交付方法中的主要考虑因素。
我将运营模式分为三个不同的阶段，每个阶段有两个步骤。这样一共六个步骤，每个步骤包含多项活动和可交付成果：
第一阶段是确定数据产品的范围。这涉及定义数据产品背后的原因和方式。在开始构建产品之前，团队需要发现问题/机会并确定数据产品的设计范围，以增加业务价值。
(1)发现
了解该数据产品试图解决的问题或它为更广泛的业务带来的机会。
.每个数据产品都需要从业务的战略目标和产品解决的问题定义开始。最好的参考点是现有的数据策略或业务/团队目标，它们有助于决定为什么需要构建产品。
.确定这一点的最佳方法之一是开展利益相关者参与活动，如访谈、需求研讨会或初步研究(例如用户测试、流程图等)。总结从这些活动中获得的见解可以为产品需要做什么以及它可能如何运作提供基础。
.这些来自战略和利益相关者咨询的见解有助于确定业务和技术可行性。在这里，产品交付团队需要确定数据产品的优先级和潜在价值，将他们的专业知识投入到构建产品所需的工作中，并决定是否可行开始设计。
.可交付成果
1.业务需求——了解数据产品需要交付什么才能实现业务价值，以及它将衡量(或衡量)哪些 KPI
2.访谈报告——从利益相关者访谈中获得的关于他们当前业务需求、现有流程中的痛点以及他们已确定的潜在解决方案的见解
3.用户故事——在故事中捕获的需求，展示业务和产品用户将如何与产品交互以及如何使用产品
(2)设计
将发现阶段的见解转化为需求和设计文档，为产品交付提供明确的指导。
.在设计阶段，产品团队应继续在业务和技术可行性中添加非功能性和功能性要求。这也将融入初始产品线框/设计，提供产品外观、功能、输入数据、回答/显示的相关 KPI 等视图。与最终用户一起映射和验证设计至关重要。不过，也必须避免过度设计此阶段，并确保反馈是建设性的而不是消极的。
.接下来，将数据产品与组织数据模型和平台/解决方案架构相结合至关重要。确保产品的构建方式与其他产品一致，并且整个平台能够实现效率、可扩展性和互操作性。
.设计基础到位后，下一步就是制定切实可行的交付计划。考虑最佳交付模式(如何组建团队来交付计划以及方法是什么)以及如何将其与产品开发保持一致。了解现有的工作流程和交付流程，以便与所有必要的人员进行适当的协作。报告线和组织结构应使团队之间能够相互理解，帮助确定谁需要参与以及指导交付所需的领导力。
.可交付成果
1.数据模型和流程图——模式和流程图，展示数据如何融入业务流程
2. 产品要求——产品的技术和数据要求，将业务需求与实际数据交付工作联系起来
3. 交付计划——开发团队如何构建和测试产品的详细计划，包括涉及的利益相关者、专家、治理和时间表
第二阶段是构建数据产品。这应该以迭代方式进行，以便获得业务利益相关者的反馈。同时，它需要利用现有的基础，在投入生产之前，测试和验证起着关键作用。
(1)构建
使用经过验证的设计来迭代开发数据产品(后端和前端)，并通过冲刺来确保与用户和相关利益相关者保持一致。
.虽然许多公司都在谈论以敏捷方式构建，但真正的敏捷交付要复杂得多。敏捷交付冲刺始于设计阶段构建的交付计划。敏捷交付以 1-2 周的冲刺为设计周期，意味着采取以用户为中心的方法(例如，用户故事、用户测试和反馈)，并考虑灵活性，允许团队根据业务/用户的最新需求重新确定优先级。
.敏捷交付由 Scrum 主管或交付负责人领导，他们定义明确的成功指标、规划敏捷仪式(冲刺计划、站立会议、评审、回顾)，并利用跨职能团队为数据产品开发带来正确的专业知识。
.敏捷交付冲刺中的前两个开发活动是数据采购和管道集成(后端)以及功能开发(前端)。
.首先，在后端，数据工程师可以构建管道来连接主要数据存储解决方案和拟议的前端解决方案。工程师应咨询任何数据治理和管理专家或指导，以确保在提取过程中设定和维护质量标准。
.接下来，在前端，分析师应该开始使用用户故事、访谈报告和产品需求/线框来构建团队将与之交互的所需功能。功能的增量构建和签入在这里很重要，以确保数据产品将被使用，用户被纳入流程/最终解决方案，并且数据分析师正在与用户分享他们的专业知识，说明为什么以某种方式构建事物。
.在真正的敏捷方式中，后端和前端团队应该相互合作，以确保两个工作流以一致的方式完成。
.可交付成果
1. 概念验证 (POC) — 产品解决方案的初步版本，用于展示其可行性和潜力。此版本需要展示价值以保证进一步投资。
2. 最小可行产品 (MVP) — 包含大多数功能的数据产品的基本版本。允许用户提供反馈，以便开发团队进行迭代和改进。
3. 前端应用程序 — 数据产品面向用户的部分，为反馈提供更切实的解决方案。这将包括在 POC 和 MVP 开发中。
(2)测试与验证
确保输入产品的数据符合质量要求，同时确认业务需求的前端要求。
.整个步骤仍然属于敏捷交付冲刺的范围，主要交付团队会验证正在构建的内容是否按设计运行。
.与开发一样，测试和验证也有两个方面。数据质量测试和 Stagegate 实施应与数据来源和管道构建保持一致。持续集成和持续部署 (CI/CD) 方法将确保管道开发具有自动化流程来检测代码问题。这应该与数据治理或管理团队设定的质量标准保持一致。还可以设置数据生命周期内的数据质量阶段，以验证通过管道传输到最终产品的数据是否符合要求。
.此步骤的另一面是用户验收测试，其中分析师和业务利益相关者确保产品满足他们的需求。这应该在每个冲刺结束时进行，并举办研讨会来汇集想法并提出如何提高可用性的想法。
.迭代改进是测试的顶峰。在收集反馈后，团队应该改进和完善产品。实际上，这是一项持续的活动，应该在整个敏捷交付冲刺中进行。
可交付成果
1.产品验证——经过用户测试的产品，并附有关于如何测试和改进的详细规范
2. 是否通过决策——领导层根据 UAT 结果和其他反馈，决定产品是否已准备好投入生产
第三阶段是数据产品的运营和优化。这需要仔细监控产品发布，以防止最后一刻出现故障或问题。然后，团队需要了解用户是否了解如何使用数据产品，以及它是否符合既定目标，从而帮助进一步改进。
(1)产品化与部署
将数据产品部署到可供最终用户使用的实时环境中
一、在准备上线时，团队应确保环境协调一致。这需要将开发/测试环境与生产环境相匹配，并应包括：
1. 配置生产服务器和数据库
2. 设置必要的软件和依赖项
3. 授予正确的访问控制
4. 创建安全规则和措施
5. 验证集成和连接在生产环境中是否正常工作
二、最后，到了最终部署的时候了，将数据产品移至生产环境。在按下“开始”按钮之前，开发团队应该进行任何最终检查和验证。如有必要，还可以考虑分阶段推出，尤其是对于更复杂的发布。团队还可能包括回滚计划，以防出现意外发布问题。哦，不要在周五发布。
三、监控设置提供了指南和工具，帮助您了解数据产品的性能、使用情况和问题。其中可能包括错误跟踪、日志记录、使用情况仪表板、关键问题警报和性能阈值。
四、在监控的同时，应向所有数据产品用户推出用户培训和文档。最佳实践是在敏捷冲刺阶段开发这些培训材料。用户问题的支持渠道、培训课程、产品拥护者/所有者和用户手册都是需要考虑的因素。
无、可交付成果
1.实时数据产品— 最终用户可以访问的完全可操作的产品
2. 产品测试计划 — 测试和了解产品团队如何在上线后监控数据产品的计划(指标、KPI)
(2)持续改进
寻求实时数据产品的反馈并实施更新以增强和优化其有效性。
.持续改进并不是真正的步骤;它更像是一种持续改进数据产品的方法。这是通过用户反馈循环实现的，其中收集持续的评论、建议和性能数据以输入到产品的未来设计/迭代中。
.这种反馈应由数据产品负责人/经理推动，在投入生产后被任命负责数据产品。这种反馈循环需要从用户扩展到其他数据团队，因为安全政策、数据质量标准、平台基础设施等的变化都会影响产品管理。
.除了用户反馈之外，产品所有者/经理还应关注产品跟踪和投资回报率报告。数据驱动应该延伸到了解您的数据产品是否有助于实现价值并实现业务目标。这建立在监控设置活动的基础上。
可交付成果
1. 用户反馈 — 用户对现有痛点、改进机会和最佳实践的见解，用于指导产品更新
2. 产品更新 — 根据用户需求和 KPI 输出对产品提出的建议。这些建议应切实可行，以促进预期的改进。
3. 使用和价值 KPI — 通过仪表板或报告提供准确的指标，展示数据产品在业务目标和需求方面的性能
数据产品并不是一个容易的话题。对于许多用户来说，它们是数据生命周期的终点，数据生态系统中的一切都指向它们。
这就是为什么数据产品这一主题以及正确使用它如此重要!当试图证明数据的商业价值时，基础和运营交付模型对于确保数据产品得到使用至关重要。
如何在数据生态系统中运营数据产品的...
