O limite entre o desenvolvedor e o usuário

Olá, leitores! Vocês se recordam do artigo 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 desse artigo, porém, direcionado para uma abordagem mais técnica. Vamos discutir sobre algo que algumas vezes é contestado pelo desenvolvedor: o usuário do sistema.

Introdução

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.

Ficou intrigado? Acompanhe o exemplo abaixo.

Exemplo de falha no software

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 considera apenas o valor monetários.

Pois bem, ao cadastrar uma venda, o sistema irá validar o valor da parcela com os caracteres “R$” que estão no parâmetro e… boom! Um erro estoura na tela, informando 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?

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.

Analogia da cafeteira

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.

Conclusão

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!
Já que comentei sobre parametrização neste artigo, na próxima semana entrarei em detalhes no assunto, ok?

Abraço!