O limite entre o desenvolvedor e o usuário

O limite entre o desenvolvedor e o usuárioOlá, 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.

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

Abraço!


Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

10 comentários

  1. eu pensei q tava em outro site, rs
    ficou mto bom! 😀
    ja estava demorando a trazer belas materias como essa hein! rs
    abraco

  2. Eu concordo com você, temos que proteger a integridade do sistema protegendo ele de erros dos usuários. Eu sempre coloco regras de validação e segurança nos programas, mas alguns acabam achando uma brecha. Às vezes é uma briga de gato e rato.
    Hoje a versão 3.10 da NFe verifica se o código de barras é um EAN válido. Vários produtos vem com código barras gerados por eles mesmos, ai na emissão da NFe não passa, e o cliente diz “mas tem código de barras e o sistema leu”. Solução pratica: coloquei um validador do EAN para esse caso. Melhor prevenir que se desculpar depois.

    1. Isso mesmo, Gerson! Quanto mais validações houverem na aplicação, menores serão as chances dos usuário encontrarem “brechas” ou inconsistências. Uma dica interessante é testar a aplicação com a “cabeça” do usuário, simulando possíveis operações que estejam fora do padrão da funcionalidade. Porém, nós, desenvolvedores, temos uma síndrome conhecida como “vício de programação” e precisamos de uma pessoa externa para testar a aplicação. É aí que entram os Analistas de Testes.

  3. Nunca ouvi falar sobre ‘Analistas de Testes’. Como isso funciona? Quanto custa?
    Eu cheguei a ter 32 versões ‘customizações do software’ para os clientes, quando decidi juntar tudo parametrizando o programa como você orientou em um outro post (que maravilha se eu tivesse isso alguns anos atrás), deu muito trabalho, se tivesse um ‘Analistas de Testes’ evitaria vários transtornos, mas ele não deveria ser um conhecedor do software?

    1. Isso, Gerson, Analistas de Testes devem conhecer tanto as regras de negócio quanto a utilização do software. Por conta disso, nas empresas, estes analistas recebem basicamente o mesmo treinamento dos desenvolvedores.
      A função desse profissional é validar as funcionalidades do software através de várias técnicas de testes, procurando cobrir todos os cenários possíveis. Para isso, eles elaboram testes automatizados para serem executados em cada versão do software, garantindo a integridade.
      A área de testes ainda está em crescimento aqui no Brasil. Mesmo assim, várias empresas já estão investindo bastante nesse setor.

Deixe uma resposta

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

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.