Quanto tempo leva para desenvolver um sistema

Uma automação pontual fica pronta em 2 a 6 semanas; um sistema interno enxuto, em 1 a 3 meses; uma plataforma com várias integrações e regras complexas, em 3 a 8 meses. Esses prazos pressupõem uma condição que quase nunca é declarada em proposta: alguém do lado de quem contrata disponível para decidir rápido.

Quais são os prazos típicos por porte de projeto

São faixas típicas de mercado e variam conforme a clareza dos requisitos. Repare que a coluna diz "até a primeira versão em uso", não "até ficar pronto". Sistema em evolução não fica pronto; ele entra em produção e continua mudando.

O que realmente atrasa um projeto de software

Quem nunca contratou software imagina que o gargalo é a programação. Na prática, os atrasos vêm de outro lugar.

Decisão pendente. O time trava esperando alguém responder "esse desconto é aplicado antes ou depois do frete?". Uma pergunta que leva dois minutos para ser respondida pode custar cinco dias de espera se a pessoa certa está em viagem e ninguém mais tem autoridade para decidir. Esse é, com folga, o motivo número um de atraso.

Acesso a sistemas de terceiros. Credencial de API do ERP, ambiente de homologação do banco, certificado digital, liberação de firewall. Cada um desses itens depende de um processo que quem desenvolve não controla. É comum um projeto de dois meses ter três semanas de espera por acesso.

Escopo que cresce. Não em uma decisão grande, mas em dezenas de pequenas: "já que estamos aqui, dá para colocar um filtro?". Cada uma é razoável, o conjunto é um mês a mais.

Dados reais. O sistema é construído com dados de exemplo, limpos e bem formados. Quando os dados de verdade chegam, aparecem duplicatas, campos vazios obrigatórios, formatos de data inconsistentes e registros que violam a regra que todo mundo jurava ser universal. Migração é uma fase, não uma tarefa.

Homologação sem responsável definido. Se ninguém foi nomeado para testar e aprovar, o sistema fica pronto e parado. É frustrante, é comum e é evitável com uma linha no contrato.

Erro de estimativa técnica. Existe, mas é minoria. Um time experiente erra estimativa em uma faixa administrável; o que estoura cronograma são os quatro itens anteriores.

Por que entregar em fatias reduz risco

O modelo de entrega única, seis meses de silêncio seguidos de um lançamento, concentra todo o risco no final. Se algum entendimento estava errado, você descobre quando não há mais orçamento nem prazo para corrigir.

Entregar em fatias funcionais significa colocar em uso real o primeiro pedaço que resolve um problema completo, mesmo pequeno. Um exemplo concreto num sistema de gestão de pedidos:

1. Semanas 1 a 4: cadastro de clientes e produtos, com importação da planilha atual. Já dá para parar de usar a planilha de cadastro.
2. Semanas 5 a 8: registro de pedido e status. Já dá para acompanhar o que está em aberto.
3. Semanas 9 a 12: integração com a emissão de nota. Fecha o ciclo.
4. Semanas 13 a 16: relatórios e painéis, agora desenhados com base no que o uso real mostrou ser necessário.

Três ganhos práticos: o erro de entendimento aparece na semana 4, não na 24; o time do cliente aprende a usar o sistema aos poucos, em vez de receber tudo de uma vez; e, se o orçamento acabar na semana 12, existe algo funcionando em vez de um projeto pela metade.

O que quem contrata pode fazer para acelerar

O contratante tem mais influência no prazo do que costuma imaginar:

• Nomeie uma pessoa com poder de decisão e disponibilidade real. Não um comitê. Alguém que responde em até 24 horas.
• Providencie acessos antes do começo. Credenciais, ambientes de teste e contatos técnicos dos fornecedores dos sistemas que serão integrados. Coloque isso como pré-requisito da primeira semana.
• Separe o que é lançamento do que é melhoria. Toda ideia nova vai para uma lista, e a lista é revista ao final de cada fase. Isso não bloqueia mudança, apenas evita que ela entre pelo meio.
• Forneça dados reais cedo. Uma amostra de mil registros de verdade na segunda semana vale mais que uma planilha de exemplo perfeita.
• Defina quem homologa e reserve as horas dessa pessoa no calendário.

Prazo e preço se movem juntos

Reduzir prazo pela metade sem reduzir escopo raramente é possível. Adicionar pessoas a um projeto atrasado costuma piorar o atraso no curto prazo, porque cada pessoa nova consome tempo de quem já está produzindo. Isso não é pessimismo de programador, é aritmética de coordenação.

Existem três alavancas reais e você só pode puxar duas ao mesmo tempo: escopo, prazo e custo. Se a data é inegociável, uma feira, uma exigência legal, o início de uma safra, a única alavanca honesta é o escopo. Defina desde o início o que é obrigatório para a data e o que pode entrar depois, e coloque essa divisão no contrato.

Um fornecedor que aceita qualquer prazo sem discutir escopo não está sendo flexível; está adiando um problema que vai aparecer na metade do projeto.