Processo de desenvolvimento de um app: guia para o fundador que paga a conta

O processo de desenvolvimento de um app é vendido como uma esteira de seis etapas. Aqui está o que realmente acontece em cada uma, qual é a sua única tarefa e onde o fundador silenciosamente perde o controle do produto que está pagando para construir.

Uma fundadora com quem trabalhamos tinha aprovado tudo. Assinou embaixo dos wireframes, concordou com a cabeça em todas as demos de sprint e encaminhou a data de lançamento para o investidor-líder. Três semanas antes do go-live, o desenvolvedor comentou, de passagem, que o app não conseguia enviar e-mail de redefinição de senha. Nunca tinha entrado no escopo. Ninguém tinha mentido para ela. Ela simplesmente aprovou seis meses de trabalho sem nunca saber o que deveria estar conferindo em cada etapa.

O processo de desenvolvimento de um app é a sequência que uma ideia de software percorre até virar um produto que funciona: discovery, design, construção, testes, lançamento e manutenção. Toda agência e toda software house descreve isso como um conjunto arrumadinho de etapas, quase sempre numeradas, quase sempre com uma seta apontando para a direita. Esse desenho é verdadeiro e inútil. Verdadeiro porque essas fases de fato acontecem nessa ordem. Inútil porque ele é desenhado a partir da cadeira de quem constrói, e você não está nessa cadeira. Você é quem paga a conta, e a sua tarefa em cada fase é diferente da tarefa deles.

Este é um guia sobre essas mesmas seis fases a partir do lugar onde você de fato está sentado. Para cada uma: o que acontece, a única coisa que cabe a você acertar e o sinal específico de que a fase está indo mal enquanto todo mundo ainda sorri.

A única regra que rege todo o processo de desenvolvimento de um app

Antes das fases, a regra que dá sentido a todas elas:

Seu poder de influência sobre um build é maior antes de a primeira linha de código ser escrita, e cai a cada semana depois disso. Gaste sua atenção onde ela vale mais: nas duas fases antes da construção, não nos standups durante ela.

A maioria dos fundadores de primeira viagem faz o oposto. Fica de fora durante o discovery e o design, quando uma frase sua poderia redirecionar o projeto inteiro, e depois se enche de ansiedade e se envolve durante a construção, quando as decisões caras já foram concretadas. Quando você está assistindo aos standups diários, já está tentando administrar o clima. A influência foi embora sem você.

Fase 1: Discovery, decidir o que não construir

O discovery é onde o time transforma a sua ideia em uma lista específica do que a versão um vai e do que não vai fazer. Times bons conduzem entrevistas, esboçam fluxos e cravam o punhado de coisas que o produto precisa fazer para valer a pena lançar. Times fracos pulam essa etapa e já começam a desenhar telas, o que parece progresso e é só chutar com uma ferramenta mais bonita.

Sua única tarefa aqui é subtrair. O time consegue adicionar features o dia inteiro; só você consegue decidir o que o negócio não precisa na primeira versão. Cada feature que você corta no discovery é dinheiro que você não gasta e um bug que você nunca vai ter que corrigir. Esta é a fase em que o trabalho de discovery de produto se paga várias vezes, porque é o lugar mais barato de todo o processo para mudar de ideia.

O sinal de alerta: o time quer começar a construir já na primeira semana e trata o discovery como formalidade. Uma software house ansiosa para pular o discovery é uma software house que é paga para construir, não para pensar, e a diferença vai aparecer na sua fatura daqui a três meses, na forma de retrabalho.

Fase 2: Design, o último lugar barato para errar

O design transforma as decisões do discovery em algo que você consegue ver e clicar: primeiro os wireframes (o esqueleto), depois mockups de mais alta fidelidade e, em geral, um protótipo interativo. Esta é a última fase em que mudar de ideia custa uma tarde em vez de uma semana. Mover um botão num arquivo de design é de graça. Mover ele depois de conectado a dados reais e testado, não é.

Sua tarefa é clicar no protótipo como um cliente desconfiado, não admirá-lo como um pai orgulhoso. Tente fazer as três coisas que seus usuários reais vão fazer com mais frequência. Se qualquer uma delas exigir mais toques do que deveria, fale agora. Entender a diferença entre um wireframe e um mockup importa aqui, porque fundadores muitas vezes aprovam um esqueleto cinza achando que aprovaram a aparência final, e depois se sentem enganados quando a coisa real chega.

O sinal de alerta: te mostram imagens estáticas e pedem que você imagine o fluxo. Se você não consegue de fato percorrer a jornada principal com o dedo antes de a construção começar, você está aprovando uma história sobre o app, não o app.

Fase 3: Construção, onde sua influência já foi gasta

Agora os engenheiros escrevem o código. Esta é a fase mais longa e mais cara e, contra a intuição, aquela em que você tem menos a acrescentar. As decisões que importavam foram tomadas nas duas fases que você talvez tenha atravessado com pressa. O que você ainda pode fazer aqui é proteger o build de você mesmo.

Toda vez que você introduz uma ideia nova no meio da construção, você não está adicionando uma feature, está reabrindo o plano. O time precisa re-sequenciar o trabalho, e o custo raramente é só a coisa nova; é tudo que a coisa nova encosta. É esse o mecanismo por trás da maioria dos prazos estourados. Se você quer entender por que o número mudou, leia a sua estimativa de desenvolvimento de software como uma faixa que pressupõe que você pare de mudar de ideia, porque essa premissa está fazendo um trabalho silencioso e enorme.

Sua única tarefa durante a construção é manter uma versão que funciona na sua frente. Peça um link que você mesmo abre, não uma gravação de tela que alguém editou. Software que só existe numa demo é software que você não consegue inspecionar. O sinal de alerta é uma fase de construção em que toda atualização é um slide e nunca um link.

Fase 4: Testes, a fase que é cortada primeiro

O teste é onde o time tenta quebrar o app antes que seus clientes façam isso: ele funciona num Android baratinho, sobrevive a uma rede ruim, o que acontece quando alguém digita um emoji no campo de nome. É a fase com mais chance de ser silenciosamente comprimida quando a construção atrasa, porque é a última coisa de pé entre uma data escorregando e um lançamento.

Você não consegue ler o código de teste, mas pode pedir o resultado: um relatório curto do que foi testado, do que quebrou e do que foi corrigido. Você não está auditando a engenharia. Está verificando se o teste aconteceu como uma atividade com uma saída, e não como uma palavra que alguém falou numa reunião. O e-mail de redefinição de senha que ninguém colocou no escopo é exatamente o tipo de coisa que uma rodada de testes de verdade pega e uma rodada comprimida não pega.

O sinal de alerta: “a gente foi testando conforme fazia” oferecido como substituto de uma fase de testes. Testar conforme se avança é boa prática e é uma desculpa ruim. Se não existe um artefato mostrando o que foi conferido, presuma que a cobertura é o que deu na telha.

Fase 5: Lançamento, um evento de engenharia antes de ser um de marketing

O lançamento não é a festa. É o trabalho chato e de alto risco de colocar o app na frente de usuários reais, em infraestrutura real: revisão da app store, dados de produção, monitoramento e um plano para a primeira vez que algo quebrar às duas da manhã. O lançamento de marketing pode esperar uma semana. O lançamento de engenharia tem uma centena de portinhas que precisam ser todas fechadas, e a maioria delas é invisível para você.

Sua tarefa é saber quem está com o pager na mão. Faça uma pergunta: quando algo quebrar nas primeiras 48 horas, quem percebe e em quanto tempo consegue corrigir. Se a resposta for vaga, você não tem um plano de lançamento, tem uma esperança. O lançamento também tem porteiros que não estão sob seu controle: as diretrizes de revisão da App Store da Apple podem rejeitar um build por motivos que nada têm a ver com o app funcionar, e uma rejeição a poucos dias da sua data é um problema de lançamento que você quer ouvir na fase um, não na fase cinco.

O sinal de alerta: o plano de go-live é uma data e nada mais. Uma data não é um plano. Um plano diz quem faz o quê quando a coisa que você não esperava acontece.

Fase 6: Manutenção, a fase que todo mundo esquece de precificar

Software não é um prédio que fica de pé depois que você corta a fita. Celulares atualizam, bibliotecas quebram, usuários encontram cantos que você nunca imaginou, e o app precisa de atenção constante e sem glamour para continuar funcionando. Manutenção não é uma fase depois do processo; é o processo não terminando. Fundadores que tratam o lançamento como linha de chegada descobrem isso na primeira vez que a Apple muda alguma coisa e o app deles para de abrir.

Sua tarefa é recusar a ideia de que a manutenção é opcional. Decida, antes do lançamento, quem mantém as luzes acesas e quanto isso custa por mês. A versão mais barata dessa conversa acontece agora. A versão mais cara acontece depois que o seu único desenvolvedor foi embora e ninguém que ficou consegue mexer numa linha com segurança.

O sinal de alerta: uma proposta que termina no lançamento, sem uma linha sobre o que acontece depois. Um build sem plano de manutenção é um carro vendido sem nenhuma forma de comprar combustível.

O Teste do Handoff: como saber que uma fase realmente terminou

Aqui está a única ferramenta que amarra as seis fases. Em cada fronteira entre fases, existe um artefato que você deveria conseguir segurar na mão:

• Depois do discovery: um escopo de uma página que você lê em cinco minutos e que lista o que ficou de fora, não só o que ficou dentro.
• Depois do design: um protótipo clicável da jornada principal, não uma pasta de imagens.
• Depois da construção: um link para uma versão funcionando que você mesmo consegue abrir.
• Depois dos testes: um relatório curto do que foi conferido e do que quebrou.
• Depois do lançamento: um runbook dizendo quem responde quando algo falha.

O teste é simples. Se uma fase termina e você não consegue segurar o artefato dela, a fase não terminou de verdade. Ela só empurrou o risco para frente, para a fase seguinte e, no fim, para você. Todo desastre em um build é alguma versão de uma fase declarada concluída sem produzir a coisa que prova que ela terminou. O Teste do Handoff é como um fundador não técnico audita um processo cujo código ele não consegue ler: você não confere o trabalho, você confere se cada fase deixou evidência para trás.

Você vai reparar que isso também te diz em qual software house confiar. Um time que pensa em artefatos os entrega a você sem que você peça. Um time que pensa em faturas te entrega um status e torce para você se sentir tranquilizado. A forma como você escolhe uma empresa de desenvolvimento deveria se apoiar fortemente nisto: pergunte o que você vai conseguir segurar no fim de cada fase e observe se a resposta é específica.

Perguntas frequentes

Quais são as etapas do processo de desenvolvimento de um app?

Seis: discovery (decidir o que construir), design (torná-lo visível e clicável), construção (escrever o código), testes (quebrá-lo antes dos usuários), lançamento (colocá-lo no ar com segurança) e manutenção (mantê-lo funcionando). Alguns guias dividem isso em sete ou doze passos, mas os números extras costumam ser subtarefas dessas seis. O número importa menos do que saber qual é a sua tarefa em cada uma.

Quanto tempo leva o processo de desenvolvimento de um app?

Uma primeira versão de verdade costuma levar de três a seis meses, com discovery e design tomando algumas semanas e a construção levando o grosso do tempo. A resposta honesta depende de quanto você corta no discovery e de quantas vezes você muda de ideia durante a construção. As duas alavancas que você controla ficam na frente do processo, não no meio.

Qual é a fase mais importante para um fundador não técnico?

As duas antes da construção: discovery e design. É ali que sua influência é maior e uma mudança custa menos. Fundadores que investem sua atenção ali e depois dão um passo atrás durante a construção conseguem apps melhores por menos dinheiro do que fundadores que fazem o contrário.

Posso pular o discovery para ir mais rápido?

Pode, e é a forma mais comum de gastar mais para conseguir menos. Pular o discovery não elimina as decisões sobre o que construir; só as empurra para a fase de construção, onde mudá-las custa dez vezes mais. Largadas rápidas aqui geralmente compram chegadas lentas.

Como fico no controle de um build que não consigo avaliar tecnicamente?

Use o Teste do Handoff. No fim de cada fase, peça o artefato que prova que ela aconteceu: uma página de escopo, um protótipo clicável, um link funcionando, um relatório de testes, um runbook. Você não precisa ler código para perceber quando uma fase terminou sem deixar evidência para trás.