É difícil saber o que veio primeiro no Damnoen Saduak: os clientes, com sua curiosidade e guias de bolso, ou os comerciantes com seus chapéus de bambu e folhas de palmeira e seus produtos coloridos. Mas, uma certeza: eles são atraídos mutuamente. As pessoas não vão ao mercado flutuante porque os preços são mais baixos, mas sim porque o produto é fresco, acessível e vendido de forma conveniente e interessante. 

Os fornecedores remam seus barcos pelo rio comprando e vendendo frutas, vegetais e outras mercadorias, atravessando o sistema de canais de Bangkok. Os canais eram convenientes, os barcos eficientes e a extensão dos canais abrangia toda a cidade. 

Onde eu quero chegar com isso? As redes móveis atuais são abrangentes, os aplicativos móveis são interessantes e conseguem chegar primeiro aos clientes, exatamente onde eles estão.

Quando chega a hora de criar aplicativos móveis com capacidade para alcançar os clientes, o time-to-market tem mais a ver com a habilidade de desenvolver aplicativos móveis que rodam em sistemas operacionais de vários dispositivos e integrá-los a sistemas de transações comerciais back-end de forma eficiente e ágil. 

A distância até o cliente é uma vantagem que os aplicativos móveis têm, pois eles reduzem a zero a distância da transação entre você e seu cliente. A capacidade de vender aos clientes está bem na palma da mão de seus clientes.

Mas, para ser bem franco, o time-to-market é, muitas vezes, uma desvantagem dos aplicativos móveis devido aos longos prazos necessários para desenvolver o app utilizando as ferramentas de desenvolvimento nativas das plataformas. É por isso que quando vemos uma plataforma que afirma combinar as vantagens de técnicas de desenvolvimento rápido, soluções de integração pré construídas e capacidade multiplataforma para implementação em smartphones e tablets, temos que prestar bastante atenção. Um time-to-market mais rápido para aplicativos móveis requer uma plataforma de aplicações mais inteligente.

A maioria das abordagens de desenvolvimento são vítimas do triângulo tempo-qualidade-custo e sugerem que você pode escolher somente duas das três qualidades benéficas: menos tempo e mais qualidade, ou menos tempo e menos custo, ou mais qualidade e menos custo. 

A sabedoria predominante sugere que você não pode ter todos os três. Mas francamente, esse dilema popular baseia-se na ideia preconcebida de que todas as abordagens necessitam de um esforço fixo.

O que imaginamos no início da década de 80, com a ideia de uma plataforma de protótipos rápida para criar aplicações comerciais, resulta hoje em uma tecnologia bastante inteligente e sofisticada que ainda é ignorada com muita frequência pela comunidade convencional de programação de computadores. 

Os benefícios de uma plataforma de aplicações podem ser encontrados no fato de que ela elimina o problema do esforço fixo. As plataformas possuem soluções embutidas. Elas possibilitam resultados muito rápidos através do aproveitamento dos requisitos de desenvolvimento de aplicações comuns em um conjunto de soluções ou plataforma.

De acordo com Daniel Coyle, autor de The Talent Code: “Os passos de um bebê constituem a estrada real para a habilidade”. Como eu disse antes: “Independente de você utilizar metodologias de gerenciamento de projeto ágeis ou scrum, ter resultados imediatos e frequentes é essencial. Muitos projetos são cancelados no meio do processo simplesmente porque seu progresso é coberto de mistérios”. 

Uma plataforma de aplicações propicia a você essas vitórias iniciais e leva-o a vitórias frequentes que manterão os investidores executivos comprometidos com a conclusão e pedindo por mais.

O desenvolvimento nativo sofre em comparação com o desenvolvimento da plataforma de aplicações devido a uma série de motivos:

Primeiro: são necessárias mais ferramentas. Isso não é uma opinião, é fato. Com o desenvolvimento nativo, você necessita de uma linguagem do lado do servidor, uma metodologia de implantação e uma linguagem do lado do cliente. 

Além disso, as linguagens do lado do cliente são diferentes: Objective-C, J2ME, J2SE, etc. Devido ao esforço extra por parte dessas ferramentas, são designados mais programadores para um projeto de desenvolvimento de aplicativos móveis. Enquanto a complexidade ambiental aumenta com o desenvolvimento móvel nativo, o paradigma da plataforma de desenvolvimento da Magic baseado em metadados permanece constante: uma ferramenta para todos os requisitos – do lado do servidor e clientes de vários sistemas operacionais.

Para entender o significado absoluto disso, é necessário considerar o Modelo COCOMO II de estimativa de software perfeito no USC Center for Software Engineering (Go Trojans!). O modelo COCOMO II pode ser simplificado como segue:

Esforço = (Equipe) x (Ferramentas) × (Complexidade) x (Processo)

Conforme você aumenta o número de linguagens de programação necessárias (ferramentas), aumenta o esforço. O conceito é muito simples. À medida que você aumenta o número de desenvolvedores (equipe), o esforço aumenta. E conforme você aumenta os requisitos funcionais do aplicativo a ser entregue (Complexidade), aumenta o esforço. A relação entre esses três componentes de esforço é fatorial.

Os restaurantes ao longo dos canais do Mercado Flutuante de Damnoen Saduak desejam seus vegetais realmente frescos. Para aplicativos móveis realmente frescos, considere uma plataforma de aplicação abrangente e deixe a plataforma nativa de lado.

* Glenn Johnson é vice-presidente sênior da Magic Software Américas.