1.1. 随着企业摄取越来越多的数据，数据分析也逐渐成为企业战略的重要组成部分，对高质量数据的需求只会不断增加，这给数据工程师、分析工程师，甚至数据分析师都带来了压力，要求他们承担起这个重要但富有挑战性的任务

1.2. 只有整个公司都认为数据是可信的，才能实现数据信任

1.2.1. 和一共运行了多少数据质量测试没什么关系

1.3. 几乎所有团队都是由数据驱动的，但在追踪、执行和扩展数据质量计划方面，承担大部分工作的往往还是数据团队

1.4. 数据质量不仅仅是构建更可靠的数据管道并为数据新鲜度设置(SLA)

1.4.1. 数据质量既是技术方面的流程，也是文化方面的流程

1.4.2. 其关键并不在于拥有完全准确的数据，而是在于理解我们能在多大程度上信任数据

1.5. 在数据质量的推广和普及方面，让使用数据变得尽可能地简单和可迭代会很有帮助

1.6. 像对待产品级软件一样来认真对待你的数据

2.1. 在过去几十年中，大多数公司将数据保存在组织的信息孤岛中

2.2. 分析团队服务于业务部门，即使数据在决策制定和产品路线图方面变得更为关键，负责数据管道的团队也多被视为管道工人，而非合作伙伴

2.3. 数据已经不再是二等公民了

2.4. 将数据视为一种产品

2.5. 成果

2.5.1. 提高数据的可访问性（在人们需要时，将数据呈现出来）

2.5.2. 加大数据的推广和普及（让人们更容易操作数据）

2.5.3. 让数据产生更快的投资回报率（更快地获得洞察）

2.5.4. 为数据团队或数据消费者节省时间

2.5.5. 更精确的洞察（即实验平台）

2.6. 重要特征

2.6.1. 可靠性和可观测性

2.6.2. 可规模性

2.6.2.1. 随着组织和需求的增长，数据产品应该具有规模上的弹性

2.6.3. 可扩展性

2.6.4. 易用性

2.6.4.1. 优秀的SaaS产品注重提供出色的用户体验

2.6.4.2. 易于学习、便于使用并能快速完成工作

2.6.5. 安全性和合规性

2.6.5.1. 数据泄露是昂贵而痛苦的，违反监管规定的罚款也是如此

2.6.6. 发布规程和路线图

2.6.6.1. SaaS产品会持续演变和改进

2.6.6.2. 在构建路线图时至少要展望一年后的情况，并采用强有力的质量保证流程进行更新

3.1. 数据驱动着产品路线图，支持着高层决策，并为付费营销活动提供了信息

3.2. 来自公司内部和外部的数据不断流入和流出

3.3. 没人负责开发数据解决方案，使数据分析具有可操作性、可扩展性和可访问性

3.4. 数据质量是头等大事，而达成这个目标的方式在很大程度上源于将数据视为产品

3.5. 数据即服务或输出

3.5.1. 由职能团队和团队中的分析师来负责确保数据质量、数据可用性和性能

3.5.2. 将数据视为不断演变的跨学科实体的过程和工作流将成为行业标准

3.5.3. 数据以两种不同的方式被视为产品：作为服务或输出

3.5.4. 任何推送到公司内部可访问的“生产数据环境”的东西都是产品

3.5.5. 据不再是一个孤立的实体，而是一项微服务

3.5.5.1. 不同的业务功能会在多个用例中利用相同的数据，并且数据团队之外的更多用户实际上也会访问这些数据

3.5.5.2. 据也经常被用在公司决策之外的用例中：为金融产品赋能，向用户展示相关广告，甚至生成在线观看的电影和电视节目列表

3.5.6. 在任何一种用例下，团队都需要优良的数据测试、清晰的SLA、SLI和SLO，以及全面的文档记录和监控

3.5.7. 期待数据是可靠的，而如果它不可靠，我们应当通知数据团队和利益相关方，并提供解决问题的工具

3.6. 数据产品经理的崛起

3.6.1. 数据作为其竞争优势，并利用数据为用户提供更可靠、更量身定制的使用体验

3.6.2. 从构建实时定价模型的数据科学家到建立预报模型以预测司机需求的业务分析师等不同职位

3.6.3. 将数据视为生产软件：它可以被公司内的多个团队使用，而非一组仅能支持分散用例的分散服务

3.6.3.1. 在传统的软件公司中，产品经理负责管理软件解决方案从构思到实现的全过程

3.6.4. 数据产品经理负责数据的推广普及和增加数据本身的价值

3.6.4.1. 设计、构建和管理数据平台或一套特定数据工具的跨职能开发，以服务于多个用户

3.6.5. 问题

3.6.5.1. 存在哪些数据？

3.6.5.2. 谁需要这些数据？

3.6.5.3. 这些数据从哪里来，流向哪里？

3.6.5.4. 这些数据的目的是什么？

3.6.5.5. 是否有一种方法能更简单地处理或访问这些数据？

3.6.5.6. 这些数据是否合规并可操作？

3.6.5.7. 如何让数据更快、更有效地为公司内的更多人提供帮助？

3.6.5.8. 主要目的是确保上述问题得到解答，并由此生成可靠、新鲜、可用的数据，将其交付给需要的人

3.6.6. 数据产品经理需要满足利益相关方（数据分析师、数据科学家和运营团队等）和公司高管的需求

3.7. 采用“数据即产品”的方法

3.7.1. 尽早并经常与利益相关方达成共识

3.7.1.1. 当数据是你的产品时，你的内部用户也是你的利益相关方

3.7.1.2. 有助于你进行数据叙事

3.7.1.2.1. 软件、产品和用户体验团队使用叙事来通过不同视角分享他们的工作情境，从而帮助利益相关方从其最关心的方面出发，理解他们的工作价值

3.7.1.2.2. 数据叙事是非常有价值的工具，它能帮助你说服利益相关方着力于数据基础设施的建设，而不是选择光鲜亮丽的机器学习模型，或者某种承诺能产生数百万美元的新功能

3.7.1.3. 数据质量与营收之间的联系总是不太明显

3.7.1.3.1. 数据被独立管理，而利益相关方不得不接受他们只能访问少量数据的无奈

3.7.2. 应用产品管理思维

3.7.2.1. 将产品管理思维应用于构建、监控和评估数据产品中

3.7.2.2. 在构建数据管道和系统时，你也应该使用与产品级软件相同的经过验证的流程

3.7.2.3. 数据模型变得混乱的主要原因之一就是我们通常首先专注于快速构建服务，而没有仔细地对数据进行思考

3.7.2.4. 在开始构建任何新的数据产品之前，建立与业务目标相匹配的KPI

3.7.2.4.1. 数据叙事可以帮助说明对数据质量进行投资的潜在好处，但大多数组织仍然希望成熟的团队可以评估其数据计划的财务影响

3.7.3. 投资于自助式工具

3.7.3.1. 为了让数据摆脱信息孤岛并成为一种有价值的产品，业务用户需要能够使用自助式工具来满足自身的数据需求

3.7.3.2. 自助式工具可以为非技术型团队赋能，帮助他们自主访问数据，这样你的数据团队就可以专注于增加价值的创新项目，而不是作为按需服务的团队来满足各种临时请求

3.7.3.3. 自助式工具也是数据网格概念的主要原则之一

3.7.3.3.1. 数据网格是一种新的去中心化数据架构方法

3.7.3.3.2. 自助式工具是数据架构和数据产品不可或缺的组成部分

3.7.4. 优先考虑数据质量和可靠性

3.7.4.1. 将数据视为产品的一个关键组成部分是将严格的标准应用于整个生态系统，从数据摄取到面向用户的数据交付

3.7.4.2. 主要阶段

3.7.4.2.1. 响应阶段

3.7.4.2.1.1. 团队在响应紧急情况和处理数据问题上花费了大量时间，从而导致在重要项目上没有进展，进而让整个组织都难以有效地利用数据来创建更好的产品、训练机器学习模型或者进行业务决策

3.7.4.2.2. 积极主动阶段

3.7.4.2.2.1. 在包括工程师、数据工程师、数据分析师和数据科学家的团队之间积极合作，开发手动检查和定制的质量保证查询来验证他们的工作

3.7.4.2.3. 自动化阶段

3.7.4.2.3.1. 通过预定的验证查询来优先考虑可靠、准确的数据，从而可以更广泛地覆盖整个数据管道

3.7.4.2.3.2. 使用数据健康仪表板来查看事故情况，进行故障排除并向组织中的其他人提供数据状态更新

3.7.4.2.4. 规模化阶段

3.7.4.2.4.1. 借鉴了已被验证的DevOps理念，建立了临时的运行环境、可重复使用的验证组件，以及对数据错误的强弱警报机制

3.7.4.2.4.2. 对关键任务数据的大范围覆盖，团队可以在数据事故影响到下游用户前就解决大多数问题

3.7.5. 为你的数据组织找到合适的团队结构

3.7.5.1. 集中式数据平台团队负责基础设施和数据质量

3.7.5.2. 分散的、嵌入式分析师和工程师处理语义层并将数据应用于业务

3.7.5.3. 轮辐模型可以帮助不断壮大的团队快速地满足业务需求，而无须放弃对数据质量和治理的所有权

3.8. 将数据视为产品不是一时的跟风

3.8.1. 一种有意识的思维转变，能够带来有意义的结果

3.8.2. 增加数据的推广普及和自助式服务的能力，提高数据质量，让人们能够准确、自信地做出决策，从而提升数据在整个组织中的影响力