Papel dos Data Products Owners no time de Engenharia de Dados
Há 6 meses tomei a decisão profissional de mudar de área. Depois de 10 anos e 4 empresas diferentes, sempre trabalhando com Supply Chain direcionada totalmente ao negócio, decidi que era hora de migrar para Tecnologia e me dedicar mais aquilo que já vinha atraindo a minha atenção e esforços a algum tempo: dados.
Mas qual função escolher na área de dados? Eu não me identificava muito com Ciência de Dados ou BI, e o assunto que sempre me atraiu foi a Engenharia de Dados. Mas como eu, administradora de empresas, com um background todo voltado pra negócios, conhecendo dados apenas em um contexto acadêmico de pós-graduação, poderia me inserir numa área tão técnica? A vaga de Data Product Owner me apareceu e caiu como uma luva, pois com ela consegui conciliar duas coisas importantes: contribuir com minha visão de negócios em uma área extremamente técnica e ter a melhor oportunidade possível para desenvolver este lado técnico.
Mas afinal, o que um Data Product Owner faz?
Funções em um time de dados
Em um time de engenharia de dados, ainda em muitas empresas, é comum vermos o papel do engenheiro também mesclado em analista, cientista, BI etc., o que dificulta muito uma gestão mais estratégica dos produtos que estão sendo criados.
Em uma empresa de grandes proporções como o Grupo Boticário, fomos entendendo que a separação desses papéis mais “clássicos”, somada à função do Data Product Owner, poderia ser uma solução muito viável para atingir um resultado mais estratégico e produtivo. A função do DP ainda é pouco vista na literatura quando comparada as suas vizinhas, mas fomos testando esse desenho e estamos tendo resultados bem interessantes.
Papel do Data Product
E qual seria o papel do DP na engenharia de dados se quem de fato irá executar a parte de “coding” é o(a) engenheiro(a)?
Eu costumo dizer que uma das principais funções de um bom DP é fazer o “mise em place” do engenheiro, ou seja, para que o(a) engenheiro(a) consiga colocar a mão na massa e não perder tempo, nós entendemos, analisamos, definimos e separamos todos os ingredientes para o bolo, na ordem correta de execução para o melhor rendimento possível da receita. Para isso, é necessário que o DP transite bem entre esses dois mundos, tanto de negócios como da linguagem mais técnica da Engenharia.
Toda a tradução de um projeto vindo da área de negócio é feita sob gestão do Data Product, e essa etapa é de extrema importância para que sejam identificadas as oportunidades de melhorias e automatizações, sinergia de dados com outras frentes, evitando duplicidades e sempre garantindo que a solução construída atenda os padrões da plataforma, seja ela Google Cloud, AWS, Azure…
Além disso, com a catalogação de dados que o DP faz, ajudamos o processo de governança, e que o dado seja compreensível para todos que quiserem utilizar dele. Ou seja, estamos contribuindo diretamente na caminhada da tão sonhada democratização dos dados!
Data Product vs Analista de Negócio
Uma dúvida muito comum entre papéis e responsabilidades é sobre a diferenciação entre um DP e o(a) Analista de Negócios. A primeira e fundamental diferença é que normalmente a figura do Analista de Negócio pertence à própria área de negócio, enquanto o DP está na área de Engenharia de Dados. Ambos precisam trabalhar juntos, porém, o Analista possui o conhecimento mais profundo da utilização no dia a dia daqueles dados, além de ser responsável por analisá-los para gerar os insights da área e habilitar tomadas de decisão baseadas em dados. O Analista é o ponto focal para que o DP tire suas dúvidas e entenda melhor a necessidade do projeto para traduzi-la ao engenheiro(a).
Data Product e o Ágil
Por fim, um outro skill importante do DP é o conhecimento e aplicação das metodologias agéis. Um dos papéis importantes do DP é o de ser o representante do produto de dados em uma squad. Ele(a) precisa garantir o melhor cenário entre velocidade de entrega e integridade/qualidade/padronização do produto de dados que está sendo desenvolvido. Mais que um simples levantador de requisitos, o DP precisa se utilizar da metodologia para fornecer entregas que atendam o negócio sem perder de vista a qualidade do produto, fazendo continuamente o detalhamento e priorização de releases e sprint backlogs.
Conclusão da história…
Ter a figura do DP dentro da área de Engenharia de Dados aqui no GB tem se provado bem vantajoso, pois garantimos um alinhamento contínuo entre DPs e engenheiros. Apesar de habitarem mundos muito distintos de “business x técnico”, as empresas necessitam cada vez mais que essas áreas se interliguem caminhando juntas, e o DP é um papel de extrema importância para auxiliar nessa tradução.
A melhor parte é que, como se trata de uma nova função, temos o espaço pra muita diversidade de expertises no time, o que é excelente, pois a troca no dia a dia se torna muito mais rica. Pessoas com perfil mais técnico que querem aprender de negócio e vice e versa estão chegando e sempre agregando mais e mais.
