Várias discussões mantém o mundo mobile aquecido, desde o notável crescimento de algumas fintechs mobile based, passando pelas novas versões de sistemas operacionais ou devices (smartphones e wearables) e é claro, as diferenças do desenvolvimento mobile frente a outras plataformas. A escolha da tecnologia para criar aplicativos é também uma destas discussões e a seguir discorro sobre como enxergo a diferença entre lamentar prejuízos e escolher com louvor:
Falando em bom senso
Nada melhor do que o bom senso para conduzir reuniões, sejam elas de planejamento de escopo de projeto ou definições técnicas relacionadas a arquitetura do aplicativo. O fato é que a presença ou ausência do bom senso traz consigo elogios e críticas, respectivamente.
Este comportamento será o amigo número um durante a escolha da tecnologia a ser utilizada para desenvolvimento de aplicativos. Digo isso, pois a primeira vista é muito simples considerar o desenvolvimento híbrido ou cross-platform como as melhores opções, afinal, quem não quer desenvolver um aplicativo em menor tempo e ainda vê-lo operar em todos os Sistemas Operacionais mobile?
Agir desta maneira ou criar projetos para atender nativamente os SOs mais expressivos (Android, iOS, W. Phone)?
A diferença é insana e parece injustificável, contudo, nem tudo deve ser levado a ferro e fogo, keep reading.
“Escolhi a melhor tecnologia” vs “Escolhi uma boa tecnologia” para desenvolvimento de aplicativos
Observo que, na esmagadora maioria dos casos, o desenvolvimento híbrido é levado em conta nas situações abaixo:
- “Não tenho tempo para desenvolver um aplicativo nativo para cada Sistema Operacional.”
- “Não tenho dinheiro para desenvolver um aplicativo nativo para cada Sistema Operacional.”
O que as situações 1 e 2 têm em comum é que são cenários nos quais o dev. híbrido está sendo levado em conta pois falta algum recurso – tempo ou dinheiro – alegadamente requerido para o desenvolvimento nativo, e não por ser a melhor opção. Caso a decisão não leve outros fatores em conta, agir assim pode ser equivalente a beber óleo por falta de dinheiro ou tempo para buscar água. O exemplo anterior parece extremo, mas observe as situações 3, 4 e 5 abaixo, nas quais os motivos do desenvolvimento híbrido ser considerado me parecem muito mais plausíveis:
- “O escopo do meu aplicativo é enxuto, de modo que seu uso não será recorrente ou este manipulará dados em um cenário de baixa complexidade (integrações e carga)”;
- “O grau de exigência de meu público alvo frente a performance do app não é alto”;
- “Meu aplicativo não abriga funcionalidades específicas que requerem desenvolvimento nativo para sua operação adequada.”
Nestas situações, o desenvolvimento híbrido foi tratado como a melhor opção para desenvolvimento de aplicativos por motivos baseados no projeto e público alvo, e não como uma medida paliativa ao desenvolvimento nativo. Compreende a diferença?
Haters gonna hate
O desenvolvimento híbrido e também o cross-platform são excelentes abordagens de desenvolvimento para aplicativos, entretanto, devemos avaliar sua escolha sob os mesmos parâmetros que utilizamos ao avaliar o dev. nativo: os seus prós e contras se encaixam na realidade e expectativa atuais e futuras do projeto? (Quem sabe tema de um próximo artigo, rs).
Enxergo que surgem várias opiniões fanáticas sobre essa escolha, principalmente porquê aqueles que formam tais opiniões buscam escolher o que lhes é mais favorável como fornecedores e não o que é mais favorável ao projeto/cliente.
Gato por lebre
É responsabilidade do fornecedor explicar tais diferenças ao patrocinador do projeto e embasar a decisão em argumentos concretos. Quando isso não acontece, a negligência entra em cena e a tecnologia mais favorável ao fornecedor (nativa ou híbrida) é utilizada, seja para aumentar sua lucratividade ou até mesmo por este não possuir uma equipe especializada que atenda o que o projeto precisa. Sabemos quem paga essa conta.
A verdadeira lebre não é o desenvolvimento de aplicativos nativos ou híbridos, mas sim desenvolver algo mais robusto do que o necessário ou algo que atenda a necessidade momentânea mas falhe na evolução. Copy?
Contrate certo
A contratação de um bom fornecedor mitiga as situações adversas que abordei neste artigo.
Seja tempo: caso o projeto grite por dev. nativo, a boa fábrica de software mobile deve possuir equipes de desenvolvimento especialistas em cada Sistema Operacional. Isso permite que o desenvolvimento seja realizado paralelamente e que haja entrega única.
A garantia de que os profissionais (analistas, designers e desenvolvedores) envolvidos em seu projeto sabem como o SO funciona e, ainda mais, como os usuários do referido sistema se comportam durante o uso de um app trará absurdo ganho na aceitação de seu aplicativo.
Seja custo: neste cenário creio que a argumentação é um tanto contextual, visto que declinar o uso de uma tecnologia por custo pode ou não ser viável de acordo com a realidade do seu projeto/empresa. Além disso, existem diversas abordagens para que o projeto seja bem sucedido com orçamento reduzido, isso nos leva ao Mínimo Produto Viável 🙂
Espero que a reflexão acima contribua de alguma maneira com seus projetos atuais ou futuros.
Publicado originalmente no Blog Capptan | mobile expert.
