A resposta curta
Quanto tempo leva para desenvolver um sistema depende do tamanho do problema, das integrações e da clareza do escopo, e não existe um prazo único. Com entregas em sprints curtas, uma primeira versão útil costuma sair em semanas, não em meses. O prazo total se define no estudo inicial.
Vale desconfiar de quem dá um número antes de entender a operação. Um sistema que substitui uma planilha de controle interno e um sistema que atende o cidadão, conversa com outras bases e registra cada movimentação são projetos de natureza diferente, mesmo que os dois caibam na frase "precisamos de um sistema". O que dá para garantir desde o começo é o ritmo: software funcionando a cada ciclo, para você ver o andamento em vez de esperar o fim.
O que mais pesa no prazo de um sistema
Cinco fatores explicam quase toda a diferença de prazo entre um projeto e outro. Nenhum deles é a linguagem de programação. A tabela mostra o que encurta e o que alonga cada um.
| Fator | Encurta o prazo quando | Alonga o prazo quando |
|---|---|---|
| Tamanho do problema | o sistema atende um perfil de usuário e uma rotina bem delimitada | há vários perfis, como cidadão, atendente e gestão no Ágil Cidadão, cada um usando a mesma informação de um jeito |
| Integrações | o sistema fica sozinho ou os outros oferecem API documentada | cada base existente tem regras, acessos e testes próprios, e é nelas que costuma morar a surpresa |
| Clareza do escopo | a operação já sabe o que precisa mudar e quem decide está de acordo | o problema ainda está emaranhado e a validação precisa separar o essencial do desejável |
| Disponibilidade de quem decide | a aprovação de cada sprint acontece na demonstração | a aprovação demora e o ciclo seguinte espera |
| Segurança, acessibilidade e LGPD | os requisitos entram no desenho desde o início | aparecem no fim e obrigam a refazer telas, permissões e registros |
Repare que só o primeiro fator tem a ver com o tamanho do sistema. Os outros quatro dependem de organização, acesso e decisão, e por isso dá para trabalhar neles antes mesmo de começar. Se o escopo ainda está nebuloso, o guia sobre como definir o escopo de um software ajuda a chegar mais preparado à primeira conversa.
As fases do desenvolvimento e o que cada uma entrega
O ciclo que seguimos tem seis etapas, descritas em detalhe em como trabalhamos. Elas não acontecem em fila rígida: design, desenvolvimento e infraestrutura se sobrepõem a partir das primeiras sprints, e é essa sobreposição que evita o prazo somado de seis fases inteiras.
- Validação e estudo de produto. Entendemos a operação, quem usa e o problema antes de propor tecnologia, com protótipo e conversa com quem vai usar de verdade. Daqui saem o escopo validado e o backlog priorizado, e é aqui que o prazo total fica definido.
- Design de interface. Fluxos e protótipos navegáveis testados com quem vai usar, antes de virar código. Corrigir um fluxo no protótipo custa bem menos do que corrigir no sistema pronto.
- Desenvolvimento. Sprints curtas, código revisado e testes automatizados. Cada sprint termina com software funcionando em homologação, para você testar e aprovar.
- Infraestrutura. Ambientes, publicação automatizada e monitoramento dimensionados para a operação, montados enquanto o sistema cresce.
- Segurança. Controle de acesso, proteção de dados e LGPD desde o desenho, com verificação antes de cada publicação.
- Suporte e evolução. O sistema entra em produção e o uso real alimenta o próximo ciclo de melhorias.
Cada sprint começa com o planejamento, em que priorizamos juntos o que entra e definimos o critério de aceite de cada item, e termina com a demonstração. Esse ritmo previsível é o que permite medir o andamento pelo que já funciona, e não por uma porcentagem estimada.
Como um MVP encurta o tempo até a primeira versão útil
O jeito mais seguro de chegar rápido a um sistema útil é não tentar construir tudo de uma vez. No estudo, separamos o que resolve a dor principal do que pode esperar e começamos pela parte que gera valor mais cedo. Essa primeira versão enxuta, usada de verdade, é o que o mercado chama de MVP, e explicamos o conceito em detalhe no guia o que é MVP e como validar um sistema.
O MVP não diminui o tamanho do projeto. Ele muda a ordem. Em vez de esperar o sistema inteiro para começar a usar, a equipe passa a operar com a primeira parte enquanto o resto é construído, e o uso real mostra o que de fato importa. Funções que pareciam essenciais no papel às vezes perdem prioridade, e outras aparecem. Ajustar a rota a cada sprint sai mais barato do que descobrir o desvio no fim.
É o caso do nosso sistema de gestão de pacientes para pronto atendimento, em desenvolvimento para substituir um sistema de mercado que não acompanhava a operação. O escopo vai da recepção do paciente ao relatório da gestão, e cada parte passa pelo mesmo ciclo de sprint e demonstração.
O que acelera e o que atrasa um projeto de software
Boa parte do prazo está nas mãos de quem contrata. Estes cuidados fazem diferença real:
- Uma pessoa responsável do seu lado. Alguém com autonomia para priorizar e aprovar, presente nas demonstrações.
- Acesso cedo a quem opera a rotina. Não só à gestão. Quem executa o processo no dia a dia é quem aponta a regra que ninguém escreveu.
- Documentação das integrações reunida antes. Contatos, acessos e manuais dos sistemas que vão conversar com o novo, para a integração não parar esperando resposta.
- Aceitar uma primeira versão enxuta. Começar a usar o que já resolve a dor principal, em vez de esperar o sistema completo.
- Decisões registradas. Critérios de aceite e mudanças documentados evitam rediscutir o que já foi combinado.
E algumas coisas atrasam quase sempre: mudar a prioridade no meio da sprint, descobrir uma integração obrigatória depois do escopo fechado e deixar a validação com os usuários para o fim. Mudança de escopo faz parte de qualquer projeto. O que atrasa é a mudança sem avaliação de impacto, por isso cada pedido novo vem com o efeito que ele tem no prazo, para você decidir o que entra agora e o que fica para depois.
Por que o prazo só fica firme depois do estudo inicial
Antes do estudo, qualquer prazo é palpite. Ninguém ainda conversou com quem usa, ninguém sabe o que os sistemas atuais permitem e o escopo é uma lista de desejos. Um número dado nessa hora tende a virar uma de duas coisas: um prazo inflado para cobrir o desconhecido ou um prazo curto demais que estoura na primeira integração.
O estudo existe para trocar suposição por informação. Ele mapeia a operação, as integrações e as prioridades, e devolve um escopo validado com etapas. A partir daí o prazo deixa de ser uma aposta e passa a ser um plano, que você acompanha sprint a sprint. Isso vale para empresas e também para órgãos públicos, onde a contratação tem regras próprias e o planejamento por etapas ajuda a dar previsibilidade ao cronograma, como mostramos no guia sobre contratar software para órgão público.
Como chegamos a um prazo para o seu caso
Antes de qualquer compromisso maior, fazemos um estudo curto que define escopo, prioridades, prazo e investimento do seu software sob medida. Você sai dele sabendo por onde começar e o que entra em cada etapa. Não é preciso chegar com o escopo pronto: basta contar o que hoje dá trabalho, atrasa ou gera erro.
Se quiser uma primeira leitura do seu caso, o nosso consultor no site faz as perguntas iniciais e encaminha a conversa para o time.