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?! De inicio, para muitos a resposta parece óbvia, TI possui o foco em computadores e sistemas e não em pessoas. Se você pensa desta maneira saiba que você está redondamente 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 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:
Ok, de quem é a culpa?
Agora que já sabemos que sem nossos usuários não somos nada (?), pergunto, quem é o responsável por esta falha na comunicação? De forma direta, meus amigos, devemos admitir que na maioria das vezes é nossa a culpa, vou explicar porque:
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 fácil 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?! É de suma importância para a realização de um bom trabalho o compreendimento das operações do cliente e o seu negócio.
3- Muito se diz em uma TI alinhada as 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 “engessa” e não consegue entregar um produto ou serviço de qualidade. Devo salientar que não é a falta de efetividade de tais práticas, pelo contrário, mas o cliente deve estar apto a receber estas estruturas de trabalho.
Obviamente que não devemos tirar a parcela de culpa do usuário, por alguma razão ainda não identificada (por mim), 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.
A importância de requisito
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 própria experiencia, em aula e artigos relacionados.
Quando um cliente procura uma fabrica 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 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 ramo de negócio e o analista interpretará como se o usuário fosse um grande conhecedor de sistemas.
Esta diferença de visão está ligada na forma como os envolvidos interpretam a maneira como o sistema atuaria sobre o problema do negócio e para minimizar a distância deste entendimento alguns pontos devem ser observados no levantamento de requisitos:
O cliente deve passar o problema e não a solução: uma característica comum dos usuários ao passar a necessidade é falar sobre a possível solução já mentalizada por ele, esquecendo que é justamente este o papel do analista.
Nenhuma informação deve ficar subentendida: parte do analista não deixar nenhuma informação subentendida, ou seja, se algum ponto não foi totalmente compreendido, não deve passar para o próximo assunto.
Minimizar o inimaginável: imagine a seguinte situação, na homologação de um projeto surge uma necessidade que nenhuma das partes lembraram que poderia acontecer e que tal funcionalidade é de total importância para o funcionamento do negócio, este é o inimaginável. Os itens anteriores são complementares a este, deve buscar todos os detalhes do usuário sobre as operações diárias, se necessário, uma observação in loco.
O requisito deve conter:
- Claro entendimento: o requisito não deve nunca proporcionar múltiplas interpretações, ou seja, deve mante-lo de forma objetiva e direta.
- Pontualidade: o requisito deve ser pontual a necessidade, não deve conter a generalização de uma funcionalidade 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: deve ser registrado a origem do requisito, poderá ser uma pessoa ou até mesmo outro requisito já documentado.
Concluindo…
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 sobrepõem qualquer capacidade técnica.
Obrigado pela a atenção e até o próximo pitaco. 🙂