Mais que Código, uma Jornada de Impacto

Sabe, quando comecei minha jornada na área de Dados, eu não imaginava que um simples script Python, rodando no meu computador, se transformaria na espinha dorsal de um projeto capaz de economizar mais de R$ 1 milhão por mês para uma organização. Parece um conto de fadas tecnológico, certo? Mas garanto que é uma história real, repleta de desafios, aprendizados e, acima de tudo, a prova de que a verdadeira autoridade em dados não se constrói com uma pilha de certificados, mas com método, estrutura e muita prática real. É sobre essa jornada, e como ela se conecta com o que eu acredito e ensino, que quero conversar com você hoje.

Recentemente fiz uma postagem no meu LinkedIn, sobre um dos projetos que já atuei na minha carreira que obtiveram um grande resultado. Na epoca também foi um dos mais desafiadores. É sobre isso que irei comentar nesse artigo, se não viu o post segue o link. Postagem

Os 7 Estágios da Maturidade desse Projeto de Dados: Uma Perspectiva Pessoal

Minha experiência me mostrou que a evolução de um projeto de dados raramente é linear. É um caminho de tentativa e erro, de adaptação e de constante aprimoramento. O diário técnico que compilei reflete exatamente isso, e eu o chamo de 'Os 7 Estágios de Maturidade de um Projeto de Dados'. Cada "versão" que você verá a seguir não é apenas uma atualização tecnológica, mas um salto de maturidade, impulsionado por uma necessidade real e pela busca incessante por mais solidez e impacto.

Versão 1: O Início Humilde: Script Local com Pandas e Agendador do Windows

Todo gigante um dia foi um embrião. No meu caso, o embrião foi um script Python simples, lendo arquivos com pandas, fazendo transformações básicas e salvando tudo em CSV. O agendamento? O bom e velho Task Scheduler do Windows. Por que começar assim? Porque era o que tínha! Com o tempo, conhecimento que eu tinha na epóca e estrutura disponíveis, essa foi a solução mais pragmática. E o mais importante: já automatizava um processo manual e demorado, gerando valor imediato. As limitações eram óbvias: código monolítico, falhas interrompiam tudo, e a ausência de versionamento era um risco. Mas, como eu sempre digo, o importante é começar, gerar valor e aprender com cada passo.

📌 O que foi feito:

- Leitura de arquivos com pandas
- Transformações básicas
- Salvamento em CSV
- Agendamento com o Task Scheduler do Windows

🚨 Limitações:

- Código monolítico, difícil de escalar
- Qualquer falha interrompia tudo
- Sem versionamento, sem histórico, sem logs

Versão 2: Dando um Passo Adiante: PostgreSQL e Streamlit

A medida que o projeto ganhava corpo, a necessidade de mais robustez se tornou evidente. A migração para o PostgreSQL como destino dos dados trouxe performance e integridade relacional. Comecei a usar o GitHub para versionar os scripts, um divisor de águas em termos de segurança. E para dar visibilidade aos dados, sem depender do time técnico, os primeiros dashboards no Streamlit surgiram. Foi aqui que o negócio e os dados começaram a se encontrar de verdade. Ainda era uma estrutura frágil, sim, mas funcional e, crucialmente, mais confiável. Essa fase me ensinou que a tecnologia deve servir ao propósito do negócio, e não o contrário.

📌 O que foi feito:

- Criação de base relacional em PostgreSQL
- Uso do GitHub para versionar scripts
- Primeiros dashboards com Streamlit

Versão 3: A Segurança em Primeiro Lugar: Autenticação e Controle de Acesso

Com o crescimento do projeto, os dados começaram a se tornar mais sensíveis. Escalas, valores, inconsistências, a informação que antes era restrita, agora precisava ser acessada por diferentes grupos de usuários. A solução? Implementar uma tela de login com autenticação simples e controle de acesso por grupos no Streamlit. Parece básico, mas essa etapa foi fundamental para evitar vazamento de dados e garantir que cada grupo visualizasse apenas o que era relevante para sua função. A segurança dos dados é um pilar inegociável, e essa experiência reforçou a importância de construir sistemas com essa premissa desde cedo.

📌 O que foi feito:

- Tela de login com autenticação simples
- Controle de acesso por grupos de usuários

Versão 4: Rumo à Robustez: Docker e Airflow

Chegamos a um ponto onde a estabilidade e a previsibilidade eram essenciais. Empacotar os serviços com Docker garantiu um ambiente replicável: o que funcionava na minha máquina, funcionava em produção. E para orquestrar os pipelines, o Apache Airflow entrou em cena. O Airflow me deu controle total da execução, agendamento, dependências, retry automático e um histórico de execução impecável. Essa combinação trouxe uma autonomia sem precedentes para evoluir o projeto com segurança. É aqui que a engenharia de dados começa a mostrar sua verdadeira força, transformando o caos em um fluxo orquestrado e confiável.

📌 O que foi feito:

-Empacotamento de serviços com Docker
- Orquestração dos pipelines com Apache Airflow

Versão 5: Preservando a História – Implementação de SCD Tipo 2

Muitos dados mudam ao longo do tempo, e a necessidade de preservar o histórico de alterações se tornou crítica. Troca de unidade, valor, tipo de plantão… como auditar o passado e entender a jornada do dado?

A resposta veio com a implementação do Slowly Changing Dimension (SCD) Tipo 2, que substituiu a carga destrutiva por uma modelagem capaz de rastrear cada mudança com precisão. Cada nova alteração gerava uma nova linha, preservando o estado anterior com data de início e fim. Isso trouxe rastreabilidade total, permitindo entender como cada registro evoluiu com o tempo.

Mas havia outro desafio: eficiência. Reprocessar tudo a cada execução era custoso e arriscado. Por isso, adotei também a carga incremental, processando apenas os dados novos ou alterados desde a última execução. Isso otimizou o tempo de execução, reduziu o uso de recursos e aumentou a confiabilidade.

Foi aí que esbarrei em uma barreira importante: exclusões de informações

Como lidar com dados que sumiam da origem, mas ainda existiam no destino? Se um plantão fosse apagado do sistema transacional, ele simplesmente deixava de existir para o processo de carga e isso poderia mascarar falhas críticas ou remoções indevidas.

Essa etapa exigiu um novo olhar: foi preciso implementar mecanismos de auditoria de exclusão, como comparações periódicas entre origem e destino, flags de soft delete ou até mesmo regras de inativação lógica. Não bastava capturar o que mudava, era essencial também saber o que desaparecia e por quê.

Esses ajustes tornaram o pipeline ainda mais robusto e confiável. Afinal, dados são a memória de uma organização, e essa memória precisa ser precisa, completa e honesta, mesmo sobre aquilo que foi apagado.

📌 O que foi feito:

- Implementação do SCD Tipo 2
- Uso de carga incremental
- Controle de datas de vigência
- Detecção de exclusões silenciosas
- Inativação lógica de registros

Versão 6: Qualidade é Tudo: Pydantic e Pytest

Com a complexidade crescente, começaram a surgir falhas silenciosas: mudanças no schema, campos vazios, tipos incorretos. Sem validação e testes, o pipeline quebrava inteiro e só era percebido depois, gerando retrabalho e desconfiança. A solução foi clara: usar Pydantic para validar os dados logo após a extração e criar testes automatizados com Pytest. Essa etapa foi um divisor de águas na qualidade dos nossos dados. Evitar a propagação de erros, validar a consistência e tornar o deploy mais seguro e previsível, esses são os benefícios de uma cultura de qualidade que eu defendo e aplico.

📌 O que foi feito:

- Uso do Pydantic para validar os dados logo após a extração
-Criação de testes automatizados com Pytest

Versão 7: Visibilidade e Confiança: Logging Estruturado e Alertas via Telegram

Por fim, a necessidade de visibilidade operacional em tempo real se tornou evidente. Ninguém mais precisava “checar se rodou”, o sistema avisava. Implementamos:

- Logs estruturados por task, com registro de execução, status, tempo e mensagens detalhadas;
- Alertas automáticos via Telegram, para falhas críticas, com contexto suficiente para agir rapidamente;
- E um dashboard Streamlit, que exibe os logs em tempo quase real, permitindo que a equipe visualize o status das execuções, tarefas com falhas, tentativas de retry e tempo médio por etapa.

Essa interface trouxe transparência e autonomia operacional: qualquer gestor ou analista pode ver, a qualquer momento, se os dados foram atualizados, onde houve erro, e quando o próximo ciclo vai rodar. Não depende mais do time técnico.

O resultado? Confiança.

Sabíamos quando falhou, por quê, e o que foi impactado, com alertas instantâneos e uma interface visual simples para investigação

Essa foi a cereja do bolo da maturidade: um sistema que não apenas funciona, mas se comunica, se autoexplica e nos informa sobre sua saúde. Uma engenharia de dados silenciosa, mas presente, que dá tranquilidade para a operação e previsibilidade para o negócio.

O Método D.A.D.O.S.: A Estrutura por Trás do Sucesso

Você deve estar se perguntando: o que sustentou toda essa evolução? Não foi mágica, nem sorte. Foi um método. O Método D.A.D.O.S. Cada etapa que descrevi acima foi um reflexo direto dos seus 5 pilares, que são a base do que eu ensino e acredito:

• Direção: Começamos pequeno, sim, mas com uma clareza cristalina de onde queríamos chegar. Ter uma direção bem definida é o primeiro passo para qualquer projeto de sucesso, seja ele técnico ou pessoal. É como um GPS: você pode começar a viagem sem saber o caminho exato, mas precisa saber o destino final.

• Ação: Não adianta planejar sem executar. Cada versão do projeto entregava algo funcional, testado e útil. Ação é a ponte entre a ideia e a realidade. É a coragem de colocar a mão na massa, de errar, aprender e ajustar a rota. Como dizia Tony Robbins, "Onde o foco vai, a energia flui". E no nosso caso, o foco estava em entregar valor.

• Destaque: O projeto não ficou guardado em uma gaveta. Ele passou a ser usado por diferentes áreas da organização, ganhando destaque e reconhecimento. Isso não acontece por acaso. A visibilidade e o impacto real são frutos de um trabalho bem feito, que resolve problemas e gera resultados tangíveis. É a validação de que o que você está construindo realmente importa.

• Oportunidade: O sucesso do projeto gerou novos convites, responsabilidades e, o mais importante, decisões baseadas nos dados que produzíamos. A cada nova fase, novas portas se abriam. Isso mostra que, quando você entrega valor e constrói algo sólido, as oportunidades surgem naturalmente. É a lei da semeadura: você colhe o que planta.
• Solidez: Testes, validações, versionamento e alertas. Tudo isso consolidou a confiabilidade do nosso projeto. A solidez é a garantia de que o que você construiu é robusto, resiliente e capaz de suportar os desafios do mundo real. É a base para a confiança, tanto sua quanto da sua equipe e dos usuários.

Esses pilares não são apenas conceitos teóricos. Eles foram aplicados na prática, em cada linha de código, em cada decisão de arquitetura, em cada interação com o time. E é essa aplicação prática que faz toda a diferença.

O Impacto Real: Mais que Números, Transformação

O resultado de toda essa jornada foi muito além dos números. Sim, a economia superior a R$ 1 milhão por mês é um marco impressionante, um testemunho do poder dos dados quando bem utilizados. Mas o impacto real se traduziu em:

• Redução de retrabalho nas escalas: Menos tempo gasto corrigindo erros, mais tempo para o que realmente importa.
• Decisões diárias com base em dados confiáveis: A incerteza deu lugar à clareza, permitindo que a organização agisse com mais assertividade.
• Eliminação de erros manuais críticos: A automação e a validação de dados trouxeram uma nova camada de segurança e confiabilidade.

Esses são os frutos de um projeto que não nasceu grande, mas que cresceu com propósito. Um projeto que me ensinou, e que eu busco transmitir, que a engenharia de dados não é apenas sobre tecnologia, mas sobre resolver problemas reais e gerar valor tangível.

Como mostram diversas pesquisas, o ROI (Retorno sobre Investimento) em projetos de dados e inteligência artificial é cada vez mais evidente, com empresas que investem em automação inteligente conseguindo reduzir custos operacionais e otimizar processos .

A maturidade em dados, como vimos, não é um luxo, mas uma necessidade para as organizações que buscam se manter competitivas e eficientes.

Conclusão: Autoridade em Dados se Constrói com Método, Não com Mil Certificados

Sei que muitos de vocês, assim como eu no início, podem se sentir presos em um ciclo interminável de tutoriais e certificações, estudando ferramenta atrás de ferramenta, sem saber por onde começar ou como aplicar todo esse conhecimento na prática. Eu entendo essa frustração. Mas quero reforçar o meu mantra: "Autoridade em dados se constrói com método, não com mil certificados."

Nenhuma das versões que construí, nenhuma das etapas dessa jornada, veio de um certificado. Elas vieram da prática, do erro, da escuta atenta ao usuário e, acima de tudo, de um propósito claro. A verdadeira maestria em dados não está em colecionar diplomas, mas em transformar dados brutos em soluções que geram impacto real, em construir sistemas robustos e confiáveis, e em simplificar o caminho para que outros também possam alcançar essa autoridade.

É isso que me move e é isso que entregamos na Data Driven School: aprendizado com propósito, visão de futuro e resultados no mundo real. Porque, no final das contas, o que realmente importa é a sua capacidade de fazer a diferença, de construir algo que funcione, que gere valor e que transforme a realidade. E para isso, um bom método é o seu melhor aliado.

Por Luciano Borba
Co-Fundador Data Driven
Engenheiro de Dados