Quem possui razão?

Para quem produz Software, problemas com o cliente são comuns. Quando se está em uma empresa onde o cliente é interno, ou seja, quase “do lado”, os problemas tendem a piorar. Existem diversos tipos de problemas, como as clássicas divergências entre o que foi pedido e o que está sendo entregue, mudanças bruscas de escopo, etc.. etc.. etc..  mas, gostaria de ressaltar um outro tipo de problema, que se chama comodismo. Sim, comodismo. Por natureza, as pessoas (usuários finais ou não) são preguiçosas e não gostam de pensar, consequentemente, transferem a responsabilidade com muita facilidade. Se eu sou obrigado a saber algo, mas alguém que está do meu lado também sabe, é mais fácil eu sempre perguntar a este do que gastar tempo aprendendo. Alguns podem pensar que isto não é problema, mas imagine um simples cenário, onde você possui um sistema em produção, com 200 usuários. Obviamente, se este sistema está estável, você estará em outro projeto, com prazo (quase sempre curto). De repente, um telefone toca, alguém te pergunta como faz algo. Respondida a pergunta, podemos voltar à concentração, mas, 10 minutos depois, o telefone toca novamente, com outro usuário questionando algo. Passados outros 10 minutos, outro usuário aparece na sua mesa. Algum tempo depois, você recebe email de um gerente culpando seu sistema por não funcionar direito, consequentemente este não consegue atingir suas metas. Já chegamos a escutar do usuário final que, toda vez em que o gerador de energia da empresa é ativado, os preços no sistema sobem. Enfim, eles possuindo razão ou não, vão tentar ao máximo empurrar a responsabilidade para quem fez o Software, consequentemente, isto se transforma em um loop infinito de palavras, ou seja, um jogando a responsabilidade para o outro e a empresa perdendo dinheiro. Como resolver?

Para quem desenvolve sistemas, com cronograma e prazo, suporte ao usuário final é como pedra no sapato, que precisa ser eliminada a todo custo o mais breve possível. Quanto menos suporte, melhor, porque, quando o prazo estourar, ninguém vai levar em consideração essas horas que você gastou tirando dúvidas e tentando provar por A + B que o sistema está funcionando. Então, vamos atacar os problemas.

A primeira coisa que deve ser ententida é que, se o cliente transfere a você a responsabilidade de responder dúvidas sobre o sistema, ele está usando isso porque possui saída para seu comodismo, ou seja, ele possui opções. Restringir opções é uma ótima solução para este problema, ou seja, transfira esta responsabilidade de volta, padronizando páginas de help na aplicação.  No meu atual trabalho, já discutimos N formas de se fazer isso. Alguns analistas costumam enviar docs explicando as funcionalidades, outros enviam links do wiki, mas, acredito que, o mais certo é que o help esteja acessível na própria tela do sistema em que o usuário esteja trabalhando. Se uso Word e tenho uma dúvida, não vou entrar no site da Microsoft e procurar a dúvida, gostaria de um help na própria tela sanando minhas dúvidas. Por isso, foi criado um template padronizado conforme figura abaixo

Simples não? Pois bem, esta simplicidade óbvia nos resguarda de um monte de problemas.  Primeiro porque, todas as telas das novas aplicações possuem este botão, padronizando o help, ou seja, facilitando para o usuário final o acesso, pensando o menos possível onde e em qual lugar estaria o dito cujo.  Segundo porque, quando o usuário final te ligar, você atendendo ou não, respondendo ou não, a existência do help te garantirá a razão, que é o mais importante. E a razão só é perdida quando este dizer que a dúvida não existe no help, portanto, atualize o help  e peça-o para olhar novamente.

Esta simples iniciativa transfere de volta a responsabilidade para o usuário final. Para que se desgastar, falar mal e fazer piada disso em buteco? Faça-o pensar um pouquinho, todos possuem capacidade para isso (somos todos seres humanos, acho).

O segundo ponto, é com relação à muleta. Muleta? Sim, sistemas críticos são sérios candidatos a servirem de muletas para profissionais incompetentes. Pense bem: se você possui um sistema de vendas, onde um funcionário possui a meta de vender X, e vende menos que isto, consequentemente não recebendo a sua premiação, vai procurar culpar algo/alguém. E adivinhe quem é o primeiro candidato?

Sim, você! Seu sistema será severamente acusado de não funcionar direito. Como se resguardar disso? Acho que, a primeira coisa a se fazer, é criar logs apurados. Existem pessoas que gostam de dizer “1 linha de código, 1 linha de log”. Não sei se precisa chegar a este ponto, mas se for necessário para garantir a auditoria, está valendo.  É difícil prever todas as possibilidades de comportamento de um sistema em fase de teste. Pode-se mapear 99.9999% dos casos, mas sempre, em ambiente de produção, vai acontecer com 1 em 1 milhão de clientes algo que não foi previsto com antecedência.  E este “1 cliente” é quem vai jogar a moral do seu sistema lá embaixo.  Trabalhar com uma auditoria pesada, seja em logs, aspectos para mapear operações no banco, não vão te impedir de erros em produção, mas vão fazer algo muito melhor: te mostrar a causa raiz do problema! Como é bom resolver um problema na raiz para que não ocorra mais, certo? E como vemos desenvolvedores executando “tapas” em bancos de dados, resolvendo problemas temporariamente, ou colocando workarounds, como dizem (antes que me chamem de hipócrita, sim, eu já fiz isso). 

Este trecho do log é utilizado pelos atendentes do 0800 para rastrear todo o ciclo de vida de um pedido, e, quando este não é suficiente para encontrar a falha, nos repassam o problema, para analisarmos outro nível de log, mais técnico. Neste exemplo, são 11 comandos de log que o 0800 consegue ver. No segundo nível, se transforma em mais de 30 comandos, para sabermos exatamente o que aconteceu e, consequentemente, resolver o problema na raiz, ao invés de adotar soluções temporárias. Caso seja apurado que não existe problema, o log será utilizado para nos resguardar, ao invés de transformar tudo em um jogo de palavras, onde a corda fatalmente será arrebentada no lado mais fraco

Problemas com o cliente sempre existirão, mas, dentre os males, é melhor reduzir ao máximo os atritos. Cliente bom é cliente que consegue desenvolver seu trabalho sozinho, mas, para isso, precisamos fornecer as ferramentas e nos resguardar das muletas.

About CarlosEduardoXP

Especialista em desenvolvimento de Sistemas Distribuídos, sempre aplicando boas práticas e padrões difundidos na comunidade. Auto didata, fanático por refatoração e performance, sempre buscando reutilização e testes automatizados cada vez mais eficazes.
This entry was posted in Software Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s