去年，Emilie Schario 和 Taylor Murphy 提出了 这个绝妙的想法。这篇文章的关键前提是：产品团队有很多很棒的实践，数据团队可以从采用中受益。但在此过程中，我们忽略了这一点，并愉快地用稻草人取而代之：  ， ，或者煞费苦心地定义 在强化 中的意义。所有这些当然值得考虑，但他们更关心数据和数据资产的正确处理，而不是实际推动影响的数据团队。 “像产品团队一样运行你的数据团队” 为我们的数据资产维护生产级系统 构建更多数据产品 生产 数据合同 这里的中心思想绝不是对“数据产品”的定义和边界争论不休或为数据生产者设置 SLA，而是迫使我们以产品团队为模型重新考虑数据团队的运作方式。 我想花一些时间准确地讨论如何像产品团队一样运行您的数据团队。 两个核心理念：以用户为中心和主动性 产品团队体现了两个核心原则——以用户为中心和积极主动。让我们依次讨论。 以用户为中心 最好的产品团队是以用户为中心的。他们定期与客户交谈，让直接的用户反馈直接影响他们的路线图。这种飞轮是任何优秀产品的命脉——它确保它们不仅是交付功能，而且是解决问题。 数据团队需要以同样的方式运作。我们太着迷于我们的工作在技术上的有趣程度，我们忘记了我们不是科学/工程追求的独立避风港——我们是一个被雇佣来提供商业价值的业务部门。如果我们像产品团队一样，不使用数据解决业务问题，我们隐喻的“数据产品”（我们所做的所有数据工作）就会失败。 这并不意味着对临时请求做出反应性响应。这也不意味着完全回避科学努力。它仅仅意味着与业务需求保持一致并为此寻求机会。虽然 Taylor 和 Emilie 建议您的同事是您的客户，但我认为这还不够——企业就是您的客户。你需要了解它，理解它，并围绕它做每一件事。 主动性 其次，最好的产品团队建立了积极的流程来支持产品构建过程。他们为自己提供了有意识的空间来设定愿景、集思广益、追求超出直接满足客户要求范围的激情项目。 另一方面，分析团队很少这样运作。至少，我们应该花一些时间探索入站请求之外的数据。在团队层面，我们应该寻找模式，这样我们就可以有意识地制定我们的路线图并进行高杠杆工作。 话虽如此，反应性工作仍然有它的位置——分析师是企业探索数据的主要手段，因此我们经常会发现自己必须扮演支持角色。但关键是不断推动了解这项工作背后的背景，并让这种背景激发战略性的高杠杆项目。 但是你如何开始呢？ 最初的 LO 文章有一些很棒的组织层面的建议，可以让这一切成为可能：拥有足够的员工人数，这样您就有足够的带宽来制定战略；召集多学科团队从中汲取灵感。除此之外，您还可以立即进行一些具体的 级更改： 流程  1. 建立知识整合流程。 将团队的工作放在一个地方是以用户为中心的先决条件。为了使您的工作以用户为中心，您需要了解要求您完成的所有工作。在共享空间中组织你的工作可以在你的团队工作中实现模式匹配——相当于一个产品团队在头脑风暴之前研究用户体验研究结果。 这将是您最大的障碍，因为不合规是一个大问题。人们努力保持现状，我经常看到文档/知识共享计划失败。在像 Notion、Confluence 或 Dropbox 论文这样的 wiki 工作区中发布作品（对于特定于分析的解决方案，超查询）可以打破这一障碍。 此处确保广泛采用的关键组件： 尽管使用 git 和建立同行评审流程可能很诱人，但流程层级并不能确保严格——它们会降低采用率。做一些简单、轻松的事情，并专注于确保您的团队将他们的工作投入到工具中。 降低使用摩擦。 。同样，使用超查询、Notion 或 Confluence 之类的工具，其 wiki 结构将使您的团队能够围绕集中化和 建立实践。就合理的功能类别达成一致，并创建一个中央“从这里开始”文档，让新分析师加入您的实践。  搭建组织脚手架 组织  2、深入了解业务需求。 我们不仅仅是技术工人。我们是数据与其他业务之间的桥梁。如果我们只是沉浸在数据中——这只是谈话的一方面——我们就不会像我们应该的那样有效。 我们为自己的技术实力感到自豪，但我们只有在我们知道为什么要做我们的工作时才有效。如果没有敏锐的商业头脑，我们将在分析之后编写毫无意义的分析，直到我们转移到  ，我们的交互降级为数据拉取。 存储 B 实际上，这看起来像什么：   在您深入研究 SQL 之前，请确保您在业务目标上与利益相关者保持一致。写下来，就方法达成一致，然后才开始工作。这开创了一个先例，即您在决策过程中的参与不仅限于技术工作——至少，您至少会被视为一名翻译，充其量是一名思想伙伴。 。 总是问为什么 这听起来很明显，但我经常看到分析师和数据科学家对业务视而不见，沉浸在他们工作的技术方面。这种行为是一个真正功能失调、影响低的分析组织的预兆。更高的影响通常不是来自更好的分析，而是来自更高级别战略执行的数据驱动影响。 关心业务。 结论 在过去的十年中，数据分析的性质发生了巨大的变化。我们可以访问比以往更多的数据、更多的计算能力和更多的工具。但是我们还没有想出我们应该在一个拥有我们新发现的权力的组织内运作。将其他领域的成功实践带到这里会很有帮助。特别是对于产品团队来说，关注以用户为中心和主动性可能意味着帮助台分析团队和真正推动战略的团队之间的区别。以用户为中心和主动性来自对业务需求的敏锐意识和更好的知识共享实践。 在超查询上 的原始博客文章。 发布

The writer has or has previously had a business relationship with companies mentioned in this article.

Dropbox

YouTube

Better collaboration = better analytics

Read My Stories

該音頻是用故事的原始語言製作的！

数据团队如何从像产品团队一样运行中受益

About Author

註釋

標籤

这篇文章刊登在

Related Stories

点击赚钱：Telegram 可能会在 Solana 之前吸引下一个 100 亿加密用户

创建以用户为中心的加密产品：客户反馈的重要性

扬帆起航：利用数据湖开发生产级 RAG 应用程序

架构师指南：构建 AI/ML 数据湖参考架构

点击赚钱：Telegram 可能会在 Solana 之前吸引下一个 100 亿加密用户

创建以用户为中心的加密产品：客户反馈的重要性

扬帆起航：利用数据湖开发生产级 RAG 应用程序

架构师指南：构建 AI/ML 数据湖参考架构

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps