Os erros mais caros que vi em tecnologia raramente foram técnicos. Foram decisões tomadas com a pergunta errada: escolher a ferramenta antes de entender o problema, comparar preços sem comparar dependências, automatizar um processo sem perguntar se ele ainda fazia sentido.
Este guia reúne o que aprendi em mais de vinte anos na área, de programador a Head de Tecnologia, passando por produto, times e orçamento. Os casos são reais. Os nomes das empresas ficam de fora, porque o que importa é a situação, não o logo.
Ele é para líderes de tecnologia que precisam conversar com o negócio, e para líderes de negócio que precisam decidir sobre tecnologia. As duas conversas são, no fundo, a mesma.
1. Comece pelo problema, não pela ferramenta
Quase toda decisão de tecnologia chega já com uma solução embutida: "precisamos de um CRM novo", "vamos usar IA no atendimento", "temos que migrar para a nuvem". Às vezes, a solução está certa. Mas, quando a conversa começa por ela, ninguém pergunta qual problema estamos resolvendo, para quem e como vamos saber se deu certo.
Antes de comparar fornecedores, responda três perguntas:
- Qual é o problema de negócio? Em uma frase, sem citar tecnologia.
- Quem sente esse problema hoje? E quanto ele custa, em dinheiro, tempo ou risco.
- Como saberemos que resolvemos? Um indicador, não uma sensação.
Se essas respostas não estão claras, a escolha da ferramenta vai ser decidida por quem fez a melhor demonstração.
2. Ao contratar, avalie o custo de depender, não só o preço
Uma contratação não termina quando a solução entra em produção. É ali que começa boa parte das responsabilidades. Funcionalidades são demonstráveis, preços são comparáveis e prazos cabem em cronogramas. Continuidade operacional não se avalia em uma demonstração comercial.
Por isso, além de "atende aos requisitos?" e "cabe no orçamento?", vale perguntar:
- O que acontece quando surgir um incidente crítico?
- Quem detém o conhecimento: nós ou o fornecedor?
- Quanto custaria sair dessa solução daqui a dois anos?
- Quem responde por cada parte quando algo não funcionar?
Caso real. Numa empresa de serviços em que liderei a área de tecnologia, o orçamento estava pesado de contratos, serviços que se sobrepunham e dependência de fornecedores. Renegociamos contratos, racionalizamos serviços e trouxemos para dentro parte da capacidade, sem interromper as entregas críticas. O orçamento de tecnologia caiu cerca de 40%.
O aprendizado: boa parte do custo de tecnologia não está na ferramenta, e sim no que se compra junto com ela, e em contratos que ninguém volta a revisar.
O preço de uma tecnologia aparece na proposta. O custo de depender dela aparece na operação.
3. Prefira decisões reversíveis quando o futuro é incerto
Nem toda decisão de tecnologia precisa ser a melhor. Algumas precisam ser reversíveis.
Uma plataforma que atende perfeitamente às necessidades de hoje pode impor limites quando o negócio crescer, lançar produtos novos ou mudar de estratégia. É nesse momento que descobrimos que algumas decisões custam muito mais para serem desfeitas do que para serem tomadas.
Isso não significa que tudo deva ser fácil de trocar. Algumas escolhas exigem compromisso de longo prazo, e isso pode ser racional. A diferença está entre aceitar conscientemente uma dependência e descobri-la quando já não há alternativa.
Uma pergunta simples ajuda: se precisarmos mudar essa decisão daqui a dois anos, quanto vai custar e quem vai pagar? Se a resposta for "muito, e não sabemos", a decisão merece mais conversa.
4. Trate dívida técnica como decisão de negócio
"Precisamos pagar a dívida técnica" costuma vir acompanhado de uma lista de problemas de código e arquitetura. Mas parte da dívida técnica é o registro de decisões de negócio que fizeram sentido: lançar antes da concorrência, atender um cliente importante, validar uma hipótese antes de investir mais.
O problema não está em criar a dívida. Está em esquecer que ela foi criada. O provisório, quando funciona, começa a receber novas responsabilidades. A integração emergencial ganha dependências. A solução feita para testar uma ideia passa a sustentar o negócio inteiro.
Para tratar a dívida com o negócio, e não só dentro da engenharia:
- Registre a escolha: o que aceitamos, em troca de quê e até quando.
- Mostre os juros: incidentes, lentidão para mudar, custo operacional.
- Decida junto: tecnologia explica o risco; o negócio decide quanto risco aceitar, por quanto tempo e em troca de qual resultado.
Uma organização madura não é a que elimina toda dívida técnica. É a que sabe qual dívida carrega e por quê.
5. Mude o modelo sem perder o cliente
Grandes mudanças de tecnologia, como trocar de plataforma, migrar para a nuvem ou mudar o modelo de negócio, costumam ser avaliadas pelo cronograma e pelo orçamento. O indicador que mais importa, porém, está do outro lado: o cliente continuou?
Caso real. Numa empresa com produtos digitais em que fui gerente de produto, migramos os produtos do modelo tradicional para assinatura (SaaS). Em vez de tratar a mudança como um projeto de tecnologia, trabalhamos a jornada do cliente, fizemos experimentos e integramos de forma automática o financeiro e a operação. Em 2023, o faturamento mensal passava de R$ 2 milhões, com 95% de retenção de clientes e de receita.
O aprendizado: uma mudança de modelo é, antes de tudo, uma mudança na relação com o cliente. A retenção mostra se ela foi entendida.
6. Automação e IA: governe as decisões que você incorpora
Quando automatizamos um processo, não estamos só tornando a execução mais rápida. Estamos transformando decisões em comportamento do sistema, inclusive as exceções, inclusive critérios que já não fazem sentido, inclusive regras criadas para contextos que não existem mais.
Com inteligência artificial, essa responsabilidade aumenta, porque passamos a automatizar atividades que antes exigiam interpretação e julgamento. Uma decisão aplicada à mão afeta uma operação. A mesma decisão dentro de um sistema pode afetar milhares de casos e continuar sendo executada depois que deixou de fazer sentido.
Caso real. Na mesma empresa de serviços, projetos de IA e automação corporativa liberaram capacidade equivalente a cinco posições na operação. Medir o resultado em capacidade liberada, e não em cortes, muda a conversa: o tempo devolvido à equipe pode ir para o trabalho que exige julgamento.
Antes de colocar uma automação em funcionamento, responda:
- Quais decisões e critérios ela incorpora?
- Quais premissas precisam continuar válidas?
- Quem responde por esses critérios?
- Como vamos perceber consequências que não previmos?
- Quando vamos revisá-la?
Automatizar é ampliar a capacidade de executar decisões. Governar é preservar a capacidade de questioná-las.
7. Traduza tecnologia para a linguagem do negócio
Parte do valor da tecnologia fica invisível porque não é traduzida. Um time que inova todos os dias, mas não registra nem explica o que faz, entrega menos valor do que realmente produz.
Caso real. Na mesma empresa, a inovação feita pela área de tecnologia não era aproveitada como incentivo fiscal. Estruturamos os processos técnicos, financeiros e estratégicos para o enquadramento na Lei do Bem e recuperamos mais de R$ 2 milhões.
O aprendizado: tecnologia também gera valor quando documenta o próprio trabalho e fala a língua do financeiro.
Um líder de tecnologia que só fala de arquitetura é ouvido pela engenharia. Um que fala de risco, custo, receita e tempo é ouvido pela diretoria.
8. Valide antes de escalar
A forma mais barata de errar é errar cedo. Em produto, aprendi a trabalhar com ciclos curtos: formular hipóteses, testar com usuários reais e só então investir para escalar.
Caso real. Numa consultoria de produtos digitais, em projetos para um banco digital e uma empresa de meios de pagamento, trabalhávamos com Lean Inception, Design Sprint e protótipos rápidos. Reduzimos em 25% o tempo de entrega e chegávamos a validar cerca de 80% das hipóteses em ciclos de menos de três semanas.
Antes disso, como Product Owner numa grande empresa brasileira de software de gestão, fiz mais de cinquenta visitas a clientes e parceiros. Nesse período, com mais de quinze lançamentos por ano, a receita cresceu cerca de 18% ao ano. Conversas com clientes mostram o que nenhuma reunião interna mostra.
Validar não é burocracia. É a forma de gastar o orçamento no que funciona.
Antes da próxima decisão de tecnologia
Use esta lista como roteiro de conversa:
- O problema de negócio está escrito em uma frase, sem citar tecnologia?
- Sabemos como medir se resolvemos?
- Comparamos o custo de depender, não só o preço?
- Sabemos quanto custa mudar de ideia daqui a dois anos?
- A dívida que estamos aceitando está registrada, com prazo para voltar a discuti-la?
- Se houver automação ou IA, sabemos quais decisões ela incorpora e quem responde por elas?
- Conseguimos explicar o valor para o financeiro?
- Existe um jeito de validar pequeno antes de escalar?
O papel do líder de tecnologia
Durante muito tempo, achei que o trabalho de um líder de tecnologia era escolher as melhores soluções. Hoje penso diferente. O trabalho é ajudar a organização a fazer perguntas melhores antes de escolher, e a lembrar das escolhas que fez.
Tecnologia pode garantir que uma regra seja executada corretamente. A liderança precisa garantir que a organização continue capaz de avaliar se aquela regra ainda faz sentido.
Perguntas frequentes
Como reduzir custos de tecnologia sem parar as entregas?
Comece pelo que se compra junto com a tecnologia: contratos, serviços sobrepostos e dependência de fornecedores. Revise o que realmente é usado, renegocie com base em dados e traga para dentro a capacidade que faz parte do núcleo do negócio. Proteja as entregas críticas antes de cortar qualquer coisa.
Como explicar dívida técnica para a diretoria?
Como uma decisão de negócio, não como um problema de código. Mostre qual escolha deu origem à dívida, quais consequências ela produz hoje (incidentes, lentidão para mudar, custo operacional) e quanto custa continuar carregando-a. A decisão sobre quanto risco aceitar deve ser compartilhada com o negócio.
Por onde começar com inteligência artificial na empresa?
Por um problema concreto e repetitivo, em que o ganho seja mensurável e o erro tenha consequência controlada. Antes de automatizar, deixe claro quais decisões e critérios a solução vai incorporar, quem responde por eles e quando serão revistos.
É melhor comprar uma solução pronta ou desenvolver internamente?
Depende do quanto aquela capacidade diferencia o negócio. O que é comum a todas as empresas tende a ser melhor comprado; o que é parte do núcleo do negócio tende a ser melhor mantido perto. Em qualquer caso, avalie o custo de mudar de ideia no futuro, e não só o custo de começar.