Requisitos – Paradigma a ser quebrado

Requisitos - Paradigma a ser quebrado

É indispensável entendermos as reais necessidades do cliente/usuário. Este entendimento é conseguido por meios de elicitação (levantamento, identificação,…) de requisitos. Existem algumas técnicas que podem ser usadas para chegar neste entendimento, mas antes disso precisamos quebrar um forte paradigma.

Um jargão amplamente difundido na TI é “O usuário nunca sabe o que quer”. Eu discordo! O Usuário sempre sabe o que quer (geralmente não na sua completude), mas na esmagadora maioria das vezes ele não sabe como nos falar o que quer, e nem é seu papel, nós é que devemos conseguir extrair esta informação dele. É importante frisar que isto não significa que ele não tenha responsabilidade em nos apoiar na etapa de elicitação de requisitos, tem e MUITA, pois o papel dele é indispensável para tal.

“Geralmente” os usuários entendem e sabem muito sobre o negócio da empresa.
Quando entendemos e trabalhamos no nosso dia a dia em um assunto e nos perguntam algo sobre o nosso trabalho, certamente iremos falar de forma bem simples, deixando passar várias questões importantes de entendimento. Vou exemplificar: digamos que somos contratados para desenvolver um sistema de contas à pagar e perguntamos ao nosso fornecedor de requisitos: “O que você precisa que seu sistema faça?”(Provavelmente não perguntaremos assim). Certamente teremos respostas como: “Um sistema padrão de contas a pagar”,  “Um sisteminha simples de contas a pagar”, “Um software de contas a pagar básico”, “Um software igual ao XPTO”…

Por que temos respostas deste tipo? Bom, primeiro pela pergunta que fizemos, segundo pelo grande envolvimento e conhecimento do usuário no negócio dele (neste exemplo, contas a pagar). O cliente não sabe o que quer? Sim ele sabe, quer “Um sistema de contas a pagar”. O que ele não sabe é que esta informação não é suficiente para podermos desenvolver este sistema (É um exemplo, não estou levando em considerarão aqui inúmeras variáveis, como por exemplo: o analista pode ser especialistas no negócio).

Vou fazer uma analogia com uma situação real que aconteceu comigo:
Como sabemos, quem trabalha com TI tem que “saber de tudo relacionado com a área”, pelo menos aos olhos dos parentes e amigos. Eu estava no aniversário de um amigo, quando um amigo me pediu uma ajuda, disse que seu novo assistente estava tendo dificuldade para elaborar alguns documentos, por mais que eu dissesse que colocasse ele em um treinamento, não consegui convencê-lo, então falei que tentaria ajudá-lo a entender o problema.

Chegando lá entendi, num primeiro momento, que o assistente não sabia usar o editor de textos, (considero que é algo básico para esta função), ao pedir que ele abrisse o editor de textos, notei que ele não tinha entendido minha solicitação e tive que mostrar todos os passos para que chegasse no editor, sim todos os passos (clique em iniciar, arraste o ponteiro do mouse até….).

Fui bastante paciente e educado, e sugeri que ele fizesse um treinamento básico do sistema operacional e nas ferramentas de trabalho (Excel e Word), pois ele não tinha a menor noção sobre informática, mas tinha vontade de aprender. Não fiquei mais do que 10 minutos, mas não esqueço deste fato, pois me gerou um grande aprendizado (é importante aprendermos com as situações).

Foi neste momento que consegui entender o cliente quando eu tinha dificuldade em extrair dele os requisitos do sistema, eu precisava do passo a passo; e na maioria das vezes o cliente quer alguém que já tenha as noções básicas sobre o assunto, o que é justo e válido.

Com este exemplo quis mostrar que o cliente/usuário, sabe o que quer, mas não vai pegar na nossa mão e mostrar os passos. Precisamos nos preparar antes de conversar com ele, esta preparação para a elicitação de requisitos é fundamental e nos ajudará a ganhar tempo e aumentar nossa credibilidade junto ao cliente/usuário.

E antes de mais nada precisamos esquecer este jargão de que “o cliente não sabe o que quer”, pois ele sabe, e é nosso papel refinar junto com ele este entendimento até chegarmos na solução que atenda às suas necessidades.

Concordam? Querem compartilhar alguma situação real vivenciada sobre o assunto?
Participem, vamos enriquecer a discussão!

 

Carlos Burity

Engenheiro de Software, Especialista em Qualidade de Software, Implementador do MPS.BR e do CMMI. Mais de 25 anos de experiência na área de IT, Forte skill em liderança de pessoas, agilidade e foco em resultados. Muito conhecimento em processos e modelos de processos de IT. Especialista em resolução de problemas. Atuou em empresas de diferentes portes e segmentos, como Engenheiro de Software, Analista de Sistemas, Gestor de Programas, Gestor de Projetos, Scrum Master, Consultor de Processos de IT, Diretor de Produtos e Diretor Executivo.

 


CURSOS RELACIONADOS

Desenvolvimento e Gestão de Requisitos
CURSO DE GESTÃO DE REQUISITOS

Curtiu? Compartilhe

Cadastre-se para receber novidades!