abril 2026 - Rafael Franco

09/04/2026

Por que projetos de tecnologia falham mesmo com bons times

Uma das ideias mais confortáveis do mundo corporativo é acreditar que, quando um projeto de tecnologia dá errado, o problema estava no time. Faltou capacidade. Faltou senioridade. Faltou execução. Faltou gestão. Às vezes isso até é verdade. Mas, na maior parte dos casos que eu vi ao longo da vida, essa explicação é só a versão mais fácil de contar.

Projetos de tecnologia frequentemente falham mesmo com bons times. E isso acontece porque time bom não compensa enquadramento ruim, liderança confusa, prioridade instável, expectativa mal formulada e decisão tomada no teatro em vez da realidade.

Essa é uma conversa desconfortável porque ela tira a culpa do lugar mais óbvio e joga luz onde normalmente ninguém quer olhar direito: a estrutura da decisão.

Depois de mais de 20 anos trabalhando com tecnologia, negócios e operação, eu vi projetos tecnicamente bons serem engolidos por problemas que não nasceram no código. Nasceram no briefing. Na política interna. Na falta de coragem de decidir. No escopo que muda toda semana. Na ilusão de que alinhamento pode ser improvisado. E no hábito quase corporativo de querer velocidade sem pagar o preço da clareza.

Time bom não salva projeto mal enquadrado

Essa talvez seja a primeira verdade que vale colocar na mesa.

Existe um romantismo perigoso em torno da ideia de que um time excelente sempre encontra um jeito. Como se bons profissionais fossem capazes de compensar qualquer desordem estrutural na força bruta da competência.

Não funciona assim.

Time bom melhora resultado. Time bom acelera execução. Time bom evita erro bobo. Time bom enxerga problema antes. Mas time bom não deveria ser tratado como mecanismo de correção para decisão mal tomada na origem.

Quando o projeto nasce torto, mesmo gente muito boa passa a operar em terreno contaminado.

Aí começam os sintomas clássicos:

retrabalho constante
discussão que volta toda semana
sensação de avanço sem avanço real
entregas tecnicamente corretas para objetivos errados
desgaste entre áreas
frustração silenciosa do time que percebe o problema, mas não controla a origem dele

Nessa fase, o erro já não é mais técnico. O erro já virou sistêmico.

Em 2026, time de alta performance também precisa operar com IA

Aqui entra uma camada que já não dá mais para ignorar.

Em 2026, quando eu falo em time de alta performance, eu não estou falando apenas de um time humano talentoso. Estou falando de um time humano bom que também sabe operar com agentes de inteligência artificial para ampliar produtividade, reduzir atrito operacional e aumentar a qualidade do que está sendo feito.

Isso não significa substituir pensamento. Muito menos terceirizar decisão para máquina. Significa reconhecer que times realmente competitivos hoje usam IA para acelerar pesquisa, síntese, documentação, revisão, automação de tarefas repetitivas e organização de execução.

Ignorar isso, neste momento do mercado, já é aceitar uma desvantagem competitiva real.

Mas aqui existe uma nuance importante: IA não salva projeto mal enquadrado. Na verdade, ela pode até acelerar o caos se estiver acoplada a uma liderança confusa e a um sistema ruim de decisão. Agentes de IA aumentam a potência do time. Se a direção estiver errada, eles ajudam a errar mais rápido com aparência de eficiência.

Ou seja: a IA hoje é parte do jogo da alta performance, mas continua subordinada à qualidade do enquadramento estratégico.

O problema geralmente começa antes do desenvolvimento

Muita empresa acha que projeto de tecnologia começa quando alguém abre o backlog, desenha a arquitetura ou agenda a kick-off. Na prática, ele costuma começar muito antes — e é justamente aí que boa parte do fracasso já está sendo preparada.

Projetos falham quando entram em execução com perguntas demais ainda em aberto e certezas demais sobre coisas que ninguém validou.

Por exemplo:

qual problema de negócio está sendo resolvido?
qual métrica realmente importa?
o que é prioridade de verdade e o que é só ruído político?
quem decide quando houver conflito?
o que precisa ser entregue e o que seria apenas desejável?
qual é o critério de sucesso?

Quando essas respostas não existem, o time entra em campo já condenado a jogar um jogo com regra mutável.

E depois, quando a confusão aparece, alguém diz que o projeto falhou por execução.

Na maioria das vezes, não foi execução. Foi covardia analítica antes da execução.

Bons times sofrem em ambientes que romantizam desorganização

Existe um tipo de ambiente corporativo que confunde flexibilidade com desorganização crônica. Tudo muda toda hora. Toda reunião redefine prioridade. Toda opinião quer virar produto. Toda exceção quer mandar no processo.

Nesse tipo de contexto, até os melhores times começam a parecer lentos, inconsistentes ou desalinhados. Não porque perderam qualidade, mas porque estão operando dentro de um sistema que transforma inteligência em retrabalho.

E aqui mora uma das injustiças mais comuns do mundo de tecnologia: exigir previsibilidade de quem recebeu um ambiente estruturalmente imprevisível.

É fácil dizer que o time não entregou. Mais difícil é admitir que ninguém protegeu o projeto do caos institucional que o engoliu.

Projetos não quebram só por falta de competência. Quebram por excesso de ruído.

Liderança ruim cria desperdício elegante

Nem toda liderança ruim é visivelmente ruim.

Às vezes a liderança é articulada, simpática, politicamente habilidosa, boa de reunião e excelente em apresentação. Só não consegue fazer o mais importante: enquadrar bem o problema e sustentar um eixo de decisão coerente ao longo do tempo.

Esse tipo de liderança produz uma coisa perigosíssima: desperdício elegante.

Tudo parece organizado. Há documentos. Há reuniões. Há planos. Há discurso de alinhamento. Mas o projeto continua girando em torno de ambiguidade, mudança de direção e prioridades mal hierarquizadas.

Nesse cenário, o time até trabalha bastante. Às vezes trabalha demais. Só que boa parte da energia é consumida em movimento sem densidade.

É por isso que eu desconfio de projetos que se vendem como bem coordenados demais antes de mostrarem clareza real de decisão. Muita organização estética pode esconder uma enorme desordem estrutural.

Escopo instável é um imposto silencioso

Outro ponto que destrói bons projetos é o escopo instável tratado como se fosse algo normal.

Mudar faz parte. Aprender faz parte. Ajustar rota faz parte. O problema não é mudar. O problema é mudar sem critério, sem custo explícito e sem honestidade sobre o que está sendo sacrificado no processo.

Toda mudança relevante cobra em algum lugar:

prazo
foco
energia do time
consistência da solução
previsibilidade de entrega

Quando a empresa trata mudança como gesto gratuito, ela cria um ambiente onde ninguém mais consegue estimar nada com confiança. E aí começa o teatro clássico: o time parece falho, quando na verdade está tentando sobreviver a um projeto que nunca tem permissão de estabilizar.

Projetos falham quando ninguém quer pagar o preço da decisão

Esse talvez seja um dos pontos mais subestimados.

Decidir de verdade custa. Custa abrir mão. Custa priorizar. Custa dizer não. Custa decepcionar alguma área. Custa abandonar ideia boa porque ela não cabe agora. Custa assumir que não dá para otimizar tudo ao mesmo tempo.

Muita liderança foge desse custo. E quando foge, transfere a conta para o projeto.

Aí o time recebe demandas contraditórias, objetivos múltiplos, pressões concorrentes e a expectativa mágica de conciliar tudo com qualidade e velocidade.

Não existe milagre metodológico que resolva isso.

Quando ninguém quer decidir com nitidez, o projeto entra em regime de erosão contínua.

O fracasso quase nunca começa no código

Isso é importante repetir porque ainda existe uma tendência infantil de tratar tecnologia como se fosse o lugar onde os problemas nascem. Muitas vezes, o código é só o lugar onde os problemas finalmente ficam visíveis.

O fracasso real começou antes:

na leitura ruim do problema
no alinhamento mal feito
na governança frouxa
na prioridade confusa
no desejo de agradar todo mundo
na dificuldade de separar urgência de importância

O código só herda isso.

E, quando herda, passa a parecer o culpado ideal porque é a parte tangível, auditável, criticável. Só que culpar o código por um projeto mal enquadrado é como culpar a parede pela rachadura da fundação.

O que bons times realmente precisam

Se a empresa quer que um bom time funcione como bom time, precisa oferecer condições estruturais mínimas.

Entre elas:

clareza de problema
prioridade real
critério de sucesso
liderança com eixo
governança decente
espaço para dizer a verdade sem virar problema político
uso inteligente de IA para ampliar produtividade sem substituir discernimento

Bons times não precisam de heroísmo constante. Precisam de contexto decente para que a competência produza densidade, não só esforço.

Sempre que vejo um projeto falhar com gente boa envolvida, a pergunta que faço não é quem executou mal. A pergunta é que tipo de ambiente fez essa execução perder força.

Porque, quase sempre, a resposta está lá.

Conclusão

Projetos de tecnologia falham mesmo com bons times porque a qualidade da execução nunca é maior do que a qualidade do enquadramento que sustenta essa execução.

Quando o problema está mal formulado, quando a liderança é ambígua, quando a prioridade oscila demais e quando ninguém assume o custo de decidir, até profissionais muito competentes passam a produzir abaixo do que poderiam.

Não por falta de capacidade. Mas por excesso de distorção no sistema em que estão operando.

E, em 2026, vale acrescentar uma camada importante: times realmente competitivos já precisam saber operar com agentes de inteligência artificial para ganhar produtividade e consistência. Isso não corrige liderança ruim nem resolve confusão estrutural, mas aumenta a potência de execução quando o contexto está bem desenhado.

Se existe uma lição que vale preservar, é esta: antes de cobrar mais do time, vale olhar com mais seriedade para a estrutura que está moldando o trabalho do time.

Muita empresa não tem problema de talento. Tem problema de enquadramento — e depois chama isso de falha de execução.

06/04/202603/04/2026

O maior erro das empresas que querem criar uma fintech

Criei minha primeira fintech há mais de 10 anos. De lá para cá, participei de centenas de projetos, acompanhei decisões brilhantes, decisões sofríveis e vi muita empresa tropeçar exatamente no mesmo ponto. Por isso, quando alguém me pergunta qual é o maior erro ao criar uma fintech, minha resposta raramente começa pela tecnologia.

Claro que tecnologia importa. Escolher a stack errada pesa. Contratar o fornecedor errado pesa. Integrar mal pesa. Mas, honestamente, esse não costuma ser o erro central.

O maior erro, na maioria dos casos, acontece antes. Ele começa quando a empresa decide construir uma fintech sem conseguir responder com clareza o que exatamente está tentando resolver, qual operação quer sustentar, qual tese econômica pretende defender e qual nível de autonomia realmente precisa ter.

Em outras palavras: o problema não costuma ser falta de tecnologia. O problema costuma ser excesso de solução antes de existir problema bem formulado.

Esse é um erro silencioso, porque no começo ele parece produtividade. A empresa conversa com fornecedor, vê demos, escuta promessas, compara plataformas, se empolga com BaaS, white label, cronograma curto, interface bonita. Parece que o projeto andou. Mas, muitas vezes, o que andou foi só o entusiasmo. A clareza estratégica ficou para trás.

O maior erro ao criar uma fintech não começa pela tela

Existe uma tentação muito forte de começar pelo que é mais visível. A interface. O aplicativo. O onboarding. O cartão. A jornada. Isso é compreensível, porque é o que parece mais concreto. Só que fintech não nasce da tela. Fintech nasce do desenho de negócio, da lógica operacional e da arquitetura de decisão.

Quando isso não está claro, a tecnologia entra cedo demais e acaba recebendo uma tarefa impossível: compensar a falta de definição.

É nessa hora que surgem projetos que querem lançar antes de saber qual problema resolvem, escolhem parceiro antes de entender a própria dependência, compram velocidade sem entender o custo da limitação, falam de produto financeiro sem discutir operação e tratam compliance como uma pendência futura.

O resultado é previsível: o projeto parece avançar rápido no começo, mas depois passa a consumir energia em retrabalho, redefinição e tensão entre áreas.

A fintech como fantasia corporativa

Em muitos casos, a ideia de criar uma fintech nasce mais da sedução do mercado do que da clareza do negócio.

A empresa vê outras empresas lançando produtos financeiros, escuta histórias de escala, percebe que o tema está em alta e começa a tratar a fintech como símbolo de modernidade. O problema é que símbolo não é estratégia.

Uma fintech não deveria nascer porque todo mundo está indo nessa direção. Ela deveria nascer porque existe uma hipótese real de valor, margem, distribuição, retenção, ganho operacional ou expansão de modelo de negócio.

Sem isso, o projeto vira fantasia corporativa com vocabulário técnico.

E aqui mora uma das distorções mais comuns: chamar de inovação o que, na prática, ainda é só ansiedade competitiva mal organizada.

Tecnologia é meio, não tese

Esse ponto parece óbvio, mas é espantosamente ignorado.

Tecnologia é meio. BaaS é meio. Partner stack é meio. White label é meio. API é meio. Nenhuma dessas coisas, por si só, responde por que a empresa deveria existir naquele espaço com chance real de sustentação.

Quando a tese está ruim, a tecnologia não salva. Quando a tese está mal definida, a arquitetura só posterga o problema. E quando a operação não foi pensada, qualquer sensação de velocidade vira dívida futura.

É por isso que boa parte dos projetos tropeça não porque faltou competência técnica, mas porque a sequência mental foi montada ao contrário.

A pergunta não deveria ser como a gente lança rápido. A pergunta deveria ser:

que problema merece ser resolvido?
por que esse problema precisa de uma camada financeira?
qual é o modelo econômico por trás disso?
que nível de autonomia faz sentido para nós?
o que precisa ser nosso e o que pode ser alavancado por parceiros?
qual risco estamos assumindo sem perceber?

Sem essas respostas, a discussão técnica vira teatro de decisão.

O mercado adora vender atalhos

Se existe uma indústria que sabe empacotar simplificação, é o mercado de soluções prontas.

Sempre aparece alguém prometendo fintech em poucos dias, banco digital plug and play, operação pronta sem complexidade. Essas promessas funcionam porque conversam diretamente com o desejo mais perigoso de qualquer empresa entrando nesse espaço: acelerar sem precisar compreender tudo o que está assumindo.

Só que quase todo atalho desse tipo cobra em algum lugar: autonomia, margem, flexibilidade, diferenciação, segurança operacional e capacidade de evolução.

Ou seja: o projeto não fica necessariamente mais simples. Ele só fica simplificado demais na narrativa comercial.

É por isso que eu desconfio profundamente de soluções que vendem velocidade como substituta de arquitetura. Em serviços financeiros, velocidade sem leitura estrutural costuma ser só complexidade comprimida.

O regulador não é o vilão da história

Outro erro conceitual que aparece bastante é tratar a regulação como se ela fosse o grande obstáculo da inovação. Isso é uma leitura preguiçosa.

Recentemente, em visita ao Banco Central, essa percepção ficou ainda mais clara para mim. O regulador brasileiro não tem postura de quem quer sufocar inovação. Pelo contrário: o Banco Central é um dos atores mais modernos e atentos à evolução do sistema financeiro. O que ele exige é que a inovação venha com consistência, responsabilidade e sustentação real.

E isso é bom.

Porque inovação séria não deveria querer existir fora de um ambiente de segurança, governança, previsibilidade e responsabilidade. A empresa madura entende isso cedo. A empresa ingênua descobre depois, geralmente da maneira mais cara.

A diferença entre quem constrói e quem performa construção

Existe uma diferença brutal entre empresas que querem realmente construir uma operação financeira e empresas que querem performar a construção de uma operação financeira.

As primeiras fazem perguntas duras. Testam hipótese. Discutem risco. Aceitam que algumas respostas exigem maturidade. Pensam em arquitetura, distribuição, margem, suporte, dependência e evolução.

As segundas querem parecer rápidas. Querem sair apresentando iniciativa. Querem mostrar interface. Querem encurtar a parte desconfortável do pensamento estratégico.

Só que é justamente essa parte desconfortável que separa projeto sólido de projeto decorativo.

Uma fintech madura não nasce da empolgação com o que pode ser lançado. Ela nasce da clareza sobre o que precisa ser sustentado.

O erro não é técnico. É executivo.

Se eu tivesse que resumir tudo em uma frase, seria essa: o maior erro das empresas que querem criar uma fintech não é técnico. É executivo.

É erro de enquadramento.

É tratar um projeto que deveria ser discutido como negócio, operação, arquitetura e responsabilidade como se fosse basicamente uma decisão de tecnologia com tempero de inovação.

Quando o enquadramento é ruim, todo o resto tende a se organizar mal. O fornecedor é escolhido pelas razões erradas. O parceiro parece melhor do que é. O prazo vira ilusão. O custo é subestimado. O white label parece solução. O BaaS parece resposta mágica. A operação vira apêndice. E a empresa só percebe o tamanho do erro quando já gastou energia demais para voltar atrás com leveza.

O que fazer no lugar disso

O caminho melhor não é mais lento por definição. Ele só é menos infantil.

Antes de construir, a empresa deveria:

definir o problema de negócio com precisão
entender se faz sentido resolvê-lo com uma camada financeira
mapear a lógica operacional necessária
avaliar parceiros sem terceirizar pensamento
decidir qual nível de autonomia quer preservar
alinhar tecnologia à tese, e não o contrário

Curiosamente, esse caminho costuma até acelerar a execução depois. Não porque simplifica o projeto artificialmente, mas porque reduz retrabalho, erro de sequência e decisão encantada.

Quem pensa melhor antes, normalmente anda melhor depois.

Conclusão

Nos meus mais de 20 anos de experiência em tecnologia e negócios, uma coisa se repetiu com frequência desconfortável: projetos ambiciosos raramente quebram primeiro pela ferramenta. Eles quebram primeiro pelo enquadramento errado.

Criar uma fintech é uma decisão séria demais para começar pela superfície. O maior erro das empresas que entram nesse jogo não é escolher uma tecnologia imperfeita. É começar o projeto sem clareza suficiente sobre problema, operação, tese econômica e desenho de longo prazo.

Quando isso acontece, a tecnologia vira muleta para uma decisão mal enquadrada. E nenhuma pilha de ferramentas resolve o que nasceu estrategicamente torto.

Se existe um conselho que vale repetir, é este: antes de procurar a solução, tenha coragem de formular melhor o problema.

Esse quase sempre é o ponto em que a diferença entre projeto sólido e projeto performático começa a aparecer.

Leituras complementares

Se você quiser aprofundar essa discussão por um ângulo mais prático, estes conteúdos se conectam diretamente com a tese deste artigo: