O mito do projeto de tecnologia 90% pronto

Existe uma frase que ouvimos com frequência em reuniões comerciais: “o sistema está 90% pronto, só faltam uns detalhes”. Ela costuma vir de empresas que desenvolveram um projeto com um freelancer ou com outra software house, viram o dinheiro acabar ou o fornecedor sumir, e agora procuram alguém para cruzar a linha de chegada.

A conversa que vem depois quase nunca é a que o cliente espera. Depois de mais de 8 anos e centenas de projetos avaliados, aprendemos que esses supostos 10% restantes podem demorar tanto quanto, ou até mais, que tudo o que foi feito até ali.

Este post explica por quê. Não para desanimar ninguém, mas porque entender esse fenômeno é o que separa um projeto que finalmente entra no ar de um ciclo interminável de “está quase”.

O que é considerado detalhe é onde o trabalho mora

Na nossa experiência, a percepção de progresso em software é enganosa. As telas existem, os fluxos principais navegam, a demo roda bonita na reunião. Aos olhos de quem contrata, isso é 90%.

Só que o que falta raramente é volume de tela. O que falta é o que não aparece em demo: tratamento de erro, validação de dados, comportamento em conexões ruins, integrações que respondem fora do esperado, permissões, casos extremos, performance com dados reais em volume real. Cada um desses itens parece um detalhe. Somados, eles costumam ser a maior parte das horas de engenharia de um sistema sério.

É por isso que a estimativa de “faltam 10%” quase sempre está errada: ela mede o que se vê, e o custo está no que não se vê.

Onde o bicho pega: testes e usabilidade real

Fazer algo funcionar em ambiente contido é infinitamente mais fácil que em ambiente real. No ambiente contido, quem opera o sistema é quem o construiu, seguindo o caminho feliz que ele mesmo desenhou. No mundo real, o usuário não se porta como você espera.

Ele preenche o formulário na ordem errada. Cola um texto com formatação quebrada. Usa o sistema pelo celular na fila do banco, com internet oscilando. Clica duas vezes no botão de pagar. Deixa a sessão aberta por três dias e volta esperando que tudo continue funcionando.

Nenhum desses comportamentos aparece no desenvolvimento feito às pressas, e todos eles aparecem na primeira semana de operação de verdade. Testar de forma séria, com cenários reais, dados reais e usuários reais, é uma disciplina própria, e é exatamente a etapa que projetos “90% prontos” nunca atravessaram.

Decisões pequenas de negócio, impacto em tudo

Tem ainda um terceiro fator, e esse é o menos óbvio: decisões menores de negócio podem influenciar tudo o que foi desenvolvido até agora.

Um exemplo típico: o sistema foi construído prevendo que toda venda passa por aprovação de um gerente. No meio do caminho, a operação percebe que vendas abaixo de um certo valor não precisam de aprovação. Parece um ajuste de regra, uma frase no requisito. Na prática, mexer nesse fluxo pode envolver alterar o modelo de dados, as permissões, as notificações, os relatórios e todas as telas que assumiam o comportamento antigo.

Software é um organismo em que as partes conversam. Quando o fluxo central muda, a mudança se propaga, e o retrabalho recai justamente sobre o que já estava “pronto”. Projetos tocados sem arquitetura pensada para mudança sofrem mais com isso, e é o cenário mais comum nos projetos que chegam até nós para resgate.

Melhor demorar e entregar do que correr e não funcionar

Nada disso é argumento contra velocidade. É argumento contra a velocidade ilusória, aquela que produz demos rápidas e sistemas que não sustentam operação.

A nossa posição é direta: é melhor demorar e garantir a entrega do que ter algo rápido que não funciona. Um sistema que entra no ar com dois meses de atraso e opera bem é um ativo, como mostram os cases que publicamos no blog. Um sistema entregue “no prazo” que trava na primeira semana de uso real custa as duas coisas: o retrabalho técnico e a confiança do usuário, que é muito mais cara de recuperar.

Por isso, quando recebemos um projeto 90% pronto, o primeiro passo não é sair codando os 10%. É um diagnóstico honesto: auditoria do código, mapeamento do que de fato funciona, levantamento dos fluxos de negócio reais e um replanejamento com estimativa verdadeira. Às vezes a conclusão é que dá para aproveitar boa parte do que existe. Às vezes, que refazer sai mais barato que consertar. Nas duas situações, o cliente sai da conversa sabendo onde está pisando, o que é mais do que ele tinha antes.

Está com um projeto parado nos “10% finais”?

Se você tem um sistema quase pronto que nunca fica pronto, a Espresso Labs faz esse diagnóstico com frequência. Mais de 57 sistemas rodam hoje sob nossa sustentação de sistemas, muitos deles herdados exatamente assim. Traga o projeto, a gente avalia o que existe e te devolve um plano realista para colocá-lo no ar de verdade.