O verdadeiro cronograma do desenvolvimento de uma app: da ideia ao lançamento

Se perguntar a dez agências quanto tempo demora a desenvolver uma app, vai receber dez respostas confiantes e nenhuma delas será verdadeira. A resposta honesta é que ninguém lhe consegue dizer com precisão no primeiro dia, mas qualquer pessoa que já tenha entregado software de verdade lhe pode descrever a forma do percurso: que fases existem, quais delas devoram em silêncio o calendário e onde as suas próprias decisões aceleram as coisas ou as travam por completo. É exatamente essa forma, posta por escrito sem rodeios.

Já vi muitos donos de pequenas empresas entrar num projeto de app à espera de uma marcha arrumada e linear, do esboço até à App Store. O que recebem, em vez disso, parece mais uma sucessão de planaltos e saltos repentinos. Semanas em que parece não acontecer nada, e depois um dia em que tudo encaixa de repente. Nada disso é sinal de que algo está mal. É simplesmente assim que se faz o software, e assim que consegue dar nome às fases, todo o processo deixa de ser uma caixa negra na qual paga à espera de que corra bem.

Vamos então definir expectativas realistas. Para uma primeira versão focada de uma app de empresa — não uma plataforma sem fim, mas uma primeira versão que faz bem uma só coisa — fala-se normalmente de um intervalo entre três e cinco meses, de um arranque sério até um lançamento real. Onde vai cair dentro desse intervalo depende menos da tecnologia do que da sua clareza, da rapidez com que decide e de quanto tenta enfiar antes do lançamento. Vamos percorrê-lo.

Porque é que a estimativa que lhe deram está provavelmente errada

O número das seis semanas não é exatamente uma mentira: é o tempo que demora a construir a parte que toda a gente consegue imaginar. Os ecrãs. Os botões. Aquilo que se pode mostrar numa demonstração. O que esse número ignora em silêncio é tudo o que rodeia a app visível: as decisões, os dados, as integrações com ferramentas que já usa, os testes, a revisão da loja, a inevitável ronda de «já agora, será que também faz isto?»

Uma forma útil de o ver: o código raramente é o estrangulamento. O estrangulamento é a clareza. Cada hora em que o seu programador espera por uma decisão — que fornecedor de pagamentos, o que acontece quando uma reserva é cancelada, quem pode ver o quê — é uma hora de derrapagem no calendário. Os projetos que terminam depressa não são os que têm os melhores engenheiros. São aqueles em que a dona responde às perguntas num dia em vez de em quinze.

Por isso, ao ler as fases abaixo, repare nos momentos em que a bola está do seu lado. São os pontos em que um projeto mantém o ímpeto ou encalha em silêncio durante três semanas porque um e-mail ficou sem resposta. O cronograma é uma responsabilidade partilhada, e a metade que cabe ao cliente é a que se costuma subestimar.

Fase 1: Análise e definição do âmbito (1–3 semanas)

Antes de alguém desenhar um único ecrã, há uma fase que não parece progresso mas determina tudo: perceber o que está realmente a construir e, mais importante ainda, o que não está. É aqui que uma ideia vaga («uma app para os meus clientes») se torna uma lista concreta e fechável de funcionalidades para a versão um.

Bem feita, a análise é sobretudo conversa e perguntas incómodas. Quem a usa, e em que dispositivo? Qual é a única coisa que tem de fazer de forma brilhante? O que pode esperar pela versão dois? Um bom parceiro vai contrapor aqui, e é isso que quer: cada funcionalidade que corta agora são semanas que recupera. O resultado é normalmente um âmbito escrito e curto e um wireframe tosco, algo que pode ter na mão e dizer sim, é isto.

Fase 2: Design e protótipo (2–4 semanas)

Agora a app torna-se algo que pode ver e tocar, antes de uma única linha de código real o comprometer com seja o que for. Os designers transformam o wireframe em ecrãs a sério — as cores, o fluxo, a verdadeira sensação de a usar — normalmente sob a forma de um protótipo interativo que pode percorrer com o dedo no seu próprio telemóvel.

Esta fase vale ouro por uma razão: mudar um design é barato; mudar software já construído é caro. Mover um botão num protótipo demora cinco minutos. Movê-lo depois de a funcionalidade estar programada, testada e ligada aos seus dados pode demorar um dia. Por isso este é o momento de ser exigente, de o mostrar a alguns clientes ou colaboradores reais e de apanhar os problemas do tipo «ah, ninguém vai perceber isto» enquanto ainda são indolores de corrigir.

A forma mais comum de esta fase se arrastar não é o designer, é a indecisão do seu lado. Rondas intermináveis de pequenos retoques, ou três pessoas com poder de veto que nunca chegam a acordo. Decida cedo quem dá o aval, dê o feedback em lotes em vez de a conta-gotas, e esta fase mantém-se apertada.

Fase 3: Desenvolvimento (6–12 semanas)

Esta é a parte que toda a gente imagina ao pensar em «fazer uma app», e é o troço contínuo mais longo — mas raramente o mais imprevisível, se as duas primeiras fases foram bem feitas. Os programadores constroem a app por blocos, normalmente em ciclos curtos em que vê peças a funcionar a cada uma ou duas semanas, em vez de desaparecerem três meses e reaparecerem com um produto acabado.

Esse ritmo importa. Quer reagir cedo a software real e em funcionamento, não a um relatório de estado. Quando puder mesmo usar o fluxo de reserva na semana quatro, vai notar coisas que nenhuma especificação teria conseguido captar, e corrigi-las na semana quatro é muito mais barato do que na dez. Um bom processo de desenvolvimento torna a app continuamente visível para si, e não só no fim.

O que estica o desenvolvimento em silêncio

Duas coisas dilatam um desenvolvimento mais do que qualquer outra. A primeira são as integrações: cada sistema externo com que a app tem de falar (o seu fornecedor de pagamentos, a sua ferramenta de reservas atual, o seu software de contabilidade, um serviço de entregas) acrescenta trabalho, e cada um pode reservar as suas próprias surpresas. A segunda é o aumento de âmbito: o gotejar constante de pequenas adições, cada uma aparentemente mínima mas que, juntas, empurram o lançamento um mês para a frente. Ambas são geríveis, mas só se as vir chegar.

• Cada integração externa acrescenta dias, por vezes semanas: orce-as de forma explícita, não parta do princípio de que são grátis.
• «Só mais uma funcionalidadezinha» é de longe a causa mais comum de uma data de lançamento falhada.
• Os dados reais são mais confusos do que os de teste; reserve tempo para os casos-limite que a sua folha de cálculo tolerava em silêncio.
• Contas de utilizador, pagamentos e notificações são enganadoramente profundos: custam sempre mais do que parecem.
• As aprovações e os conteúdos que deve à equipa (logótipos, textos, textos legais) podem travar um desenvolvimento tão certamente como um erro.

Fase 4: Testes e correções (2–4 semanas)

Eis uma fase de cuja existência as pessoas se esquecem, e depois lamentam quando aparece. Assim que a app está construída, tem de ser posta à prova: em telemóveis diferentes, com má ligação, por pessoas que não a construíram e que vão fazer coisas que ninguém previu. Testar não é uma formalidade. É a diferença entre uma app em que os seus clientes confiam e uma que desinstalam após o primeiro encerramento inesperado.

Conte com o surgimento aqui de uma lista de erros e arestas por limar. Não é sinal de que o desenvolvimento correu mal; é o objetivo inteiro da fase. Alguns são correções rápidas, outros revelam uma decisão que é preciso rever. As equipas que lidam bem com isto tratam-no como uma parte normal e planeada do trabalho — não como uma emergência, nem como algo a saltar porque o lançamento aperta. Saltar os testes não poupa tempo. Apenas transfere os erros do seu telemóvel de teste para os telemóveis dos seus clientes, onde custam dez vezes mais a corrigir.

Fase 5: Lançamento e a espera da loja (1–2 semanas, mais a revisão)

O lançamento é menos um único momento e mais uma implementação cuidadosa. Se for uma app web, controla totalmente o timing: aciona o interruptor quando estiver pronto. Se for para a App Store da Apple ou para a Google Play, cede-lhes parte do calendário: o processo de revisão deles pode demorar de um dia a mais de uma semana, e por vezes devolvem-na com algo a corrigir. Vale a pena saber isto de antemão, para que não apanhe de surpresa uma data de lançamento que prometeu aos clientes.

A forma inteligente de lançar não é uma revelação em grande para toda a sua base de clientes. É primeiro um lançamento discreto a um grupo pequeno — um punhado de clientes bem dispostos ou os seus próprios colaboradores — para apanhar os problemas do mundo real antes de todos os verem. Depois abre mais a porta. Um lançamento que parece aborrecidamente sem incidentes é um lançamento que correu bem.

1. 1
   Lançamento suave a um grupo pequeno

   Lance primeiro a um punhado de utilizadores bem dispostos ou colaboradores. O uso real encontra o que os testes falharam, com o risco no mínimo.
2. 2
   Submeta cedo se for para as lojas

   A Apple e a Google controlam o relógio da revisão, não você. Submeta com uma margem para que uma revisão lenta ou uma recusa não rebente a data prometida.
3. 3
   Acompanhe de perto a primeira semana

   Tenha alguém à mão para reagir depressa. A primeira semana traz à tona os casos-limite reais que nenhum ambiente de teste reproduz.
4. 4
   Planeie o trabalho do dia seguinte antes de lançar

   Uma app nunca está 'terminada' no lançamento. Combine de antemão quem trata das inevitáveis pequenas correções e da primeira ronda de feedback.

Juntar todo o cronograma

Empilhadas de uma ponta à outra, estas fases dão um quadro realista. Nenhuma é exótica; o que faz as pessoas tropeçar é esquecer que as pouco vistosas — análise, testes, espera da loja — são tempo real no calendário, não erros de arredondamento. Eis mais ou menos como uma primeira versão focada tende a distribuir-se ao longo dos meses.

Some tudo e percebe porque é que três a cinco meses é o intervalo honesto para uma primeira versão a sério, e porque é que quem promete seis semanas está, em silêncio, a redefinir o que significa «uma app». Não é pessimismo: é a diferença entre uma data que vai mesmo cumprir e uma pela qual passará o projeto inteiro a pedir desculpa.

Como acelerar de verdade (e como não)

Pode ir mais depressa, mas as alavancas reais não são aquelas a que se costuma recorrer. Atirar mais programadores a um projeto definido a meio costuma torná-lo mais lento, não mais rápido. Os aceleradores honestos são pouco vistosos: decida o que deixar de fora, responda depressa às perguntas e resista à vontade de acrescentar coisas a meio do desenvolvimento.

O maior de longe é um âmbito implacável. Quanto mais pequena e clara for a sua primeira versão, mais cedo ela lança, e uma app lançada que se paga ensina-lhe mais em duas semanas do que outros dois meses de planeamento. Acrescentar pode sempre. Não pode recuperar os meses gastos a construir funcionalidades que afinal ninguém queria.

Há uma verdade relacionada que vale a pena dizer em voz alta: nem tudo precisa de ser uma app à medida. Por vezes o verdadeiro problema é uma fatia de trabalho manual que uma automatização poderia tratar em silêncio, sem app nenhuma. Um bom parceiro dir-lhe-á quando é esse o caso, em vez de lhe vender o desenvolvimento maior, porque a app mais barata é aquela que não precisou de fazer.

Perguntas frequentes