Resposta rápida: as habilidades que separam um time técnico que entrega receita de um que entrega funcionalidade são quatro: ler o dado do negócio antes de escrever código, integrar sistemas que não foram feitos para conversar, projetar para operação contínua e saber onde a IA cabe e onde ela atrapalha. Nenhuma delas é sobre linguagem de programação.
Por que a lista de habilidades da moda envelhece em seis meses
Toda virada de ano produz a mesma lista: aprenda tal framework, domine tal nuvem, estude tal modelo. Em seis meses metade está desatualizada, e quem seguiu ao pé da letra trocou de ferramenta sem mudar de patamar.
Trabalhando com grupos automotivos, clínicas e incorporadoras, a gente vê o padrão inverso. Os times que fazem diferença no resultado não são os que dominam mais tecnologia. São os que entendem onde o dinheiro entra e onde ele vaza — e escrevem software em cima disso.
Este texto é sobre essas habilidades. Elas não caducam.
1. Ler o dado do negócio antes de escrever a primeira linha
A pergunta que quase nunca é feita no começo de um projeto: qual número vai mudar quando isto estiver pronto?
Um time que não sabe responder constrói o que foi pedido. Um time que sabe às vezes descobre que o pedido está errado — e essa descoberta vale mais que a entrega.
Exemplo concreto de operação real: pediram um painel de acompanhamento de leads. A pergunta "qual número muda?" revelou que ninguém olhava painel nenhum, porque o problema não era falta de visibilidade — era que o lead esperava horas para receber a primeira resposta. O painel teria sido construído, usado por duas semanas e abandonado.
Como desenvolver isso na prática:
- Antes de estimar, peça para ver o número atual. Se ninguém souber dizer, esse é o primeiro problema.
- Pergunte o que acontece hoje quando o sistema não existe. A resposta revela o processo real, que raramente é o descrito.
- Descubra quem perde se nada mudar. Sistema sem dono some do uso em três meses.
2. Integrar sistemas que não foram feitos para conversar
Em operação de verdade, o dado interessante quase nunca está num lugar só. Está no CRM, no sistema de gestão, na planilha que alguém mantém à mão e no WhatsApp do vendedor.
A habilidade aqui não é técnica no sentido óbvio. Chamar uma API é fácil. O difícil é:
- Decidir qual sistema é a fonte da verdade quando dois discordam — e eles vão discordar.
- Lidar com o dado sujo que sempre existe: telefone com formato inconsistente, nome duplicado com grafia diferente, campo obrigatório preenchido com ponto para o vendedor conseguir salvar.
- Falhar sem quebrar. Integração que derruba o sistema quando a outra ponta cai não é integração, é acoplamento.
- Não exigir migração. Todo projeto que começa com "primeiro vamos trocar o CRM" morre antes de entregar valor. Operar sobre o que já existe é mais difícil de projetar e infinitamente mais fácil de aprovar.
Esse último ponto é o que mais separa projeto que entra em produção de projeto que vira apresentação.
3. Projetar para operação contínua, não para a entrega
Software de venda não termina no deploy. Ele passa a conviver com uma operação que muda de processo, de time e de meta.
O que isso exige de quem constrói:
- Observabilidade orientada ao negócio. Log de erro é o mínimo. O que a operação precisa é saber quantos leads entraram, quantos foram respondidos e onde travou.
- Degradação previsível. Quando a integração cai, o que acontece? Se a resposta for "ninguém percebe até o fim do mês", o desenho está errado.
- Configuração sem deploy. Se mudar uma regra comercial exige subir versão, a operação vai parar de pedir mudança e passar a trabalhar por fora do sistema.
- Dado que sobrevive à mudança de processo. O histórico precisa continuar legível depois que a regra mudar, ou toda análise de tendência morre.
4. Saber onde a IA cabe, e principalmente onde não cabe
Esta é a habilidade mais mal distribuída no mercado agora. Não porque as pessoas não saibam usar modelo — usar é fácil. É porque poucas sabem julgar quando o custo do erro inviabiliza o uso.
Um critério simples e honesto:
IA cabe bem quando o erro é barato e a revisão é natural. Classificar a intenção de uma mensagem, resumir um histórico longo, sugerir a próxima ação, priorizar uma fila. Se errar, alguém corrige e a vida segue.
IA não cabe quando o erro é caro e ninguém vai revisar. Calcular preço final, decidir aprovação de crédito, disparar comunicação para a base inteira sem conferência. Aqui a resposta certa é regra determinística, com a IA no máximo sugerindo.
A pergunta que resolve quase todos os casos: *se isto errar 5% das vezes, quem descobre e quanto custa?* Se não houver resposta, não é lugar de IA ainda.
O que fica de fora desta lista de propósito
Framework específico, linguagem específica, provedor de nuvem específico. Não porque não importem, mas porque são o mais fácil de aprender depois — e o mais fácil de contratar.
Time técnico bom em operação comercial é raro não por saber menos tecnologia, mas por entender melhor o negócio.
Como isso se aplica na prática
Se você lidera um time técnico dentro de uma operação comercial, o teste é direto: pergunte aos seus desenvolvedores qual número do negócio o trabalho da semana passada moveu. A qualidade da resposta diz mais sobre a maturidade do time do que qualquer avaliação técnica.
Se você contrata software, o mesmo teste vale para o fornecedor — e é uma pergunta melhor que pedir portfólio.
Na Dexi, esse é o critério de trabalho. Escrevemos sobre onde a receita vaza entre o lead entrar e o negócio fechar, em operações de ticket alto e ciclo longo. Se o assunto for esse, vale conhecer nosso material sobre vazamento de receita no funil comercial e tempo de resposta ao lead.