Uma provocação aos implementadores de programas de computador

Você, profissional implementador, ou trabalha com a geração de código de programas de computador ou tem sua mesa muito próxima de alguém que faz isso, ou que especifica o que deve ser feito, não é verdade?

Então, aqui vai uma pergunta: você já conversou com alguém que usa o código que você escreveu? Ou a soma dos códigos escritos por todos que virou um aplicativo, um sistema informatizado?

Vamos deixar essas perguntas no ar, por alguns momentos, e vamos a outras, onde você é o usuário. Responda rápido:

Você sabe qual o sistema operacional de seu celular? Se sabe, você optou por ele por causa do sistema operacional ou da linguagem de programação? E de suas funcionalidades, você usa qual percentual? Quais você não usa por dificuldades de navegação, ou de velocidade de acesso?

Você escolhe um banco por causa da arquitetura de seu sistema de internet banking? Aliás, você sabe qual é a infra que seu banco possui?

E o software embutido em seu aparelho de DVD ou mp3 player? Foi decisivo na hora da compra?

Então… com base nessas suas respostas, pense nos nossos clientes finais, aqueles que vão usar o código que fazemos. Além de, por óbvio, estarem com zero erro, sem faltar nada, ele deve ter bom desempenho, não pode travar, fazer aquilo que foi descrito nas especificações (e mais um pouco também) e, especialmente, ser atrativo, agradável ao uso.

Experiências globais com usuários de internet mostram que a média de cliques por site acessado é de 1,15, ou seja, a maioria dos usuários abre a página principal e vai embora.

Mesmo os sites mais visitados, uma boa média é de 2 acessos por visita.

Considerando que as modernas aplicações são baseadas (ou deveriam ser) nos princípios da navegação por browser, é provável que um fator crítico de sucesso esteja na facilidade de navegação entre as diversas páginas ou funções do sistema. Será que o software que está sendo codificado neste momento leva isso em conta?

Outra coisa que é mais antiga, mas não menos importante, e cito aqui o grande poeta e compositor, por vezes diplomata, Vinícius de Morais: “As feias que me perdoem, mas beleza é fundamental”.

Mesmo supondo que ele escreveu isso numa época em que o politicamente incorreto era a voga, e indo direto aos aplicativos, será que cuidamos adequadamente da apresentação, da beleza, da arte?

Tudo isso pode parecer irrelevante, desde que entreguemos o código funcionando bem. Mas, numa época onde a concorrência é grande, esses cuidados são fundamentais.

Um artefato que funciona rigorosamente segundo suas especificações não é garantia de sucesso. Décadas atrás, um engenheirado do ITA (Instituto Tecnológico de Aeronáutica) fez como trabalho de graduação uma caixinha que provava exatamente isso. Chamava-se “Nãofazímetro de Porra Nenhuma”. Era uma caixa com uma tomada que, ligada na energia abria-se a tampa da caixa, saia a mãozinha mecânica que pegava o fio e puxava da tomada, desligava o engenho, e a mão voltava à caixa e ela se fechava, exatamente como antes de ser ligada.

O trabalho passou com louvor, por se tratar de demonstrar duas coisas: (1) a possibilidade de fazer a custo baixo um dispositivo de robótica muito sofisticado, seguindo estritamente o teorema de realimentação de Lyapunov e (2) a possibilidade de se fazer algo tecnicamente sofisticado que não serve para…, bem, para porra nenhuma.

O engenheirando tirou nota máxima no trabalho, mais pela sofisticação do seu engenho. Hoje talvez o Nãofazímetro de Porra Nenhuma ganhasse louvor por demonstrar que é preciso gerar utilidade a um produto ou serviço, aliado a confiabilidade, custo adequado e facilidade de uso, tudo isso num ambiente agradável aos sentidos, como tão bem descrevia Vinícius.

Anúncios

4 Respostas

  1. Eu diria (com muito pesar) que em alguns momentos a relação ‘custo x prazo x escopo’ impede que isso aconteça. Não por falta de vontade ou criatividade, mas simplesmente porque tornar um software fácil de usar e agradável aos olhos do cliente, exige tempo e esforço.Como fazer todos esses requisitos trabalharem juntos e em harmonia?

  2. Eu diria (com muito pesar) que em alguns momentos a relação ‘custo x prazo x escopo’ impede que isso aconteça. Não por falta de vontade ou criatividade, mas simplesmente porque tornar um software fácil de usar e agradável aos olhos do cliente, exige tempo e esforço.Como fazer todos esses requisitos trabalharem juntos e em harmonia?

  3. Wellington, o pior é que você tem razão… Muitas (ou quase todas as) vezes, essas variáveis são irreconciliáveis, e o cliente não quer nem saber!Eu diria a você que o jeito é minimizar esses conflitos. Talvez, numa reunião de “kick-off” de um projeto ter gente com experiência em design ou em usabilidade.Mas será que isso é levantado pelos implementadores nas reuniões de kick-off? Eu acho que… nem sempre.Ou melhor, os técnicos (eu tenho essa origem, logo permito me incluir no grupo) seguem separando o “invented here” do “not invented here”, e a percepção de seu modelo como prevalente sobre o modelo do cliente.Isso às vezes funciona bem em um produto, mas não no software sob medida. Mesmo assim, as coisas vão para o lado do usuário (que nome feio damos aos caras que nos pagam a conta, não? ‘usuário’… deveria ser ‘cliente amigo’) de forma inevitável.Veja as interfaces mais populares do momento, as intuitivas: Google, iPhone, Facebook… por aí… a turma se preocupa muito com a parte da usabilidade.Aqui no Brasil, temos um bom exemplo de usabilidade que por vezes faz os clientes mudarem de banco: o internet banking. Pesquisas mostram que, para o perfil de clientes que usam muito o internet banking (e têm bons negócios para o banco) que um fator de peso na fidelidade ao banco está um decente e usável internet banking.Uma pergunta aos implementadores: depois de terminar um caso de uso, daqueles suados, complexos e quase impossíveis, quantos olham para sua obra e sentem o mesmo que Michelangelo diante de sua obra prima: “Parla!” ??Abraço

  4. Wellington, o pior é que você tem razão… Muitas (ou quase todas as) vezes, essas variáveis são irreconciliáveis, e o cliente não quer nem saber!Eu diria a você que o jeito é minimizar esses conflitos. Talvez, numa reunião de “kick-off” de um projeto ter gente com experiência em design ou em usabilidade.Mas será que isso é levantado pelos implementadores nas reuniões de kick-off? Eu acho que… nem sempre.Ou melhor, os técnicos (eu tenho essa origem, logo permito me incluir no grupo) seguem separando o “invented here” do “not invented here”, e a percepção de seu modelo como prevalente sobre o modelo do cliente.Isso às vezes funciona bem em um produto, mas não no software sob medida. Mesmo assim, as coisas vão para o lado do usuário (que nome feio damos aos caras que nos pagam a conta, não? ‘usuário’… deveria ser ‘cliente amigo’) de forma inevitável.Veja as interfaces mais populares do momento, as intuitivas: Google, iPhone, Facebook… por aí… a turma se preocupa muito com a parte da usabilidade.Aqui no Brasil, temos um bom exemplo de usabilidade que por vezes faz os clientes mudarem de banco: o internet banking. Pesquisas mostram que, para o perfil de clientes que usam muito o internet banking (e têm bons negócios para o banco) que um fator de peso na fidelidade ao banco está um decente e usável internet banking.Uma pergunta aos implementadores: depois de terminar um caso de uso, daqueles suados, complexos e quase impossíveis, quantos olham para sua obra e sentem o mesmo que Michelangelo diante de sua obra prima: “Parla!” ??Abraço

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: