这适用于哪些人？
适用于正在考虑数据目录变更，并且需要明确“为什么现在要变革”的原因，并以业务、用户和治理成果为依据的数据同行。
我担任数据产品经理期间，无论是在航空公司还是在医疗科技行业，都一直有一个梦想：能够在了解数据上游来源的同时，迭代改进数据资产，并管理变更对下游用户的影响。
我也曾梦想，在加入任何一家新公司时，都能找到可靠且集中化的关键概念定义，并有充分的文档记录。作为一名前财务总监，我梦想着找到合适的数据产品（通常是仪表盘）来追踪我需要的数据。而作为一个热爱数据的人，我梦想着能够清晰地了解整个数据格局。
我知道数据目录可以帮助解决所有这些问题，但我没想到有一天我会亲手实现我一直以来梦寐以求的改变。这就是我们小米公司如何通过在公司内部实施新的数据目录，将这些数据梦想变为现实的故事。
但数据目录究竟是什么？它可以被定义为组织内所有数据的实时清单，数据使用者可以轻松浏览，找到并理解满足自身需求的数据。它就像一个窗口，展示组织中存在的所有数据。它本身并不包含数据，而是包含元数据（即关于数据的数据）——就像所有现有数据资产的身份证件集中存放在一个地方一样。
把数据目录想象成“宝可梦图鉴”是一种既有趣又简单的方法。对于那些没经历过90年代的人来说，宝可梦图鉴是一个数字百科全书，它列出了所有在经典宝可梦游戏和系列作品中出现的宝可梦。拥有宝可梦图鉴并不意味着你一定拥有这些宝可梦或能够使用它们，它只是一个包含所有现有宝可梦及其结构化信息的目录。如果你把数据想象成宝可梦，那么你也可以用同样的方式来理解数据目录。你可以浏览这个宝可梦数据目录，找到你想要的内容后，你可以看到它的元数据，甚至还有结构化的定义。
事实上，数据目录是您在数据治理策略中采取积极主动行动的有力工具。数据治理团队通常会为组织内的数据生产者和数据使用者提供指导，帮助他们了解应遵循的正确标准，从而确保公司所有数据都保持合规、可访问和值得信赖。
在小米公司，我们的目标是支持所有同事在合规（防御性部分，始终是第一要务）和自信（进攻性部分）的前提下充分利用数据。因此，作为小米公司该产品的功能负责人，我们的数据目录必须帮助我们建立对数据的信任，并让所有小米公司员工轻松理解公司数据，从而从中获取价值。一个成功的数据目录能够真正帮助构建公司元数据，使其成为数据发现的单一数据源，这超越了数据治理仅限于防御的普遍认知。
投资于数据治理的主动性方面意义重大。据《哈佛商业评论》的一项研究显示，知识工作者估计他们花费了50%的工作时间“搜寻数据、识别和纠正错误，以及为他们不信任的数据寻找佐证来源” （《数据的可信度问题》，托马斯·C·雷德曼，《哈佛商业评论》，2013年12月）。由于一半的时间没有用于积极创造价值，这种情况可能会导致巨大的隐性成本；例如，额外的人工成本或糟糕的战略决策带来的后果。
一项较新的研究强调，在5000名员工中，十分之九的人表示他们每周可能浪费多达8个小时来查找所需文件（ABBYY研究，2021年11月）。岁月流逝，但趋势依旧：找到满足自身需求的可靠数据并非易事。随着人工智能的日益普及，数据治理变得愈发重要。未来，关键将不再是花费的时间，而是输出结果的质量。
当然，这不仅仅是拥有合适的工具；还需要建立正确的流程和实践。但引入数据目录是一个很好的开始！
在小米公司，愿景和战略在公司、团队和个人等各个层面都以目标的形式体现。个人目标必须服务于团队目标，而团队目标也必须服务于公司目标。这些目标通常是年度目标，关键成果按季度进行衡量。这样，各个层面的所有行动和举措都专注于实现服务于既定目标的关键成果——这就是 OKR（目标与关键成果）流程，它使公司能够以结构化、协调一致的方式实现其目标。
根据数据部门的整体 OKR，我们的目标是实现以下目标：
-
小米公司员工通过安全便捷的访问方式从数据中获取价值
最初，小米公司已经构建了一个数据目录，我们姑且称之为Catadata，不幸的是，它并没有真正满足我们的需求。
我们深信，一个可用的数据目录是满足公司数据需求和实现目标的关键工具之一：
为所有小米公司员工营造数据自助服务的文化，尤其是在我们最近对数据团队进行重组之后。此处的目录旨在作为数据发现的单一权威来源，从而简化所有人的数据使用体验。
凭借对完整数据价值链的掌控，提供可靠的数据。数据价值链是指从多个来源收集数据，然后进行转换和聚合，最终以各种形式转化为可供使用的产品：例如人工智能数据集、仪表盘、报告、分析等等。
在确保合规的前提下，加速推进医疗保健人工智能的发展。我们需要一个平台，能够快速识别哪些数据可以用于哪些用途，以及数据本身是什么——同时最大限度地减少数据治理团队所需的维护时间。
但我们使用得越多，就越意识到这个特定的数据目录限制了我们的发展目标：
Catadata并不易于使用。它被视为又一款仅供技术人员使用的工具，既不利于文档编写，也不利于用户互动。
数据沿袭既不完整，也不具备端到端的可读性，无论从技术层面还是功能层面都是如此。除了缺乏用户友好性之外，Catadata 还无法与数据源和仪表盘进行关键集成。因此，数据生产者在迭代自身拥有的数据时如同盲人摸象，而数据用户也无法了解数据的来源。
用于快速明确治理政策和识别分类法的功能不足。因此，用户难以理解规则和类别，这限制了目录的一致性和可信度。
这导致数据治理团队浪费了大量时间和精力。由于数据目录提供商缺乏支持，我们被无数未解决的漏洞所困扰。
所有这些限制导致 Catadata 的月活跃用户数 (MAU) 非常低。在我们的数据目录中，如果用户在一个自然月内（每月1日至3月4日之间）至少访问过一次目录，则被视为活跃用户。使用 Catadata 时，小米公司平均只有不到 120 位员工在使用——其中大部分是由于“强制”使用。而这一切却要花费一笔不小的年费，尤其是在小米公司正努力实现盈利的时候。这种情况令人难以接受，我们意识到我们需要一个更好的解决方案。
上面我讲述了小米公司在2024年4月面临的困境。我们现有的数据目录已无法满足公司的数据发展需求，我们意识到需要更优的解决方案。当时，公司的目标是在2025年底实现盈利。巧合的是，我们与这家数据目录提供商的合同即将于年底到期。这为我们提供了一个绝佳的变革契机，但我们只有8个月的时间来选择并全面实施新的数据目录解决方案。
鉴于时间紧迫，我们的团队优先考虑在不到一个季度的时间内完成详细的概念验证 (POC)，目标是在7月份决定是否更改数据目录。为什么我们只给自己两个月的时间来测试和决策？我们知道必须抓住时机，如果决定做出更改，就需要在9月份启动，以便有足够的时间在年底前自信地部署新的目录。在小米公司，我们乐于迎接挑战，不断成长，始终走在技术前沿，所以我们对自己说：“冲啊！”
规划并运行新数据目录的详细概念验证 (POC) 或许听起来并不那么令人兴奋。但对于我的团队而言，为了实现积极的变革，做出正确的决策至关重要——尤其是在时间如此紧迫的情况下。对于任何处境相似的人来说，投入时间完成这一重要步骤是成功的关键因素。
从一开始，我们就面临诸多挑战。首先，由于会议和节假日影响，加上传统的暑假，夏季并非理想的工作时间，因为团队成员的可用时间大大减少。此外，时间安排也显得过于紧凑。在我之前的公司，即使有经验丰富的数据管理员团队参与，同样的方案也需要长达一年的时间才能完成。
其次，我们团队规模很小，只有三个人，负责执行这项详细的测试。数据治理方面只有我一个人，既是功能目录的所有者又是项目经理；数据工具团队里一位经验丰富的数据工程师负责数据目录的技术管理；还有我们与平台安全团队的联络人。
最后，也是至关重要的一点，我们必须拿出强有力的论据来支持变革。公司领导层甚至从未考虑过更换数据目录提供商。这可以理解，因为他们没有进行过深入的测试来证明其他解决方案可能更适合我们的特定需求。此外，我们当前的数据目录在公开的基准测试中排名靠前，并且已成功部署到其他面临不同限制的公司中。因此，我们必须向领导层提供确凿的证据，证明做出这一改变是正确的选择。
无论存在哪些限制，我们都需要通过概念验证实例来测试这些工具。演示或网站上的宣传是一回事，在实际环境中应用又是另一回事。在我们之前的数据目录中，一些宣传中声称功能完善的集成对我们来说根本不起作用。上当一次，绝不会再上当两次。
我们搭建了概念验证环境，但除了我们原有的供应商之外，只新增了两家供应商。选择这些供应商是基于我们近期完成的内部理论基准测试，以及我们从业内类似公司获得的非正式反馈——人脉很重要！
我参与了功能评估，并收集了来自公司各个团队（不仅仅是数据团队）的 30 多位 Beta 测试人员的反馈。我们的目标是让数据目录成为所有小米公司er 员工的实用工具，而不仅仅是少数数据爱好者的专属，因此来自真实用户的反馈至关重要。
除了我们现有的目录供应商Catadata之外，我们还决定测试以下数据目录供应商：
Coalesce Catalog（前身为CastorDoc）是一家法国初创公司，凭借数据社区的积极反馈在市场上迅速发展——几个月后，它被 Coalesce 收购。
其中一个棘手的问题是，我们不能让当前的数据目录提供商知道我们正在将其与其他解决方案进行比较，因为这可能会损害我们与他们的合作关系。如果概念验证结果表明我们确实应该更换供应商，我们的服务可能会降级；如果概念验证结果表明我们应该继续使用现有方案，则可能会对我们两家公司之间的信任产生负面影响。
确认所有贡献者是否在岗，只有当所有关键利益相关者包括内部和外部利益相关者都到场时，才能进行详细的概念验证。
在公司内部，这项详细的概念验证已纳入数据治理团队（职能方面）和数据工具团队（技术方面）2024 年第二季度的 OKR 中。在小米公司，OKR 用于规范团队成员投入到项目中的时间，以便他们能够实现服务于中长期业务目标的关键成果 (KR)。
我们从一开始就希望让采购合作伙伴参与进来的另一个关键内部贡献者。为什么呢？
开展详细的概念验证 (POC) 通常需要关键文件来规范讨论并保护各方利益，例如保密协议 (NDA) 和第三方协议 (TPA)。与将在您的环境中部署实例的供应商进行的讨论可能涉及敏感信息。
在合同方面，他们是您的指路明灯。就现有合同而言，如果我们决定更换供应商，我们的采购合作伙伴可以就如何操作以及未来规划中需要考虑的因素提供建议。如果我们在完成概念验证 (POC) 后决定更换供应商，我们的采购合作伙伴也能尽早洞察潜在的双赢合同方案。
我们的采购合作伙伴在确定我们能从每家供应商那里获得的最佳定制化定价方面也发挥了关键作用。根据概念验证 (POC) 的进展情况，采购合作伙伴能够确定对我们最有价值的功能，并将其与任何迁移支持费用一起计入总价。这一点尤为重要，因为我们知道供应商的报价并非总是直截了当的。
最后，与这位同事的合作让我得以使用通用的采购评分体系，我利用该体系来设计和构建概念验证测试。这不仅能在我们最终决定更改数据目录时节省采购时间，还有助于我构建和组织对三种目录解决方案的评估。
在外部合作方面，我们与每家供应商都组建了一个两人团队，结合功能和技术视角进行协作。我们首先与每家供应商召开启动会议，以确认他们的供货能力是否符合我们的产品路线图。此次启动会议也让我们有机会明确指导我们决策的关键因素，例如：
为了与项目贡献者成功合作，您必须为他们提供一个清晰的预期目标。这包括开展概念验证的根本原因，以及您期望从中获得的价值。我准备了幻灯片，详细阐述了所有这些内容，并在与两家正在考虑的新供应商的启动会议上进行了讲解。
本次启动会最重要的部分当然是分享我们的路线图，其中清晰地阐述了我们理想的时间框架和概念验证的关键步骤，包括我们如何判断每个步骤是否完成。路线图还让我们深入了解了潜在的迁移方案将如何实施。
1初始化，目的是为开展概念验证 (POC) 奠定充分的基础。
-
技术搭建工作由数据工程师主导。我们需要确保两家供应商的POC实例在6月份之前准备就绪，以便进行测试，并尽可能地将其集成到我们的数据堆栈中。
-
我主导了需求细化工作。目标是清晰了解用户画像及其使用场景，并确保所有 Beta 测试人员在概念验证 (POC) 实例可用时都已做好测试准备。
3. 对工具进行积极测试，目标是收集关于 3 个公司数据目录（包括当前目录）的最大反馈意见。
4. 结论和总结，旨在使我们的业务领导者能够就选择哪个数据目录做出最明智的决定。
最后，从运营角度来看，制定概念验证 (POC) 策略也意味着找到清晰的工作方式。在实践中，这意味着与合作伙伴就常规流程达成一致。就我们而言，我们制定了以下每周节奏：
每周与我的数据工程师和安全主管同步，以跟踪所有 POC 实例部署的进展情况，并确定我可以在哪些方面帮助准备与每个供应商的讨论。
与各供应商举行联合技术功能会议，双方均派出数据工程师和功能负责人，此外还有我们的安全代表参加。会议旨在完善需求，同时解决实例设置过程中遇到的技术难题。
按需与采购合作伙伴进行一对一沟通，以确保他们拥有支持我们进行潜在数据目录变更所需的一切资源。
为了规范概念验证 (POC) 的进展，我创建了一个仅供内部使用的 Asana 看板。它有助于我们梳理工作，并记录与采购和技术相关人员的讨论。
为了构建一个有效的评分体系，我问自己：高管需要哪些条件才能放心地批准数据目录变更？从这个角度出发，我重点关注了以下四个方面：
-
集成与我们的数据堆栈无缝协作，使数据目录能够提供从数据源到最终用户的完整数据视图。我们通过以下比率来衡量这一点：“数据目录与小米公司目前使用或将来可能使用的y 个工具中的x 个具有可用的连接器。”
-
技术和安全标准得到满足，数据目录在性能、安全性和维护成本之间实现了平衡。这包括支持质量、Terraform 兼容性、提取模式、日志、API 等因素。
-
-
这 4 个评分类别及其子类别均按照以下采购评估矩阵进行评分：
0：不合格（甚至不合格）
1：不足——完全不满足需求，或仅略微满足需求
2：基本满意——部分满足需求
3：比较满意——很大程度上满足需求
4：非常满意——完全满足需求
5：超出需求（但要注意避免过度设计）
所有评分表中都提到了这个评估矩阵，以便所有测试人员保持一致。
既然概念验证的基础工作已经完成，我们该如何计划才能取得成功呢？
我跟经理说我会找大约10个测试人员。三天后，我带回来40个。
那一刻改变了我们概念验证 (POC) 的走向。凭借合适的社群和清晰的评分方法，我们最终将长期的“待定”变成了高管的“同意”。前面我详细介绍了我们如何启动一个新数据目录的详细 POC。接下来，我们将讲述我们如何积蓄力量、开展严谨的评估，并最终获得新数据目录的批准。
在我主导的功能需求阶段，当沙箱准备就绪可以进行测试时，我希望具备以下条件：
-
清晰、优先级排序的需求，按适用于至少一个用户角色的通用用例进行分组。
-
在产品生命周期管理中，以用户为中心是不可妥协的原则。数据目录满足着截然不同的需求：管理员运行产品，贡献者添加内容，而浏览者则阅读内容。不同角色的用例各不相同，因此每个需求都必须与一个用户画像相对应。然而，我从理论基准测试中获得的初始需求列表很长，而且没有与任何用户画像关联——它必须经过提炼和简化。
因为产品需要用户参与改进，所以我很早就建立了我的测试用户群体。我的经理原本希望有 10 个人，但最终我们聚集了来自 10 个不同团队的多达 40 人。我是怎么做到的？我充分利用了我的人脉：Slack 通知、咖啡聊天和推荐。
-
在小米公司，技术和产品团队由 60 多个功能团队组成，这些团队负责管理我们产品特定部分的生命周期。团队成员包括产品经理 (PM)、工程经理 (EM) 和开发人员。我的测试人员中有多位分别代表了这三种角色。
-
-
-
-
数据相关人员，例如分析工程师、数据科学家、数据产品经理等等。
我用一个简单的电子表格记录了测试人员和用户画像，这之后帮助我整理了反馈。我发现与这个群体互动最简单有效的方式是通过我为此专门创建的 Slack 频道。
测试人员到位后，我们明确了约 100 项基准测试需求。我们按用例对这些需求进行分组，并将其映射到用户画像，然后与社区进行迭代。最终，我们新增了四项需求。总共有 75+项需求对应 10 多个用例。社区还帮助我们确定了需求的优先级，区分了哪些是必需的，哪些是“锦上添花”的功能。
我们确定了清晰的按用户角色划分的使用场景矩阵后，我将其分发给了供应商。对于每一项需求，供应商都确认了他们是否具备我们愿望清单上每一项的功能，并提供了相应的文档链接。这样，如果测试人员需要测试子需求，他们就可以独立完成测试。对供应商而言，这有助于他们针对社区中的每个用户角色准备即将进行的演示。演示参与人数众多，为测试人员提供了充足的背景信息，以便对每款工具进行评估。
到 2024 年 6 月，所有概念验证实例都已上线，我们为每种工具都制定了一个“测试人员试验场”评分标准。核心用例包括：
-
-
-
AI 助手 [所有用户] — 请记住，当时的 AI 远没有今天这样普及。
-
-
在短短三周内，超过 20 位测试人员对每款工具进行了评估——考虑到季度末通常非常繁忙，这着实令人瞩目。除了评分之外，我们还收集了大量的定性反馈，以便向领导团队汇报。
高管们不可能事无巨细地参与其中，但他们的支持至关重要。我的提案可以归结为两句话：
“即使 Catadata 是市场上的领先产品之一，但它在各方面都是一个昂贵的负担，难以满足我们的发展需求。我们应该用性价比更高的产品来替代它：Coalesce Catalog（原名 CastorDoc）。”
-
对每种工具的价格和价值进行了平衡评估，并与采购评分标准相一致。
-
确定了与 CastorDoc（现为 Coalesce Catalog）签订为期 3 年合同的战略优势
-
指出即将实施的为期三个月的迁移目标可能存在的潜在风险（如果该目标获得批准）。
-
我在附录中加入了更详细的信息，并且只在相关的时候才将其呈现出来。
Coalesce Catalog 最吸引我们的是：
-
他们的产品在满足大多数用户需求的同时，也兼顾了用户友好性。这在数据目录行业中具有颠覆性意义，因为在数据目录行业，数据目录通常被视为仅供数据专家使用的工具，而非组织内任何潜在用户都能使用的工具。
-
Catalog 的数据沿袭功能非常强大，而且易于阅读。我终于找到了实现数据梦想的方法。
-
在我们成为 Catalog 的客户之前，他们就提供了卓越的支持。他们让我们感觉自己是他们唯一的客户，而实际上他们已经与许多公司合作多年。正如招聘流程能反映出员工的待遇一样，我们相信，之前 Catadata 缺乏支持的问题，在 Catalog 的帮助下将会成为过去。
-
Catalog 在利用创新和人工智能驱动其解决方案方面也遥遥领先，尤其值得一提的是他们对 AI 助手功能的大力投入。该功能以 ChatGPT 的方式利用大型语言模型 (LLM)，为数据用户提供自然语言问题（AI 搜索功能）和 SQL 查询（SQL Copilot 功能）支持。为了获得流畅的数据体验，用户甚至可以通过 Google Chrome 扩展程序，直接在他们使用的各种数据消费工具中向 AI 助手寻求帮助。所有测试人员都亲眼见证了它在 Tableau 和 Metabase 中的出色表现，并对此赞叹不已。
在我们的概念验证实例中，Coalesce Catalog 实现了端到端的数据沿袭。
-
Catalog 非常渴望与我们共同成长。这一点从其联合创始人兼首席执行官 Tristan Mayer 和首席产品官 Arnaud de Turckheim 的持续参与中可见一斑。后者实际上是我在他们那边的职能对接人。或许是因为他们也创立于法国，并且和小米公司一样来自创业圈，所以能与我们合作对他们来说意义非凡。相反，对于 Catadata 或 Altadata 这样规模更大、业务更全球化、客户更多的公司来说，我们显得微不足道。
-
Coalesce Catalog 非常积极地与小米公司建立合作关系。我们感受到他们希望在产品开发过程中采纳我们的反馈意见，而事实上，他们在概念验证阶段也确实做到了这一点，为我们开发 Redshift Serverless 连接器提供了帮助。此外，我们在数据产品展示、数据用户 AI 体验、分析等产品路线图方面的贡献也与他们的理念高度契合。
最终，领导层批准了我们的计划——他们充分意识到摆在我们面前的挑战：在三个月内完成部署，赶在现有合同到期之前，并努力让一个通常被视为“仅限专家使用”的工具得到广泛应用。
我们面临的更具挑战性的运营任务是同步所有概念验证 (POC) 实例，以确保所有测试人员都能获得流畅且可比的体验。问题在于，其中一家供应商 Altadata 在技术实施过程中进展缓慢，与已经做好技术测试准备的 Coalesce Catalog 相比，其进度严重滞后。尽管 Altadata 是一家大型公司，但似乎并未像 Coalesce Catalog 那样投入足够的资源来快速支持我们。我们费尽周折才催促他们，甚至一度考虑停止与他们的测试。然而，正如我们的采购合作伙伴所建议的，这样做会使我们详细的 POC 测试结果不够客观中立。竞争是招标书 (RFP) 的必要组成部分，因此我们不能进一步减少供应商的数量。于是，我采取了特别的措施，对 Altadata 采取了强硬的态度，最终取得了成效，将测试活动的启动延迟控制在了两周之内。
供应商们也试图猜测竞争对手的情况；然而，我没有透露任何信息。我希望每个供应商都专注于满足我们的需求，而不是互相竞争。这种方法，再加上结构化且公正的评分体系，最终帮助我们向所有数据目录提供商（包括我们停止合作的那家）提供了反馈。反馈永远是一份礼物，即使你们不再是合作伙伴，它也能为建立良好的关系铺平道路。数据行业圈子很小！
从这次概念验证中我们学到的另一个重要经验是，小米公司的核心价值观之一——彼此关怀——是多么重要。测试人员的投入令人赞叹——在需求完善和/或测试的高峰期，有超过 30 位活跃贡献者。作为回报，我及时向他们通报进展，提供现成的资源来减轻他们的工作量，并公开表扬他们的努力。如果没有他们的付出，我们或许无法实现所需的变革。这绝对是一次双赢的合作！
最后，文档记录至关重要。我维护了一个 Confluence 页面，记录了每个步骤和所需资源。这帮助新加入的利益相关者快速上手——也让撰写这篇文章变得更加容易！
这就是我们在小米公司开展数据目录变更的详细概念验证 (POC) 的故事。在领导层批准后，时间紧迫：90 天的时间，我们需要在整个组织内完成迁移、部署和习惯转变。
下面是我们遵循的计划、遇到的问题以及我们最终如何按时完成任务。
成功测试了不同的数据目录之后，我们该用新的目录Catalog（原CastorDoc，现为Coalesce的一部分）替换“Catadata”了。一个很小的细节是：我们只有三个月的时间来完成这项工作，因为我们与Catadata的合同即将到期。挑战，我们接受了！
为了赢得这场与时间的赛跑，制定反向进度计划至关重要，这与详细的概念验证（POC）类似。不同之处在于，产品上线后，需要考虑的利益相关者和限制因素要多得多。帮助我们制定路线图的关键在于明确了关键截止日期并设定了就绪状态的定义。这些包括：
-
我们与 Catadata 的合同将于年底到期，因此 Coalesce Catalog 必须在三个月内准备就绪。
-
在签订合同并完成采购订单流程之前，Coalesce Catalog 无法接入我们的生态系统。
-
围绕敏感性分类的一个关键治理流程被称为“数据分类法”（稍后会详细介绍），因此我们必须对其进行更新，这样我们就不必再依赖数据目录了。
-
所有关键利益相关者都必须确认他们是否在场：数据产品经理、IT 部门、数据源所有者、数据平台和摄取团队、站点可靠性工程师 (SRE)、安全部门、采购部门。
-
Coalesce Catalog 需要与我们的数据堆栈进行端到端的每日连接，以便开始接纳贡献者，后来接纳所有小米公司员工。
-
在向所有小米公司员工推出之前，必须将我们过去目录中的所有书面文档迁移到Coalesce Catalog中。
-
所有小米公司员工都必须在启动日期之前默认拥有查看器访问权限，这需要我们的活动目录、SSO身份验证和新数据目录之间成功建立链接。
-
只要 Coalesce Catalog 没有连接到我们的堆栈并且文章没有迁移，我们就无法将我们的决定告知我们未来的前目录提供商。
这一切最终促成了以下路线图，但事情永远不会完全按照你想象的那样发展，尤其是路线图：
与详细的概念验证 (POC) 类似，我们在初始化阶段之后也加入了一个功能和技术二合一的步骤，在此步骤中，我们完成了贡献者（拥有编辑权限）和管理员的入职培训。然而，与详细概念验证不同的是，由于所有小米公司用户默认都是查看者，为了确保充分的变更管理，我们还必须增加一个功能性工作流程，对所有小米公司用户进行入职培训。沟通和变更管理的更多细节将在后面介绍。
最初，目录迁移项目团队的组织结构与详细概念验证阶段大致相同：
-
技术方面：数据工具团队有一位经验丰富的数据工程师。由于当时的数据治理团队缺乏技术能力，因此该团队负责数据目录的技术维护。
-
功能方面：一名数据治理负责人（就是我！）作为目录的功能负责人，担任迁移的项目经理。
事实上，经过一个月的迁移，概念验证阶段提出的风险之一变成了现实：功能方面的工作量过大。管理迁移本身就是一项全职工作，尤其是在如此短的时间内。而管理如此重大变革的后续入职流程也是一项全职工作。幸运的是，管理层采取了行动，为项目团队增加了两名成员：
我已将技术迁移管理工作委托给数据工具的技术产品经理，以便他能更好地专注于变更管理和新用户导入。
因此，我们能够按时完成此次迁移的必要环节，并且每个项目团队成员的工作量都在可承受范围内。
之前的数据目录停用也为我们改进一项已实施的治理标准提供了契机：小米公司的敏感性分类流程，即“数据分类法” 。数据分类法的原则是，所有表中的每个字段都必须标明敏感性类别和数据主体。这样一来，就能确保始终对正确的数据应用正确的保护措施，小米公司也因此继续保持数据保护领域的领先地位。
事实上，许多保护规则都依赖于这种数据分类。例如，数据分类是我们匿名化流程中必不可少的检查环节。这对小米公司至关重要，因为我们的产品处理非常敏感的信息：不仅包括个人数据，还包括健康数据。数据分类使我们能够确保，即使是小米公司的员工，默认情况下也无法看到此类敏感数据，这得益于我们秉持的隐私设计原则。
小米公司的数据分类流程：每列数据包含一个类别和一个数据主题。
此前，数据分类是按照我们之前的数据目录中所有表的所有者逐列进行的，主要由60多位工程经理（EM）负责，他们各自负责产品端功能团队的所有表。问题很多：
-
目录是一个以结构化方式从各种来源收集元数据的商店窗口，而不是一个可编辑的基于规则的管理引擎。
-
对于技术精湛的工程师来说，这是一个极其繁琐且耗时的过程，他们必须手动编辑数据目录中的数百页内容。
它人为地抬高了我们之前用于衡量数据目录采用率的关键指标——月活跃用户数 (MAU)。Catadata 的平均 MAU 从 120 开始，而这一变化始于……当时有 60 多位 EM 需要对目录中的数据进行分类。这可能对之前的数据目录改进尝试毫无帮助。
60多位EM用户需要昂贵的编辑许可才能编辑目录中其职责范围内的数据分类。因此，由于当时的许可数量限制，一些真正需要编辑权限的合法用户无法始终获得许可。敏感度分类与合规性密切相关，因此始终优先于其他一切。
我们进行目录变更的愿景是阻止数据目录的滥用。具体做法是：不再像以前那样在数据价值链末端的数据目录中进行分类，而是让功能团队直接在代码中完成分类。这些改进甚至超越了数据目录本身的范畴：
-
由于可以批量处理数据分类并将其委托给EM开发人员，因此节省了大量数据分类时间。
-
-
缩短分类时间：分类现在由代码预先设定，无需等待新数据资产的元数据出现在数据目录中。
-
提高了分类质量，以确保相似的数据资产（例如：不同功能团队拥有的不同表中的“visit_motive”列）具有相同的分类，从而具有相同的保护级别。
在目录迁移初期，我们成功实施了这一新流程。我们经验丰富的数据工程师还成功地将类别在新数据目录中显示为不可编辑的标签。
根据代码输入进行分类后，数据分类法以标签的形式存在于目录中。
另一个在功能方面需要处理的棘手问题是，小米公司花了八个月的时间准备结束与我们之前数据目录的合作关系。在整个详细的概念验证和迁移过程中，我不得不频繁地与这家供应商开会，进行我所谓的“分手肚皮舞”：
我们会持续委婉地表达对他们缺乏支持以及我们耗时的产品管理却导致小米公司用户参与度低的不满。这样，分手就不会让任何人感到意外。
不要太明显地表现出我们正在认真考虑和准备分手，以免失去对方的全部承诺，或者冒着关系出现裂痕的风险（即使这种情况不太可能发生在这样的伴侣身上）。
感谢采购合作伙伴的支持，我们早就知道与之前的数据目录供应商签订的合同中并没有规定我们续约前需要提前告知。事实上，我们甚至没有义务通知他们我们不续约，也不需要解释原因。但我们还是这么做了，因为我们一直很重视这位合作伙伴，而他们的反馈对我们来说弥足珍贵。
尽管如此，我们还是等待了最稳妥的时机。这个最佳时机出现在合同到期前一个月，当时合作伙伴正期待我们正式签署续约协议。从迁移的角度来看，那时Coalesce Catalog已经部署完毕，并与我们的数据价值链紧密连接，而且所有人工知识也已成功迁移到新的数据目录中。
这次分手舞竟然成功了！我们之前的数据目录供应商对我们的决定并不感到意外。他们也很欣赏我详细解释了我们做出这个决定的原因并提出了一些建议。这次合作以非常积极的方式结束了！
说到进展顺利之处，数据目录提供商之间的平稳过渡就是一个例子。正如上文所述，我们及时通知了之前的数据目录提供商，并做好了充分的准备，因此过渡过程非常顺利。不仅如此，Coalesce Catalog 还找到了帮助我们迁移原数据目录中手动编写的知识库（文章）的方法。这实际上是我们最没有把握的环节之一。最终，他们帮助我们节省了大量时间，使我们能够专注于与数据项目管理团队合作，共同推进这项工作并进行测试。
Coalesce 的支持团队还指派了一位客户成功经理 (CSM)，他的职责是帮助我们运用最佳实践和满足我们需求的新功能，最大限度地提升数据目录的用户参与度。我们的 CSM 在所有用户角色（管理员、贡献者和查看者）的入职过程中都发挥了至关重要的作用。他提供了易于理解且最新的内容，节省了我们为每个用户角色构建工具内常见问题解答 (FAQ) 部分的时间。他还指导我们完成了管理员的入职流程，并在编辑和查看者的入职过程中提供了关键支持。
与数据产品经理团队的合作是此次迁移的另一大亮点。在小米公司，数据产品经理负责制定数据和人工智能产品战略，并在其职责范围内管理产品的生命周期。他们与分析工程师紧密合作，后者负责设计、交付和维护面向全公司的数据和人工智能产品。在数据目录方面，数据产品经理负责在分析工程师的协助下，确保其职责范围内的数据文档齐全。他们拥有编辑权限，可以参与数据目录的创建。
因此，作为迁移的一部分，数据项目经理 (Data PM) 帮助我们确定了他们负责领域内哪些内容需要迁移。他们还测试了迁移是否正确。为了尽可能简化他们的迁移流程，我使用 Catadata 的 Coalesce Catalog 导出功能，准备了一个包含所有文章的电子表格，并按数据项目经理的职责范围进行组织，表格中包含了旧数据目录和（迁移后）新数据目录中的链接。这有助于集中管理并确保迁移这一关键环节的顺利进行。至于时间安排，从我们确定需要迁移的文章开始，文档工作就暂停了，直到 Coalesce Catalog 执行迁移（1-2 天）。迁移完成后，所有数据项目经理都验证了他们职责范围内的内容是否已正确迁移到新的数据目录中。
另一个成功因素是我们在迁移过程中保持了项目团队的组织架构。在工作方式方面，我们沿用了概念验证阶段的工作模式——与同一技术团队紧密合作，并继续使用同一项目管理工具（Asana）——这帮助我们保持了进度。正如我们在概念验证阶段所做的那样，我们继续在专门的 Confluence 页面上记录所有内容。事实证明，记录迁移过程至关重要，尤其是在跟踪所有连接的状态或确定迁移后剩余任务方面。
当然，这次迁移过程中有些方面我们可以做得更好。首先，数据治理团队本可以拥有更专业的技术人员，例如高级数据工程师。在产品生命周期管理中，同一产品的功能和技术所有权不属于同一团队或小组，这并非理想之选。两个团队的优先级可能并不总是完全一致，或者资源也未必充足。例如，我们不得不降低接收数据目录分析数据的优先级，而这些数据对于数据治理的关键绩效指标 (KPI) 至关重要，此前的数据目录提供商一直提供这些数据。结果，我们的 KPI 中断了五个月，这对数据治理工作造成了不利影响。此外，在同一团队或小组内明确职责划分有助于沟通顺畅，而我们在迁移过程中并未做到这一点。最后，在关于数据摄取模式的讨论中，作为一名功能型人员，我感觉自己处于劣势，远不如技术型人员。要论证为什么某些情况看起来很冒险，需要付出相当大的努力，而且我常常觉得自己缺乏足够的信誉来完全说服别人。
此外，与数据项目管理团队的合作是一大亮点，但我认为合作还可以更深入。在项目方面，我本可以做得更好的地方在于提前做好规划。虽然我在所需工作量到来前两到三个月就通知了所有利益相关者，但我应该更加强调这一点，并与其中一些人进行后续沟通，特别是数据项目管理团队。他们是一个非常繁忙的团队，无法在我们要求的时间里投入足够的资源来完成迁移工作。他们必须在有限的资源下同时处理太多关键事项。为了缓解这种情况，我本可以更早地借助 Coalesce Catalog 准备好文章概述，从而给团队留出比我们最初设想的一到两周更多的时间。
尽管遇到了一些挑战，我们还是赶在与前供应商的合同到期前完成了新数据目录 Coalesce Catalog 的部署。但这仅仅是个开始。再好的产品，如果不能解决问题，或者目标用户根本不知道它的存在，那就毫无意义。
下面我们将重点讨论用户参与和部署后的产品生命周期。
即使世界上最好的产品再出色，如果没人意识到它能解决实际问题，也永远无法获得成功。我们全新的数据目录Coalesce能够满足不同用户群体的众多使用场景。然而，如何将 Catalog 推广给非技术用户却是一项挑战。尽管 Catalog 本身非常直观易用，无论用户技术水平如何，但数据目录通常被认为是高度技术性的数据治理工具，因此不具备技术技能的用户往往对此不感兴趣。本文将讲述我们如何突破数据领域的壁垒，努力让小米公司的全新数据目录满足所有小米公司用户的需求。
我们的主要成功标准：超越我们之前的数据目录月活跃用户数……并且做得更好！
就是它！我们成功测试了多个数据目录，以替换之前的 Catadata，最终在 2024 年底部署了 Coalesce Catalog。这一切仅用了短短两个季度。但这仅仅是我们利用新数据目录释放价值的开始。到了 2025 年 1 月，我们又面临着一项新的挑战：如何让小米公司员工使用 Catalog。
无论你的产品是 Instagram、Spotify、咖啡店、数据目录，还是小米公司，关键始终在于用户采纳。你的目标受众必须了解你的解决方案，并在它能帮助他们的情况下尽可能多地使用它。用户采纳对于管理产品生命周期至关重要。缺乏用户采纳的产品要么无法解决任何问题，在这种情况下，它应该被淘汰；要么那些需要它的人甚至根本不知道它的存在。但是，如何衡量像数据目录这样的数字产品的采纳率呢？你可以使用关键绩效指标 (KPI) 作为衡量采纳率的指路明灯。由于 KPI 中的“K”代表“关键”，你必须专注于几个关键指标，当然，你也可以依靠辅助指标进行更深入的分析，并决定下一步的行动。对于我们的数据目录，我们衡量用户采纳率的 KPI 一直是月活跃用户 (MAU) 指标。MAU 指的是一个月内使用过该产品的独立认证用户数量。在我们的数据目录中，如果用户在一个自然月内（从该月的第一天到最后一天）至少访问过一次目录，则该用户将被计为活跃用户。
关键绩效指标 (KPI) 通常与量化目标相关联，这些目标支持整体战略，帮助团队保持正轨。对于我们的数据目录而言，我们的月活跃用户 (MAU) 目标，以及其他数据工具，共同证明了它确实能够赋能小米公司员工，让他们通过安全便捷的访问方式从数据中获取最大价值，尤其是在促进数据自助服务和掌握数据价值链方面。到2025年，我们的目标是使Coalesce Catalog的月活跃用户至少达到200，高于之前数据目录的平均月活跃用户120。
截至2025年8月，我们的计划取得了成功：Coalesce Catalog的平均月活跃用户数约为328（远超200的目标），比之前的数据目录月活跃用户数大幅增长。值得注意的是，之前目录的约120月活跃用户数是由于合规性要求进行的分类更新造成的，这些更新需要60多位工程经理直接在工具中执行。即使没有数据分类流程，我们目录的月活跃用户数仍然显著增长，这进一步证明了我们的支持者对我们的信任是正确的。
我们之前的数据目录对月活跃用户数 (MAU) 进行了解释。
产品上线前三个月的月活跃用户数 (MAU) 统计。
从上面的截图中，您可以看到2025年1月的月活跃用户数（MAU）峰值超过600。换句话说，超过20%的小米公司员工用户在我们的数据目录上线时访问了该目录。尽管这个数字后来有所下降，但这无疑帮助我们的数据目录影响了更多人，而不仅仅是数据部门的少数数据爱好者。
我们是如何取得这一切成就的？通过一场大胆的传播活动。
精准沟通对于产品推广至关重要。我们的新数据目录 Coalesce Catalog 要想获得广泛应用，就必须开拓之前目录从未覆盖的领域。这片领域主要面向小米公司员工用户，他们大多是“浏览者”，数据技能普遍较低，但无论从事何种工作，都离不开数据。
我的第一个想法是在即将召开的小米公司月度会议 (DMM) 上申请五分钟的推介时间。这是我们规模最大的内部活动，届时来自世界各地的小米公司员工将分享公司和产品新闻、OKR 进展情况以及即将推出的相关创新。这是一个介绍我们新数据目录的绝佳时机，尤其是在最近的数据调查显示，大多数小米公司员工对数据感到迷茫的情况下。
我尽力争取那五分钟的发言时间，但失败了。剧透一下：在DMM大会上，另一个工具Dust也会亮相。数据目录远不如Dust吸引人，Dust原本是我们公司新的ChatGPT工具。稍后我会在本文的“如果我们当初做了不同的选择”部分详细讨论这一点。总之，数据目录的推广之路已经关闭了。
由于我们的新数据目录仍需触达目标用户，我利用了所有其他可能的渠道来促进用户采用。我希望确保所有在数据方面遇到困难的小米公司员工都能想到我们的数据目录——Coalesce Catalog。因此，我在整个一月份将数据目录实物送到了所有小米公司办公室：
-
在电梯和食堂入口等战略位置张贴宣传产品目录的印刷品；
-
在所有办公屏幕上（每层楼多个屏幕）播放宣传视频，同时播放公司其他新闻。
如果没有另外两个团队的帮助，这一切是不可能实现的：设计团队和工作场所团队，这两个团队是我以前从未合作过的数据团队。在这次活动期间和之后，我偶尔会听到小米公司员工谈论Coalesce Catalog。任务完成！
为了配合这次别出心裁的推广活动，我还利用了一些更传统的渠道。我开始在不同的 Slack 频道以及定期召开的技术和产品会议上预告我们的新数据目录，这些会议覆盖了 900 多名小米公司员工（主要是功能团队）。我只需五分钟就能从他们遇到的数据问题入手，介绍我们数据目录的价值主张，并进行一个简短的演示。所有这一切都是为了宣布……几周后公司内部的启动大会。
由于我无法在DMM会议上快速介绍Coalesce Catalog，我邀请了所有使用Tableau或Metabase（我们的数据可视化工具）的小米公司员工员工参加一个40分钟的启动会，专门介绍Catalog。这些小米公司员工占公司员工总数的80%以上。与我之前向技术和产品团队介绍Catalog的方式类似，但这次时间更充裕。我首先探讨了小米公司员工面临的数据问题，然后介绍了我们的数据目录及其作用。鉴于小米公司员工的员工群体非常广泛，他们的平均数据素养不如技术和产品团队。这让我们有机会重新阐述数据为何是能够为每个人创造价值的资产，以及数据目录究竟是什么。启动会还包括目录演示，联合创始人之一Tristan Mayer的简短演讲，以及最后的问答环节。
与 2025 年 1 月的 Catalog MAU 数据同步，本次启动会取得了圆满成功：吸引了 600 多位与会者，其中大部分人都坚持听完了整个演示。鉴于我对这款产品充满信心，这样的出席人数着实超出了我的预期，毕竟我当时只是在介绍一款工具而已。本次启动会的亮点之一是，与大学里教授数据理论类似，运用简单的类比能够极大地帮助听众理解内容。例如，将数据目录比作企业版的宝可梦图鉴就非常贴切，因为许多小米公司员工 的成员都是 90 后。
另一个奏效的因素是，我预先设想了问答环节的一些问题。对于我预料到的问题，我可以利用额外的幻灯片来佐证我的回答。这些问题主要围绕 Catalog 和 Dust（小米公司同时部署的新 AI 工具）之间的联系展开。完全不提及之前的数据目录实际上也对我们的变更管理起到了支持作用。Catalog 的优势不仅在于其新颖性，还在于它能够根据我们的需求量身定制。这正是我在启动会后发送给所有未能参会人员的总结邮件中重点阐述的内容。这实际上是另一个能够显著帮助您进行变更管理的渠道。
更广泛地说，此次数据目录启动的成功也归功于我们周密的准备工作。正如迁移文章中所述，数据产品经理再次发挥了关键作用。他们非常清楚自身职责范围以及各利益相关方的职责，因此协助我推广了数据目录。此外，由于他们本身也是优秀的内容创作者，他们比以往任何时候都更加认真地确保各自领域的文档也准备就绪。
至于挑战，最主要的是如何与颠覆性工具 Dust 同步推出我们的数据目录。Dust 使像小米公司这样的组织能够部署一个安全的 AI 助手平台，该平台可以利用 Confluence、Jira、Google Workspace 等内部资源。实际上，它提供了一个安全的内部 ChatGPT，使小米公司的员工能够轻松构建基于不同 AI 模型的代理。这彻底改变了我们的工作方式。我们面临的挑战并非 Dust 本身，而是如何同时部署我们新的数据目录。
实际上，我在上个月准备新目录的宣传活动时才发现，Dust 将于一月份与我们的新目录同时大规模推广到所有小米公司员工用户。负责推广Dust的小米公司员工担心宣传信息过多会给同事们造成困扰。他们也担心小米公司员工会将Catalog AI助手和Dust混淆。甚至一度，一些内部利益相关者对Catalog的启动提出了质疑。最终，我们达成一致的解决方案是，在所有宣传材料中尽量减少提及Catalog的AI助手。Dust和Catalog之间的联系是我在准备启动问答环节的辅助幻灯片中提到的内容。
我早就意识到，总有一天，必须在目录和尘埃之间架起一座桥梁。拥有最完善的宝可梦图鉴数据是一场永无止境的竞赛。
在部署小米公司的新数据目录 Catalog from Coalesce六个多月后，我们如何在充满挑战的环境下从项目模式过渡到产品模式，数据目录领域未来可能面临的挑战是什么。
产品的成功不仅仅在于其首次发布。更重要的是用户的持续使用，因为这才能体现产品对目标用户的价值。没错，用户在产品发布之初必须了解其提供的解决方案。但他们也需要随着时间的推移记住这些功能，并始终能够识别出哪些场景需要它。这就是以用户为中心至关重要的原因。这一点同样适用于我们最近推出的数据目录——Coalesce Catalog。
在构建全新数据目录的过程中，我们从一开始就重视以用户为中心。除了我为详细的概念验证 (POC) 召集的 30 多位 Beta 测试用户之外，我还创建了一个反馈表单，尽可能集中收集用户的意见。需要填写的字段如下：
-
标题：请用不超过 10 个字描述您的需求→ 作为工单标题
-
目的：请选择以下选项：🎁 缺少功能、🤔 问题、🚨 发现错误、📣 反馈
-
-
每份表单都会在我们的 Asana 目录系统中生成一个带有“用户反馈”标签的工单。所有新工单都归入专门的“用户反馈”版块。该版块随后成为我们每周内部技术（工具团队）和职能（治理团队）数据目录负责人会议的首要讨论议题。几个月内，我们收到了来自数据目录用户的 30 多份反馈表单。
我们优先处理了用户反馈中提出的功能缺失问题。这样做的目的是确保被标记为缺失的功能确实无法使用。这些反馈会被添加到我们为 Coalesce Catalog 准备的功能请求待办事项列表中，该列表也包含了我们作为数据目录所有者的想法。事实上，根据我们的合作理念，我们希望尽可能清晰地向目录团队传达小米公司员工 的意见，以便他们能够结合其他客户的反馈来迭代产品。
此功能请求待办事项列表是按类别和角色进行逻辑组织的，就像我们在详细的概念验证中所做的那样：
我们目前还无法做到这一点，但在这方面，我设想我们可以从功能请求积压中受益的两种方式：
-
它允许目录用户对他们最迫切的需求进行投票，以便我们可以向 Coalesce Catalog 提供优先级更高的列表。
-
我们鼓励 Coalesce Catalog 举办用户组活动，以便他们的客户能够分享需求并为关键需求投票。我之前在为一家全球多家航空公司开发值机和登机系统时就体验过类似的活动。对于我们用户来说，分享最佳实践并解决我们最迫切的需求非常有益。对于供应商（Amadeus）而言，这大大简化了产品经理的优先级排序工作，并提升了用户的满意度！
产品管理包含两个关键阶段：发现和交付，数据目录也不例外。但是，既然我们是外部供应商开发的产品的内部所有者，我们又能交付什么呢？
就纯粹的交付相关主题而言，我们也有一个包含以下工作流程的运营待办事项清单：
-
技术方面的问题包括：尚未实施/改进的集成、用于支持我们内部数据治理 KPI 的分析数据、与我们即将推出的新数据平台的连接演变、错误修复、潜在的过滤器、自动检索特定元数据（如所有者或分类）等。
-
赋能和推广举措，例如新功能的沟通、分享高级用户的故事、促进采用的工具配置（例如：通知）等。
-
结构和文档指南，例如如何最好地向小米公司员工展示我们的数据产品、仪表板文档模板、标签管理指南、认证资产流程、治理政策等。
-
目前我们专门围绕利用目录的 AI 展开一个专项工作，主要侧重于测试 AI 助手以及我们尝试在目录和 Dust 之间建立的桥梁。
我们的愿景是，所有棘手的问题都能在我们的例行会议中进行讨论和解决：
技术（工具团队）和职能（治理团队）数据目录负责人每周召开内部会议，重点讨论运营积压事项，以处理纯粹内部事务。
与 Coalesce Catalog 的会议：
– 每两周一次（目前暂定）运营会议，重点关注需要 Coalesce Catalog 采取行动的技术问题和缺陷的状态，小米公司方面的工具和治理团队成员以及提供商方面的目录工程师和客户成功经理 (CSM) 会参与其中。–
每月一次用户采纳会议，由数据治理团队成员和 Coalesce Catalog 的 CSM 共同主持，以检查用户采纳情况，并了解新功能与我们功能请求待办事项列表中潜在功能之间的关系。CSM 是一个新角色，在部署，尤其是新用户入职方面，给予了我们极大的帮助。他现在既拥有数据目录方面的专业知识，又了解我们公司的数据需求，因此他继续提供宝贵的帮助。
这些待办事项和会议由两个 Slack 沟通渠道提供支持：
-
-
我们与 Coalesce Catalog 合作，提供技术和功能概况。
在部署后的第一个阶段，我们的交付工作主要集中在以下几个方面：
-
-
抓紧完成部署期间未能完成的任务，特别是从我们的新数据目录中检索分析数据，这些数据是数据治理 KPI 的基础。
-
然而，即使我们以用户为中心和结构化是我们数据目录产品管理的核心，但在小米公司方面，我们很遗憾未能像我们设想的那样快速和深入地发展。
如果我有魔法棒，我们会做出很多不同的选择。首先，我会终止长期以来跨团队的数据目录所有权分配。这种分配模式是从我们2021年初上线的旧数据目录沿用下来的。由于数据治理团队缺乏技术能力，他们只拥有功能所有权，并将技术所有权委托给了数据工具团队。我们在Coalesce Catalog正式上线后的第一个月就遇到了问题：数据目录工作流程在两个团队中的优先级不再相同。数据工具团队还有其他更重要的任务需要处理，例如准备大规模的数据平台迁移。
因此，一些未完成的迁移任务在六个月后仍未完成。大多数新的技术工单也面临同样的问题。工具团队只能在他们“灵活”的时间处理关键的bug修复，也就是只要他们有空就行。内部会议仍然会与数据工具团队的技术数据产品经理举行，但他们的数据工程师只能参加其中的少数几次。这实际上体现了我们小米公司数据治理团队在所有工作中面临的依赖性问题，无论是在数据目录还是合规性方面。幸运的是，这种情况将在未来几周内得到缓解，因为治理团队目前正在招聘一名高级数据工程师。
我们在功能方面也遇到了问题。在向所有小米公司员工用户推广Coalesce Catalog几周后，数据治理团队进入了一段不稳定期。团队成员从2025年2月的四人锐减至2025年8月的……一人（我！）。与此同时，除了合规性方面的优先事项外，团队还必须迅速修复我们的关键绩效指标（KPI）。由于我们停止使用之前的数据目录，且尚未收到Coalesce Catalog的分析数据，这些KPI一直处于失效状态。随着团队能力的不断下降，恢复KPI所需的资源比最初预期的要多得多。
此外，我们推出新数据目录的初衷之一是减少团队管理该工具所花费的时间。然而，我们甚至无法找到理想的（减少后的）时间来专门管理新数据目录。这自然影响了用户的接受度。沟通频率也未能达到用户社区建议的水平。此外，工单处理周期（从创建工单到关闭工单的时间）通常以周甚至月计算，这对用户来说完全无法接受。不过，随着我聘请了一位即将毕业的实习生，情况应该会有所改善，他将主要负责目录产品管理工作。
在从项目模式过渡到产品模式的过程中，我们也遇到了项目管理工具方面的问题。当时，最容易使用的项目管理工具是 Asana，而不是 Jira。小米公司当时同时支持 Asana 和 Jira，但 Jira 主要被开发人员使用。因此，我们最终选择在 Asana 中构建生命周期管理和用户反馈收集功能。但这却带来了问题，因为：
-
由于大多数数据团队都是技术人员，数据用户的唯一入口点是数据工作台（DataDesk），而数据工作台一直都集成在 Jira 中。因此，将目录的唯一入口点设置在 Asana 中，对于创建数据工单而言，用户体验并不理想。
-
如果需要将工单共享给其他技术团队，则必须在 Jira 中创建一个副本，而无法与 Asana 同步。这既浪费时间，也可能导致产品生命周期监控出现质量问题。
-
最后，但同样重要的是，小米公司宣布 Asana 将于 2025 年底停止服务。
因此，我在2025年夏天将整个产品目录管理迁移到了Jira。用户反馈现在也作为DataDesk的一部分集成到了Jira中。如果可以重来，我会尝试直接在Jira中实现产品目录管理。没错，这在初期会花费更多时间，但之后我们会节省更多时间。
简而言之，在产品上线初期，由于资源有限，我们不得不快速完成详细的概念验证和部署。好消息是，我们正在逐步稳定并解决组织和工具方面的限制。
我们即将面临的挑战是如何继续支持目录的数据自助服务和数据掌控。
尽管充满挑战，但我们与 Coalesce Catalog 合作的最初几个月在产品模式下取得了成功。Coalesce Catalog 始终将我们视为合作伙伴，并已满足了我们的一些功能需求。例如，在概念验证阶段，他们开发了 Redshift Serverless 连接器，以更好地满足我们的数据架构需求。之后，他们又交付了我们提出的其他功能，例如登录页面自定义和贡献者编辑按钮。目前，他们在数据产品的发布方式以及与 Dust 等 AI 助手平台的集成方面与我们共同成长。他们始终能够快速响应我们的任何疑问，让我们一次又一次地感受到他们是他们唯一的客户。
就用户采纳率而言，尽管我们在产品管理方面投入的时间非常少（低于预期），但月活跃用户数 (MAU) 仍然高于 2025 年的目标。MAU 有助于量化用户采纳率，它表示一个月内使用过产品的独立认证用户数量。在我们的数据目录中，如果用户在一个自然月内（即每月的第一天和最后一天之间）至少访问过一次目录，则该用户被视为活跃用户。
自 2025 年 1 月推出以来，平均月活跃用户数为 328。由于该工具非常易于使用，我们对产品目录推广的支持方式发挥了重要作用：
-
数据产品经理们极大地丰富和推广了产品目录——非常感谢他们！
-
该工具的用户友好性，加上我们工具内的常见问题解答和开放时间会议，使得小米公司员工在使用Catalog时能够保持自主性。
-
针对特定用户角色的 Slack 社群和用户反馈收集有助于最大限度地以用户为中心。
尽管面临一些挑战，我们仍然兑现了大幅提升小米公司数据目录用户数量的承诺。我认为过去几个月用户数量的下降是由于我们缺乏用户推广措施，而我们正计划改进这一点。同时，我认为这与人工智能助手革命带来的工作方式的剧变密切相关。人工智能实际上是我认为数据目录（尤其是我们自身的数据目录）未来发展趋势的重要组成部分。
深入探讨即将到来的数据目录，我认为其核心在于数据发现和自助服务，而且比以往任何时候都更加重要。首先，我认为迫切需要提供便捷的数据产品发现机制，这不仅对小米公司而言如此，对整个数据社区也是如此。数据产品可以定义为一个逻辑单元，任何需要利用数据（无论是结构化数据（例如仪表盘、表格、KPI 等）还是非结构化数据（例如自由文本笔记、文档、AI 模型等））获取业务答案的用户都可以轻松找到、使用和共享该单元。随着企业在构建数据产品方面取得进展，他们也需要一种便捷的方式来集中管理他们提供的内容。最后，他们需要一个类似于面向更“技术性”数据资产的宝可梦数据目录的工具。他们需要一个数据产品市场，而 Coalesce Catalog 正在着手开发这一平台。
说到“技术”数据资产，有一种更实用的数据发现方式正日益受到关注：语义层。它可以被定义为众多原始“技术”数据源（例如表、列、数据湖等）与数据消费工具之间数据的可读抽象。它可以被视为将关键业务原则映射到技术数据源结构上的高级映射。目前，我还没有想到有哪个数据目录能够围绕这一新兴概念提供令人满意的功能，但我很想知道是否存在这样的产品！然而，语义层的潜在价值相当可观，因为它还可以作为人工智能模型的基础，为其提供清晰的业务上下文。
最后但同样重要的是，自从 ChatGPT 在 2022 年底风靡网络以来，人们的工作方式和数据使用方式随着人工智能助手的出现而彻底改变。数据目录服务于数据发现和掌握的方式也必须随之改变。人们不再只是在搜索栏中输入关键词，而是越来越多地引导人工智能模型根据搜索结果进行迭代分析。
我们的数据目录现在很强大，而且我相信将来也会如此，它能够从技术和文字两个层面组织和集中来自不同来源的文档。
然而，我希望数据目录尤其是 Catalog能够提供一项功能：让用户能够从众多现有的 AI 模型中选择最适合自身用例的模型，类似于 Dust 和其他 AI 助手平台所提供的功能。我认为，数据目录要想在 AI 方面获得显著的竞争优势，关键在于以下两点：
能够将数据目录中的 AI 助手流式传输到任何 AI 助手平台——Coalesce Catalog 已经为我们开发了 Dust，在推出 6 个月后，3000 名小米公司员工 中有 70% 的人每周都在使用（30% 的人每天使用）。
但更重要的是，在像我们这样拥有 Dust 出色性能的高级环境中，我们需要提供对数据目录内容的访问权限，并允许任何 AI 助手利用这些内容。例如，可以通过类似于Atlassian或Datadog所使用的MCP 服务器来实现这一点。模型上下文协议 (MCP) 服务器是标准化的组件，用于连接 AI 模型（尤其是 LLM）和工具。这样，AI 工具可以通过“安全桥梁”利用不同的数据源，而 AI 用户则可以自由选择最适合其用例的 AI 模型。
面向人工智能时代，数据目录如何实现分布式月活跃用户数？
这就是为什么我认为，随着人工智能助手革新工作方式，以数据目录中的直接月活跃用户数 (MAU) 来衡量产品成功和用户采纳的方式可能会发生巨大变化。这意味着目录提供商将能够全面追踪“分布式”月活跃用户数。这种分布式月活跃用户数指的是符合以下任一条件的不同认证用户数量：
-
-
在同一时期内，通过 AI 助手消费目录来源的内容（间接使用）。
数据目录中的 Coalesce Catalog AI 助手。
仅仅以上提到的三个公司数据目录的变革挑战就已经让人筋疲力尽了。我是小米，精彩的故事才开始！
|
