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.
* Eduardo Virgílio é diretor de tecnologia da LG Sistemas.
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.