Aumento da mobilidade, acesso via múltiplos dispositivos, e a forma como você disponibiliza a informação? É satisfatório?

Com o avanço da tecnologia, e a crescente utilização dos dispositivos móveis para acesso a internet, empresas intensificaram a oferta de produtos a esse nicho de mercado, onde se tem um novo canal de comunicação B2P (Business to Person).

No entanto, não se pode ater somente a um determinado publico, ou seja, aqueles que utilizam os dispositivos moveis para acessar às redes sociais, trocar mensagens, baixar aplicativos para uso com fins de entretenimento, pois existe uma grande vertente que está associada à aplicações corporativas, para auxiliar em resolução de dúvidas ou orientação, mapas, marketing de produtos, dentre outros.

Com esse publico bem diversificado, observa-se uma difusão e disseminação de conteúdos para dispositivos móveis. Jornais, bancos, provedores de e-mails, varejistas, a cada dia aumentam seu marketshare para tais dispositivos, porem, em alguns casos, sem nenhum controle de crescimento ou planejamento da forma como vai ser publicado tal conteúdo.

Passo algumas horas do dia acessando conteúdos através do celular, e o que estou vendo é que alguns canais de informação não possuem uma interface customizada a tal dispositivo. Isso é, o mesmo look and feel que é mostrado para uma monitor de 19” também é apresentado para uma tela de 4”, sem falar nas imagens que são descarregadas sem nenhum tipo de filtro para o celular. Por mais que avancemos na rede móvel,com  aumento de memória dos dispositivos móveis, facilidade de interação, ainda temos problemas de sinal de agente de externo estabilizado, onde depende da localização onde se encontra o aparelho, dificultando downloads dos conteúdos estáticos.

Até agora só identificamos dois requisitos: usabilidade e desempenho, em determinados casos, são cruciais para a satisfação de quem utiliza tal serviço. Pesquisadores de Stanford fizeram estudos relacionados ao consumo de memória navegando em sites através de browsers de celulares, onde conseguiram reduzir, em alguns casos, até 25% do consumo de memória, simplesmente alterando os scripts que eram utilizados pelas páginas, alterando o formato das imagens que eram transferidas aos navegadores, utilização de caches, dentre outros.

Nesse estudo foi focado somente o consumo de memória, restando então a usabilidade. Papel que exige um pouco mais do Arquiteto de software. Na maioria dos projetos, o tempo no cronograma é requisito primordial, ao seja, não se dispõe. Logo não se dá ao projetista o tempo necessário para pensar na melhor forma de se criar componentes ou mesmo o desenho lógico de como tal sistema irá se comportar.

Voltando a prancheta, existem padrões que pode resolver tal problema de requisições de múltiplos clientes (desktop ou móvel). Esse padrão se chama: FrontController. A motivação para utilizar esse padrão passa pelos seguintes aspectos:

- Sistema comum de processamento de serviços por solicitação;

- Centralização da lógica de visão;

- Múltiplas visões são usadas para responder a uma requisição similar de negócio. Dentre outras.

A utilização desse padrão visa a centralização ou mesmo o ponto inicial de contato de uma requisição, que pode ser via desktop, celular, tablet, etc, e redirecionando a camada de negócio ou  mesmo tomando alguma decisão. Nesse controle é gerenciado todo o processo de requisição englobando: serviços de segurança (autenticação e autorização), processar a regra de negócio, gerenciar a escolha de uma visão apropriada, manipulação de erros, e gerenciar a seleção da estratégia da criação do conteúdo.

Associado ao FrontController, podemos utilizar o InterceptingFilter como responsável dentre outros aspectos por:

- Validar se um cliente está ou não autenticado;

- Validar se um cliente tem uma sessão válida;

- Validar se uma requisição é oriunda de uma rede válida (essa constraint é validade pelo google music, onde só se pode acessar seu conteúdo em determinados país, no Brasil ainda não é possível);

- Validar se um determinado tipo de navegador é valido ou não;

Observando a conjunção desses padrões, pude constatar que em sites como o google (em todas as aplicações), banco Itaú, Wikipédia, hotmail, dentre outros. Nesses sites, uma versão mais enxuta é disponibilizada no browser, somente com conteúdo e em alguns casos sem os banners de patrocinadores. O tempo de resposta para o google reader, foi muito superior ao mesmo utilizado no Chrome. O resultado disso, é que estou ganhando mais tempo na leitura de feeds de tal dispositivo.

No banco Itaú, pude ter acesso a consultas de faturas de cartão de crédito anteriores, com poucos toques na tela. A informação foi exibida de uma forma similar ao navegador tradicional e muito mais rápido.

Existem alguns sites que deixei de acessar via celular, pelo fato de não serem providos de tais recursos de gerenciamento de conteúdo. O tempo de renderização da tela sai dos padrões de resposta por ter um tempo muito excessivo, páginas contendo mais de 2MB (dois mega bytes) de tamanho devido às imagens que o contem.

Nesse estudo foi focado em conteúdo publico na internet. Agora já imaginou isso em conteúdo corporativo? Onde um colaborador precisa exercer suas atividades, por exemplo, em coleta de dados em pátio de produção? Será que os projetos para dispositivos móveis serão continuados na empresa?

O dia em que o processo falhou

Para tudo na vida definimos algum tipo de processo. Processo pela definição literal do Aurélio, “é um conjunto de papeis relativos a um negócio” e que pode ser aplicado a qualquer tipo de seguimento de trabalho, software, administrativo, jurídico, etc.

Para Sommerville o processo de software consiste em atividades e informações associadas que são exigidas no desenvolvimento de um sistema de software (Sommerville, 2003). Logo uma das partes mais importantes para a correta definição e manipulação de um processo é a informação.

Tal informação é trafegada por diversas camadas e definidas pelas atividades que cada pessoa exerce no sistema. E o mais importante que em um processo de qualidade são as formas com as quais uma informação pode se transformar.

Depois de entender um pouco mais sobre processos, chegamos ao momento automatizar uma parte das atividades, tornando-as mais ágeis e menos suscetíveis a falhas. Uma automatização sempre se dá através de máquinas ou programas. Quando a automatização se processa através de software, deve-se pensar em primeira instancia nos papeis que os atores exercem em um processo, assim a definição do workflow da informação fluirá mais fácil. Vale ressaltar que o foco do processo sempre está direcionado a qualidade do andar do negócio, não se constrói falhas, furos ou mesmo lacunas no processo.

Na construção da automatização de um processo, pode-se escolher (comprar) frameworks já prontos onde pode-se utilizar ipsi litem, customizar esse framework ou mesmo criar um novo baseado no correto entendimento do negócio. Os passos básicos que não se pode faltar nesse framework são: Comunicação, Modelagem, a Construção e a implantação. Quando se constrói alguma coisa cujo negócio não faz parte do nosso dia a dia, devemos adotar a pratica da boa comunicação, uma boa comunicação pode eliminar falhas de entendimento o que pode causar conflitos, pode também gerar compromissos e se gerenciado por uma coordenação, estimula e intermédia a percepção dos interlocutores do processo e facilita a Cooperação nas tarefas executadas no processo. Esse modelo 3C (Figura 1) é detalhado em (Borghoff and Schlichter, 2000).

Se um processo for seguido sempre a risca, isto é, nunca há desvios, exceções ou falhas, nesses casos deve-se sempre mensurar, com periodicidade, a execução das atividades do processo de negócio. Quando se codifica um procedimento não há possibilidades de burlar, manipular, alterar o fluxo das atividades bem como as informações que são imputadas pelos atores do negocio. Essas medidas são eficazes, pois sempre a desvios do fluxo normal de uma atividade. Exceções acontecem, são esperadas, não são freqüentes, mas existem.

Construído, testado e implantado o processo automatizado vive seus dias em produção e passa a cada dia por provas que nem sempre foram levantadas em tempo de projeto.
Vejamos agora se esse processo automatizado for para um negocio de segurança predial. Há um fluxo de cadastro de pessoas, entradas de dados diversos, gerencia de informações, controle de hardware, liberações que dependem de cadastros x dados informados que podem estar relacionados com horários, estatísticas, periodicidade de entradas e diversas outras regras envolvidas nesse processo que aparentemente é muito simples: entrar com nome e CPF sair com a liberação de uma catraca.

Analisando em primeira instância, uma boa segurança patrimonial se torna morosa, pela quantidade de variáveis que devem se validadas para uma simples ação. Essa morosidade é compensada quando seus gerentes conseguem rastrear todas as informações de entrada e saída de pessoas em estabelecimento com processos automatizados. Em segunda instancia já identificamos uma falta de agilidade no processo quando, por exemplo, uma pessoa não cadastrada precisa entrar no estabelecimento para uma reunião emergencial e sua atuação é crucial para o negocio da empresa, mas como o processo é altamente seguro, exige um cadastro de pelo menos 24h de antecedência, a fim de liberar seu acesso.

Para esse tipo de problema a solução é bem simples:
1 – Criar o fluxo de exceção no sistema e fazer o redeploy;
2 – O Gerente do processo mandar entrar fora dos cadastros e fluxo de atividades descritos no sistema.

Mas é claro que a primeira solução é a mais recomendada. Pois com ela é possível a rastreabilidade das exceções que ocorrem no processo, porem essa solução se torna ainda mais morosa que o simples fato de liberar a entrada de uma pessoa às dependências da empresa. Agora imagina que essa segunda ação é tomada contra uma empresa de segurança patrimonial? O que pode gerar? Desconforto aos envolvidos, irritação por parte dos atendentes, a não correção do processo por aqueles que definem tais regras de acesso, tempo despendido para liberar o acesso até a tomada da ação.

Conclusão

Não se executa mais nenhuma tarefa sem que as informações sejam cadastradas, cruzadas, medidas e analisadas manualmente. Processos automatizados que não contemplam fluxo de exceções são geralmente mais lentos que os manuais, pois todo desvio num processo manual pode ser simplesmente contornado na hora, podendo não haver uma rastreabilidade desse desfio. Um processo que tem a cada passo um fluxo de exceção pode ser que não seja in totum seguro.

Para que um processo automatizado seja equilibrado, deve-se pensar em todas as alternativas cabíveis: quais atores irão utilizar o sistema, alguns fluxos de exceção que não altere a segurança, desempenho ou a modularidade do processo.

Referências:

Borghoff, U.M., Schlichter, J.H. 2000. Computer-Supported Cooperative Work: Introduction to Distributed Applications. Springer, USA

Sommerville, Ian. “Engenharia de Software”, Addison Wesley, São Paulo, 2003.

Custo efetivo da falta de qualidade.

Há algum tempo venho dizendo que qualquer pessoa que nunca passou pela cadeira dá área de Ti se alto intitula: Programador, Analista e Arquiteto. Acredito que esse último é mais um status do que capacidade de realização, bem não vou discutir isso aqui. Sem discriminação ou preconceito, mas o que mais vejo nessa estrada é um pouco de descaso com a qualidade em detrimento do marketing.

Falando em estrada, e a computação nada mais é que a resolução virtual de um problema real pode-se comparar programas de computadores às rodovias estaduais e federais. Uma boa rodovia é aquela onde é definido o tipo de solo a fim de se preparar o mesmo para que, por exemplo, passe o asfalto, a região onde será construída a rodovia, medição e identificação através de curva de nível onde será tirado ou depositado mais material (solo) para nivelamento, diminuição do trajeto e custo da obra. Disponibilização de maquinário apropriado e muitos outros fatores para o sucesso dessa obra. Mas tudo isso e bem antes foi definido a equipe qualificada para o correto desenvolvimento do projeto: Engenheiros: que não se resume em um único engenheiro civil, técnicos de estrada, laboratoristas que efetuam diversos testes antes, durante e algumas vezes depois da estrada pronta, gerentes do projeto e outros.

E o que fazer quando não se encontra profissionais qualificados para execução dessa tarefa? Subcontrata uma empresa com profissionais qualificados para essa tarefa ou treina a equipe ou simplesmente executa com o que se tem.

O caso acima nada mais é que uma construção de rodovia, mas se analisarmos bem e compararmos com nosso cotidiano, podemos identificar com a construção de software que fazemos todos os dias. Vamos pelo caso de sucesso.

A empresa contratada tem uma equipe qualificada, treinada e com vasta experiência na empreitada. Qual o produto que irão entregar? Uma rodovia plana, segura, confiável onde os carros poderão realmente exercer a velocidade máxima estipulada pela legislação de transito corrente, possibilidades de duplicação sem ter que destruir tudo para duplicar, etc. Isso tudo seria uma maravilha, mas como isso algumas vezes não é realidade o que vemos? Estradas que ao passar o tempo cheias de buracos devido a carga excessiva de carros e caminhões que todos os dias passam por elas, asfaltificação não adequada ao tipo de solo ou mesmo não compactado para receber tal carga, diversas emendas por causa de reformas ou passagem de tubulação tanto energia quanto dutos de gás. Nesse caso o mais correto seria a reconstrução de um trecho da estrada pois não existe emendas no asfalto e muitos outros problemas que vemos no dia a dia. E qual a solução se dá a esses problemas? Uma delas é a operação tampa buracos, logo já sabemos o que vai ocorrer daqui alguns tempos que esses buracos que foram superficialmente tampados.

Agora voltando a computação, em um caso de sucesso de projeto, temos produtos confiáveis, performáticos, completos, robustos, seguros, de fácil manutenção, que quase nunca é gerado incidentes, problemas e seus releases são de evoluções. Esses tipos de projetos com certeza foram rentáveis aos seus idealizados: Contratante e Contratada. Mas o que na maioria das vezes vemos? Produtos mal acabados, de péssima qualidade, problemas de disponibilidades, não rastreáveis, baixo desempenho, e o pior: índice alto de incidentes, recorrentes, problemas, mudanças, cobranças internas e externas, especialistas em trecho de código, desmotivações, stress.

O desfecho dessas construções se dá a capacidade de realização de cada profissional na retirada e preparação do solo na peneira ou refino dos casos de usos, na capacitação da equipe ou a busca do alto conhecimento em fontes confiáveis. Mas o grande problema de não seguir um padrão é o custo excessivo na construção e em seguida na sustentação do mesmo. O não investimento em qualificação profissional acarreta iterações não findadas de projetos de TI e sempre voltando ao custo de manter pessoas e software. Mas aos caros da área, o que vai sobrar é a experiência, como já dizia a máxima: “conhecimento nunca é demais”. Se você participar de projetos que sempre tem final feliz, esse será o seu melhor marketing, e isso só se consegue através de vivencia, estudo e a capacidade de aprender com o erros.

Até a próxima.

Leonardo Marteleto