Boas práticas para análise e levantamento de requisitos

Resolvi abordar o tema de levantamento de requisitos dentro de gerenciamento de projetos, lembrando que minhas diretrizes e apontadores são baseados nos estudos do PMBOK do PMI.

Muitos sentem uma tremenda dificuldade na hora de lidar com o levantamento feito no inicio do projeto, principalmente aqueles que já pegam um projeto iniciado e tem que absolver tudo e buscar a melhor maneira de entender o que está acontecendo.

Em função disso estão os Focais para ajudar na Interpretação do projeto.

Primeiramente gostaria de ressaltar que o modo de levantamento varia da hierarquia que você trabalha.

Se faz necessário um documento padrão para coleta de dados para que o gerente possa interpretar os dados necessários para dar continuidade no cronograma.

Ao fazer a primeira abordagem ao cliente aonde vai ser implantado o Sistema ou Ferramenta verifique se a viabilidade de atender aos requisitos desse projeto, caso não tenha o know-how, abra a pauta e coloque todas as dúvidas e alinhe com o seu gerente, em caso de divergência o gerente se encarrega de resolver esse problema com o cliente.

Durante a reunião com o cliente e as partes interessadas faça as perguntas certas ao “analista operacional (cliente)” que estará encarregado de mostrar como é o AS-IS da empresa.

Faça com que as respostas obtidas do cliente não deixem nenhuma questão pendente de interpretação, isso pode acarretar atraso no projeto, custo e ,muita dor de cabeça…

Baseado no que seu gerente requer de você, a precisão de dados faz com que o projeto aconteça claramente e sem pausas desnecesárias.
Uma pergunta mal feita ou mal interpretada pode acarretar em um “ponto zero” ou  famoso  … Quem faz o quê aqui? e começa o looping de reuniões de contratempo, Sempre esteja atento ao ESCOPO.

Dentro dos processos, onde os analistas ficam quebrando a cabeça procurando por informação que não foi repassada do cliente para a consultoria quando na verdade a falha está na comunicação interna, evidencie tudo o que fizer no projeto e apresente a solução.

Este erro é muito comum em empresas que colocam analistas que são bons em seguir processo porém não  intendem uma virgula do que realmente faz! são os famosos soldadinhos da empresa com procedimentos em mãos para explicar ao analista de requisitos como funciona o processo e não o sistema.

Abaixo cito Alguns apontadores que faço prática:

WorkShop: Trata-se de uma técnica de elicitação em grupo usada em uma reunião estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders que melhor representam a organização e o contexto em que o sistema será usado, obtendo assim um conjunto de requisitos bem definidos.

 (Entrevistas): A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê espaço ao entrevistado para esclarecer as suas necessidades. É uma discussão do projeto desejado com diferentes grupos de pessoas.

BrainStorming: É utilizado normalmente em workshops. Após os workshops serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido. Seu objetivo é uma apresentação do problema/necessidade a um grupo específico, requerendo assim soluções.

Questionário: Diferente da entrevista, essa técnica é interessante quando temos uma quantidade grande de pessoas para extrair as mesma informações. As questões são dirigidas por escrito aos participantes com o objetivo de ter conhecimento sobre opiniões das mesmas questões. São auto-aplicáveis pois o próprio informante responde.

Grupo Focal (Focus Group): É um grupo de discussão informal e de tamanho reduzido (até 12 pessoas), com o propósito de obter informação qualitativa em profundidade. As pessoas são convidadas para participar da discussão sobre determinado assunto.