Nem todo dado é um produto. Essa foi a provocação inicial de uma palestra sobre engenharia de dados no palco Stadium, que listou os critérios que precisam existir para que um conjunto de dados mereça o rótulo de "produto": propósito claro, consumidores bem definidos, propriedade estabelecida (tanto no time técnico quanto na área de negócio dona do conceito), documentação viva, interface de uso adequada e um ciclo contínuo de melhoria — nunca um projeto com data de término.
Dashboard, tabela, aplicação ou API
Segundo o palestrante, o mesmo critério pode se manifestar em formatos bem diferentes de entrega. Um dashboard dentro de uma ferramenta de BI é o exemplo mais clássico, mas uma tabela também pode ser produto — por exemplo, quando serve para harmonizar um indicador que antes tinha lógicas divergentes entre áreas. Aplicações analíticas, que somam front-end e back-end a um pipeline, e APIs, que permitem que um produto de dados alimente outros produtos, completam a lista apresentada na tela.
Da dor de negócio ao pipeline
O fluxo de trabalho apresentado separa duas camadas que precisam caminhar juntas: a de negócio/produto (identificação da dor, discovery, roadmap, validação e go-to-market) e a de engenharia (levantamento de fontes, ingestão, transformação, modelagem e data quality). Um ponto reforçado foi que a engenharia não precisa esperar a definição completa do negócio para começar: já na "etapa zero" é possível mapear fontes de dados e antecipar entraves de acesso e permissões.
Quando a fundação falha
A parte mais prática da apresentação tratou das consequências de falhas na engenharia: dado atrasado (decisão tomada tarde), dado incorreto (decisão errada) e processos sem governança (uso inadequado da ferramenta). O risco comum a todos, segundo o palestrante, é a perda de confiança dos consumidores — e aqui vale a citação literal: "reconstruir confiança é mais difícil do que corrigir pipeline".
Quatro pilares para sustentar o produto
Para evitar esse cenário, foram apresentados quatro pilares interligados: confiabilidade (disponibilidade, idempotência, testes e versionamento), qualidade de dados (ausência de duplicidade, completude, aderência às regras de negócio, revisada continuamente), observabilidade (capacidade de detectar e explicar problemas antes que o usuário perceba) e governança (saber quem está usando o quê). Nenhum pilar funciona isolado: de nada adianta um pipeline rodando se ninguém sabe se o dado está correto, ou se ninguém percebe quando ele deixa de estar.
O fechamento resumiu bem o espírito da palestra: "o produto é o que os nossos consumidores veem, mas a fundação aqui [...] acaba sustentando o produto como um todo" — geralmente invisível, até o momento em que falha.