Armadilhas: o desenvolvedor interface

No dicionário kiconiano acabo de incluir um novo termo: desenvolvedor interface, cuja definição é:

“desenvolvedor que acidentalmente acaba se tornando a interface dos seus sistemas”

Esta é uma situação comum em empresas nas quais TI é um meio e não um fim: ocorre quando os realmente interessados pelo resultado final de um sistema (normalmente relatórios) não o utilizam diretamente, mas sim através daquele que o desenvolveu.

Você sabe quando esta situação ocorre ao ouvir frases como “ei Fulano: será que você pode enviar para o meu e-mail o relatório X?” e este não é um novo tipo de relatório, mas sim aquele que o usuário precisa esporádicamente já faz algum tempo.

No frigir dos ovos, o que ocorre é a inclusão de uma nova camada no sistema: o desenvolvedor, tal como no esquema abaixo:

O desenvolvedor deixa de ser o profissional responsável por desenvolver e criar soluções e passa a ser mais uma camada do sistema: a sua interface. É fato: o cliente sempre quer o resultado final, porém ao cair neste tipo de situação, o que obtém é muito mais caro que o inicialmente proposto (afinal de contas, o “tal do sistema” não funciona sem a presença do “desenvolvedor”).

Já passei por uma situação similar (e vejo alguns companheiros passando pela mesma) e, após me concentrar nas questões abaixo, fica nítido que ao menos em 90% dos casos a culpa é nossa.

Pergunte-se:

Você tem certeza de que seu software é fácil de usar?

Muitas vezes o produto gerado é tão complexo que o usuário final fica com medo de se aproximar. Lembre-se: o que é fácil para você não necessáriamente o é para o resto do mundo.

Fórmula kiconiana: software difícil = atividade tediosa = mais um desenvolvedor que vira interface.

Seu usuário sabe usar o sistema?

Resolvida a primeira possibilidade, segue a segunda: será que você treinou o seu usuário corretamente? A documentação do seu sistema é legível para seres humanos comuns (leia-se: que não trabalham na área de TI)?

Seu sistema é de fato confiável?

Ponha-se na situação do seu usuário. Ele sabe usar o seu software, que considera até agradável. Porém, ao tentar executar determinada tarefa, se depara com uma mensagem de erro (claro: sempre no pior momento possível). O primeiro pau do seu software após ter sido homologado destrói 70,837373% da confiança inicial.

Caso o problema não seja resolvido efetivamente e rápido, o usuário se sentirá mais confortável pedindo a você utilize o software em seu lugar (e neste caso, é inclusive sua obrigação).

Pior: imagine que os resultados obtidos estejam errados. Neste caso, além  de gerar os resultados para seu cliente, terá também de comprovar a validade dos mesmos! E acredite: não será uma única vez.

Foi criado um sistema ou uma gambiarra?

Eis a pergunta desagradável. Normalmente o “sistema” é na realidade aquela “rotina” ou “macro” feita para suprir uma necessidade de momento que se tornou periódica. De fato: seu usuário não é obrigado a saber como executar scripts ou macros do Excel. E a solução é simples: transforme a gambiarra em sistema.

Além do questionamento

Acredito que um fato simples normalmente é ignorado por muitos desenvolvedores interface: quanto mais independente um sistema for do seu criador, maior o grau de satisfação do seu cliente. Sei que parece incrível pra muitos, mas já ouvi diversas vezes de alguns pilantras desenvolvedores que se o cliente não estiver preso, não há como garantir o próprio sustento. Eita falácia! Software bem feito requer menos manutenção, que torna seu cliente mais feliz, que o indicará para outros trabalhos. Simples assim.

O desenvolvedor é uma interface sim: entre a idéia do cliente e a geração de uma solução para a mesma. Uma coisa é criar soluções, outra se tornar um botão.