Projetos de TI que fracassam quase nunca fracassam por falta de tecnologia. Fracassam por acordo pouco claro, expectativas diferentes e ninguém responsável do lado da empresa.
Os sete erros a seguir se repetem em todas as escalas, do negócio familiar à corporação. A boa notícia é que todos podem ser evitados antes da assinatura — justamente a fase em que corrigir sai mais barato.
Escolher o orçamento mais barato
O menor preço quase sempre significa uma de três coisas: o escopo é mais estreito do que você supõe, a qualidade foi sacrificada, ou o fornecedor entrou barato de propósito para recuperar margem com pedidos de mudança depois.
Antídoto: exija todo orçamento detalhado por componente — análise, design, desenvolvimento, testes, migração, treinamento e garantia. Orçamento que não se decompõe normalmente não foi pensado, e o que não foi pensado vira fatura depois.
Não escrever a definição de pronto
É a principal fonte de disputa. A empresa considera o projeto encerrado quando toda a equipe usa o sistema sem tropeços; o fornecedor considera encerrado quando entregou a lista de recursos. Essas duas definições podem estar a meses de distância.
Coloque esta frase no contrato: “O trabalho estará concluído quando o sistema executar os processos X, Y e Z com dados reais da empresa por catorze dias consecutivos sem erro que interrompa a operação.” Uma frase assim elimina noventa por cento das disputas.
Não definir a propriedade do código e dos dados
Muitas empresas descobrem isso só quando querem trocar de fornecedor, quando o poder de barganha já é zero. Duas perguntas precisam de resposta antes da assinatura: quem é dono do código feito sob medida e como você recupera todos os seus dados se a relação terminar.
Não nomear um dono interno do projeto
Nenhum fornecedor ocupa esse papel. Alguém na empresa precisa ter autoridade para decidir, conhecer o processo e ter tempo efetivamente alocado. Sem isso, decisões travam por semanas e o fornecedor cobra pela espera.
Antídoto: nomeie a pessoa no contrato, informe quantas horas semanais estão alocadas e defina um substituto para ausências. Parece exagero, mas projetos que correm bem quase sempre têm alguém assim.
Comprar recursos em vez de resolver problemas
Listas de recursos são o jeito mais fácil de comparar propostas, e por isso mesmo o mais enganoso. Os recursos que impressionam na demonstração raramente são os que a equipe usa todo dia.
Antídoto: transforme a lista de recursos em lista de cenários. Em vez de “precisamos de módulo de relatórios”, escreva “toda segunda de manhã o gerente da filial precisa ver as vendas semanais por categoria sem pedir ajuda a ninguém”. Cenário se testa; recurso só se promete.
Pular o teste com dados reais
Demonstrações sempre fluem porque os dados estão limpos e o roteiro foi escolhido. Os problemas surgem quando o sistema encontra os seus dados de verdade: nomes inconsistentes, transações antigas estranhas, unidades diferentes entre filiais e exceções sempre resolvidas na mão.
Peça isto antes de assinar: Um teste limitado com parte dos seus dados reais, conduzido por quem de fato vai usar. Se o fornecedor recusar com explicação enrolada, essa é uma informação valiosíssima.
Não orçar a vida após a entrada em produção
Sistema não é prédio que fica de pé sozinho depois de construído. Há servidor a pagar, atualizações de segurança a aplicar, ajustes quando serviços de terceiros mudam e um fluxo de pequenos consertos que nunca cessa.
Antídoto: acorde o custo anual de manutenção desde o início, com escopo detalhado: o que está incluído, o que conta como trabalho novo e qual o tempo de resposta em incidentes.
Checklist rápido antes de assinar
| O que precisa existir | Por que importa |
|---|---|
| Orçamento detalhado por componente | Impede custos ocultos no meio do caminho |
| Definição de pronto mensurável | Elimina discussão sobre quando termina |
| Cláusulas de propriedade de código e dados | Protege seu poder de negociação futuro |
| Dono interno do projeto nomeado | Evita decisões penduradas |
| Cenários de uso em vez de lista de recursos | Testável em vez de apenas prometido |
| Teste com dados reais | Revela problemas antes do dinheiro sair |
| Orçamento anual de manutenção | Evita o abandono após a entrega |
Perguntas Frequentes
A MDH costuma ser chamada para revisar escopos e propostas técnicas antes da decisão. Apontamos as partes que provavelmente virarão custo extra depois.
Solicitar Revisão
