Quanto tempo demora desenvolver uma app ou um software à medida

«Quanto tempo demora?» é, a seguir ao preço, a pergunta que mais se faz antes de mandar fazer uma app ou um software. E tem o mesmo problema: sem saber o que o sistema tem de fazer, qualquer número é um palpite.

A resposta curta: o prazo de uma app ou de um software à medida depende do âmbito (quantas funcionalidades e integrações), das plataformas, da qualidade da informação de partida e da rapidez das decisões do seu lado. Um prazo sério só aparece depois de se perceber o que o sistema tem de fazer, e deve vir dividido em fases, com uma primeira versão útil o mais cedo possível.

Porque é que não há um prazo certo

Na internet encontra tabelas do tipo «app simples: X meses; app complexa: Y meses». São estimativas de empresas que vendem desenvolvimento, sem dizer como foram calculadas, e «simples» e «complexa» querem dizer coisas diferentes para cada uma.

Duas apps com o mesmo aspeto podem ter prazos muito diferentes. Uma lista de marcações que vive sozinha não é o mesmo que uma lista de marcações que fala com a faturação, envia avisos aos clientes e tem regras diferentes para cada loja. Por isso, é mais útil perceber de que depende o prazo do que procurar um número.

As fases de um projeto

Quase todos os projetos de app ou de software à medida passam por estas fases, com mais ou menos peso:

1. Perceber o problema. Conversas com quem vai usar o sistema, levantamento do processo atual, das regras e das exceções. É a fase mais curta no calendário e a que mais poupa tempo depois.
2. Desenhar. Ecrãs, percursos e, idealmente, um protótipo clicável para validar a app ou o sistema antes de o programar. Mudar um desenho é muito mais rápido do que mudar código.
3. Desenvolver. Programar o sistema, normalmente em ciclos curtos, com versões para experimentar pelo caminho.
4. Testar. Com dados reais e com as pessoas que vão usar o sistema, não só com a equipa que o fez.
5. Lançar. Migrar dados, formar a equipa e, no caso das apps, passar pela revisão das lojas.
6. Acompanhar. Corrigir o que aparece nas primeiras semanas de uso real. Depois disso, começa a manutenção.

Estas fases não têm de acontecer uma vez para o sistema inteiro. É comum fazer o ciclo completo para uma primeira versão e repeti-lo para as seguintes.

O que mais pesa no prazo

O último fator é o mais subestimado. Num projeto à medida, o fornecedor depende de quem conhece o negócio para tirar dúvidas e validar o que está feito. Se essa pessoa só tem disponibilidade de semanas a semanas, o calendário acompanha-a.

O que costuma atrasar um projeto

• Mudar o âmbito a meio. Acrescentar funcionalidades depois de o trabalho começar empurra tudo o que vem a seguir. Não é proibido, mas deve ser uma decisão consciente, com o impacto no prazo dito por escrito.
• Regras que só aparecem no fim. «Ah, mas no caso destes clientes é diferente.» Quanto mais tarde se descobre uma exceção, mais caro é acomodá-la.
• Conteúdos e dados que não chegam. Textos, fotografias, listas de produtos, dados de clientes: alguém tem de os preparar.
• Integrações com terceiros. Acessos, chaves e documentação de outro fornecedor podem demorar mais do que o próprio desenvolvimento da ligação.
• Testes deixados para o fim. Problemas encontrados na véspera do lançamento atrasam o lançamento.

Os prazos das lojas de apps

Se o projeto inclui uma app para iPhone ou Android, há prazos que não dependem de quem desenvolve:

• App Store: a Apple indica que revê habitualmente pelo menos metade das submissões em menos de 24 horas e 90% em menos de 48 horas. Se a app for rejeitada, é preciso corrigir e voltar a submeter.
• Google Play: a Google avisa que, para algumas contas, a revisão pode chegar a sete dias ou mais em casos excecionais.
• Contas pessoais novas no Google Play: as contas de programador pessoais criadas depois de 13 de novembro de 2023 têm de fazer um teste fechado com pelo menos 12 testadores, durante 14 dias seguidos, antes de poderem publicar.

Convém contar com estes prazos no calendário, sobretudo se o lançamento tem uma data fixa. Uma app web não passa pelas lojas: comparamos as duas opções em app web ou app nativa.

Como ter uma primeira versão mais cedo

O que mais encurta o prazo não é trabalhar mais depressa: é fazer menos de cada vez.

1. Separar o essencial do desejável. A primeira versão deve resolver o problema que justifica o projeto. O resto entra depois.
2. Começar pela parte que dói mais. Se o maior problema são as encomendas, comece pelas encomendas, não pelos relatórios.
3. Validar com um protótipo antes de programar, para não construir ecrãs que vão ser refeitos.
4. Ter uma pessoa do seu lado com tempo e autoridade para decidir.
5. Adiar integrações não essenciais. Às vezes uma exportação manual resolve nos primeiros meses, até a ligação automática estar pronta.

Acrescentar programadores ajuda menos do que parece: mais pessoas exigem mais coordenação, e há trabalho que não se pode dividir. Reduzir o âmbito da primeira versão costuma ter mais efeito.

Como avaliar o prazo de uma proposta

Um prazo numa proposta só vale o que vale a descrição que o acompanha. Antes de comparar datas, confirme:

• O prazo está dividido por fases, com o que cada fase entrega?
• Há versões para experimentar pelo caminho, ou só se vê o sistema no fim?
• O que é preciso do seu lado (dados, conteúdos, acessos, disponibilidade para reuniões) e quando?
• O prazo inclui testes, migração de dados e a revisão das lojas, ou só o desenvolvimento?
• O que acontece se o âmbito mudar a meio do projeto?

Um prazo muito mais curto do que os outros quase sempre quer dizer que a proposta inclui menos, ou que assume que tudo corre bem à primeira. Explicamos como receber propostas comparáveis em como pedir um orçamento para uma app ou um software.

Como trabalhamos o prazo na Quadrix

Começamos por perceber o que o sistema tem de fazer e, nas apps, por um protótipo clicável. Depois propomos o projeto por fases, e a primeira versão útil entra em uso antes de o sistema estar completo, para a equipa começar a ganhar tempo cedo. O prazo de cada fase fica definido na proposta.

Em resumo

• Não há um prazo certo para uma app ou um software: há fatores que o fazem crescer ou encolher.
• Funcionalidades, integrações, plataformas, dados a migrar e a rapidez das decisões são o que mais pesa.
• As lojas têm prazos próprios de revisão, e as contas pessoais novas no Google Play exigem um teste de 14 dias.
• A forma mais eficaz de ter algo mais cedo é uma primeira versão mais pequena.
• Compare prazos de propostas só depois de confirmar o que cada uma inclui.

Para perceber o que mais influencia o custo, leia quanto custa uma app; para os custos depois do lançamento, quanto custa manter uma app. Veja também como desenvolvemos software à medida e apps.