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.
Ótimo artigo.
Vamos manter isso sempre em mente, para desenvolvermos casos de sucesso.
Obrigado,
Gostei bastante do post, e concordo inteiramente com você acho que existem muitos softwares que acabam e dificultando a vida do usuário e atrasando suas tarefas, o que causa o não atingimento dos objetivos primordiais de um sistema que é ser um solução e não mais um problema para se trabalhar.
Já passei também por uma situação semelhante, mas em cima de um outro fator chamado tempo, no caso, a pouco tempo um cliente estava necessitando de um site com um conjunto de dados a serem postos no mesmo baseado nos dados de outro sistema, no caso uma quantidade absurda de dados, antes de eu chegar a empresa, um conjunto de “web designers” (com excessão do últim web designer que de fato era competente) estava fazendo este trabalho de todo caso estava sempre observando o absurdo trabalho que estavam fazendo e pensava comigo mesmo: “que é isso que eles fazendo?”, até que um dia pois de três meses após eu estar na empresa (aquela aberração deles girava dois anos) propus que se fazendo um sistema de data scrapping poderia amenizar parte do problema, enquanto que a outra parte poderia ser feito com um pequeno sistema de gestão para caso eles cadastrem outros produtos.
E o chefe lá vendo que isso pouparia trabalho então aceito que eu construisse o sistema, de fato fiz um sistema muito simples e direto ao ponto de forma que o cliente facilmente usaria sem stress, fiz um script de data scrapping que capturou todos os dados do outro sistema (cerca de mais de 4000 produtos) com excessão de imagens e alguns textos de sub-links por não haverem padrão de captura o que poderia resultar em uma série de conflitos, fora os downloads absurdos de um conjunto de arquivos que com certeza era um trabalho que não compensaria adicionar, assim fiz com que o script capturasse apenas os dados mais importantes e mais padronizados deste material o que de fato era a solução para o problema do cliente, entretanto como essa fora apenas uma solução recente e que de fato o problema era de longo tempo, fez com que ficasse os web designers não mais adicionando conteúdo html para o site, mas pegando imagens e cadastrando no sistema, pelo menos não precisam me chamar para tirarem duvidas sobre o mesmo já que é fácil demais.