A figura do Data Translator — parte 2: Data Translator vs Data Product Manager
Saiba navegar pelas diferenças sdimilaridades essenciais entre Data Translators e Data Product Managers. Descubra como essas funções impulsionam a inteligência dos negócios e a inovação Data-Driven
--
Disclaimer: Este artigo faz parte da série, “Data Mesh na Prática”, que visa abordar de maneira prática e objetiva como de fato trazer o que temos de literatura para o mundo real. Abaixo segue a lista completa dos artigos :
- Data Mesh? O que é isso, é de comer?
- Data Product vs. Data as a Product
- O Ciclo de Desenvolvimento Ideal para Data Products: L5 Framework em Ação
- Product Team vs. Data Product Team
- A figura do Data Translator — parte 1: Você sabe o que é um Data Translator?
- A figura do Data Translator — parte 2: Data Translator vs Data Product Manager
- A figura do Data Translator — parte 3: O dia a dia de um Data Translator
- Data Mesh é cultura, não um framework!
- Como saber se a minha organização está pronta e/ou precisa do Data Mesh?
- Medindo os resultados de cada um dos princípios do Data Mesh
Como falamos na parte 1 dessa série, (A figura do Data Translator — parte 1: Você sabe o que é um Data Translator?), o Data Translator tem como principais funções:
- Traduzir o jargão técnico em linguagem de negócio
- Identificar oportunidades de negócio através dos dados.
- Fazer a gestão de programas, projetos e iniciativas de dados
- Desenvolver soluções data-driven
Porém, dúvidas como a da Alice Pizetta no artigo anterior, me fez detalhar mais as semelhanças e diferenças de amba a posições.
Diferenças e Semelhanças Entre os Papéis de Data Translator e Data Product Manager
A distinção fundamental entre o Data Translator e o Data Product Manager do ponto de vista de literatura, reside em suas áreas de foco. Enquanto o Data Translator concentra-se na comunicação eficaz e na transformação de análises complexas em informações compreensíveis, o Data Product Manager está mais envolvido no ciclo de vida de desenvolvimento de produtos orientados por dados.
Para compreender melhor, precisamos entender como funciona na prática o ciclo de desenvolvimento ideal de um produto de dados. Este ciclo já foi abordado em O Ciclo de Desenvolvimento Ideal para Data Products: L5 Framework em Ação, porém vamos recapitular
Ciclo de Desenvolvimento Ideal de um Produto de Dados
Simplificando um pouco o processo de PDCA, temos basicamente, três grandes passos dentro do ciclo de planejamento, desenvolvimento, entrega e acompanhamento de um produto dados: Discovery, Development, Delivery.
Assim como estágios dentro desses passos bem definidos para uma entrega de qualidade. Abaixo exempifico cada um deles e cada uma das suas fases:
Screening Stage
O estágio de "screening", é o momento onde realizamos a triagem e garatimos os definitons of ready e done. Dividimos ela em duas fases:
- Immersion: Neste momento, realizaamos o entendimento da demanda, como os primeiras perguntas quanto ao Produto a ser desenvolvido, para que, quem consumirá, etc.
- Ideation & Planning: Aqui, trabalhaamos na identificação da viabilidade do produto, traduzindo de forma colaborativa com os staeholders, definindo as métricas de acompanhamento de sucesso, Definition of Done e Definition of Ready.
Launching Stage
O estágio de "launching", é o momento de garantirmos que o que foi idealizado e planejao na ae anterior, será tangibilizado, com a entrega de um produto mínimo viável. Sendo asim, dividimos em faes como:
- Experimentation: Aqui temos o tempo para realizar as prova de conceitos (POC), testes de viabilidade e mapeaamento mais detalhaaod para execuçãao o produto de dados.
- Execution: Aqui entra na fae do desenvolvimento do produto de dados efetiva, com suas regras e requisitos bem definidos.
- Approval: Neste momento, ocorre a validação dos D.O.R (Definition of Ready), D.O.D (Defintion of Done) com os stakeholders e o plaanejamento para a próxima fase de "landing"
Landing Stage
Uma vez, com os requisitos definidos e aprovaos entre todos os times, paamos para a fae de colocar no ar o produto de dados para consumo. Nisto divididmos nas fases de:
- Build: A finalização o produto de dados, deixando pronto para ir para produção e consumo dos stakeholders.
- Deploy: A publicação e form efetiva o produto de dados em ambiente produtivo.
Learning Stage
Este é o estágio provavelmente mais negligenciado durante o ciclo. Neste estáio conseguimos saber exatamente a qualidade do processo e mensura-lo se foi um sucesso ou não. Para iso divididmos em:
- Measure: Compilamos, crimos e relacionamo a métric para acompanhamento do sucesso do que foi entregue do produto de daos e se ele resolve os problemas propostos no documento de visão do produto.
- Detect: Após medir pelo determinado tempo do produto, passamos a detectar se o produto de dados está sendo utilizado ou não, se as métricas de sucesso estão sendo atingidas, o nível de satisfação do produto, dando a possibilidade do Data Translator propor melhoria contínuas ou novas anáises derivadas do produto de dados construído.
Como gosto de exemplificar as coisas, pra trazer um pouco mais de clareza, segue um caso hipotético de construção de um produto de dados.
No entanto, esses papéis compartilham semelhanças cruciais. Ambos exigem colaboração eficiente com equipes multidisciplinares e habilidades de comunicação excepcionais. Além disso, tanto o Data Translator quanto o Data Product Manager precisam ter uma compreensão sólida de análise de dados e suas aplicações para fornecer insights valiosos para a tomada de decisões estratégicas.
