Blog
custo de desenvolvimento (3ª passagem: a dispersão entre orçamentos como informação sobre o escopo)

Orçamento de sistema interno: por que os preços variam tanto

Marlon TrettinPublicado em 8 min de leitura
Vala aberta numa praça urbana à noite revelando tubulações e cabos enterrados, com tripés de escaneamento projetando feixes de luz para dentro dela e um técnico de capacete de costas na borda

Três orçamentos para o mesmo sistema chegam com preços distantes porque cada fornecedor leu um grau diferente de acoplamento na sua operação. O preço não mede o tamanho da tela. Mede quantas coisas o fornecedor acha que vai precisar mexer para a tela funcionar. A diferença entre as propostas é informação sobre o seu pedido.

Por que três fornecedores leem o mesmo pedido e respondem preços tão distantes?

Porque o seu pedido descreve a tela e o preço deles descreve o que fica atrás dela.

"Preciso de um sistema de pedidos" é uma frase completa para quem opera e uma frase ambígua para quem orça. Ela não diz se o pedido nasce do vendedor em campo ou do cliente, se o estoque precisa responder na hora, se o preço vem de uma tabela ou de uma regra por cliente, se a nota sai do mesmo lugar. Cada fornecedor responde essas perguntas sozinho, em silêncio, e cobra pela resposta que deu.

O barato costuma ter respondido "isso é uma tela de cadastro". O caro costuma ter respondido "isso encosta no estoque, no financeiro e na emissão fiscal". Os dois estão orçando com honestidade. Estão orçando projetos diferentes.

A dispersão, então, não é um problema de mercado. É um retrato de quanta coisa ficou sem ser dita no seu pedido.

O que a pesquisa mostra sobre o risco de custo em software?

Que o risco não está na média. Está na cauda.

Bent Flyvbjerg e colegas compararam 23 tipos de projeto em estudo publicado em 2026, com 5.360 projetos de TI na amostra. Projeto de TI estoura o orçamento em 40,86% dos casos, uma das três menores frequências da tabela inteira. Prédios estouram em 73,66%. Túneis, em 73,91%. Usinas nucleares, em 96,94%. Olimpíadas, em 100%.

Esse primeiro número contraria o senso comum de que software sempre atrasa e sempre custa mais. Na maior parte das vezes, o orçamento fecha.

O segundo número é o que importa. Entre os projetos de TI, 18,26% estouram em mais de 50%, e nesses casos o custo final médio é 5,53 vezes a estimativa inicial. Esse 5,53 é o mais alto dos 23 tipos comparados, acima de armazenamento nuclear, de defesa e das Olimpíadas. A mesma tabela mostra a assinatura estatística disso: em TI, a média de estouro fica 73 pontos percentuais acima da mediana.

Traduzindo para a sua decisão: a chance de o orçamento fechar é razoável, e a conta do dia em que não fecha é de outra ordem de grandeza. Quem escolhe fornecedor olhando só para o preço está otimizando a parte fácil do problema.

De onde vem a cauda?

De acoplamento. O trabalho que destrinchou o mecanismo por trás dessa distribuição vem do mesmo grupo de pesquisa e trabalha sobre a mesma base de projetos de TI, num recorte de 5.392 projetos. Não são duas evidências independentes, e sim dois cortes do mesmo conjunto. A explicação que eles propõem é a interdependência entre componentes: um problema numa peça dispara reação em cadeia nas peças ligadas a ela, e é essa propagação que produz os estouros extremos.

Esse estudo traz dois achados que vale guardar. O primeiro é que estouros e economias aparecem com frequência parecida, o que reforça que a estimativa inicial é uma faixa, não um número. O segundo está numa nota de rodapé: o maior estouro de toda a amostra não foi um megaprojeto. Foi uma customização pequena de workflow, orçada em 1.500 dólares, que terminou em 425 mil dólares.

Guarde esse par. Escopo pequeno e operação acoplada é a combinação que produz a conta grande. E uma operação que acumulou sistemas comprados em épocas diferentes é exatamente o ambiente onde o acoplamento mora sem ser visto.

É por isso que a pergunta certa antes de comparar preços não é "quanto custa construir isso". É "quantas coisas isso encosta".

Quem está avaliando a proposta do seu lado da mesa?

Em muitas empresas, ninguém cuja função seja essa.

A TIC Empresas 2025, do Cetic.br, mostra que 37% das empresas brasileiras que terceirizam funções de TIC terceirizam desenvolvimento de aplicações. Dentro desse mesmo grupo, a proporção é de 34% entre as empresas de 10 a 49 pessoas ocupadas e de 62% entre as de 250 ou mais.

A mesma pesquisa mede o outro lado da mesa. Entre as empresas que não têm área ou departamento de TI, 89% também não têm nenhum especialista em tecnologia da informação. Nas de 10 a 49 pessoas ocupadas, a proporção se repete.

A leitura combinada é direta. Uma parte relevante das empresas contrata desenvolvimento fora, e boa parte delas não tem, dentro de casa, ninguém cuja profissão seja ler proposta técnica. A decisão cai no colo de quem entende de operação, e a única variável comparável entre três documentos técnicos passa a ser o preço.

Na maior parte das PMEs, esse papel não tem dono declarado no organograma. Dá para cobrir esse vazio sem contratar ninguém, desde que você mude o que pede.

Como comparar três orçamentos que não medem a mesma coisa

Peça a cada fornecedor a lista do que ele vai encostar. Não a lista de funcionalidades, que todos escrevem igual. A lista dos sistemas, planilhas, rotinas e pessoas que precisam mudar de comportamento para o sistema novo funcionar.

Quatro perguntas dão conta da maior parte da dispersão:

Quais sistemas que já existem aqui esta proposta lê ou escreve? Quem responde "nenhum" está propondo mais uma ilha, e ilha é barata na entrega e cara na conta de três anos.

O que acontece quando um desses sistemas muda ou sai do ar? A resposta separa quem pensou em acoplamento de quem vai descobrir isso durante o projeto.

Qual parte desta proposta é premissa e qual é compromisso? Premissa que ninguém marcou como premissa vira aditivo depois.

O que foi deixado de fora de propósito? Fornecedor sênior responde essa com rapidez e com uma lista. Quem não tem a lista não desenhou fronteira nenhuma.

Se as três respostas vierem diferentes, você não tem três preços. Tem três escopos, e agora dá para escolher qual deles é o seu.

Um cenário para tornar isso concreto, apresentado como hipótese de trabalho e não como medição de cliente nosso: uma distribuidora com 60 funcionários pede um sistema de pedidos. O fornecedor A orça a tela de pedido e a lista. O B inclui leitura do estoque em tempo real. O C inclui estoque, a regra de preço por cliente e o gatilho da emissão fiscal. Os três preços vão estar distantes, e nenhum dos três está errado. Errado está o pedido que permitiu as três leituras. Meia hora desenhando a fronteira antes de pedir orçamento move mais dinheiro do que qualquer negociação depois.

Esse desenho de fronteira é a mesma disciplina que separa comprar de construir e a que define o custo de manter o sistema depois de pronto. No resgate da plataforma da Colo Saúde, o primeiro projeto não foi construir: foi auditar a segurança e ajustar a performance de uma plataforma herdada que estava sem dono técnico.

A Yowpi também emite orçamento, e as quatro perguntas acima servem para avaliar o nosso do mesmo jeito que servem para avaliar o dos outros. Proposta que não sobrevive a elas não merece assinatura, venha de quem vier.

Perguntas frequentes

O orçamento mais barato propõe no-code. A diferença de preço está só na ferramenta?

Raramente. A ferramenta explica uma parte da diferença, e a fronteira de escopo explica a maior. Compare primeiro o que cada proposta encosta na sua operação. Se os dois fornecedores tocarem o mesmo conjunto de sistemas e rotinas, aí a comparação entre abordagens passa a ser honesta, e aí ela é uma decisão técnica legítima.

A integração com o que já uso vai ser complicada. Isso aparece no orçamento?

Aparece, quase sempre na forma de premissa. Procure frases como "considerando que o ERP disponibiliza API" ou "assumindo acesso ao banco". Cada uma dessas linhas é um risco que ficou do seu lado sem estar precificado. Peça que cada premissa venha com o que acontece se ela não se confirmar.

Não tenho equipe qualificada para avaliar proposta técnica. O que faço?

Você não precisa avaliar a arquitetura. Precisa comparar escopos, e isso você faz melhor do que qualquer fornecedor, porque conhece a operação. Peça as quatro perguntas deste artigo por escrito e leia as respostas como quem lê descrição de processo. Onde a resposta ficar vaga sobre o que o sistema encosta, está o risco.

O próximo passo

Se você está com propostas na mesa e preços que não conversam entre si, o Diagnóstico de Arquitetura Operacional de 30 minutos ajuda a desenhar a fronteira antes da assinatura. Traga os orçamentos.

Cases relacionados

Marlon Trettin

Marlon Trettin

Fundador da Yowpi · 25+ anos de engenharia de software

LinkedIn
Próximo passo

Reconheceu a sua operação neste artigo?

Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.

Agendar diagnóstico