5 boas práticas que aprendi como Data Product Owner
Ao final do próximo mês, completo 1 ano de vinda para a Engenharia de Dados. Como já explorado no meu 1º artigo, atuo como Data Product Owner que é o papel que fica entre Engenharia e Negócio.
Pelo que vivenciei nesse ano, entendo que é um papel muito novo no mercado, e que seus perfis, papéis e responsabilidades ainda estão sendo escritos, conforme necessidade e disponibilidade de cada empresa.
Notei que existem alguns fatores que me ajudaram muito no trabalho do dia a dia e conforme ia colocando-os mais em prática comecei a ter menos barreiras para as entregas. Alguns assuntos aqui podem parecer triviais e talvez até sejam, mas você se surpreenderia com a quantidade de coisas no dia a dia que podem tirar seu foco e atenção desses pontos fundamentais. Pode ser que na sua empresa, você não seja necessariamente um Data PO, mas um engenheiro, ou um analista que precisem se envolver com a parte de levantamento das demandas e gestão dos backlogs por exemplo, de qualquer forma o objetivo aqui é compartilhar com pessoas que exerçam essa função de alguma forma, alguns dos meus aprendizados.
1. Quebre, quebre, quebre suas entregas
Um dos maiores motivos de insatisfações quando comecei, era a sensação da área de Negócio de que as coisas não andavam. Os cards ficavam parados e no final da sprint, quase não haviam entregas . Aos poucos fui percebendo que isso acontecia porque os “Definition of Done” eram entregas que deveriam ser quebradas em muitas etapas. Pessoalmente eu gosto de trabalhar com no mínimo 4 etapas para a entrega de uma tabela/objeto em produção, mas isso é o esqueleto básico que pode mudar dependendo da complexidade. Cabe uma análise para entender quais etapas se encaixam mais no seu modelo:
1. Entendimento, análise e definição do modelo de dados — Data PO
2. Documentação (após aprovação do Negócio) — Data PO
3. Criação procedure/pipeline na Cloud e disponibilização do output em Sandbox para validação do Negócio — Engenheiro
4. Code review e produtização — Engenheiros
Implementar essa mudança na gestão dos cards me ajudou muito na gestão de expectativas dos meus clientes de Negócio que tiveram mais visibilidade das etapas do processo de Desenvolvimento.
Além disso, foi fundamental entender quais produtos de dados estavam envolvidos naquela demanda/projeto criando as famosas “histórias”. Em um projeto de tecnologia como desenvolvimento de um site ou aplicativo, essa divisão já é bastante clara, e existe muito material em literatura para você consultar e aprender. Porém como já disse para dados é tudo muito novo e precisamos ir construindo, literalmente, essa história juntos.
Definir épicos e histórias de dados leva em consideração mais o domínio/contexto dos dados e menos a funcionalidade, por isso é preciso realmente conhecer o contexto de Negócio junto as áreas para estruturar histórias coerentes.
2. Desenhe seu modelo de dados e saiba o que é preciso para levantar o maior número de informações necessárias para o Desenvolvimento
Para tabelas de camada negocial que já são mais complexas, ajuda muito o Engenheiro se o modelo conceitual já for definido no momento da documentação. Você pode aplicar um modelo simples baseado em MER(Modelo de Entidade e Relacionamento) que já é o suficiente para dados relacionais, que hoje ainda são a nossa maioria. O intuito aqui é descrever da maneira mais gráfica e didática possível a sua demanda. O Engenheiro tem toda liberdade para modelar os dados da forma mais performática, porém com esse desenho em mãos ele consegue entender um pouco mais do que é necessário e como os dados se conectam.
Além da modelagem conceitual, existem outros fatores que influenciam muito na prontidão dessa demanda para o desenvolvimento de um Engenheiro como: tipo e frequência de carga, e agora na cloud, a definição de campos de particionamento e clusterização são informações fundamentais que um Data PO precisa ter em mãos pensando em performance daquele produto que será desenvolvido. Se você ainda não conhece esses últimos conceitos, sugiro esse artigo do meu colega Rodrigo que traz uma explicação bem detalhada desses pontos.
3. Comunique-se com seu engenheiro, o tempo todo que ele precisar
Um dos principais desafios de um Data PO é conseguir fazer a gestão da rotina. Fazemos malabarismos para reportar aos stakeholders, atender as dúvidas e necessidades de área de Negócio, participar de todas as agendas necessárias além das nossas funções de documentação e gestão de backlog. Mas uma atividade super importante que precisa ser priorizada sempre que necessário é a comunicação com seu Engenheiro. É muito normal no decorrer do desenvolvimento, surgirem dúvidas em cima da documentação que você fez ou até mesmo blocks. Dedicar esse tempo com o seu Engenheiro quando ele precisar vai te salvar bastante tempo de retrabalho lá na frente, garantindo que o desenvolvimento irá refletir 100% da necessidade de Negócio que você mapeou.
4. Cria formas didáticas para falar de dados
Um dos fatores que mexeu muito o ponteiro no meu dia a dia e que com frequência pode ser subestimado por se tratar de uma soft skill, é a comunicação e didática com as áreas de Negócio. Para áreas mais técnicas como a própria Engenharia ou áreas vizinhas como BI e Ciência de Dados, essa atividade se torna dispensável, porém com frequência a área de Negócio não possui conhecimento técnico de dados para compreender as complexidades envolvidas e tomar decisões de priorização/planejamento assertivas. Marcar conversas para explicar alguns conceitos, montar treinamentos direcionados a público não técnico e montar apresentações usando artifícios de analogias que irão captar esse público são algumas ferramentas que usei e tiveram bastante retorno positivo. É uma situação ganha ganha em que nós trazemos a área para mais perto de nós e influencia muito nas decisões que eles terão em suas demandas. Abaixo, segue uma apresentação que fiz para uma diretoria cliente de uma analogia já bem utilizada que é a das peças de lego. Por mais que pareça trivial para a área de Tech, foi muito importante para mostrar a importância da Engenharia de Dados dentro do projeto.
5. Que problema estamos resolvendo?
Como disse acima, ainda existe muito pouco material falando de produtos de dados, e como consequência disso, é preciso mergulhar nos conteúdos que já temos e aos poucos ir fazendo as conexões de como aplicar isso em dados.
Um dos principais assuntos que estou mergulhando atualmente é o Product Management que é mais estratégico do que a atuação do PO em si, porém agrega muito aprender seus conceitos. Acredito que a principal lição que aprendi e aplico para o meu dia a dia é entender o problema e não a solução. Quando você descuida um pouco já se vê pensando na solução que o seu cliente acredita ser a correta. É papel nosso como Data PO questionar e explorar o problema primeiro, fazendo o link entre as dores e as possibilidades técnicas, pensando no caminho mais simples possível, porém que atenda o Negócio de maneira usual e com qualidade.
Para quem se interessar e quiser começar a entender mais sobre o assunto, indico muito o livro Inspired: How to Create Tech Products Customers Love escrito por Martin Cagan que é uma excelente porta de entrada para os iniciantes de PM como eu.
Conclusão
Em resumo de tudo que foi falado, temos uma área muito nova (Dados) e uma função muito nova (Data PO) que ainda está se construindo e criando sua identidade, processos e boas práticas no mercado. Espero que de alguma forma esse artigo possa ajudar você caso tenha problemas parecidos com o que eu tive nesse primeiro ano. Os desafios estão só começando e com certeza precisamos nos aproximar cada vez mais para trocar aprendizados e experiências.
