Tem gente que chega pedindo lakehouse no primeiro e-mail. Tem dado, tem planilha, tem alguém que “já pensou em Databricks”. A pergunta certa não é qual ferramenta. É se o número ainda cabe numa aba, com uma pessoa dona da regra, e ninguém toma decisão de risco com ele.
Se cabe, planilha resolve. Forçar engenharia de dados nisso é teatro: custo de nuvem, pipeline pra manter, e o time continua abrindo o Excel na reunião.
O que a planilha faz bem
Uma aba é um contrato informal. Quem preenche sabe o que conta, o que ignora, quando atualiza. Para um negócio pequeno — um caixa, um estoque, um controle de agenda — isso é suficiente. O problema não é o Excel ser “amador”. O problema é fingir que já passou dessa fase.
Nós usamos planilha o tempo inteiro. Rascunho de regra, conciliação pontual, protótipo de métrica. O que não fazemos é tratar rascunho como fonte da reunião quando duas áreas já discordam do total.
Quando a conversa muda
A troca de ferramenta não vem do volume. Vem do conflito:
- duas áreas brigam pelo mesmo número e cada uma tem um extract;
- o arquivo quebra e só uma pessoa sabe remontar;
- o painel existe, mas ninguém cita ele na reunião — citam a planilha;
- o dado é sensível o bastante para precisar de linhagem: quem viu, de onde veio, quando.
Aí não é “implementar BI”. É contrato entre dado cru, dado limpo e métrica de negócio. No ForBarber isso cabe num PostgreSQL analítico. Quando o volume e a governança crescem, a conversa vai para lakehouse. A disciplina é a mesma; o palco não é.
Anti-teatro
Não vamos desenhar medallion num slide se o cliente ainda decide no WhatsApp com um print. Também não vamos vender “dashboard em duas semanas” se a briga é de definição — o que é ocupação, o que é ticket, o que entra no faturamento.
Diagnóstico curto: onde está o número hoje, quem mexe, o que quebra quando essa pessoa sai. Se a resposta ainda for “uma aba e uma cabeça”, a gente deixa a planilha em paz.
Se a resposta for as quatro do meio, escreve. Sem proposta genérica no primeiro e-mail.