Quanto tempo leva desenvolver um sistema, e por que "depende"
O prazo depende de quantas decisões o projeto exige, de quantos sistemas ele integra, de quanto dado antigo precisa migrar e de quantas pessoas vão usar no primeiro dia. Colocar mais gente não acelera. O que acelera é ter quem decida do lado do cliente e aceitar receber por partes.
Por que "depende" é uma resposta honesta, e insuficiente
Ninguém consegue dizer o prazo de um sistema antes de saber o que ele faz, do mesmo jeito que ninguém orça uma reforma por telefone. O problema é que "depende" costuma encerrar a conversa em vez de abri-la. O que dá para dizer com honestidade é do que depende — e isso já permite a você estimar sozinho se o seu caso é de semanas ou de meses.
O que faz o relógio andar
O número de decisões, não o de telas
Desenvolvimento para pouco quando aparece uma pergunta que só o cliente responde: o que acontece quando o pedido é cancelado depois de faturado? Quem pode aprovar desconto acima de tanto? Cada uma dessas é uma parada. Projetos que andam rápido são os que têm alguém do lado do cliente com autoridade para decidir na hora.
De quantos sistemas ele depende
Integração acrescenta prazo que não é seu: depende da documentação da outra ferramenta, de credencial de acesso, de ambiente de teste e, muitas vezes, da resposta de um suporte que não tem pressa. É a parte do cronograma que mais escorrega, e a que menos aparece na estimativa inicial.
Quanto dado antigo precisa entrar
Migração é um projeto dentro do projeto. Cinco anos de planilha com cadastro duplicado e data em três formatos consomem tempo de gente experiente — e é tempo que não produz tela nenhuma, o que faz parecer que o projeto parou.
Quantas pessoas precisam usar no primeiro dia
Um sistema para três pessoas entra em produção quando estiver pronto. Um sistema para trinta precisa de treinamento, de período de convivência com o processo antigo e de um plano para o que fazer quando algo falhar no meio do expediente.
O que não acelera
- Colocar mais gente. Depois de certo ponto, cada pessoa a mais acrescenta coordenação, não velocidade — e no começo do projeto, quando o desenho ainda está sendo feito, atrapalha.
- Pular o desenho. Programar antes de decidir o fluxo não economiza etapa: troca desenho barato por retrabalho caro.
- Cortar teste. O tempo não some, muda de lugar: sai do cronograma e entra na semana seguinte à entrega, com a equipe do cliente encontrando os problemas.
O que acelera de verdade
Três coisas, e as três dependem mais do cliente que do fornecedor:
- Uma pessoa que decide. Não um comitê. A diferença entre responder uma dúvida no mesmo dia e na semana seguinte, multiplicada por dezenas de dúvidas, é o cronograma inteiro.
- Aceitar entregar por partes. A primeira versão utilizável não precisa ter tudo. Ela precisa ser usada — é o uso real que corrige o que a reunião não previu.
- Cortar escopo, não qualidade. Quando o prazo aperta, a única alavanca honesta é fazer menos coisas. As outras duas — mais gente e menos teste — devolvem o tempo com juros.
Entrega única ou por partes
Uma entrega única concentra o risco: você descobre se o sistema serve no fim, quando mudar custa mais caro. Por partes, a primeira versão chega cedo, a equipe começa a usar e o que vem depois é priorizado pelo que o uso mostrou, não pelo que foi imaginado meses antes.
O calendário total costuma ser parecido. O que muda é quando o valor começa — e o tamanho do estrago quando alguma suposição estava errada.
Como ler um prazo numa proposta
Prazo sem escopo escrito ao lado não é prazo, é expectativa. Vale conferir três coisas: o que está incluído, o que não está, e o que acontece quando o cliente demora a responder. Essa última é a que evita a discussão mais comum do meio do projeto — a de quem atrasou.
No desenvolvimento sob medida, prazo e preço saem juntos, por escrito, depois do diagnóstico e antes de qualquer compromisso.