Entrevistas a Stakeholders
Origem: Wikipédia, a enciclopédia livre.
| Este artigo ou seção precisa ser wikificado. Por favor ajude a formatar este artigo de acordo com as diretrizes estabelecidas no livro de estilo. (Fevereiro de 2008) |
No contexto da Engenharia de Requisitos, são usadas entrevistas como um método de identificação de requisitos de um sistema. A identificação de requisitos é um dos passos mais importantes do processo de Engenharia de Software. Consiste na identificação das necessidades do cliente por parte de um analista ou engenheiro de software. Depois de terem identificado estes requisitos, estão aptos para conceber uma solução para o problema. Este processo pode ser árduo e moroso. Os especialistas em requisitos contactam os clientes, documentam os seus progressos, analisam a informação reunida para descobrir inconsistências, e depois voltam ao contacto com os cliente. Este ciclo pode assim levar algum tempo, e pode estender-se pelo ciclo de vida do projecto. Os analistas podem fazer uso de diversas técnicas para obterem os requisitos do cliente. Estas incluem a realização de entrevistas, workshops de requisitos, brainstorming, ou listas de requisitos. Técnicas mais modernas incluem a prototipagem e casos de uso.
Índice |
[editar] Introdução
A utilização de entrevistas é uma das técnicas mais usadas para identificar e assimilar os requisitos do cliente. Trata-se de uma técnica simples e direta que pode ser usada em virtualmente qualquer situação. Um dos aspectos fundamentais deste tipo de entrevistas é garantir que as ideias e predisposições naturais do entrevistador não interfiram com uma livre troca de informação. Isto pode ser algo difícil de conseguir uma vez que cada pessoa é influenciada por um conjunto de vivências pessoais, que podem dificultar a compreensão de ideias vinda de outras pessoas. No caso dos engenheiros de software, que têm um papel de fornecedores de soluções, normalmente conseguem imaginar (mesmo em fases iniciais do processo) qual o tipo de abordagem e metodologia para resolver o problema em causa. Isto porque em muitos casos o domínio aplicacional é restrito e certos elementos parecem à partida óbvios para a solução final. Este facto, não sendo totalmente negativo, não deixa de muitas vezes colidir com a compreensão do verdadeiro problema a ser resolvido. Assim, é fulcral que o contexto em que o entrevistador se insere interfira o menos possível com a análise do problema proposto. Elaborar cuidadosamente as perguntas e estrutura da entrevista deve ser então o primeiro passo a tomar. Passo esse que é de extrema importância para o sucesso da entrevista.
[editar] Elaboração das perguntas
[editar] Perguntas de contexto livre
As perguntas de contexto livre ajudam o analista a obter informação acerca do problema, minimizando ao máximo as suas influências pessoais na resposta do cliente. Isto consegue-se através de formular perguntas acerca da natureza do problema sem entrar em detalhes técnicos, evitando entrar em contextos de potenciais soluções. Este conceito de "perguntas de contexto livre" foi introduzido pela primeira vez por Gause e Weinberg [1989]. Como exemplo de perguntas deste género, podemos ter:
- Quem são os utilizadores?
- Quem é o cliente?
- Têm necessidades diferentes?
- Onde podem ser encontradas outras soluções para este problema?
Estas perguntas obrigam o analista a ouvir primeiro antes de tentar encontrar uma potencial solução, e começar a descrevê-la quase instintivamente influenciando desta forma o entrevistado. O ouvir cuidadosamente permite uma melhor compreensão do problema principal e quaisquer outros problemas relacionados, que muitas vezes passam despercebidos, mas que afectam a motivação e comportamento do entrevistado. As perguntas de contexto livre podem ser comparadas a uma técnica usada por vendedores comerciais chamada "venda de soluções". Esta técnica consiste no vendedor fazer uma série de perguntas cujo primeiro objectivo é o de compreender ao máximo o problema do cliente e que soluções o cliente já tem em mente (no caso de já ter alguma). O objectivo destas perguntas é permitir ao vendedor perceber na sua totalidade o verdadeiro problema do cliente, para que possa sugerir soluções eficazes. Este processo permite evidenciar a importância do vendedor como um elemento da solução para o problema do cliente.
[editar] Perguntas centradas na solução
Durante a fase de pesquisa e identificação de requisitos, pode também ser apropriado começar a dirigir o tipo de perguntas mais para o contexto de uma solução, após terem sido obtidas as respostas às perguntas de contexto livre. No fundo, o papel do analista é o de fornecer soluções específicas aos problemas em causa, e não apenas compreender o problema no geral. A referência a um contexto de solução pode permitir que o utilizador surja com novas ideias, e até mesmo com uma visão diferente do problema, uma vez que é confrontado com uma potencial direcção para a sua resolução. Claro que os entrevistados dependem directamente dos entrevistadores para obter uma contextualização do caso; de outra forma, teriam de ser eles mesmos a ensinar ao entrevistador tudo o que sabem acerca do assunto em causa. Após terem sido feitas as perguntas de contexto livre, pode começar-se a explorar as soluções propostas com estas perguntas mais direccionadas:
- (Apresentar as capacidade gerais de uma solução) E se pudesse fazer ... e ...?
- Como classificaria a importância de cada uma das funcionalidades apresentadas?
[editar] A entrevista
Com alguma preparação, uma estrutura de entrevista bem definida e com os objectivos delineados, não tem necessariamente levada a cabo pelo analista do sistema. Qualquer membro da equipe de trabalho pode realizar a tarefa de entrevistar um utilizador ou cliente de forma correcta e com bons resultados. Ainda assim, deve ser dada preferência a membros da equipa com mais aptidões de interacção social, e com à vontade para manter uma conversa com os utilizadores num ambiente empresarial e de forma por vezes pouco estruturada. Aqui ficam algumas dicas para uma entrevista de sucesso:
- Prepare uma entrevista de contexto livre apropriada, e tome nota para que isso sirva como referência no decorrer da entrevista. Faça uma revisão às questões a colocar nos momentos que antecedem a entrevista.
- Antes da entrevista faça uma pesquisa ao background do stakeholder e da empresa a serem entrevistados. Não mace a pessoa a ser entrevistada com perguntas que poderia facilmente saber a resposta à priori. Ainda assim, pode confirmar brevemente essas respostas dando a mostrar o seu interesse e conhecimento da pessoa e empresa em questão.
- Anote as respostas no seu bloco de notas durante a entrevista. (Não tente capturar a informação de forma electrónica nesta fase!)
- Consulte as notas da estrutura da entrevista no decorrer da mesma. Desta forma tem a certeza que está a fazer as perguntas correctas e que não se está a desviar dos objectivos definidos.
- Discuta os problemas com o utilizador. Esclareça situações que possa observar no ambiente. Faça sugestões e observações baseadas em conhecimento teórico e familiarização com outros sistemas.
O guião da entrevista não deve ser demasiado restritivo. Depois de estabelecida uma ligação positiva com o entrevistado, é normal que a entrevista acabe por entrar numa dinâmica própria. Por vezes o cliente pode começar a entrar em grande detalhe acerca das inúmeras dificuldades e problemas da situação em que se encontra. Isto é exactamente o comportamento que procura. Se tal acontecer, não interrompa o fio de diálogo ao interpor uma nova questão. Em vez disso, tome nota rapidamente do máximo que conseguir, deixando o cliente dizer tudo o que pretende. Faça perguntas relacionadas com a informação que acabou de obter tentando aprofundar o tema, pois esta é uma forma de ir de encontro ao verdadeiro problema do cliente. Quando o tema se extinguir, então sim deve voltar à sequência definida para a entrevista. Não há qualquer problema em desviar-se um pouco do contexto da entrevista, desde que mantenha em mente os objectivos que traçou para a entrevista. Após algumas entrevistas (bastam até duas ou três para tal ser notado), o analista/técnico vai concluir que obteve valioso conhecimento acerca do domínio do problema e vai ter uma melhor compreensão do problema a ser trabalhado e das opiniões do utilizador acerca das características que uma solução de sucesso deve ter. Para além disso, o técnico consegue fazer um apanhado das necessidades chave do utilizador ou das funcionalidades do produto. O entrevistador deve ter sempre em mente que este método deve basear-se numa troca de informação mútua entre entrevistador e entrevistado.
[editar] Compilação da informação obtida
Após a realização das entrevistas, o analista já deve ter ficado com um leque de necessidades identificadas. Para compilar o conjunto de necessidades gerais dos utilizadores entrevistados deve ser usado um método que pode ser denominado de "Resumo do Analista". Esta é a última secção da estrutura de uma entrevista. É usada para registar as três principais necessidades ou problemas que vieram ao de cima no decorrer da entrevista. Em muitos casos, após apenas algumas entrevistas, estas necessidades prioritárias começam a aparecer repetidas. Isto significa que se pode começar a convergir para alguns requisitos e necessidades comuns. Isto acontece principalmente quando os entrevistados partilham uma perspectiva comum sobre o problema. Assim, ao fim de por exemplo um conjunto de dez entrevistas, iremos ter apenas 10 ou 15 necessidades diferentes. Isto é o ponto de partida para um repositório de requisitos, algo que irá ser usado como base para as fases futuras do processo de engenharia de requisitos. Assim, o processo de entrevista pode ser usado para ir alterando e melhorando o desenho do sistema, descobrir aspectos únicos do domínio do problema e discutir prioridades.
[editar] Questionários
Muitas vezes surge a dúvida se se pode ou deve substituir o processo de entrevistas por um questionário. Por vezes, os questionários são vistos como um processo mais eficiente (o tempo que demora a fazer uma entrevista daria para fazer diversos questionários). Para além disso, muitas vezes pode-se ter uma tendência natural para evitar o contacto humano e o ter de falar pessoalmente com os utilizadores, tentando obter as mesmas respostas sem esse tipo de interacção. No entanto, qualquer que seja a motivação, não existe substituto para a realização de uma entrevista. Trata-se de uma técnica que privilegia o contacto pessoal, o fortalecimento de relações, e uma interacção sem grandes restrições. Após a realização de uma ou duas entrevistas as diferenças ao nível dos resultados encontrados devem ser evidentes. A visão do problema e mesmo da solução vão mudando ao longo deste processo, algo que se pode vir a revelar decisivo no sucesso do projecto. Deve ser dada prioridade à utilização de entrevistas comparativamente a questionários. Devem ser realizadas entrevistas para todas as classes de problemas, e para todos os projectos. Embora a técnica dos questionários seja usada frequentemente, e possa parecer científica devido à oportunidade de serem feitas análises estatísticas à informação recolhida, esta técnica não é um substituto para as entrevistas. No que diz respeito à fase de identificação e pesquisa de requisitos, a técnica dos questionários apresenta alguns problemas graves:
- Não se podem tomar decisões relativamente a questões importantes com antecedência.
- As suposições contidas nas perguntas podem influenciar as respostas.
- É complicado explorar novos domínios, e não existe interacção para explorar domínios que necessitem de ser aprofundados.
- Quando as respostas dos utilizadores não são claras, é difícil aprofundar essas questões de forma a obter mais informação.
No entanto, a técnica de questionários pode ser bastante eficaz se usada como técnica de corroboração de conceitos após a entrevista inicial e posterior análise. Por exemplo, se se tratar de um projecto com um grande número de utilizadores, e o objectivo for saber informação estatística acerca das suas preferências de entre um conjunto limitado de opções, um questionário pode ser usado sendo eficaz ao conseguir reunir uma grande quantidade de informação em relativamente pouco tempo.
[editar] Vantagens
Após a exposição de todo o processo referente ao uso do método das entrevistas para a pesquisa e identificação de requisitos de um projecto, podem ser identificadas as seguintes vantagens gerais:
- É a forma mais fácil de descobrir as necessidades de um sistema, pois passa por perguntar directamente aos stakeholders.
- Permite uma melhor compreensão do problema e seu domínio.
- Pode ser utilizada em praticamente qualquer situação.
- É uma solução de baixo custo.
- Uma vez bem definidas as perguntas e estrutura da entrevista, é possível encontrar requisitos reais, e não apenas necessidades de alto nível.
- É um método que aproxima as entidades envolvidas no projecto.
[editar] Desvantagens
Embora seja um método que essencialmente contribui de forma positiva para o processo de engenharia de requisitos, apresenta alguns pontos fracos:
- Consome bastante tempo.
- Utilizadores diferentes podem ter necessidades contraditórias.
- Pode originar grandes discrepâncias entre o funcionamento actual do processo de negócio, e o plano para o futuro.
[editar] Referências
[1] http://www.stickyminds.com/sitewide.asp?ObjectId=9150&Function=DETAILBROWSE&ObjectType=ART Sticky Minds.com - Getting Software Requirements Right
[2] http://en.wikipedia.org/wiki/Requirements_analysis Wikipedia - Requirement Analysis
[3] Dean Leffingwell, Don Widrig - Managing Software Requirements: A Use Case Approach, 2nd Edition - Addison Wesley, 2003
[4] Ian Sommerville - Sofware Engineering, 7th Edition - 2004
