Qual é a comunicação e os requisitos para Projetos de TI

Autor: Genizis Vinicius Gonçalves

Que profissionais de TI e usuários muitas vezes não conseguem falar a mesma língua não é novidade. Mas afinal, por que isso acontece?

Certa vez, numa discussão sobre o assunto, ouvi de alguém que o motivo era que a TI possui o foco em computadores/softwares e não em pessoas. Obviamente que foi uma resposta equivoca, e se você pensa desta maneira, há grande chance de estar enganado!

Todo e qualquer projeto de TI possui ao menos um objetivo que vai a favor de benefícios a uma ou mais pessoas. Talvez, em alguns casos, não de forma direta, mas ao final do processo o resultado proporcionado sempre impactará em decisões humanas. Não há por onde fugir, somos totalmente dependentes de usuários, e em caso de resistência, os resultados serão catastróficos.

De quem é a culpa?

Agora que já sabemos que sem nossos usuários não somos nada, pergunto: quem é o principal responsável por esta falha na comunicação? De forma direta, meus amigos, devemos admitir que na maioria das vezes é nossa a culpa. Calma, vou explicar:

1- Muitos profissionais de tecnologia não compreendem que a TI é uma área de apoio. Pensar que somos o topo da cadeia é um erro, por mais que saibamos que muitas vezes fazemos negócios alavancarem, não somos nós que ditamos as regras. Não é a empresa e nem o usuário que deve se adequar aos processos de TI, e sim o oposto.

2- É comum profissionais de TI procurarem trabalhos limitados a conhecimentos técnicos, afinal, é muito mais cômodo lidar com máquinas a pessoas. Eis que surge o problema: como vamos desenvolver uma solução para uma empresa se ao menos não entendemos claramente o seu problema? É extremamente importante para realizarmos um bom trabalho, primeiramente compreender as operações do cliente e o seu negócio.

3- Muito se fala em uma TI alinhada às necessidades do negócio, mas antes disto acontecer, a TI deve entregar o que o negócio precisa. A TI nem sempre terá uma vida própria, dependerá da cultura e organização da empresa.

4- Nem sempre metodologias, certificados e boas práticas ajudam o negócio do cliente, em alguns casos apenas “engessam” e não conseguem entregar um produto ou serviço de qualidade. Devo salientar que não há falta de efetividade de tais práticas, pelo contrário, mas o cliente deve estar apto a receber estes métodos de trabalho.

Obviamente que não devemos tirar a parcela de culpa do usuário, por alguma razão os usuários tendem a simplesmente ignorar a possibilidade de melhoria dos processos, estão mais preocupados em manter a rotina confortável ao invés de ganhar tempo e praticidade em seus trabalhos diários.

Comunicação e Levantamento de Requisitos

Neste artigo vou exemplificar a falha de comunicação Usuário x TI no processo inicial da construção de um software e também colocar algumas dicas e técnicas captadas na minha própria experiência e estudos.

Quando um cliente procura uma fábrica de projeto de software, seu objetivo principal é solucionar seus problemas processuais por meio de automação através de sistemas computacionais. Essas necessidades são passadas a um profissional que possua conhecimentos tecnológicos e de negócio, para que então seja possível transformar esses requisitos em um software. É neste momento que muitas vezes a falha ocorre.

A visão do usuário e do profissional de tecnologia nem sempre serão as mesmas, o usuário falará como se o analista fosse experiente no seu negócio e o analista interpretará como se o usuário fosse um grande conhecedor de sistemas.

É comum que haja essa divergência na visão, afinal, os ambientes de trabalho destes profissionais são diferentes. Para minimizar a distância no entendimento das partes, alguns pontos devem ser levados em consideração no levantamento de requisitos:

O cliente deve passar o problema e não a solução Uma característica comum dos usuários no levantamento de requisitos é falar sobre a possível solução já mentalizada por ele, esquecendo que é justamente este o papel do analista. O analista deverá conduzir o diálogo fazendo que o usuário fale sobre as necessidades e não a possível solução.

Nenhuma informação deve ficar subentendida

Parte do analista não deixar nenhuma informação subentendida, se algum ponto não foi totalmente compreendido, não deve passar para o próximo assunto.

Evitar o inimaginável

Para melhor entendimento, vamos exemplificar. Imagine a seguinte situação: na homologação de um projeto surge uma necessidade que nenhuma das partes lembraram que poderia acontecer, tal funcionalidade é indispensável para o funcionamento do negócio, isto é o inimaginável. Se você trabalha com análise de sistemas, sabe que isto é tão comum quanto se imagina, devemos sempre estar atentos aos detalhes e buscar retirar a maior parte das informações do usuário.

Além das técnicas citadas acima, precisamos ter consciência que cada requisito descrito deve conter:

- Claro entendimento: o requisito não deve nunca proporcionar múltiplas interpretações, devemos descrevê-los de forma direta e objetiva.

- Pontualidade: o requisito deve ser pontual a necessidade, não deve conter generalização das funcionalidade e/ou regra do sistema.

- Análise de diversos cenários: o requisito deve tratar todas as possibilidades possíveis, quando, como e por onde.

- Rastreabilidade: sempre registrar a origem do requisito, pode ser um usuário ou até mesmo outro requisito.

Está claro que deve haver uma melhoria na comunicação entre TI e usuários, mas isso não irá acontecer até que alguma das partes tome iniciativa. Aproveite a situação atípica e seja um profissional diferenciado, tenha a boa comunicação como característica essencial e tenha em mente que a capacidade de relacionamento é tão importante quanto qualquer capacidade técnica.

FONTE: CorpTV