Uma empresa fornecedora de software tem como principal objetivo atender aos contratantes. Para isso, ela precisa identificar as necessidades dos usuários dessa organização de modo a desenvolver ou modificar um programa, também conhecido por solução informatizada. Isso para que a solução passe a ajudá-la a se tornar mais competitiva e eficiente.

Assim como um arquiteto busca dos futuros donos da casa os requisitos à sua construção, também é papel do analista de requisitos capturar os desejos do usuário, de forma a construir ou modificar a solução a ser fornecida. Embora não existam mais limitações tecnológicas é possível afirmar: há um fosso intransponível entre estes dois mundos, o do analista de requisitos e do usuário.

Por que ainda não resolvemos esta questão? Como podemos diminuir o risco do fornecedor entregar algo pouco eficiente? Essa é a discussão que pretendo provocar com esse pequeno texto.

A tecnologia deu um salto gigantesco, por outro lado ela ainda deixa a desejar quando o assunto é a implantação de uma solução empresarial. A organização busca no mercado a solução mais próxima à sua realidade, isto é, aquela que melhor espelha sua forma de trabalho e solicita adaptações na ânsia de conseguir uma boa dose de aderência. Em outras palavras, a solução escolhida precisa sofrer mudanças, inevitavelmente. Raramente um produto informatizado oferece todas as funcionalidades conforme deseja a empresa adquirente.

No entanto, quando a aplicação oferece bons processos, a empresa acaba por se adaptar aos mesmos. Isto é, a solução emprega boas práticas e se vê impelida a se comportar da maneira estabelecida pela aplicação o que, diga-se de passagem, é uma das vantagens da informatização.

Não há dúvida: o empresário, ao investir num fornecedor, deseja, entre outros benefícios, a otimização das rotinas operacionais e ainda mais! Conclusão, embora ele esteja disposto a fazer mudanças para se adequar à solução adquirida, ele também quer que a solução sofra alterações de maneira a se ajustar aos processos para os quais ele não vê sentido que sejam substituídos.

O cenário do desenvolvimento

Pelo lado do fornecedor, o analista de negócio se obriga a buscar do usuário, lado do cliente, quais são as suas especificidades, o que lhe é próprio, de modo a prover as alterações cabíveis. É a fase de levantamento do verdadeiro escopo do projeto. Aqui se define o que será feito, assim como o que não vai fazer parte da solução final. Depois de realizado esse levantamento, é o momento de se providenciar as mudanças. Porém, quando a aplicação é entregue, o usuário percebe que ela não o atende ou, ainda, a falta de alguma coisa não realizada de acordo com os seus anseios.

O mais interessante é: apesar das técnicas de obtenção das necessidades, em que prevalece a entrevista e os modelos gráficos inerentes ao processo de desenvolvimento, ainda assim conclui-se o projeto sem um resultado final plenamente satisfatório.

Então onde reside o principal problema com o projeto?

Certamente o principal problema está na comunicação entre as partes, o analista não conhece o negócio como deveria e o usuário, por sua vez, não consegue repassar ao analista, com segurança, todos os seus requisitos. Portanto, no meu ponto de vista, a falha mais grave está identificada: a ausência de um meio de comunicação em que ambas as partes se entendam.

É incontestável. Quanto mais um analista conhece uma determinada aplicação, mais ele consegue obter junto ao usuário os requisitos para a criação/modificação de uma solução informatizada. Poderia até dizer: quanto mais um analista conhece o negócio a ser trabalhado, mais chances nós temos de obter sucesso com o empreendimento.

Portanto, ao levar esse raciocínio ao extremo, o melhor profissional para modelar (especificar requisitos de) uma aplicação é na verdade o próprio usuário, claro, desde que ele conheça ferramentas de análise e a aplicação metódica e sistemática de técnicas de domínio da complexidade.

Visões convergentes para os melhores resultados

Feito o diagnóstico, falta-nos oferecer a receita. Como reduzir o fosso existente entre o que o analista captura e os desejos do usuário?

Não existe uma bala de prata, uma solução mágica. No entanto, seguramente é possível adiantar algumas medidas com as quais, se a questão não é resolvida, pelo menos se minimiza o fracasso. Quanto mais experiência um analista adquire com o assunto, mais apropriado ele se encontra para fazer as entrevistas e consequentemente obter a solução com exatidão. Adquire-se experiência com trabalho, com suor, com erros e acertos e isso exige tempo.

Um bom analista também é um bom pesquisador, ele é um profissional que reúne as características de um arqueólogo com as de um escriba e acrescenta uma boa dose de psicologia. Saber investigar, gostar de escrever e acima de tudo ter paciência para ouvir são competências caracterizadoras de um analista.

Para os analistas com essas características, mas sem o background necessário, diria, vivência no tema, a sugestão é se inteirar do assunto tanto quanto possível, seja por meio de livros, de outras aplicações similares ou de cursos apropriados. Se pudesse descrever o papel do analista poderia dizer: ele é um “dominador de complexidades”.

Outra dica refere-se aos interlocutores entrevistados. O analista em hipótese alguma deve se tolher ou se restringir a buscar os requisitos somente de um único usuário. Diferentes pontos de vista ajudam a esclarecer tópicos pouco claros.

Finalmente uma dificuldade para se obter êxito num empreendimento dessa natureza, algo nunca rechaçado pelos engenheiros de software, é que o negócio em si comporta-se como um alvo móvel. Quando você acredita tê-lo focado, de imediato, ele já está em outro ponto e desse modo torna-se impossível implementar algo com 100% de acerto. Essa é uma das razões do insucesso, sem dúvida, até porque os processos de negócio evoluem, são dinâmicos.

Então um modelo útil a ser empregado no projeto refere-se ao desenvolvimento incremental. Após concluir a implementação/modificação de um conjunto de requisitos, a versão intermediária gerada deve ser discutida com o usuário de modo a se obter um feedback sobre o produto inacabado.

Versões que demandam prazos enormes para a sua conclusão, medidos em meses, devem ser evitadas. Desse modo, quanto antes o usuário tomar conhecimento do produto a ser entregue, mais chances ele terá de fazer ajustes e, no final do projeto, receber uma solução plenamente satisfatória. [Webinsider]

Eduardo Virgílio

Eduardo Virgílio é professor universitário na área de engenharia de software. Graduado e mestre em Física, foi diretor de tecnologia da LG lugar de gente.