É muito interessante abordar tal pensamento, pois como analista de TIC, sempre me pergunto o que deve ser feito quando um cliente traz ideias mirabolantes, fantásticas e na maioria das vezes…irreais. Sim, caros leitores, irreais, porém é nesse momento que nosso bom senso e profissionalismo entra em ação.
Deixar o cliente falar, ouvir de verdade é algo difícil. Muitas vezes a vontade de interromper e criar o “nosso” sistema é uma procura de sobrepor aquilo que está sendo identificado nas palavras, desencontradas, de alguns stakeholders, porém mesmo não sendo palavras de fácil identificação para levantamento de requisitos, o analista deve ter paciência, escrever tudo que for dito e de forma, inteligente, cordial e profissional, devolver aquilo que foi dito com perguntas pertinentes que levem ao entendimento mútuo de ambos os envolvidos. Muitos clientes entrevistados (seja em reuniões coletivas ou individuais) identificam mais requisitos não funcionais, que tem seu valor – e temos que nos atentar a isso – do que de fato identificar o que o sistema precisar ter para operar funcionalmente e corresponder aos seus desejos finalísticos. Pode ser que a partir de um requisito não funcional, tenhamos o caminho para um correto entendimento daquilo que se quer, que se espera.
Há algum tempo li algo que falava o seguinte: “considerando-se a complexidade na execução das atividades de elicitação de requisitos e a dependência do relacionamento entre os envolvidos é preciso delimitar as linhas de ação para obter maior ganho na atividade proposta”.
Entendendo, como acadêmico e analista de TIC, que algumas boas práticas devem ser adotadas pelos de forma a facilitar o andamento e melhor aproveitamento de processo de levantamento de requisitos:
- Preparação: Prepare-se previamente e de forma adequada para as atividades planejadas, as quais são geralmente realizadas através de entrevistas, questionários, brainstorms e workshops.
- Stakeholders: Mapeie (com antecedência) quem serão os participantes do processo, quais os seus papéis no projeto e na organização e quais são os seus níveis de conhecimento e influência. É imprescindível que as pessoas corretas sejam envolvidas o quanto antes.
- Postura: Busque sempre a efetividade nas comunicações, assim como procure demonstrar ponderação durante as situações de conflito.
- Entendimento: Procure focar no entendimento do problema e evitar conclusões precipitadas. Nesse primeiro momento o mais importante é saber escutar.
- Experiências passadas: Utilize de forma positiva as experiências vividas anteriormente para ajudar a melhor compreender o problema. Evite considerar que o problema atual é igual a algum outro que tenha sido resolvido em um cliente ou projeto passado.
- Documentação: descreva o problema de forma clara e objetiva. Em caso de dúvidas, consulte o cliente e evite inferências. Procure usar exemplos citados pelos stakeholders. A adoção de diagramas e figuras sempre ajuda na documentação e entendimento dos requisitos. A criação de protótipos também contribui para o entendimento comum da solução proposta.
- Validação: Faça com que os stakeholders validem a documentação, verificando o entendimento do problema e as melhorias desejadas e eventualmente façam solicitações de mudanças.
Identificar a real necessidade de um cliente/usuário é nosso papel. Ele pode “voar” e desejar o mundo perfeito o quanto entender ser certo para ele, sendo que cabe a nós: orientar e esclarecer, sem muito “tecniquês” para que ele possa ter aquilo que deseja, mesmo não sendo o seu Mundo ideal, só que atingindo seus objetos práticos de usabilidade e desempenho, gerando o menor custo e maior grau de satisfação possíveis.
Esse é o caminho.
[Crédito da Imagem: Levantamento de Requisitos – ShutterStock]