Percepção do Trabalho de Arquiteto de Informação

O mercado de Tecnologia de Informação (TI) brasileiro tem um problema. Este problema não é de estrangulamento, não é mercadológico, assim como não é da falta de especialização profissional. Há muito percebe-se que o foco das empresas de TI tem sido a resolução de problemas de uma forma desordenada, rápida, produtos entregues em um processo que visa mais a impressão momentânea do cliente do que a qualidade. Impressão sim, pois os bons resultados só acontecem nos primeiros dias de uso para depois serem descobertos erros básicos, muitas vezes pela falta de planejamento ou ignorância das necessidades, modelo mental e outras características do público-alvo e/ou da tarefa e regras de negócio.

O mais triste é escutar que estes erros eram previstos pois "o que o cliente percebe é a velocidade de entrega", ou seja, há um conhecimento prévio de que as coisas vão dar errado e serão refeitas diversas vezes (o famoso refactorying), o código será refeito e rearrumado, a modelagem UML refeita, o design modificado e arquitetura de informação só será avaliada com o produto pronto. Pior que depois da análise de arquitetura, você ainda irá escutar: "- Concordo, mas agora não dá para voltar atrás, não dá para refazer esta parte do código, não dá para colocar esta informação.", entre outras frases célebres que permeiam o desenvolvimento caótico onde se quer construir o sobrado da casa antes das fundações e depois sai mais caro consertar do que fazer de novo.

O mais perigoso é a má interpretação de modelos estrangeiros como Agile, Scrum e outras técnicas que, aqui, são aplicadas através de uso literal, inflexível, quase que como uma receita de bolo. Como toda receita de bolo na cozinha de um Chef, a receita ou é seguida sem reflexão, ou é alterada ao bel prazer sem se medir as consequencias. Já pude até escutar de um amigo que a metologia scrum que utilizávamos em outra empresa era "meia-boca" uma vez que na outra empresa percebeu-se que a interpretação do material de estudo não estava correta, o que gerou a criação de um próprio processo scrum interno, adaptado à dinâmica dos projetos, pessoas e empresa. O processo chamado de "meia-boca", depois de 01 ano de insistência, passou a considerar a arquitetura de informação e o design como partes essenciais do projeto, sendo que os profissionais de TI já estavam começando a compreender o efeitos destas disciplinas no sucesso dos produtos.

As características multidisciplinar de atividades como design, arquitetura de informação, ergonomia, até mesmo a arquitetura de prédios, casas e interiores, faz com que todos de fora tenham uma opinião sem terem base científica ou de mercado. contando apenas com o "achismo". Ninguém pede a um médico que coloque o coração mais para o lado direito, ou que um engenheiro civil deve colocar a coluna na lateral e não no meio do teto.

Por que para estas outras profissões há uma vontade do palpite enquanto que para outras isto não existe? Por que não há a percepção de que existem pessoas que estudaram, possuem conhecimento avançado naquelas áreas e podem elucidar e pensar problemas que você não percebe? Por que falta a percepção que isso pode significar perda de dinheiro, de público e o crescimento da concorrência?

Isto inclusive afeta o nível salarial de arquitetos e designers que em alguns casos são muito mais especializados do que alguns desenvolvedores nas empresas (ou a hora no mercado freelance). Ah, arquitetos podem ser designers, desenvolvedores, analistas, psicólogos cognitivos, ou seja, a formação básica não tem relação com a especialização, talvez apenas com o foco.

Esta introdução abre uma série de textos que irei trazer para o blog sobre arquitetura da informação que podem servir como banco de argumentos a quem trabalha com arquitetura e design. A arquitetura de informação, ao lado do design, talvez sejam as áreas mais mal-interpretadas no mercado de TI. Não sei dizer se pela falta de compreensão ou se pela visão ensinada nas faculdade e cursos de informática, mas a racionalização de processos e os "achismos" tendem a sumir com a geração de profissionais mais jovens, principalmente pela introdução da usabilidade nas faculdades de tecnologia.

Uso também este espaço para defender a engenharia. A arquitetura de informação e usabilidade se originou na engenharia de produção na ergonomia. A engenharia de usabilidade visava a análise do uso de interfaces de máquinas, tanto em displays quanto de interfaces físicas (alavancas, botões, pedais, manuseio fino, etc.). Fiz mestrado em engenharia e portanto posso afirmar que em 90% dos casos (minha experiência) os engenheiros ainda conseguem ter a cabeça mais aberta em termos de processo do que os profissionais de informática.

Os textos não visam atacar a informática brasileira visto que tenho muitos amigos, profissionais de TI, que compartilham da minha visão. O principal é trazer informações a partir de livros e artigos que li, conversas com profissionais, palestras e congressos, para que este trabalho sirva como conscientização e reflexão do porquê é tão difícil para as empresas de TI brasileiras inovar, planejar, pensar, refletir e trazer as regras de negócio e o próprio usuário para mais perto da construção dos produtos.

Roma não foi construída em um dia, e nem um sistema de sucesso será construído em dois dias, uma semana, três meses. Faça seu planejamento ser real para que qualidade real seja atingida. Não trate a arquitetura de informação e o design como etapas inúteis ou como a fase que deixará seu produto "bonitinho", pois elas talvez sejam a parte mais importante para o seu usuário e para que você consiga competir contra produtos concorrentes que vão roubar a sua idéia e melhorá-la. Arquitetura e design são justamente as etapas que você não deve tentar acelerar, fazer de qualquer jeito ou cortar do projeto.

Nota, é papel do profissinal de arquitetura de informação e do designer tornar sua documentação compreensível a qualquer profissional envolvido com o projeto, inclusive o cliente. Se materiais como wireframes, fluxos de tarefa, mapas do sistema, mapas mentais, e outros "entregáveis" não estiverem compreensíveis, exija da sua equipe ou contratado que o material seja mais esclarecedor e menos técnico, mas da mesma forma detalhado, sem perder informações por simplificação. O bom profissional é aquele que consegue explicar o que faz para uma criança de 7 anos e ela entende.