Há três anos, Marc Andreessen disse em um artigo no The Wall Street Journal que o “Software is eating the world”. No fim do ano passado, porém, Benedict Evans reformulou a frase para dizer que “Mobile is eating the world”. No blog da Concrete Solutions você vai ver que já deixamos claro em alguns textos, como este e este, que temos todos os motivos para acreditar em Ben Evans. Entretanto, nascemos como uma empresa de software, e temos software no nosso DNA. Por isso, tivemos que nos transformar para seguir essa nova direção. Dito isso, seguem algumas lições que aprendemos no caminho:

1. A fragmentação é um inferno: são centenas ou milhares de combinações de aparelhos e sistemas operacionais diferentes. Mesmo com a supremacia de iOS e Android, você tem que prestar um mínimo de atenção às mais de 60 milhões de pessoas que usam smartphones no Brasil. Neste cenário, se você não tiver práticas como integração e deployment contínuos e testes automatizados, simplesmente o projeto não tem chances de dar certo.

2. O UX funciona de forma diferente no mobile: mesmo trabalhando em conjunto com o time, o profissional de UX tem que conhecer as diferentes guidelines das diferentes plataformas, seja ela Android, iOS ou Windows Phone. Além de ter que combinar essas guidelines com a identidade visual e marca do cliente, a experiência do usuário é muito diferente ao usar o celular, o tablet e o desktop. O público e, consequentemente, o comportamento é diferente, o que muda todo o trabalho do UX.

3. A pergunta certa não é se a API está pronta, mas se alguém está usando a API: o cliente sempre vai dizer que a API dele está pronta, mas a definição de pronto nesSe caso não é respeitar o contrato que está no papel, mas o uso efetivo da API. Sem a API pronta, o desenvolvimento do produto deve gastar de duas a três vezes mais tempo do que o necessário.

4. Sem um PO, é melhor nem começar: no desenvolvimento mobile, as decisões de simplificação têm que ser impiedosas. Tudo o que sabíamos de desenvolvimento web é intensificado, com ciclos mais curtos, até porque a expectativa do usuário é bem maior. Neste ponto, devemos ser muito mais ágeis e Lean. Ressalto ainda que, neste ponto, a web ainda tem muito o que aprender com o mobile.

5. Controle de qualidade deve ser preemptivo e proativo: em mobile, é indispensável resolver o máximo possível de problemas antes de eles acontecerem. Isso significa que o pipeline deve ser montado com integração contínua, deployment contínuo, testes unitários, testes funcionais e tudo o que for possível para que um erro não apareça depois que o aplicativo já estiver disponível na App Store. Isso porque um pequeno erro pode ser decisivo para aumentar sua avaliação negativa e afetar diretamente sua instalação orgânica. O time, por sua vez, deve ser proativo e olhar todos os indicadores instrumentados, como de crash, funil e marketing, para tomar decisões mais bem orientadas.

6. O nível de instrumentação é maior: para garantir o alto grau de qualidade, muitas ferramentas são necessárias e indispensáveis para o desenvolvimento mobile, como Google Analytics e Tag Manager ou Flurry para saber como os usuários estão usando o aplicativo, ad-X e Adjust para marketing, Crashlytics ou Crittercism para relatórios de falhas, Newrelic para performance, distimo para informações sobre performance nas app stores etc. O uso e o conhecimento básico de cada uma dessas ferramentas, entre outras, são extremamente necessários para garantir a qualidade do seu aplicativo.

7. Protótipos com mais fidelidade: com a implementação do Backend as a Service (BaaS), em nuvem, os protótipos de alta fidelidade são cada vez mais fáceis, e com certeza muito mais próximos que no desenvolvimento web. Você tem a possibilidade de iterar só o aplicativo, e a versão final dá para ir para produção muito mais rápido, o que não acontecia na web. Neste ponto, é bom citar que é interessante começar com o Discovery para Android, que é mais fácil ciclar e tem uma app store menos “chata” para publicação (menos tempo para aprovação) do que a app store do iOS.

8. O papel de Quality Assurance: uma vez o Daniel Braz publicou os seis papéis de um time ágil. No time mobile, um sétimo papel ganha uma responsabilidade muito importante. Enquanto na web os testes unitários, de carga e de disponibilidade, eram automatizados e os funcionais podiam ser feitos manualmente (apesar de o ideal ser automatizá-los), uma vez que são dois ou três browsers, com a fragmentação é praticamente impossível não usar testes automatizados. Neste contexto, o perfil do QA muda e ele fica responsável por desenvolver o código de teste e garantir que estes testes funcionem. O objetivo é que o teste de aceite do cliente seja apenas uma formalidade.

9. Mudanças rápidas de paradigma: em pouquíssimo tempo, a Nokia e o BlackBerry, que eram líderes de mercado, desapareceram, e entre os smartphones estão surgindo relógios, fones, casas inteligentes. As mudanças em mobile ocorrem muito mais rapidamente do que na web. Neste contexto, desenvolvedores mobile têm que sempre estar atentos às novidades, que são divulgadas anualmente, para se manterem competitivos.

10. A conexão: enquanto é garantia que o seu usuário desktop está conectado à Internet, o usuário do seu aplicativo pode estar no Wi-Fi, no 4G ou no 3G. Considerar a velocidade e a qualidade da conexão do usuário para conseguir a melhor experiência para ele é extremamente importante para quem está desenvolvendo um aplicativo.

E é com essas lições que continuamos tentando fazer desenvolvimento mobile do jeito certo. Mas é claro que continuaremos ainda aprendendo muito, e muito rápido, como é de praxe nesse segmento. Tem alguma dúvida ou quer também contribuir com seu aprendizado? Deixe aqui nos comentários.