Olá, estudante! Seja bem-vindo(a) ao segundo ano da disciplina de Análise e Projetos de Sistemas, é um prazer estar, novamente, com você! Em lições anteriores, vimos que o primeiro passo de um Técnico em Desenvolvimento de Sistemas, ao iniciar o desenvolvimento de um software, é identificar os requisitos daquele software, ou seja, saber o que aquele programa deve fazer, quais são as suas funcionalidades e restrições operacionais.

A melhor pessoa para te passar essas informações é o chamado stakeholder, aquela pessoa ou aquele grupo de pessoas que são os principais interessados no software. Não é obrigação do desenvolvedor do software, no caso, você, saber tudo sobre todos os tipos de problemas organizacionais, mas é sua função saber coletar informações dos stakeholders, para que seja possível o desenvolvimento de um software.

Nesta lição, estudaremos algumas técnicas que facilitam o processo de coleta e entendimento dos requisitos de um software na perspectiva do solicitante (stakeholder), ou seja, nesta lição, conheceremos, analisaremos e discutiremos técnicas de entrevista e coleta de dados para o processo de levantamento de requisitos de um sistema computacional. O que veremos, aqui, aplica-se a qualquer tipo de software ou situação que envolva o levantamento de requisitos para um sistema computacional.

Nós já vimos, em lições anteriores, que uma das principais técnicas de elicitação de requisitos (levantamento de requisitos) é a entrevista, preferencialmente, face a face, mas, se não for possível, ela pode ocorrer por meio de uma ferramenta de encontro virtual (ex.: Zoom, Google Meet ou Microsoft Teams).

Fazer uma entrevista visando a coletar dados e informações a um novo sistema computacional, contudo, não é uma tarefa simples. Digo isso por dois fatores: o primeiro fator está associado à necessidade de que você esteja bem-preparado(a) e organizado(a) para a entrevista — precisa saber o que, quando e para quem perguntar — o segundo fator está associado ao próprio ser humano. Lidar com pessoas as quais, muitas vezes, você nunca viu, e fazer perguntas a ela durante o seu horário de trabalho, talvez, gere resistência ou sentimentos que estimulem a não cooperação com o processo. 

Você precisa ter habilidades para “quebrar o gelo” durante esse tipo de processo, e deixar o entrevistado o mais confortável possível, para que ele possa contribuir durante a entrevista, caso contrário, ela não terá utilidade alguma à identificação dos requisitos do sistema. Isso é comum acontecer com técnicos em desenvolvimento de sistemas que não dominam técnicas de entrevista.

Você já pensou como convidaria uma pessoa para participar de uma entrevista de elicitação de requisitos? Você já pensou no que perguntaria a essa pessoa se ela aceitasse o seu convite? Que atitude você tomaria se a pessoa que você convidou negasse o convite para participar do processo de elicitação, mesmo ela sendo a que mais entende determinado processo da organização ou a que mais informações valiosas possui para o desenvolvimento do novo sistema? Já pensou no que faria se a pessoa que você está entrevistando fosse ríspida ou desrespeitosa durante a entrevista? As respostas para todas essas perguntas serão apresentadas nesta lição.

Imagine que você é o(a) responsável pelo desenvolvimento de um software em uma grande empresa do ramo de sapatos, a qual produz calçados para todo o Brasil e, também para o exterior. O objetivo do dono da empresa é ter um sistema de Inteligência de Negócios (Business Intelligence) que viabilize a análise da enorme quantidade de dados gerados pela empresa, diariamente, nos seus mais diferentes setores (ex.: setor de vendas, compras, exportação, marketing, recursos humanos, departamento pessoal, gerências locais, entre outros). 

Devido ao fato de o novo sistema envolver dados de diferentes setores, é fundamental que você, como responsável por esse projeto, compreenda a fundo quais são os tipos de dados que cada um desses setores possui. Assim, o primeiro passo a ser seguido por você, técnico(a) em desenvolvimento de sistemas, é obter informações que viabilizem o seu trabalho de desenvolvimento desse sistema. Para tanto, você precisará conversar com as pessoas as quais, realmente, compreendem que dados existem, em qual formato eles estão, como eles são imputados no sistema e possíveis dados que, porventura, sejam gerenciados fora do sistema de informação da empresa (ex.: existência de planilhas eletrônicas que não são lançadas no sistema da empresa).

Por se tratar de uma empresa de grande porte e com muitos setores, é impossível que você converse com todos, até porque o tempo de desenvolvimento de um sistema tende a ser bastante curto nos dias atuais; seria inviável você passar meses fazendo entrevistas com stakeholders. Assim, o nosso primeiro passo é definir quem será entrevistado e justificar o motivo dessa escolha. As entrevistas devem começar nos escalões mais altos da empresa e seguir para o nível de gerentes intermediários, gerentes de linha e, por fim, funcionários de nível operacional. Mesmo que a gente siga essa estratégia, ainda assim, precisamos escolher quem do alto escalão será entrevistado e em qual ordem. 

Essa escolha deve se basear na importância do stakeholder para o sistema e no nível de contribuição que ele pode dar ao objetivo central do sistema de informação que se deseja desenvolver. Por se tratar de um sistema de Inteligência de Negócios, e pelo fato de os principais usuários desse sistema serem, geralmente, diretores e/ou gerentes de nível estratégico, opte por essas pessoas, com especial destaque àquelas vinculadas ao setor administrativo, de vendas ou da área de estratégia, se existir na empresa.

Para esse tipo de sistema de informação, talvez, o pessoal de nível operacional não tenha tanta importância, porque eles tendem a não lidar com dados estratégicos ou com informações que sejam relevantes para diretores e/ou gerentes estratégicos. A elicitação dos requisitos deve se fundamentar, sempre, no tipo de stakeholder com mais capacidade de contribuir para o objetivo daquele sistema. 

Caso o objetivo fosse desenvolver um sistema de informação para automatizar uma rotina operacional do dia a dia dos funcionários que carregam caminhões na área de logística, os funcionários de nível operacional seriam mais importantes do que os gerentes de área, pois eles lidam, diariamente, com aquele processo cujo sistema que você está desenvolvendo automatizará, logo, conhecem, profundamente, todo o funcionamento do processo e os tipos de dados que são tratados.

Um dos principais desafios dos desenvolvedores de sistemas computacionais é compreender “o que” o stakeholder deseja que o sistema faça (ENGHOLM, 2010). Há inúmeras brincadeiras e piadas relacionadas a essa dificuldade entre os programadores porque muitos dizem que o stakeholder só sabe o que ele quer depois de o sistema estar pronto, mas aí já é tarde demais e qualquer modificação implica sérias mudanças. Assim, uma das etapas-chave no desenvolvimento de sistemas é a elicitação de requisitos. Na literatura de desenvolvimento de sistemas, a entrevista é a maneira mais produtiva de obtenção de informações/requisitos de sistemas. 

A forma mais comum de entrevista é por meio de uma reunião pessoal e direta entre você (talvez acompanhado por um ou dois analistas auxiliares do mesmo projeto) e um ou mais entrevistados. Sugiro que você faça entrevistas com mais de um stakeholder somente se o número de stakeholders for muito grande (ex.: acima de 100). Caso contrário, faça entrevistas individuais, porque as respostas de um podem influenciar na resposta do outro. Se o seu objetivo for obter o consenso em alguma funcionalidade do sistema na qual um stakeholder disse uma coisa, outro diz outra e um terceiro disse algo diferente, aí sim você pode colocar todos juntos e confrontar as informações para chegar num consenso. 

Nas entrevistas, normalmente, você pode “tomar notas” em um papel ou no próprio computador. Não há problema em usar um gravador, desde que, previamente, autorizado pelo entrevistado, para que você ouça a entrevista em outro momento e anote detalhes (LINDA, 1996). Contudo a anotação no momento em que o entrevistado responde às perguntas é mais comum e costuma gerar menos conflito com o entrevistado, que pode se sentir desconfortável pelo fato das suas respostas estarem sendo gravadas. Outra situação é você utilizar um secretário na entrevista. Essa pessoa atuaria como um escrivão, ou seja, tomando notas para você enquanto a entrevista ocorre. Esse tipo de situação não é comum e, na grande maioria das vezes, o próprio profissional realiza a entrevista e toma notas.

Você, talvez, esteja se perguntando se há outras formas para que as informações obtidas em uma entrevista sejam obtidas por outros meios, e a resposta é sim, mas com ressalvas. Por exemplo, você pode solicitar que os entrevistados respondam por escrito a um questionário formal ou que descrevam por escrito os requisitos do novo sistema. Contudo essas técnicas somente devem ser usadas se houver total impossibilidade de realização da entrevista, seja de forma presencial, seja de forma virtual. Faço essa sugestão porque um questionário ou um texto apresentado pelo stakeholder sempre será bem menos profundo do que uma entrevista. 

A entrevista se tornou a principal forma para elicitar requisitos de sistemas de informação desde a década de 1980 (YOURDON, 1990). Para uma entrevista ser bem realizada, devemos estar atentos a alguns problemas fundamentais que a envolvem. À primeira vista, pode parecer que o processo de entrevistar um usuário seja algo simples e direto, mas entrevistar alguém com o objetivo de identificar os requisitos para um software não é simples. A literatura científica tem destacado que os principais problemas associados ao desenvolvimento de um sistema de informação não estão associados a hardware ou software, mas ao chamado peopleware (YOURDON, 1990; ENGHOLM, 2010). O peopleware apresenta as suas principais dificuldades durante uma entrevista de elicitação de requisitos. 

Assim, discutiremos, um pouco, sobre os problemas mais comuns em entrevistas:

1) Entrevistar a pessoa errada no momento errado 

Esse tipo de problema é muito fácil de ocorrer devido aos problemas e interesses organizacionais, por exemplo, tentar entrevistar uma pessoa que está passando por conflitos dentro da empresa ou mesmo fora dela: esse tipo de situação tenderá a desenvolver uma entrevista pouco produtiva.  Você pode focar somente na pessoa que é o chefe daquele setor ou do processo que será informatizado, mas que demonstra não saber muito a respeito dos verdadeiros requisitos do sistema. Dependendo do tipo de sistema, nem sempre o chefe será a melhor fonte de requisitos. Sistemas de informação que buscam a automatização de processos operacionais costumam ter nos funcionários de níveis hierárquicos mais baixos as principais fontes de requisitos. 

Visando a minimizar os problemas anteriores, você tem a chance de utilizar a técnica de etnografia (observação do ambiente de trabalho) para identificar aqueles funcionários com mais conhecimento dos processos. É comum o analista que está levantando os requisitos do sistema passar um tempo junto ao setor ou a área que o sistema será implantado, a fim de identificar as principais fontes de requisitos, ou seja, identificar aquelas pessoas que mais conhecem e entendem dos processos daquele setor/área. 

2) Fazer perguntas erradas e obter respostas erradas

É muito importante que o técnico em desenvolvimento de sistemas entenda que a realidade do stakeholder é, às vezes, completamente diferente da realidade do técnico em desenvolvimento de sistemas. Assim, tente evitar termos técnicos ou situações que fazem parte, apenas, do “seu mundo”. Fazer uso de termos técnicos pode levar à má compreensão do entrevistado, e ele te dará uma resposta muito diferente daquela que você espera. Da mesma forma, pode acontecer de o entrevistado usar termos técnicos do cotidiano dele, e você não entender. Caso ocorra, solicite uma explicação ao entrevistado e anote-a.

O objetivo principal é fazer perguntas que levem a respostas próximas daquilo que você espera. Caso o entrevistado “fuja” daquilo que é esperado, refaça a pergunta e tente guiá-lo ou forneça alguns detalhes do que espera como resposta, mas coloque palavras na boca do entrevistado. Ele é o especialista, enquanto você deve entender o que ele sabe.

Nesse sentido, as ferramentas de modelagem (prototipação) são uma tentativa de fornecer uma linguagem comum e sem ambiguidades para diminuir esses mal-entendidos. Ferramentas de prototipação (ex.: Balsamiq ou Fluid UI) e o diagrama de caso de uso podem ser utilizados em entrevistas como uma forma de facilitar a compreensão do usuário.

3) Criar ressentimentos recíprocos

Um processo de entrevista envolve a relação entre duas pessoas que, muitas vezes, têm expectativas diferentes sobre aquele momento. O técnico em desenvolvimento de sistemas está com a expectativa de identificar os requisitos funcionais do sistema, enquanto o entrevistado acha que o novo sistema o substituirá, uma vez que aquilo que ele faz no dia a dia será informatizado/automatizado. Se o entrevistado tiver essa percepção, na grande maioria das vezes, poderá desenvolver um comportamento de resistência à entrevista, assim, ele tentará dificultar o trabalho do técnico em desenvolvimento de sistemas. Esse tipo de situação leva a situações constrangedoras, como: respostas não muito educadas ou mesmos insultos por parte do entrevistado. Também pode acontecer de o entrevistado se sentir pouco valorizado porque o técnico em desenvolvimento de sistemas é muito jovem. Essa situação é mais comum do que você imagina, especialmente com stakeholders que possuem muitos anos na empresa (ex.: mais de 20 anos).

Caso uma ou outra das situações mencionadas ocorram, o técnico em desenvolvimento de sistemas deve evitar qualquer tipo de discussão com o stakeholder. Se a situação se tornar insustentável, encerre a entrevista e comunique o superior do entrevistado sobre o ocorrido. A elicitação de requisitos, como eu disse, envolve pessoas, então, a variabilidade de situações nesse caso é grande. As sugestões dadas, anteriormente, e as que seguem no decorrer dessa lição ajudarão você a reduzir a probabilidade desses problemas ocorrerem.

Considerações gerais sobre entrevistas

Uma boa entrevista deve ser dividida em três partes distintas, a saber: introdução, entrevista e encerramento. Elas devem ser interligadas de forma que, para o entrevistado, sejam imperceptíveis. 

A introdução de uma entrevista consiste em: (I) na sua apresentação e na apresentação dos objetivos daquela entrevista. Além disso, você deve informar ao entrevistado quais as razões que o levaram a ser a pessoa escolhida; (II) o técnico em desenvolvimento de sistemas deve ser bastante claro e objetivo; (III) tente criar um clima descontraído e de confiança entre o entrevistado e o entrevistador. 

Após a etapa de Introdução, começa-se a entrevista propriamente dita, a qual deve ser conduzida com muito profissionalismo pelo técnico em desenvolvimento de sistemas. Sugere-se que o técnico evite perguntas as quais o entrevistado possa responder, apenas, sim ou não. A colocação de perguntas abertas e bastante abrangentes produzem respostas com muitas informações e, por isso, são recomendáveis. Evite distrações como olhar no relógio ou fazer comentários fora do contexto. Durante a entrevista, o técnico em desenvolvimento de sistemas deve ter como princípio não criticar a empresa, o trabalho do entrevistado, o sistema existente ou qualquer funcionário da organização. Por outro lado, o técnico precisa tomar certo cuidado para não transformar a entrevista em um interrogatório; perguntas, aparentemente, sem importância devem ser evitadas.

No encerramento, o técnico deve manter o mesmo clima de descontração inicial, agradecendo a atenção do entrevistado e informando-o que, caso seja necessário, um novo encontro será agendado. Após a conclusão da entrevista, o técnico deverá fazer um relatório das informações obtidas, de preferência, com urgência, para não perder detalhes ou informações relevantes que, porventura, não foram anotadas. 

Diretrizes para a realização de entrevistas

As seguintes diretrizes podem ser de grande auxílio na direção de entrevistas bem-sucedidas com seu usuário.

a) Desenvolva um plano geral de entrevista

O primeiro passo para uma entrevista bem-sucedida é identificar, na organização, as pessoas que poderão ser entrevistadas, ou seja, aquelas que, realmente, poderão contribuir para a elicitação dos requisitos. Não tem como entrevistar todo mundo, isso levaria muito tempo, caso seja uma organização grande ou um setor com muitas pessoas. O ideal é identificar as pessoas que são chave em determinados processos e conversar com elas, diretamente. O organograma da empresa pode lhe ajudar nesse momento, mas, caso não exista um organograma, verifique quem conhece a estrutura organizacional da empresa e pergunte sobre as pessoas que mais “entendem” dos processos do setor/organização. Você também pode usar a técnica de etnografia, ou seja, você passar um ou dois dias no setor identificando quem sabe mais sobre os processos.

b) Certifique-se que você tem autorização para falar com o usuário

Em organizações que não seguem procedimentos tão formais, talvez não seja necessário uma autorização por escrito para conversar com os stakeholders, apenas uma autorização verbal pode ser suficiente. Esse cenário é mais comum de acontecer em micro ou pequenas empresas, contudo, em empresas médias e grandes, sugere-se que haja uma autorização por escrito, e você esteja com ela para abordar os funcionários. 

Sugere-se que um comunicado da chefia imediata dos stakeholders seja enviado, eletronicamente, com certa antecedência. Assim, quando o técnico em desenvolvimento de sistemas abordar o stakeholder, este já estará sabendo do que se trata e contratempos podem ser evitados.

c) Planeje a entrevista para fazer uso eficiente do tempo 

O principal aspecto dessa sugestão é que se deve compreender que o tempo de entrevista é um tempo no qual o entrevistado não está trabalhando no posto dele, o chefe pode supor que aquela entrevista está tomando tempo demais e que o trabalho está parado. Da mesma forma, o entrevistado pode ter muitas tarefas pendentes, e a entrevista está tomando o tempo dele.

Dessa forma, para fazer uso eficiente do tempo do entrevistado e do próprio entrevistador, alguns procedimentos devem ser realizados pelo técnico em desenvolvimento de sistemas antes que ele, realmente, inicie a entrevista. Tenha a certeza de que o stakeholder (entrevistado) conhece o processo ou os processos que serão discutidos. A entrevista de uma pessoa que, recentemente, iniciou naquele trabalho e ainda está aprendendo os processos pode não ser adequada para conhecer a fundo como “as coisas funcionam”. 

A fim de ter certeza se o futuro entrevistado compreende do processo que será discutido na entrevista, você pode, por exemplo, enviar um documento de texto simples com perguntas básicas sobre aquele processo (nada complexo!). Com base nas respostas, você já saberá se é uma pessoa com bom ou mau conhecimento daquele assunto/processo. Caso tenha dificuldade no retorno da resposta desse documento, pode ser que o stakeholder (futuro entrevistado) esteja muito ocupado, desinteressado na participação ou tenha alguma resistência em relação ao próprio desenvolvimento do sistema. Caso isso aconteça, tente conversar pessoalmente ou por uma ferramenta de reunião online com o stakeholder e compreenda a posição dele. Não tome nenhuma atitude sem conhecer o lado do stakeholder.

 d) Possíveis formas de resistência na entrevista

O técnico em desenvolvimento de sistemas deve estar preparado para o fato de que alguns usuários serão contrários à ideia de uma entrevista; esta é uma das razões para garantir que o chefe ou alguém com autoridade no setor esteja ciente e tenha permitido a entrevista. A autorização do superior do entrevistado pode facilitar a situação bem como evitar formas de resistência, mas não use isso como uma “arma” para persuadir o entrevistado a participar da entrevista. Isso pode causar um desconforto e, até mesmo, se espalhar pela empresa, comprometendo todo o processo de elicitação dos requisitos.

Nesta lição, aprendemos como o técnico em desenvolvimento de sistemas pode preparar e realizar uma entrevista para a elicitação de requisitos de um sistema. Agora, você sabe que são muitos detalhes a serem levados em consideração e, provavelmente, compreendeu o porquê de estudar sobre ERS! 

Agora, discutiremos algumas situações do cotidiano em que podemos aplicar as técnicas discutidas, anteriormente. Primeiro, sempre é importante conversar com os usuários na sequência adequada e na combinação certa. Muitas vezes, você saberá em que sequência os usuários deverão ser entrevistados devido ao seu conhecimento geral da organização ou os próprios usuários te dirão quem deve ser entrevistado. 

Vamos a um exemplo: você está entrevistando Marta, que diz: "bem, naturalmente, recebo todos os meus dados de entrada de Jorge; ele poderá te falar sobre esses dados. Em seguida, faço o seguinte...". Em um caso assim, muitas vezes, é melhor falar, primeiro, com o Jorge, deixando para falar com a Marta depois. Ou você pode estar entrevistando o Paulo, que diz: "bem, na verdade, Suzana e eu desempenhamos essa função juntos; ela faz uma parte e eu faço o resto...". Neste caso, seria, evidentemente, mais produtivo entrevistar Suzana e Paulo ao mesmo tempo. 

Você também poderá passar por alguns tipos de situações durante uma entrevista. O entrevistado talvez diga: “você está tomando muito tempo meu”. No caso de acontecer essa situação, o técnico em desenvolvimento de sistemas deve manter a calma, explicar os motivos que o levaram a estar ali e os objetivos que pretende alcançar com o novo software. Você também deve deixar claro que não tomará muito tempo do stakeholder e informar o tempo de duração máxima da entrevista. Sugere-se que sejam evitadas entrevistas superiores a 40 minutos, mas, caso ultrapasse esse tempo, verifique se o stakeholder tem disponibilidade para dar continuidade, então, informe que vocês podem encerrar ali e, caso necessário, uma nova entrevista é agendada. 

Outra situação comum seria o entrevistado dizer: “você está ameaçando o meu emprego”. Este tipo de situação pode ocorrer por diversos fatores. Caso a empresa esteja passando por dificuldades financeiras, qualquer mudança leva os funcionários a pensar que se trata de um corte de pessoal (demissão). Assim, o desenvolvimento de um novo software pode levar a esse tipo de pensamento por parte dos funcionários. Neste caso, é importante que o dono da empresa ou pessoas que façam parte da alta administração da organização enviem um comunicado a todos informando os reais motivos daquele novo software. Mesmo que com esse produto, alguns postos de trabalho sejam informatizados, sugere-se que isso não seja divulgado, porque há muita chance de haver forte clima de resistência ao novo sistema. De qualquer forma, caso o técnico em desenvolvimento de sistemas passe por essa situação, não é sua função discutir nada relacionado a isso (corte de pessoal). Você deve explicar que só está fazendo o seu trabalho e que não tem condições de discutir a posição daquela pessoa na empresa.

O entrevistado pode considerar o técnico em desenvolvimento de sistemas como alguém que sabe mais do que ele sobre aquele processo e que todo o seu conhecimento será substituído pelo novo software. Novamente, o técnico não deve entrar nesse tipo de discussão. Sugere-se que os superiores sejam informados sobre o ocorrido e, se necessário, um comunicado seja enviado a todos da organização ou do setor. O técnico não deve opinar ou fazer pronunciamentos em nome da organização, de forma alguma. 

Outra situação corriqueira é o entrevistado dizer: “você está há pouco aqui e acha que já sabe tudo da empresa?”. Este tipo de situação pode ocorrer junto com a situação anterior, em que o entrevistado acredita que o novo software retirará a importância do entrevistado na empresa. Neste caso, sugere-se que o técnico em desenvolvimento de sistemas esteja calmo e explique que a ideia de o entrevistar é, exatamente, compreender o que ele sabe e que está sendo entrevistado, exatamente, por ser uma pessoa que possui profundos conhecimentos sobre aquele assunto. Destaque a importância do stakeholder para aquela atividade, nunca questione as suas informações, isso é capaz de despertar um sentimento de resistência à entrevista. O respeito, o tom de voz calmo e a fala pausada (sem desespero) é importante para passar tranquilidade ao entrevistado e evitar conflitos.