Como planejar o desenvolvimento de um sistema, etapa por etapa
Do levantamento de requisitos ao sistema em produção
Quem gerencia projeto de software ouve a mesma pergunta na primeira reunião: quando fica pronto? A resposta honesta depende de coisas que ainda não existem nesse momento, como o backlog estimado, a arquitetura escolhida e o tempo que o cliente vai levar para testar. Por isso o cronograma de desenvolvimento precisa mostrar mais do que as sprints. Ele tem que deixar visível o que vem antes da primeira linha de código e o que acontece depois da última.
Neste modelo, as etapas antes da Sprint 1 somam 22 dias úteis: levantamento de requisitos, backlog com critérios de aceite, protótipo e design da interface. A construção ocupa 30 dias úteis em três sprints. Testes, homologação e correções levam mais 15 até o deploy, que cai no dia útil 67. Os últimos 5 dias são de monitoramento em produção. Em contrato por escopo fechado, essa divisão evita o erro clássico de prometer a data olhando só para o tempo de programação.
É diferente de um cronograma de lançamento de produto, em que a campanha e o posicionamento correm em paralelo. Aqui o foco é entregar um sistema que funciona, passa na homologação e fica documentado para quem vai manter.
Para quem este cronograma foi pensado
O modelo funciona em três situações bem diferentes, e vale ajustar a ênfase de cada fase conforme o caso.
- Fábrica de software com contrato por escopo fechado: o cronograma vai anexo à proposta, cada fase vira um marco de faturamento e a data de entrega costuma ter multa. A homologação com o cliente e o termo de aceite precisam estar no plano com nome e data.
- Time interno de TI trocando uma planilha ou um sistema legado: não há contrato, mas há diretoria cobrando. O peso maior fica na migração de dados, no treinamento das áreas e no período de operação em paralelo.
- Consultoria em alocação de horas ou squad terceirizado: o escopo muda a cada sprint review. O Gantt serve para mostrar ao cliente o impacto de cada pedido novo na data final, antes de aprovar a mudança.
- Projeto para órgão público ou empresa regulada: entram documentação mais pesada, adequação à LGPD, testes de segurança formais e prazos de aprovação que não dependem do time.
Como montar o cronograma do seu sistema em seis passos
A ordem abaixo segue a lógica do modelo. Cada passo depende do anterior, e pular um deles costuma aparecer como atraso três meses depois.
- Feche o levantamento de requisitos com o cliente e registre o resultado num documento de especificação assinado. Os 5 dias úteis do modelo bastam para um sistema pequeno, sistemas maiores pedem duas ou três semanas.
- Quebre os requisitos em histórias com critérios de aceite. É o critério de aceite que vai dizer, lá na homologação, se a entrega está pronta ou não.
- Defina arquitetura, stack e ambientes (desenvolvimento, homologação e produção) em paralelo com o protótipo. No modelo a arquitetura tem 8 dias de folga, então um atraso pequeno nela não mexe na data final.
- Distribua o backlog pelas sprints. Renomeie as três do modelo com as entregas reais e acrescente sprints em vez de esticar as que existem.
- Reserve tempo de verdade para testes integrados e para a homologação com usuários do cliente. Os 11 dias úteis do modelo são o mínimo para um sistema de porte pequeno.
- Feche com o plano de deploy, o marco de produção e um período de monitoramento e garantia combinado em contrato.
Entregas e marcos que o cliente vai cobrar
Em projeto de software sob contrato, cada fase termina com um documento ou uma demonstração. Colocar essas entregas no cronograma como marcos ajuda a amarrar pagamento, aprovação e prazo. O modelo não traz uma tarefa separada de documentação. Muita equipe cria uma, correndo junto com a Sprint 3 e os testes, para não deixar manual e documentação técnica para depois do deploy.
- Especificação funcional ou documento de requisitos aprovado
- Protótipo navegável validado pelo cliente
- Documento de arquitetura com ambientes e decisões técnicas
- Demonstração do incremento ao fim de cada sprint
- Relatório de testes funcionais e de segurança
- Termo de aceite da homologação
- Manual do usuário, documentação da API e guia de implantação
- Deploy em produção com plano de rollback
O que mais atrasa um projeto de software
O atraso raramente vem da programação em si. Os pontos que mais empurram a data são a homologação que o cliente não consegue fazer no prazo, porque os usuários-chave estão no dia a dia da operação, e as mudanças de escopo aceitas sem aditivo. Integrações com sistemas de terceiros, como emissão de NF-e, APIs bancárias, Pix e o ERP do cliente, também costumam levar mais tempo do que parece na proposta. Ambiente de homologação montado só na véspera dos testes é outro clássico.
No Great Gantt, a duração em dias úteis já desconta fins de semana, e você pode cadastrar feriados nacionais e o recesso de fim de ano. O caminho crítico destacado mostra que requisitos, protótipo, design, sprints, testes e homologação definem a data, enquanto a arquitetura tem folga. Salve uma linha de base quando o cronograma for aprovado para comparar com o andamento real em cada sprint review.