8 erros caros no desenvolvimento de apps que as PME continuam a cometer

Eis a verdade incómoda sobre os projetos de app que correm mal: quando o código parece errado, o projeto já estava perdido há semanas. Os erros caros no desenvolvimento de apps de pequenas empresas quase nunca acontecem ao teclado. Acontecem em conversas casuais — o briefing que nunca foi posto por escrito, a funcionalidade que alguém acrescentou 'já agora', o programador escolhido porque um amigo o recomendou. No momento, nada disto parece uma decisão. E tudo isto custa-lhe mais tarde.

Vi muitas pequenas empresas encomendarem a sua primeira app, e fui chamado para salvar várias depois do facto consumado. Os donos raramente são pessoas descuidadas. São perspicazes, cuidadosos, bons a gerir um negócio. Mas o software tem o seu próprio conjunto de armadilhas que não existem em mais lado nenhum da sua vida profissional, e ninguém os avisou. Por isso caminham a direito para os mesmos oito obstáculos, mais ou menos pela mesma ordem, de cada vez.

Esta é a lista que eu gostaria que cada dono tivesse antes de gastar um cêntimo. Não é teoria — são os erros reais e recorrentes, e as pequenas correções de rumo que teriam salvado cada projeto. Se está prestes a construir uma app, ou já vai a meio do desenvolvimento e algo lhe parece estranho, leia isto primeiro. A maioria destes erros ainda tem solução se os detetar cedo.

Erro 1: Construir antes de ter provado que alguém a quer

O erro mais caro é também o mais comum: comprometer-se com um desenvolvimento completo antes de existir qualquer prova real de que a app resolve um problema pelo qual as pessoas pagarão ou que usarão. Ao dono, a ideia parece óbvia — claro que os clientes a vão querer — e é precisamente essa certeza que é perigosa. A certeza parece validação. Não é.

Validar não significa perguntar a dez amigos se gostam da ideia; toda a gente diz que sim por delicadeza. Significa colocar a versão mais pequena possível diante de utilizadores reais numa situação real e observar o que eles realmente fazem. Um protótipo clicável, uma página de destino que mede as inscrições, uma versão manual de 'concierge' em que finge a automatização à mão — qualquer uma destas diz-lhe mais do que uma app acabada construída sobre um palpite. A ordem importa: prove a procura de forma barata, depois construa de forma cara. Inverta isso e pode gastar todo o orçamento a polir algo que ninguém abre duas vezes.

Erro 2: A expansão do âmbito disfarçada de ambição

Toda a app começa leve e arrumada. Depois começa o 'já agora'. Já que estamos a construir o ecrã de reservas, podia também gerir vales de oferta? E pontos de fidelidade? E um sistema de recomendações? Cada acréscimo soa razoável por si só. Juntos triplicam em silêncio o prazo e a fatura — e empurram o lançamento para tão longe que o ímpeto inicial morre.

A solução não é dizer não às boas ideias. É estacioná-las. Mantenha uma lista 'versão dois' visível onde cada ideia brilhante aguarda a sua vez. Isto produz um efeito psicológico além de prático: as pessoas deixam de lutar para enfiar funcionalidades na primeira versão assim que confiam que há um lugar real para a sua ideia mais tarde. A sua primeira versão deve fazer uma coisa genuinamente bem, não dez coisas de forma aceitável. Uma app que domina um único fluxo de trabalho é usada. Uma app que faz tudo pela metade é abandonada.

Erro 3: Sem briefing escrito — apenas uma imagem mental partilhada

Este erro é invisível até morder. O dono tem uma app clara na cabeça. O programador tem uma app clara na cabeça. Toda a gente acena na reunião de arranque. Ninguém o põe por escrito como deve ser — e as duas imagens, afinal, nunca foram a mesma imagem. Descobre isto a meio do caminho, quando aquilo que está a ser construído não é o que imaginava, e agora há uma discussão sobre quem disse o quê.

Não precisa de uma especificação de cem páginas. Precisa de algumas páginas que qualquer recém-chegado consiga ler e entender: quem usa esta app, quais são as três ou quatro coisas que precisa de fazer com ela, como é um resultado bem-sucedido. Acrescente um esboço aproximado dos ecrãs principais. É tudo. O propósito do briefing não é a burocracia — é uma referência partilhada para a qual ambos podem apontar quando a memória e a realidade começam a divergir, o que acontece sempre.

Erro 4: Escolher o programador da maneira errada

A maioria dos donos escolhe o seu primeiro programador com base num de dois sinais frágeis: o orçamento mais baixo, ou uma recomendação pessoal de alguém de outro setor. Ambos podem resultar por sorte. Nenhum é uma forma fiável de escolher alguém a quem vai confiar uma fatia considerável de dinheiro e vários meses do futuro do seu negócio.

O orçamento mais baixo é particularmente traiçoeiro no software, porque o fosso entre um orçamento e o custo final é enorme e invisível. Um programador barato que precisa de três rondas de retrabalho, desaparece durante duas semanas e lhe deixa um código que mais ninguém consegue manter sai muito mais caro do que um um pouco mais dispendioso que o faz bem. O preço é o que vê; o custo total é o que paga.

O que verificar de facto

Peça para ver coisas que lançaram e que continuam a funcionar e, se puder, fale com esses clientes sem o programador na sala. Pergunte como lidam com alterações a meio do projeto, porque vai haver alterações. Pergunte de quem são o código e as contas quando estiver concluído — a resposta deve ser sempre suas. E preste atenção a se lhe fazem boas perguntas de volta. Um programador que apenas cumpre ordens construirá exatamente a coisa errada de forma muito eficiente. Os bons contrapõem, apontam falhas no seu raciocínio e tratam o briefing como ponto de partida para uma conversa, não como uma lista de compras fechada.

Erro 5: Orçamentar o desenvolvimento, esquecer o resto

Uma app não é uma compra única como um folheto impresso. É uma coisa viva que precisa de ser alimentada. Os donos orçamentam habitualmente o desenvolvimento e mais nada, e depois são apanhados de surpresa pelos custos que chegam a seguir: o alojamento, as taxas das lojas de apps, a manutenção para acompanhar as atualizações do sistema operativo do telemóvel, e a inevitável ronda de correções e pequenas melhorias assim que as pessoas reais começam a usá-la.

Uma regra prática sensata: seja qual for o custo do desenvolvimento, ponha de parte de novo uma fatia significativa disso para o primeiro ano de funcionamento. O número exato varia, mas o erro é universal — tratar o dia do lançamento como a linha de meta quando na verdade é a linha de partida. A app que é lançada e depois abandonada em silêncio porque não há orçamento para a manter é um dos desfechos mais tristes e comuns de todo este campo, e é totalmente evitável com um planeamento honesto à partida.

Erro 6: Desenhar para si próprio em vez de para o seu utilizador

Conhece o seu negócio de cor, o que faz de si o pior juiz possível sobre se a sua app é fácil de usar. As coisas que para si são óbvias — o jargão, a ordem por que executa as tarefas, os atalhos que faz sem pensar — confundem um utilizador de primeira vez. Uma app que faz todo o sentido para o dono e baralha toda a gente falhou, por mais engenhosa que seja.

A cura é barata e ligeiramente humilhante: observe pessoas reais a usá-la antes de lançar. Não a sua equipa, que já sabe como é suposto funcionar — clientes ou colaboradores reais que nunca a viram. Entregue-lhes a app, dê uma tarefa e não diga nada. Onde hesitarem, tocarem na coisa errada ou suspirarem, é o seu feedback de design. Cinco pessoas chegam para fazer emergir os piores problemas. Saltar este passo é como as apps saem com um botão 'enviar' que ninguém encontra e um fluxo de inscrição que perde metade de quem tenta.

• Dê ao testador uma tarefa real, não uma visita guiada — 'marca uma consulta para a próxima terça-feira', e depois fique calado.
• Observe as mãos e a cara dele, não apenas se no fim consegue.
• Anote cada hesitação; uma pausa é um problema de design que não consegue ver de dentro.
• Resista ao impulso de explicar — se tem de o explicar, a app é que devia tê-lo feito.
• Teste com cinco pessoas, corrija as falhas óbvias e depois teste de novo.

Erro 7: Construir apps nativas de iOS e Android quando não era preciso

Existe um reflexo: construir uma app 'a sério' para iPhone e Android desde o primeiro dia, totalmente nativa, à maneira das grandes marcas. Para a maioria das pequenas empresas, isso é duas a três vezes o custo e a complexidade por um benefício que os seus utilizadores nunca vão notar. Pior ainda, passa agora a manter duas bases de código separadas para sempre, duplicando cada correção futura.

Muitas vezes, o primeiro passo certo não é de todo uma app nativa. Uma app web bem construída que funcione no navegador de qualquer telemóvel, ou uma abordagem multiplataforma que produza ambas as versões para as lojas a partir de uma única base de código, leva-o ao mercado mais depressa e mais barato — e pode sempre passar a totalmente nativo mais tarde, se o uso real provar que vale a pena. A pergunta nunca é 'nativo ou web' em abstrato. É: qual é a coisa mais pequena e mais barata que permite a utilizadores reais fazerem a tarefa essencial? Construa isso, aprenda com isso e depois gaste o dinheiro grande com provas em vez de suposições.

Erro 8: Tratar o lançamento como o fim do trabalho

O oitavo erro é acreditar que o projeto está concluído quando a app entra em funcionamento. Não está — é aí que começa o verdadeiro projeto. Uma app sem plano para chegar às mãos dos utilizadores, sem forma de ouvir o que pensam e sem intenção de a melhorar com base no que aprende é uma app que se apaga em poucos meses. O desenvolvimento era a parte fácil. A adoção é a parte difícil, e quase ninguém a planeia.

Antes de lançar, saiba três coisas: como as pessoas vão ficar a saber que a app existe, como vai medir se estão de facto a usá-la, e como vai recolher aquilo que lhe dizem para que a próxima ronda de trabalho seja guiada pela realidade em vez de palpites. Nada disto é caro. É apenas uma mentalidade diferente — a app não é uma coisa que termina e abandona, é uma relação que mantém. Os donos que percebem isto obtêm apps que se tornam mais úteis com o tempo. Os que não percebem obtêm um pico no dia do lançamento e um longo e silencioso declínio.

Como ficar livre dos oito de uma só vez

Lidos em conjunto, estes erros partilham uma única raiz: avançar depressa sobre suposições em vez de devagar sobre provas. Cada um deles é um ponto onde pareceu mais barato saltar o passo cuidadoso. E cada um deles é muito mais barato de tratar antes do desenvolvimento do que depois. Eis a sequência que contorna em silêncio os oito.

1. 1
   Prove a procura antes de construir

   Um protótipo, uma página de destino ou uma versão manual. Obtenha provas reais de que alguém a quer antes de comprometer o orçamento.
2. 2
   Escreva o briefing e a lista versão dois

   Algumas páginas claras que qualquer um entenda, mais um estacionamento para cada ideia 'já agora' para que não descarrile a v1.
3. 3
   Escolha o programador pelo historial, não pelo preço

   Trabalho lançado, telefonemas a referências, propriedade clara do código e das contas, e alguém que lhe faz boas perguntas de volta.
4. 4
   Orçamente todo o primeiro ano, não só o desenvolvimento

   Alojamento, manutenção, correções e apoio. O dia do lançamento é a linha de partida, por isso financie o funcionamento da coisa.
5. 5
   Escolha a plataforma mais pequena que faz o trabalho

   Web ou multiplataforma primeiro na maioria dos casos. Passe a totalmente nativo mais tarde, com provas, só se o uso o exigir.
6. 6
   Teste com utilizadores reais e depois planeie o lançamento

   Observe cinco desconhecidos a usá-la, corrija as falhas óbvias e decida à partida como as pessoas a vão encontrar e como vai medir o uso.

Perguntas frequentes