O limite entre o Desenvolvedor e o Usuário

AGRADEÇA AO AUTOR COMPARTILHE!

Olá, leitores!

Vocês se recordam dos artigos sobre em quem colocar a culpa quando um bug é encontrado no software? Pois bem, pode-se dizer que a publicação de hoje é uma extensão desses artigos, porém, direcionado para uma abordagem mais técnica. Vamos discutir sobre algo que só existe no ramo de desenvolvimento de software: o usuário do sistema.

Calma, não vou dizer no artigo que o usuário do sistema é o culpado pelos erros e falhas que são reportados. Pelo contrário, o usuário apenas usa o nosso software e, assim como qualquer outro produto, ele espera que não existam defeitos. Já trabalhei e conversei com desenvolvedores que não gostam dos usuários por causa das operações “inválidas” que eles costumam realizar no software, mas, pensando bem, estes desenvolvedores deveriam repensar o próprio trabalho e rever os seus conceitos de qualidade de software.

arguing

Ficou intrigado? Acompanhe o exemplo abaixo.

Vamos supor que o software que estamos desenvolvendo seja parametrizado, ou seja, o usuário tem acesso a uma tela de opções (ou parâmetros) para personalizar o comportamento do sistema conforme o perfil do cliente. Considere que um destes parâmetros se refere ao valor mínimo da parcela de uma venda. Todas as vezes que uma venda é cadastrada, o sistema compara o valor da parcela com o valor definido neste parâmetro e, caso seja menor, uma mensagem de aviso é exibida, informando que o parcelamento não é aceitável. Ótimo! Essa é a regra!

No entanto, não moramos em um mundo perfeito. Eis que, em um dos clientes, o usuário definiu o valor mínimo da parcela como “R$ 500,00″. Sim, digitando o “R$” antes do valor! Ele simplesmente não sabe que não é necessário informar o símbolo da moeda, já que o sistema trata devidamente os valores monetários. Pois bem, ao cadastrar uma venda, o sistema irá validar o valor da parcela com as letras “R$” que estão no parâmetro e… boom! Um erro estoura na tela, criticando que “R$” não é um valor monetário válido ou que houve um erro de conversão. Além de interromper o cadastro da venda atual, o problema irá também impedir vendas futuras, tornando o software inoperante. Grave, não?
Confuso, o usuário entra em contato com a empresa de desenvolvimento reportando a falha. Durante a rastreabilidade do erro (através de monitores de exceções ou logs), a equipe identifica que a falha está no valor definido no parâmetro e não pensa duas vezes para reclamar:

Esse usuário não sabe usar o sistema! Aonde já se viu definir o valor mínimo de uma parcela com o símbolo de moeda? Nunca usou um sistema antes?

Meus amigos, como desenvolvedor de bom senso, eu retruco a pergunta acima com outra questão: Por que o seu sistema permitiu que o usuário digitasse letras em um campo que se refere a um valor numérico?
Na minha opinião, isso é uma falha do software, e não do usuário. Se o sistema não possui as validações necessárias, ele não atende as condições de integridade que, na verdade, é um dos requisitos não-funcionais de um software de boa qualidade.

Para facilitar, vou usar uma analogia. A maioria das cafeteiras elétricas atuais suspendem o funcionamento se o recipiente de água estiver vazio, evitando que o equipamento queime. Porém, os modelos antigos não possuíam essa “validação”, portanto, caso o consumidor ligasse a cafeteira sem colocar a água, ela queimaria. Neste caso, de quem seria a culpa? Do consumidor, que não soube usá-la, ou dos fabricantes, que não adicionaram um mecanismo para evitar este evento? Vocês devem concordar que, com esse mecanismo de verificação da água, o número de equipamentos queimados seria reduzido e, consequentemente, haveria menos reclamações e produtos para troca, não é? No desenvolvimento de software é a mesma coisa! Quanto mais íntegro, menos problemas.

Acredito que você já tenha escutado essa frase:

O usuário é capaz de tudo, então vamos implementar o maior número de validações possíveis!

Eu concordo, mas com uma ressalva: a intenção dos usuários não é “descobrir” problemas no software. Eles são apenas consumidores dos nossos produtos que, em sua grande maioria, não possuem conhecimento técnico para adivinhar que um valor inválido atribuído a um parâmetro irá gerar uma exceção no cadastro de uma venda e travar o software. Isso significa que, a próxima vez que você receber uma comunicação de um erro, reflita que, se o erro ocorreu, é porque o software tem uma falha. Tais falhas são oriundas da ausência de validações, restrições e tratamentos, então, são de responsabilidade nossa e deveríamos nos desculpar pela inconveniência.

Leitores, lembrem-se sempre de considerar todo tipo de validação ao desenvolver uma funcionalidade do software, mesmo que elas raramente aconteçam. Por exemplo, no cadastro de clientes, um desenvolvedor pode pensar: “Não é necessário validar o nome do cliente em branco. O usuário nunca deixará de preenchê-lo!”. Negativo! A validação deve existir, sim! E não é nem por questão de irresponsabilidade ou por má fé do usuário, mas é pela integridade e confiabilidade do software caso este campo deixe de ser preenchido por algum motivo.

Por outro lado, quero deixar claro que não estou dando a razão absoluta para o usuário do sistema. Algumas vezes, estes usuários solicitam a alteração ou inclusão de funcionalidades que não fazem sentido no contexto de negócios ou são muito complexas a nível técnico. Neste caso, é necessário, sim, apresentar objeções, informando-os sobre as desvantagens, impactos e inconsistências dessas funcionalidades, buscando pelo equilíbrio destes requisitos.

Bom, espero ter transmitido a ideia!

Abraço!

AGRADEÇA AO AUTOR COMPARTILHE!

André Luis Celestino

Mais artigos deste autor »

Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Analista Implementador Delphi em Florianópolis.


3 Comentários

Aurélio Guedes
1

Acredito que um software auto instrucional resolveria a maioria os problemas relativos à publicação.

Jeferson Batista Sobczack
2

André, parabéns pela clareza!

Concordo com o seu ponto de vista.
Acreidto que independente do tamanho do sistema, ele deve ser pensado/executado com no mínimo, validações que garantem a sua confiabilidade. Desta forma é possível evoluir o sistema (naturalmente) sem ficar preso a problemas antigos para o ‘resto da vida’ dele. Sem contar que o cliente acaba sentindo confiança e não entrando no ciclo vicioso de culpar o sistema por qualquer erro (que infelizmente na maioria das vezes tem razão rsrs).

André Luis Celestino Autor do Post
3

Olá, Jeferson!

Muito bom o seu comentário! Se fosse possível, adicionaria a sua opinião no texto do artigo.
Já trabalhei em alguns sistemas que possuíam a chamada “divida técnica”, termo utilizado para problemas e defeitos introduzidos há anos e que nunca receberam atenção para serem sanados. Por consequência, essa dívida gerava vários incidentes e queixas por parte dos usuários, entrando no ciclo vicioso que você comentou.

Obrigado pelo comentário! Abraço!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">