❓ A Pergunta Central
Antes de escrever uma linha de código para um sistema, você precisa responder uma pergunta simples com honestidade brutal: essa pergunta vai ser feita mais de uma vez?
📊 O mapa 20/80 das perguntas de negócio
20% das perguntas — one-off
- • "Quantas vendas fizemos no lançamento do produto X?"
- • "Qual foi o LTV médio em 2023 para o board report?"
- • "Análise de cohort dos usuários do beta?"
→ Script único. Não precisa de sistema.
80% das perguntas — recorrentes
- • "Qual a utilização por consultor esta semana?"
- • "Como está a receita vs meta do mês?"
- • "Quais clientes não renovaram nos últimos 90 dias?"
→ Candidatos a sistema. Avaliar os outros critérios.
💡 Exemplo Real
CEO pede uma análise de LTV para um board report trimestral. Parece importante o suficiente para virar um sistema. Não é. É uma pergunta anual, com contexto único, para uma audiência específica. Um script de 50 linhas resolve em 20 minutos. Um sistema levaria 2 semanas e ficaria abandonado.
🔄 A Resposta Muda Conforme o Negócio Evolui?
Mesmo que uma pergunta seja recorrente, se a lógica por trás dela muda frequentemente, automatizá-la prematuramente cria dívida técnica. O sistema precisa ser refatorado toda vez que o negócio muda — e em early stage, o negócio muda toda semana.
✗ Lógica instável → Não automatizar ainda
- ✗Definição de "cliente ativo" muda mensalmente
- ✗Métricas de sucesso sendo redefinidas
- ✗Produto em fase de descoberta (problem-market fit)
- ✗Pipeline de vendas mudando toda semana
✓ Lógica estável → Candidato a sistema
- ✓Cálculo de folha de pagamento (muda raramente)
- ✓Relatório de utilização de consultores
- ✓Faturamento mensal com regras definidas
- ✓KPIs que o board aprovou como fixos
📐 O princípio YAGNI aplicado a dados
YAGNI — "You Ain't Gonna Need It" — é a regra mais violada em projetos de dados. Construímos sistemas para perguntas que talvez apareçam, lógicas que talvez estabilizem, escalas que talvez cheguemos. Na maioria dos casos: não chegamos, não estabilizou, a pergunta nunca foi feita de novo.
👥 Mais de Uma Pessoa Vai Usar Isso Regularmente?
Escala de uso é o multiplicador de valor de qualquer sistema. Um sistema que você vai usar sozinho, uma vez por mês, quase nunca justifica o custo de construção. Quando múltiplos usuários (ou múltiplos agentes) precisam da mesma funcionalidade com frequência, o ROI começa a fazer sentido.
Exemplo concreto de ROI
Cenário 1 — NÃO vale o sistema
Você quer saber a utilização dos consultores. Pergunta 1x/mês, demora 10 min de script. Sistema levaria 2 semanas para construir. ROI: negativo por pelo menos 1 ano.
Cenário 2 — VALE o sistema
10 gerentes querem ver utilização da equipe deles toda semana. 10 pessoas × 4x/mês × 10 min = 400 min/mês gastos em scripts. Sistema de 2 semanas se paga em 2 meses.
💰 O Custo de Sistemas Prematuros
A equação do sistema prematuro é brutal e silenciosa: maior complexidade → menos velocidade de mudança → menor valor entregue. Cada sistema que você constrói antes do momento certo se torna um âncora no produto.
Complexidade acidental
O sistema resolve um problema que o script resolvia. Mas agora você tem: banco de dados para gerenciar, CI/CD para manter, migrations para controlar, logs para monitorar. O problema é o mesmo — a complexidade operacional triplicou.
Velocidade de mudança
O negócio pede uma mudança na lógica. No script: 5 minutos. No sistema: reunião de refinamento, estimativa, sprint, code review, deploy. O que seria uma conversa vira um projeto de 2 semanas.
Custo de abandono
6 meses depois, o negócio mudou de direção. O sistema está obsoleto. Mas como tem usuários e dados, ninguém quer desligar. Vira legacy antes de completar 1 ano. É mantido, nunca melhorado, até que cause um incidente.
⚠️ O cemitério de sistemas prematuros
Toda empresa de médio porte tem um cemitério: sistemas construídos com entusiasmo, usados brevemente, e mantidos em modo zumbi porque desligar parece arriscado. Cada sistema nesse cemitério consome ~20% do tempo de um engenheiro em manutenção. 5 sistemas zumbi = 1 engenheiro inteiro ocupado com trabalho sem valor.
📜 Quando um Script Único é Suficiente
Existe um estigma cultural de que scripts são "solução de amador". Engenheiros sênior preferem arquiteturas elegantes. Na realidade, a elegância está em resolver o problema certo da forma mais simples possível — e scripts muitas vezes são exatamente isso.
Os 5 sinais de que um script é suficiente
- 1. A pergunta só faz sentido neste contexto específico (board report, lançamento, auditoria pontual)
- 2. Apenas você vai executar — e raramente
- 3. A lógica ainda está sendo descoberta (você não sabe exatamente o que vai precisar)
- 4. O resultado precisa de curadoria humana antes de ser apresentado
- 5. O dado que alimenta a análise não existe em formato limpo ainda
💡 Scripts são descartáveis por design — e isso é uma vantagem
Um script que você descarta depois de usar não tem custo de manutenção, não vira legacy, não precisa de documentação elaborada, não bloqueia ninguém. Ele resolve o problema, entrega o valor, e sai de cena. Essa leveza é uma feature, não um bug.
🌳 O Decision Tree Completo
Com as perguntas certas respondidas, o decision tree completo define qual primitivo usar para cada necessidade. Da análise mais simples ao sistema mais complexo, existe uma resposta certa — e o framework ajuda a encontrá-la em minutos.
O framework de decisão
🎯 Exemplo de aplicação do decision tree
Equipe toda quer saber utilização por consultor toda semana:
- ✓ Pergunta recorrente? Sim
- ✓ Mais de uma pessoa? Sim — toda a equipe
- ✓ Lógica estável? Sim — definição de utilização está fixada
- ✓ Precisa de UI? Não necessariamente
Decisão: Skill + tabela-resumo atualizada automaticamente. Sistema leve, sem banco, sem frontend. Entrega 90% do valor com 10% da complexidade de um sistema completo.
✅ Resumo do Módulo
Próximo Módulo:
3.3 — 📖 Data Dictionary — O documento que alimenta agentes e transforma auditoria em atividade de nível sênior