TI Corporativa

Ξ 3 comentários

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

publicado por Eduardo Virgílio

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.

Autor

Eduardo Virgílio tem quase trinta e cinco anos dedicados ao desenvolvimento de software. Nesses últimos vinte e cinco ele tem trabalhado como CIO da LG Sistemas. Seu foco de atuação recai sobre a Engenharia de Software, área na qual ele ministrou disciplinas ao longo de vinte anos na Universidade Federal de Goiás. Formou-se em física pela UNB e em seguida obteve o título de mestre pela Universidade Federal do Rio Grande do Sul. Atualmente ele trabalha no projeto de reescrita da suíte composta pelos módulos de RH da sua empresa.

Eduardo Virgílio

Comentários

3 Comments

  • Muito bom o texto. Realmente o papel de um analista é extremamente complexo, pois deve entender tanto de TI como do negócio. E infelizmente nem sempre o levantamento dos requisitos é tratado com a devida importância que merece.

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes