Analistas e usuários: quando vão se entender?

Uma empresa fornecedora de software tem como principal objetivo atender às empresas que a contratam. 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 o que o usuário deseja, de forma a construir ou modificar a solução a ser fornecida. Embora não existam mais limitações tecnológicas é possível afirmar que 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 que não resolva o problema do seu cliente? Essa é a discussão que pretendo provocar com esse pequeno texto.

Ainda que a tecnologia tenha dado 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 que esteja 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 de tal forma que ela 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 que o empresário, ao investir num fornecedor, deseja, entre outros benefícios, que a solução lhe traga mais do que ele tem e que as rotinas operacionais sejam otimizadas. 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.

Posto esse cenário, vejamos o seu desenrolar. 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. Acontece que, quando a aplicação é entregue, o usuário percebe que ela não o atende ou que ainda falta alguma coisa, que não foi feita de acordo com o que a sua empresa almejava. O mais interessante é saber que apesar das técnicas de obtenção das necessidades, em que prevalece a entrevista, e dos modelos gráficos inerentes ao processo de desenvolvimento, ainda assim conclui-se o projeto sem que o resultado final atenda plenamente o cliente.

Então onde reside o principal problema com o projeto? Certamente o principal problema está na comunicação entre as partes, o analista desconhece 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 de 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 que quanto mais um analista conhece do 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.

Feito o diagnóstico, falta-nos oferecer a receita. Como reduzir o fosso existente entre o que o analista captura e o que o usuário deseja? Não existe uma bala de prata, uma solução mágica que se empregada ofereça bons resultados. No entanto, seguramente é possível adiantar algumas medidas que se não resolvem a questão pelo menos mitigam as chances de fracasso. Quanto mais experiência um analista adquire com o assunto mais apropriado ele se encontra para fazer as entrevistas e consequentemente obter com exatidão o que o usuário deseja. Adquire-se experiência com trabalho, com suor, com erros e acertos o que 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 que fazem parte do caráter de um analista. Para os analistas que possuem essas características mas não têm o background necessário, diria, vivência no tema, a sugestão é se inteirar do assunto tanto quanto possível, seja através de livros, de outras aplicações similares ou de cursos apropriados. Se pudesse descrever o papel do analista poderia dizer que 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 que não estão 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 que o tenha focado, de imediato, ele já está em outro ponto e desse modo torna-se impossível implementar algo que atenda 100% das necessidades da organização. 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 que pode 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 que será entregue, mais chances ele terá de fazer ajustes e, no final do projeto, receber uma solução que o atenda plenamente.