Um dos problemas de desenvolvimento do Software, especialmente no Brasil, é o TI-Centrismo.

O TI-Centrismo prega que TI é o centro do Universo. Desta forma, muitas das decisões tomadas no ciclo de vida de desenvolvimento do Software visam “proteger” TI.
- “Não pudemos mudar isso, é padrão de TI!” = TI-Centrismo
- “Não dá para fazer assim, o banco não permite” = TI-Centrismo
- “Não vou deixar meu código feio assim. Deixa essa animação pra lá” = TI-Centrismo
- “Vamos fazer o Café com Leite, senão vai dar muito trabalho.” = TI-Centrismo

Precisamos mudar isso! Precisamos deixar o TI-Centrismo e adotar o Usuário-Centrismo. Pode não parecer mais isso muda muita coisa.

Programadores odeiam código feio. Por outro lado a parte estética da aplicação e as animações são sempre deixados para o final. O problema? Bem, muitas vezes perde-se muito tempo tentando fazer aquela arquitetura super hiper robusta com o super hiper design pattern onde não precisa.

Mas por que a estética, incluindo animação é importante? Porque isso deixa o usuário num estado mental muito melhor. Isso faz com que o usuário:

1. Perdoe erros mais facilmente
2. Tenha maior pré-disposição para aprender a mexer na aplicação

Fizeram uma experiência com dois caixas eletrônicos idênticos em termos de usabilidade e implementação. Um bonito e outro feio. O Caixa mais bonito teve uma avaliação muito melhor do que o caixa mais feio. No Caixa mais feio as pessoas reclamaram muito mais dos erros (propositais) do que no caixa mais bonito. Uma coisa é o usuário bater o olho numa coisa bonita e falar: “Uau… que legal isso. Bem, agora deixa eu ver como eu uso!”. Outra coisa é ele falar “Nossa! Que coisa medonha, como eu uso isso?” O estado mental é tudo. A motivação é tudo. E coisas feias definitivamente desmotivam.

Quando abandonamos o TI-Centrismo e adotamos o Usuário-Centrismo nossa percepção muda. Eu prefiro perder tempo fazendo uma animação que vai agregar mais valor à experiência do usuário do que aplicando aquele super ultra design pattern que li no ultimo livro que ostento na minha estante e que só vai servir para eu exercitar o que aprendi. E isso tem a ver com outra coisa que eu chamo de Tradeoff com foco no valor agregado (assunto para um outro post).

Em muitos casos o TI-Centrismo é como uma religião. Só espero não ser condenado como Galilei Galilei por tentar mostrar que o centro do Universo não é o que os devotos pensam.

Ao adotar o Usuário-Centrismo comecei a me perguntar se os POGs que tanto incomodam os programadores que pregam boas práticas em 100% do Software (TI-Centrismo) são realmente um mal em todos os contextos. Eu ousaria dizer que, no Usuário-Centrismo existe o POG do Mal e o POG do Bem. Imagine que você precisa implementar uma animação em Flex e que, como um bom programador, você tentou fazer da melhor forma possível. Mas não teve jeito! Você vai ter que colocar um Timer para fazer funcionar perfeito (típico POG para resolver problemas de tempo em animações em Flex). Mas você é um programador “bonzão”. Você jamais vai fazer este POG. Então você se recusa. Afinal de contas, para quê animação, não é mesmo? Mas a pergunta é: Tal animação vai agregar valor à experiência do usuário? Sim! O POG vai ser fonte potencial de problemas? Não! O POG vai ser difícil dos programadores entender? Não (nada que um comentário simples não resolva). Então, por que que eu vou me recusar de fazer algo que mais agrega à experiência do usuário do que, de fato, prejudica TI? Porque eu sou adepto do TI-Centrismo. Eu não faço software para o usuário, eu faço para mim. Para o meu ego.

Eu quis manter o diagrama acima simples e por isso o fiz “incompleto”. No caso da complexidade, por exemplo, mesmo que POG pareça “comprometer a complexidade” é preciso colocar isto na balança pois também acredito que não há mal algum em algo complexo, encapsulado e que pouco vai ser mexido. Mais um vez, é o que eu chamo de Tradeoff com foco no valor agregado.

O TI-Centrimo começa nas Universidades ou quando o iniciante está aprendendo a programar. Nesta época, sem experiência e capacidade para julgar, os professores colocam na cabeça das pessoas que a performance do sistema é um problema independente do contexto. Em outras palavras, aprende-se que sempre se deve otimizar um simples “for” (tentar transformar 200 iterações em 100 por exemplo). Aprende-se que se deve preocupar com a performance desde o início. Mas o que não é dito é que código otimizado é mais complexo. O que não é dito é que o gargalo de performance corresponde a um percentual muito pequeno do código do seu software. O que não e dito é que você geralmente não sabe onde está este gargalo e que no final das contas você vai perder muito tempo tentando otimizar código onde não é preciso, adicionando complexidade ao seu código e deixando de fazer outras coisas que agregam mais valor. Isto é TI-Centrismo!

O TI-Centrismo cria tantas restrições para se fazer um bom trabalho que Software de qualidade do ponto de vista do usuário é praticamente impossível. O TI-Centrismo é respaldado (entre outras coisas) pela alienação do programador. Softwares existem porque alguém precisa usar. Este alguém é o usuário. Ele é a razão do software existir. Mas muitos programadores esquecem disto e o seu código passa a ter uma razão de existir em si. Este programador aplica Design Pattern porque ele gosta. Ele aplica boas práticas porque ele gosta. Ele faz código otimizado porque ele gosta. Mas ele não gosta de perder tempo com animação – que as vezes é o que vai agregar valor à experiência final.

Você pode adotar o Usuário-Centrismo e continuar apreciando código bonito e de qualidade. A diferença é que o Usuário-Centrismo vai lhe fazer pensar que o seu código tem que ser bom para lhe permitir fazer um Software cada vez melhor não para você, mas sim para o usuário.

O que jamais podemos esquecer é que fazemos softwares para os usuários. Então ele deveria ser o centro do universo, e não TI.

Este post foi criado quinta-feira, 6, agosto , 2009 às 9:06 am e arquivado sob Crítica, Desenvolvimento, Design, Outbox. Você pode acompanhar as respostas para este post no RSS 2.0 feed. Você pode deixar uma resposta, ou trackback do seu próprio site.