Como pedir e comparar orçamentos de desenvolvimento de sistema

A empresa pede orçamento a três fornecedores, recebe três valores muito diferentes e escolhe o do meio — porque o mais barato assusta e o mais caro não cabe. É o método mais usado do mercado e um dos piores, porque compara números que não descrevem a mesma coisa.

Orçamento de software só é comparável quando todo mundo estimou o mesmo escopo, com as mesmas premissas e o mesmo nível de responsabilidade. Conseguir isso é trabalho seu, e vale cada hora investida.

Parte 1 — O que enviar para receber propostas comparáveis

Um documento de duas a quatro páginas já resolve. Ele precisa conter:

O problema, antes da solução

Descreva a dor da operação, não a sua ideia de sistema. "A equipe refaz orçamento na planilha porque a tabela de preço muda toda semana" diz mais a um fornecedor competente do que uma lista de vinte telas.

Quem usa e quantos são

Perfis de usuário, quantas pessoas em cada perfil e o que cada uma faz. Número de perfis é um dos fatores que mais mexe no esforço.

Volumes reais

Pedidos, atendimentos, documentos ou transações por mês, e a expectativa para daqui a dois anos. Volume define arquitetura — se não for informado, não foi orçado.

O que já existe e vai continuar existindo

ERP, emissor fiscal, meio de pagamento, WhatsApp, base legada. Para cada um: tem API, tem documentação, tem alguém que conhece? Integração é o item mais subestimado de qualquer proposta.

As regras que têm exceção

"Sempre funciona assim, menos quando o cliente é X" é a frase mais cara do projeto. Liste as exceções que você conhece — elas vão aparecer de qualquer jeito, e é melhor que apareçam agora.

O que é sucesso

Um resultado mensurável de operação, com o número de hoje. Sem ele, ninguém consegue priorizar nada depois.

O que está fora

Tão importante quanto a lista do que entra. Escopo sem fronteira explícita cresce em silêncio.

Parte 2 — O que exigir em toda proposta

Peça, por escrito, que todas as propostas tragam estes sete itens. É o que torna a comparação possível:

1. Estimativa de esforço por etapa, em horas ou semanas. Sem isso você compara chutes, não propostas.
2. Premissas assumidas. O que o fornecedor supôs para chegar naquele número.
3. O que está explicitamente fora do escopo.
4. Propriedade do código e da infraestrutura. Em nome de quem ficam o repositório e as contas.
5. Garantia: o que cobre, por quanto tempo, e o que é considerado escopo novo.
6. Custo mensal estimado de operação: infraestrutura e sustentação depois do go-live.
7. Plano de saída: o que acontece com dados, acessos e conhecimento se a relação terminar.

Parte 3 — Como comparar de verdade

Monte uma tabela com uma linha para cada item acima e uma coluna por fornecedor. Duas coisas aparecem imediatamente:

Propostas com escopos diferentes. Se uma estimou 600 horas e outra 1.800 para a mesma descrição, alguém entendeu outra coisa. Normalmente a mais baixa não incluiu migração de dados, integração real, testes ou implantação. Pergunte — a resposta costuma resolver a diferença.

O custo de três anos, não o do projeto. Some desenvolvimento, infraestrutura mensal e sustentação anual. A proposta mais barata na construção frequentemente é a mais cara no total, principalmente quando não inclui testes automatizados nem documentação: tudo o que for mudar depois vai custar mais caro para sempre.

Parte 4 — Perguntas para a reunião

• O que vocês colocaram em produção que ainda está rodando hoje, e com quantos usuários?
• Quem trabalha no meu projeto, e qual a senioridade de cada pessoa?
• Como funciona a homologação? Com que frequência eu vou ver o sistema?
• O que vocês precisam de mim, e quando? (Boa resposta é específica e desconfortável.)
• Quais são os três maiores riscos deste projeto, na sua visão?
• O que vocês fariam diferente se o orçamento fosse 30% menor?

Essa última pergunta é a mais reveladora: quem responde "entregaríamos menos funcionalidades, mas com a mesma qualidade" pensa como engenheiro. Quem responde "a gente dá um jeito" está dizendo que cortaria teste, documentação ou arquitetura — exatamente o que você vai pagar depois.

Sinais de alerta

• Preço fechado na primeira conversa, sem ter visto a operação;
• Prazo muito mais curto que os demais para o mesmo escopo;
• Proposta que lista tecnologias, mas não lista premissas;
• Nenhuma menção a testes, ambientes separados, documentação ou operação;
• Desconforto com a cláusula de propriedade do código;
• Desconto grande oferecido espontaneamente para fechar rápido — se a margem comportava o desconto, a estimativa inicial não era séria.

O atalho que economiza mais

Contrate primeiro um diagnóstico da operação, pago e com entregáveis definidos: mapa do processo, escopo priorizado, proposta de arquitetura e estimativa com premissas escritas. Com esse documento na mão, você pede orçamento a quem quiser — inclusive a quem fez o diagnóstico — e todos estarão estimando exatamente a mesma coisa.

É a lógica descrita em Discovery: a etapa que decide o preço do seu projeto. Custa uma fração do desenvolvimento e é o que separa uma comparação real de três chutes com carimbo.

Se quiser fazer esse levantamento antes de fechar escopo com qualquer fornecedor, fale com a Sixtec.