No ano passado, Emilie Schario e Taylor Murphy propuseram essa ideia maravilhosa de “dirigir sua equipe de dados como uma equipe de produto” . A principal premissa do artigo foi esta: as equipes de produto têm muitas práticas excelentes que as equipes de dados se beneficiariam com a adoção. Mas em algum lugar ao longo do caminho, perdemos esse ponto de vista e felizmente o substituímos por espantalhos: mantendo sistemas de nível de produção para nossos ativos de dados , construindo mais produtos de dados ou definindo minuciosamente o que significa produção a serviço de fortalecer contratos de dados . Todos eles certamente merecem consideração, mas estão mais preocupados com o manuseio adequado de dados e ativos de dados do que com as equipes de dados que realmente geram o impacto.

A ideia central aqui nunca foi questionar a definição e os limites do “Produto de Dados” ou definir SLAs para produtores de dados, mas nos obrigar a reconsiderar como as equipes de dados operam usando equipes de produtos como modelo.

Gostaria de passar algum tempo discutindo exatamente como administrar sua equipe de dados como uma equipe de produto.

Duas ideias centrais: foco no usuário e proatividade

Existem dois princípios básicos que as equipes de produto incorporam - foco no usuário e proatividade. Vamos discutir cada um por sua vez.

Centralização no usuário

As melhores equipes de produto são centradas no usuário. Eles falam com seus clientes regularmente e permitem que o feedback direto do usuário influencie diretamente seu roteiro. Este flywheel é a força vital de qualquer bom produto - ele garante que eles não sejam apenas recursos de envio, mas que resolvam problemas.

As equipes de dados precisam operar da mesma maneira. Ficamos muito encantados com o quão tecnicamente interessante nosso trabalho pode ser e esquecemos que não somos paraísos independentes para atividades científicas/de engenharia — somos uma unidade de negócios contratada para fornecer valor comercial. E se nós, como equipes de produtos, não resolvermos problemas de negócios com dados, nosso metafórico “produto de dados” (todo o trabalho de dados que fazemos) está falhando.

Isso não significa responder reativamente a solicitações ad hoc. Isso também não significa evitar completamente os empreendimentos científicos. Significa simplesmente ficar atento ao que o negócio precisa e buscar oportunidades para esse fim. Embora Taylor e Emilie sugiram que seus colegas de trabalho são seus clientes, não acho que isso seja suficiente - a empresa é seu cliente. Você precisa conhecê-lo, entendê-lo e orientar tudo o que fizer em torno dele.

Proatividade

Em segundo lugar, as melhores equipes de produto têm processos proativos configurados para dar suporte ao processo de construção do produto. Eles fornecem a si mesmos um espaço intencional para definir a visão, debater, perseguir projetos de paixão que estão fora do escopo de atender diretamente às solicitações dos clientes.

As equipes de análise, por outro lado, raramente operam assim. No mínimo, devemos gastar algum tempo explorando os dados fora das solicitações de entrada. E no nível da equipe, devemos estar atentos aos padrões para que possamos elaborar intencionalmente nosso roteiro e fazer um trabalho de alta alavancagem.

Dito isso, o trabalho reativo certamente ainda tem seu lugar – os analistas são o principal meio pelo qual a empresa pode explorar os dados, portanto, muitas vezes nos encontraremos necessariamente em uma função de suporte. Mas a chave é constantemente buscar entender o contexto por trás desse trabalho e deixar que esse contexto motive projetos estratégicos e de alto impacto.

Mas como você pode começar?

O artigo original do LO tem algumas ótimas sugestões em nível de organização para tornar tudo isso possível: tenha pessoal suficiente para ter largura de banda suficiente para ser estratégico; reunir uma equipe multidisciplinar para se inspirar. Para adicionar a isso, aqui estão algumas mudanças concretas no nível do processo que você pode fazer imediatamente:

1. Estabeleça um processo de consolidação do conhecimento.‍

Colocar o trabalho de sua equipe em um só lugar é um pré-requisito para ser centrado no usuário. Para que seu trabalho seja centrado no usuário, você precisa ter uma visão de todo o trabalho que está sendo solicitado a fazer. Organizar seu trabalho em um espaço compartilhado pode permitir a correspondência de padrões no trabalho de sua equipe - equivalente a uma equipe de produto estudando as descobertas da pesquisa de UX antes do brainstorming.

Este será o seu maior obstáculo porque a não conformidade é um grande problema. As pessoas se esforçam para manter o status quo, e muitas vezes tenho visto iniciativas de documentação/compartilhamento de conhecimento falharem. A publicação do trabalho em um espaço de trabalho wiki como Notion, Confluence ou papel do Dropbox (e para uma solução específica de análise, hiperconsulta) pode quebrar essa barreira.

Os principais componentes aqui para garantir a adoção generalizada:

• Abaixe o atrito ao uso. Por mais tentador que seja usar o git e configurar um processo de revisão por pares, as camadas do processo não garantirão o rigor — elas reduzirão a adoção. Faça algo fácil, leve e concentre-se em garantir que sua equipe coloque seu trabalho na ferramenta.
• Configurar andaimes organizacionais . Mais uma vez, use uma ferramenta como hyperquery, Notion ou Confluence, com uma estrutura wiki que permitirá que sua equipe estabeleça práticas não apenas de centralização, mas também de organização . Concorde com categorias funcionais razoáveis e crie um documento central “Comece aqui” que integre novos analistas em suas práticas.

2. Entenda as necessidades do negócio intimamente.

Não somos apenas trabalhadores técnicos. Somos uma ponte entre os dados e o resto do negócio. E se apenas mergulharmos nos dados – que é apenas um lado da conversa – não seremos tão eficazes quanto deveríamos ser.

Orgulhamo-nos de nossa proeza técnica, mas só somos eficazes na medida em que sabemos por que estamos fazendo nosso trabalho. Sem grande perspicácia nos negócios, escreveremos análises inúteis após análises até que sejamos movidos para o Storage B , nossas interações relegadas a extração de dados.

O que isso parece, praticamente falando:

• Sempre pergunte por quê . Antes de mergulhar no SQL, certifique-se de estar alinhado com seus stakeholders nos objetivos de negócios. Escreva isso, concorde com uma abordagem e só então faça o trabalho. Isso estabelece um precedente de que seu envolvimento no processo de tomada de decisão não se limita ao trabalho técnico — no mínimo, você será visto como um tradutor e, na melhor das hipóteses, como um parceiro de pensamento.
• Preocupe-se com o negócio. Parece óbvio, mas muitas vezes vi analistas e cientistas de dados colocarem vendas nos negócios e mergulharem nos aspectos técnicos de seu trabalho. Esse comportamento é um prenúncio de uma organização analítica verdadeiramente disfuncional e de baixo impacto. Maior impacto geralmente não vem de melhores análises, mas de impacto orientado por dados em níveis mais altos de execução estratégica.

Conclusão

A natureza da análise de dados evoluiu drasticamente na última década. Temos acesso a mais dados, mais poder de computação e mais ferramentas do que nunca. Mas ainda não descobrimos que devemos operar dentro de uma organização com nossos novos poderes. Pode ser útil aqui trazer práticas bem-sucedidas de outros domínios. Nas equipes de produtos, em particular, o foco no foco no usuário e na proatividade pode significar a diferença entre uma equipe de análise de suporte técnico e uma que realmente conduz a estratégia. E o foco no usuário e a proatividade vêm de uma consciência aguda das necessidades de negócios e melhores práticas de compartilhamento de conhecimento.

Postagem de blog original publicada no hyperquery.