Os 6 erros mais comuns em projetos mobile

Bruna Bites | | tive uma ideia

Ao longo de todos esses anos que trabalhamos com projetos mobile, muitos compartilharam ideias de aplicativos e nos perguntaram se daria certo, se a ideia era boa. O curioso é que a primeira pergunta nunca foi qual o melhor jeito de construir o app ou de colocar esta ideia na prática.

Após inúmeros projetos e produtos, de empreendedores, empresas grandes ou pequenas, identificamos os erros mais comuns e que mais comprometem o sucesso de um produto que além de comprometerem a qualidade final, quebrarem prazo e aumentarem o custo (seja para o cliente ou para quem está desenvolvendo, não tem jeito, vai dar prejuízo) desgastam a relação entre os membros dos times.

São eles:

1) Começar o desenvolvimento e só depois iniciar o layout:

Uma comparação é ao construir uma casa. Começar a desenvolver antes de pensar no layout, equivale a começar a subir paredes sem saber exatamente onde elas devem ficar. Percebe que a chance disso dar certo é muito baixa, certo? É incrível a quantidade de projetos iniciados assim. O custo para implementar o layout, o fluxo e os comportamentos depois acaba ficando mais alto, sem contar a gravidade de não trabalhar corretamente o UX ou acabar diminuindo a liberdade de criação no design por medo de não dar certo na hora de implementar em um sistema já pronto.

O melhor é iniciar o projeto tendo uma estratégia do produto mínimo (MVP) alinhando UX/UI e também envolvendo desenvolvedores – porque não? – para que quando for iniciar o desenvolvimento os trilhos já estejam montados para fluir o máximo possível.

2) Começar desenvolvendo e depois integramos com APIs:

Se usarmos a analogia de construção de casa, isto seria como começar pelas paredes e telhado para depois fazer o alicerce. Esta situação é uma das mais comuns, muitas vezes pelo fato da equipe de backend e web ter outras atividades priorizadas. Em geral, o retrabalho nos aplicativos no momento de integrá-los após já construídos é significativo, podendo inclusive inviabilizar algumas funcionalidades porque a arquitetura não comporta o comportamento desejado.

O backend e os WebServices devem ser feitos antes do início do desenvolvimento do app, e é fundamental que esteja 100% alinhado com os comportamentos previstos na etapa de UX e UI.

3) Não ter um UX/UI com conhecimento Mobile:

Investir tempo para aprendizado em Mobile e suas melhores prática é fundamental. Estamos cada vez vendo mais layouts com características muito mais de web que de mobile, talvez pelo boom de criação e planejamento de aplicativos e demanda de profissionais, o que acaba comprometendo o produto final. Além de velocidade e qualidade, na maioria das vezes os fluxos e comportamentos não são comuns para um app na visão do usuário, o que gera desconforto e péssima reputação.

O melhor a fazer é estudar e praticar muito os guides de cada OS e assim, potencializar as chances de sucesso do produto.

4) Não realizar testes com cenários de rede e memória:

Ok, é muito difícil realizar testes em todos os aparelhos necessários, pelo alto valor de investimento na compra dos devices e pelo tempo para execução da rotina de teste (impressionante como tem pressa quem quer desenvolver um app!). Por isto muitos acabam realizando a maior parte dos testes em simuladores. Este erro compromete muito o pós lançamento, pois na vida real os usuários vão usar diferentes modelos de smartphones e tablets, com diferentes configurações de memória e tela, com inúmeros vídeos, músicas, fotos e apps instalados, e com todo tipo de sinal de rede (de inexistente ao ótimo).

Neste caso, o melhor a fazer é ter claramente qual o comportamento esperado para situações sem rede ou pouco sinal e testar no maior número de equipamentos possível, com diferentes cenários de rede (wifi, edge, 3G, 4G…) e memória.

5) Incluir versões antigas de OS:

É claro que quanto maior o número de usuários melhor, mas é preciso se desapegar de alguns. Se são lançadas novas versões de OS (Android e iOS por exemplo) é porque é preciso ajustar algumas coisas e evoluir outras. Apesar disso, é comum o desejo de manter versão 2.3 do Android e 6 do iOS para suportar o maior número de equipamentos possível, o que é um erro super comprometedor porque isto promove o nivelamento por baixo.

O melhor a se fazer é determinar as duas últimas versões e manter sempre o foco na próxima, para que os usuários possam usufruir do máximo de possibilidade de implementação que depende do OS.

6) Mudar escopo no meio do desenvolvimento:

Ter alguns ajustes no meio do caminho é aceitável. Mas o que ocorre com muita frequênciaé mudar o escopo adicionando ou alterando funcionalidades quando o projeto já está na fase de desenvolvimento. Isso gera potenciais  atrasos, diminuição da qualidade de entrega e na maioria das vezes, desmotivação da equipe.

Para evitar conflitos e administrar possíveis mudanças no produto o que aconselhamos é dividir o escopo em pequenas partes entregáveis e imutáveis.

É preciso reconhecer que na maioria dos projetos de aplicativos a equipe responsável nas empresas não tem experiência com apps, e em muitos casos até com tecnologia. Nas nossas observações, em geral, o cliente dono do produto é originado das áreas de comunicação das empresas, o que, em muitos casos, não permite clareza sobre o processo de desenvolvimento.

— ~ —

Por conta disso, para evitar esses erros do projeto é preciso ter 3 pontos que devem ser considerados dogmas e nunca serem ignorados:

1) Estabelecer um processo de entendimento, criação, documentação, desenvolvimento, testes e implantação muito claro e com vários pontos de validação do cliente. Sendo que sem determinadas validações o processo não pode evoluir para o próximo passo.

2) Comunicação e Alinhamento periódicos com as equipes envolvidas para que dependências, decisões e status sejam discutidos e devidamente compartilhados – o desenvolvimento de aplicativos se dá muito bem com scrum!

3) Sinceridade! A equipe desenvolvedora e a equipe cliente precisam trabalhar sempre com a verdade. Se é possível ou impossível, se é bom ou ruim, bonito ou feio, interessante ou ridículo… Além do entendimento das necessidades e limitações, com isto, é possível garantir objetividade e responsabilidade dos envolvidos.

[box type=”shadow”]A SobreApps tem uma equipe especializada em desenvolvimento e gestão de projetos mobile. Quer evitar atrasos e aumentar a qualidade? Entre em contato e saiba como: alo@sobreapps.com.br[/box]

  • Diego Motta

    Muito bom. Concordo com tudo. Algumas das dicas se aplicam não só a mobile, mas a qualquer projeto de desenvolvimento de software.

  • Genis Lopes

    Gostei muito, tenho algumas ideias de aplicativos e se tiver algum programador capacitado fique a vontade para propor parceria!

    • Lucas Henrique

      Interessante, como seria essa parceria?