Esse é um trecho da minha apresentação no Global Enterprise Mobility Forum de 12 de novembro de 2013; a apresentação completa pode ser encontrada aqui.
Com o contínuo aumento de dispositivos móveis nos negócios é fácil focar no desenvolvimento de aplicativos e sites que permitam ao usuário de aparelhos de celular acessar importantes processos corporativos. O problema é que os negócios ficam presos entre a filosofia de “um aparelho para tudo” e a difícil tarefa de desenvolver algo separadamente para cada aparelho do ecossistema. É necessária uma abordagem multicanais para desenvolver um único processo que possa aplicado de forma inteligente a qualquer aparelho.
Por que precisamos de multicanais
Hoje em dia, temos usuários que acessam dados de diferentes modelos de aparelho e arquiteturas. Eles podem variar de terminais de mainframes, até laptops tradicionais e computadores pessoais, tablets e smartphones, com diversos sistemas operacionais, navegadores de internet e, claro, uma variedade crescente de mídias sociais. Ao mesmo tempo, os usuários nunca tiveram dados tão variados ou tantos sistemas de retaguarda para acessar. Os dados podem estar nos grandes sistemas CRM e ERP ou em serviços de nuvem públicos. Podem residir no centro de dados corporativos ou então em um sistema moderno ou em um de legado.
O HTML 5 foi sugerido como resposta para esse desafio de acesso aos dados, mas, embora eu não tenha nada contra HTML (principalmente para consumidores e sites amadores), não acredito que ele seja a varinha mágica para todos os nossos desafios de mobilidade já que ele não permite o uso do contexto no qual nossos usuários tentam completar tarefas. Esse é o motivo pelo qual precisamos de uma abordagem multicanal: porque multicanais nos permitem considerar o contexto para nossos usuários.
O contexto é essencial no desenvolvimento de um workflow móvel, porque a variedade de experiências pode ser muito maior do que em um PC. Com um PC tradicional da empresa, ou mesmo um laptop, podemos ter razoável certeza de que o usuário tem um teclado e um mouse, que tem uma tela de pelo menos 14 polegadas e que estão sentados com relativo conforto. Essas deduções nos permitem incluir uma certa forma de trabalhar que envolva múltiplos aplicativos e abas no navegador abertas simultaneamente, pequenos ícones, habilidade para drill down em relatórios… mas no momento em que usamos nossos celulares em um fluxo de trabalho isso tudo não é mais possível.
Nosso usuário poderia estar prestes a embarcar em um avião e tentar acionar alertas de última hora. Poderia estar sentado em um café, ou em um trem, com tempo para trabalhar, mas paciência limitada para controles complicados. Poderia até estar em uma escrivaninha com uma grande tela, mouse e teclado, esperando poder fazer grandes trabalhos com uma tabela dinâmica, porque usar o celular para trabalhar não significa que é necessário eliminar o PC. Essa variedade de contextos deve ser levada em consideração e uma abordagem multicanal é a melhor forma para atingir isso.
Algumas definições
Antes de prosseguir, quero definir alguns termos e esclarecer o que nos preocupa e o que não nos preocupa ao desenvolver para mobile:
- Aparelhos são ferramentas usadas para executar uma tarefa: o PC, o iPad, o Galaxy S4, o Nexus, e assim por diante. Não devemos considerar o aparelho além de estabelecer regras para o tipo de aparelho, baseados nos contextos em que imaginamos que será usado.
- Plataformas são o ecossistema nos quais ficam os aparelhos, por exemplo o iOS, Android ou Windows. Novamente, não devemos nos preocupar com isso e, principalmente, não devemos desenvolver algo separadamente para cada ecossistema.
Então o que importa?
- O canal é um ponto de contato com o usuário dentro do workflow, que significa como a interação de fato toma forma. Assim sendo, um PC, tablet ou smartphone podem ser considerados canais, o que torna o canal útil por nos permitir escolher um contexto a partir do tipo de aparelho e desenvolver algo de acordo.
- Finalmente, o contexto é, onde, quando, como e porque um usuário está tentando executar uma certa tarefa, e isso pode nos dizer muito sobre como eles o querem fazer.
Isso significa que a experiência do usuário é prioritária e que o que realmente devemos fazer é produzir funcionalidade de uma forma que seja informada pelo contexto do usuário.
O sistema caiu
Esse conceito de contexto como chave nos mostra como é ruim o atual sistema de mobilidade da empresa cair: nós temos dois mundos, o dos usuários e o da área de TI, opostos um ao outro.
Os usuários querem usar seus dispositivos móveis para trabalhar, e isso significa realmente os aparelhos deles: com a revolução do BYOD, os usuários passaram a considerar que pudessem trazer o aparelho de sua escolha para a empresa e fazê-los funcionar. Certamente pouquíssimos saem satisfeitos quando ganham um antigo Blackberry!
O interessante é que esses aparelhos nasceram como produtos de consumo para consumidores: especifico consumo também porque, enquanto um PC poderoso de mídia e jogos seja certamente um produto de consumo, os aparelhos de celular foram originalmente vistos puramente para saciar o consumo. Quando o iPhone foi lançado, era visto como um brinquedo para acessar o Facebook; o iPad era visto como um brinquedo para assistir vídeos de gatos no Youtube; e o Android era visto como ainda menos adequado. E ainda assim aqui estamos, felizes trabalhando de verdade nesses aparelhos e procurando formas de fazê-los ainda mais produtivos.
Enquanto isso, a empresa é tradicionalmente muito restringente, dependente de processos definidos, dados estruturados bem organizados em bases de dados, tudo empacotado em camadas de governança e controle, cada mudança precisando ser escalada. Existe alguma forma de eliminar o abismo entre essas duas visões de mundo?
É útil considerarmos o que estamos tentando atingir, que é ter a mesma funcionalidade disponível em diferentes canais, de uma forma que seja adaptada, integrada e pronta para suportar diversos tipos de aparelhos.
Portanto, temos processos de negócios únicos que com os quais devemos interagir de modos diferentes: no smartphone queremos saber o que fazer agora, no tablet talvez passemos um pouco mais de tempo analisando o que estamos vendo; e no PC estamos felizes em abrir diversos workflows e ter uma visão mais aprofundada dos dados.
Como usamos aparelhos de forma diferente?
Mesmo entre os dois principais tipos de aparelhos móveis, podemos ver diferenças no uso: há maior chance de usarmos smartphones pelos seus sensores, enquanto um tablet é ótimo para realidade aumentada ou tarefas leves de produtividade. Algumas diferenças chaves entre os tipos de aparelho são:
- Entrada: tanto os smartphones quanto os tablets tão principalmente à base de toque, mas somos limitados, na realidade, a um ou dois dedos ou talvez ao polegar no smartphone, enquanto em um tablet podemos usar ambos os polegares ou até quatro dedos confortavelmente. Enquanto isso, com um PC temos o teclado e o mouse e uma grande tela.
- Tempo de frustração: Ao contrário do limiar de atenção (tempo que leva para se distrair), essa expressão significa o tempo que conseguimos nos dedicar a uma tarefa antes de decidir deixá-la para mais tarde no escritório. No smartphone isto é entre dois e quatro segundos, ou entre cinco e dez em um tablet. Isso está ligado ao tamanho da tela e as formas de entrada. Já nos PCs, os usuários conseguem trabalhar por mais de 10 segundos.
- Localização: A escolha do dispositivo nos diz muito sobre a localização do usuário. Um smartphone significa que ele está provavelmente com pressa, talvez andando para uma reunião, enquanto um tablet implica que está sentado, embora não necessariamente com conforto, e tem algum tempo disponível. Finalmente, usar um PC sugere que estão confortáveis a uma mesa e pode permanecer assim por algum tempo.
- Sociabilidade: Diferentes dispositivos são mais fáceis de compartilhar. Um PC tem uma grande tela que pode ser facilmente compartilhada, e as portas extras de entrada e saída significam que um monitor externo pode ser adicionado caso necessário. Por outro lado, o tablet e o smartphone são dificilmente compartilhados.
Tudo isso é útil para uma abordagem multicanal, pois permitem que se façam julgamentos sobre que tipo de ações os usuários pretendem tomar. No smartphone, por exemplo, irão usar sensores, mensagens de ação, mas têm entrada de dados limitada, enquanto em um PC poderão usar tabelas dinâmicas e fazer muitas digitações. Isso significa que precisamos focar em canais e processos, não em aplicativos e aparelhos.
Porque plataformas de aplicações são necessárias para a abordagem multicanal
Queremos usar um esforço único de desenvolvimento para estender os processos de negócios de forma inteligente para qualquer aparelho em diferentes canais, e as empresas de hoje não querem apenas “um app”. Elas precisam, na verdade, de acesso seguro e confiável a qualquer dado da empresa com alta disponibilidade; experiência de usuário nativo (que permita uso de sensores) e suporte para trabalhos off-line; e precisam ficar flexíveis para responder a tendências que surgem e garantir que o ambiente seja à prova do futuro. Segurança e funcionalidade da administração devem vir com o aparelho, com encriptação, suporte de administração do aparelho (MDM), e autenticação do usuário. Precisam conseguir monitorar e controlar acesso a dados, local e horário.
Isso significa que não podemos simplesmente assumir a visão de que a mobilidade da empresa significa decidir entre um conjunto de aparelhos ou ecossistemas. Devemos suportar o contexto do usuário através de plataformas e aparelhos, desde um único esforço de desenvolvimento e com total integração do final do processo. Segurança, monitoramento e administração devem estar incorporados no aparelho. Precisamos usar uma plataforma de desenvolvimento que possa, sem interrupções, construir essa funcionalidade no aplicativo.
Plataformas são capazes de trabalhar com contexto ao pegar um processo de negócios específico e construí-lo em uma camada de apresentação, que determina regras para como a informação precisa ser apresentada em diferentes canais. Isso significa que o mesmo aplicativo mostrará diferentes dados de formas diferentes dependendo do aparelho com o qual for acessado.
Plataformas podem construir capacidade off-line
Off-line é algo bem direito: é a habilidade de trabalhar sem acesso a uma rede e conexão de dados. No entanto, um conceito tão simples leva a algumas complicadas decisões.
Acesso off-line é necessário por vários motivos, desde inconsistente cobertura de rede (principalmente em lugares fechados e fora das grandes cidades), o tempo necessário para conseguir ou subir dados ao vivo, até o custo de roaming internacional para dados e até problemas como dados limitados quando no próprio país. A internet das coisas colocará pressão crescente nas redes, ao ponto em que em 2020 precisaremos correr para ficar no mesmo lugar e claro há situações (assim como em voos) onde não há conexão.
Quanto aos beneficiados pelo acesso off-line, não são apenas os navegantes frequentes, mas qualquer um que precise enviar muitos relatórios a um servidor central onde o tempo não é crítico. Considere um consultor que precise fornecer relatórios de acompanhamento diário dos trabalhos executados: essa informação é essencial para que a empresa cobre o cliente, mas só é coletada nas tardes de sexta. Em vez de acessar repetidamente o servidor seguro de um celular, com toda a dificuldade que isso pode envolver, por que não deixar que o consultor grave os relatórios off-line e se conecte ao servidor seguro apenas uma vez por semana?
De forma semelhante, uma parte chave do acesso off-line é determinar padrões, que são regras que dizem ao sistema como lidar com o conflito de acesso. Há uma grande variedade, que é usada de acordo com a expectativa de conflito. O maior desafio com o trabalho off-line é o número e variedades absurdas de bases de dados que podem ser afetadas, e, aqui, usar uma plataforma de desenvolvimento também é muito útil.
Construindo uma abordagem multicanal
A fim de criar uma estratégia eficiente de multicanal, comece definindo os processos que precisam ser acessados pelos múltiplos canais. Quando tiver o processo, considere as “janelas” para ele: as formas pelas quais a informação precisa ser apresentada.
Considerar o contexto no qual o usuário estará executando o processo mostra quais sensores no aparelho podem ser úteis. Isso também o ajuda a entender onde melhor guardar a informação, seja ela arquivos temporários, dados em progresso ou registro final.
Agora defina a lógica de negócios: quem está tentando executar o processo e o que pretendem conseguir? Isso é parte de um processo existente? Quais integrações podem ser necessárias? Finalmente, quais pontos de contato os usuários terão no processo e o que precisa acontecer em cada um?
Uma vez que você tenha essas informações, é muito mais fácil definir as plataformas e canais esperados, determinar quais padrões off-line serão necessários e como administrar a segurança.
