Pular para o conteúdo principal
FLEXORA
Voltar ao blog

É seguro escolher o orçamento de software mais barato no Paraguai?

ResumoUm orçamento bem mais barato não é automaticamente uma má decisão. A questão é entender o que explica a diferença: escopo, equipe, testes, integrações, migração, suporte, prazos ou responsabilidades do cliente. Antes de escolher, peça por escrito o que cada proposta inclui e o que exclui, e compare as duas nas mesmas condições.

Imagine dois orçamentos para um sistema aparentemente parecido: Gs. 10.000.000 e Gs. 80.000.000. A diferença, sozinha, não diz qual é melhor. Ela pode vir do escopo, da experiência da equipe, da arquitetura proposta, dos testes, das integrações, do suporte ou simplesmente de estruturas de custo diferentes. A pergunta útil não é por que um é mais barato, e sim se os dois estão realmente orçando a mesma coisa.

Se você ainda está na fase de comparar propostas antes de decidir, o guia Como comparar orçamentos de software sob medida no Paraguai traz o checklist completo. Aqui o foco é um risco específico: o que vale revisar antes de fechar com a opção mais barata, sem partir do pressuposto de que ela seja uma má ideia.

O risco mais concreto: dependência de uma única pessoa

Um risco real aparece quando o conhecimento e a operação do projeto ficam concentrados numa pessoa só — seja um freelancer trabalhando sozinho, um funcionário, um sócio ou o único técnico que a empresa alocou no projeto. Na engenharia de software isso é estudado sob o conceito de bus factor (ou truck factor): o número mínimo de pessoas que precisariam deixar um projeto para comprometer a continuidade dele. Existem trabalhos empíricos específicos sobre esse risco de concentração de conhecimento (Jabrayilzade, Evtikhiev, Tüzün e Kovalenko, “Bus Factor In Practice”, 44th IEEE/ACM ICSE-SEIP, 2022).

Um freelancer pode trabalhar com processos sólidos, documentação clara e algum tipo de cobertura para imprevistos. E uma empresa pode distribuir mal o conhecimento, deixando tudo concentrado numa pessoa só, apesar da estrutura. O rótulo “freelancer” ou “empresa” não define o risco por si só — o que importa é como a continuidade do projeto é garantida: quem mais tem acesso ao código, como o sistema está documentado e o que acontece se aquela pessoa deixar de estar disponível.

Isso não quer dizer que todo freelancer seja arriscado nem que toda agência seja segura: quer dizer que “quem executa e com qual retaguarda” é uma pergunta válida antes de assinar, e não depois que o projeto trava no meio do caminho.

O risco silencioso: o que não está escrito no orçamento

Um estudo da McKinsey feito em parceria com a Universidade de Oxford, Delivering large-scale IT projects on time, on budget, and on value, partiu de uma base de dados com mais de 5.400 projetos de TI. Para os projetos que o estudo classifica como de grande porte — aqueles com orçamento inicial acima de USD 15 milhões —, ele registrou uma média de 45% acima do orçamento, 7% acima do prazo e 56% menos valor entregue do que o previsto. Esses números vêm de um universo de projetos muito diferente do de uma PME paraguaia comparando orçamentos de alguns milhões de guaranis, então não deveriam ser lidos como expectativa de custo adicional para qualquer projeto. Mas são um bom argumento para não comparar propostas só pelo preço final: o próprio estudo recomenda não olhar exclusivamente para custo e prestar atenção a talento, escopo, arquitetura, QA, migração e gestão do projeto.

Há itens que vale verificar de forma expressa em qualquer orçamento — não porque “quase sempre” faltem na opção barata, mas porque, quando faltam, mudam o custo real do projeto:

  • Migração dos dados existentes. Se a sua empresa já opera com planilhas, um sistema antigo ou registros em papel, migrar essa informação exige análise, limpeza, transformação, importação e validação. Vale verificar se esse trabalho está incluído, excluído ou ainda pendente de estimativa.
  • Testes e ambientes de controle. Construir com testes automatizados e ambientes separados de desenvolvimento, testes e produção dá mais trabalho do que entregar algo que simplesmente funciona. Pergunte o que é testado, com quais ferramentas e quem aprova o resultado.
  • Manutenção e suporte pós-entrega. O custo de manter um sistema vivo (atualizar dependências, corrigir bugs que só aparecem no uso real, adaptar funcionalidades) varia conforme o sistema, a infraestrutura e o nível de serviço acordado. A FullScale, um fornecedor do setor, publica uma regra de bolso de 15% a 20% do custo original de construção por ano — não é um padrão universal da indústria, mas dá uma ideia da ordem de grandeza (FullScale). Se esse trabalho vai ser necessário e não está no orçamento inicial, vale esclarecer quem vai assumi-lo e como será orçado quando terminar o período de garantia ou de suporte incluído.
  • Treinamento e documentação para os usuários. Podem ser necessários conforme a complexidade do sistema e a rotatividade da equipe que vai usá-lo. Vale conferir se estão contemplados.

O fato de um item não aparecer no orçamento não significa necessariamente que o projeto precise dele. Mas, se depois ele se mostrar necessário, vai exigir tempo, trabalho ou orçamento adicional — por isso vale esclarecer antes de assinar, em vez de já presumir que estão escondendo alguma coisa.

No Paraguai, revise também as integrações locais

Se o sistema precisa se integrar a serviços ou exigências locais, confirme se esse trabalho está explicitamente contemplado. Um exemplo é o SIFEN: a DNIT publica documentação técnica específica (e-Kuatia: Desarrollo de Software, Documentación Técnica) para os sistemas que precisam interagir com o faturamento eletrônico, incluindo o Manual Técnico em vigor e as notas técnicas do sistema. Se o seu projeto precisa dessa integração, peça evidências de projetos anteriores comparáveis, pergunte como o fornecedor trabalha com essa documentação oficial e confirme se a análise, o desenvolvimento e os testes correspondentes estão no orçamento ou são cobrados separadamente.

Como reduzir o risco antes de assinar

A regra: as mesmas perguntas, nas mesmas condições, antes de comparar o total.

Não se trata de descartar automaticamente a oferta mais barata, e sim de exigir que os dois orçamentos respondam às mesmas perguntas antes de você comparar o número final:

  1. Peça que o escopo, as exclusões e as mudanças aprovadas fiquem documentados pelo mecanismo previsto para o projeto.
  2. Pergunte explicitamente o que acontece se a pessoa que desenvolve o sistema deixar de estar disponível: quem mais tem acesso ao código e como o sistema está documentado.
  3. Confirme se testes, migração de dados, treinamento e suporte pós-entrega estão incluídos ou se são faturados separadamente.
  4. Peça o detalhamento do que cada proposta inclui e exclui, linha por linha, em vez de comparar apenas o total (Koud).

Se você quiser ver como isso funciona do outro lado do balcão, em por que a Flexora orça assim explicamos o que cada etapa dos nossos próprios orçamentos inclui.

E se você está avaliando um projeto de desenvolvimento de software sob medida, converse com o nosso time — pedimos o escopo por escrito já na primeira reunião.

Fontes citadas

Perguntas frequentes

É seguro escolher o orçamento mais barato?
Pode ser. O preço mais baixo, sozinho, não determina nem a qualidade nem o risco. Antes de decidir, compare o que cada proposta inclui: escopo, equipe, testes, migração, integrações, suporte, propriedade do código e continuidade caso alguém deixe de estar disponível.
Por que dois orçamentos podem ser tão diferentes?
Eles podem divergir em escopo documentado versus escopo combinado de boca, composição e senioridade da equipe, nível de testes, integrações contempladas, migração de dados, documentação e suporte pós-entrega. Uma diferença grande de preço, sozinha, não prova que alguém esteja cobrando demais nem que o outro esteja deixando trabalho de fora — antes é preciso comparar o que cada um está orçando.
O que acontece se o projeto depender de uma única pessoa?
Se essa pessoa deixar de estar disponível e não houver documentação, acesso compartilhado ao código nem plano de continuidade, a interrupção pode ser séria. O mesmo risco existe dentro de uma empresa, se todo o conhecimento do projeto estiver concentrado numa pessoa só. Antes de contratar, pergunte quem tem acesso ao repositório, como o sistema está documentado e o que acontece numa ausência prolongada.
O que devo comparar além do preço?
Escopo funcional e suas exclusões, quem executa o trabalho e como o código é revisado, quais testes estão contemplados, se a migração de dados está incluída, quais integrações estão cobertas, qual suporte e qual garantia entram depois da entrega, e as condições sobre propriedade e acesso ao código.
Vale mais a pena um freelancer ou uma empresa?
Depende do projeto e de como o fornecedor está organizado. Para tarefas bem delimitadas, um freelancer experiente pode dar conta. Para projetos que exigem várias disciplinas ou continuidade entre várias pessoas, uma equipe reduz a concentração de conhecimento. Nos dois casos, avalie documentação, cobertura em caso de ausência, acesso ao código, testes, suporte e plano de continuidade — e não o rótulo.

Esse problema parece com o da sua empresa?

Conte o contexto e vemos juntos se faz sentido resolver com software, e como.