PauloMotta.pro

Uma situação muito comum na faculdade, mas que muitas vezes persiste depois que os alunos se formam é a dificuldade de definir claramente o problema que será resolvido. No contexto de desenvolvimento de sistemas é fundamental que tenhamos uma visão clara do que queremos resolver antes de começar a resolver.

Alguém pode argumentar – “Ora, mas muitas vezes isso é impossível!” – na verdade não é. Explico, primeiro temos que entender o que é um problema. De acordo com o dicionário Houaiss problema (entre outras definições) é: mau funcionamento crônico de alguma coisa, que acarreta transtornos, pobreza, miséria, desgraças etc., e que exigiria grande esforço e determinação para ser solucionado.

No contexto de desenvolvimento de sistemas, um problema é alguma situação vivida pelo nosso cliente que atrapalha os seus processos diários de seu negócio, ou seja, é alguma coisa que atrapalha o trabalho.

Particularmente acredito que um projeto de software (e isso muitas vezes gera muita discussão) deve começar com uma frase que indica qual o problema que precisa ser resolvido. É claro que as vezes o sistema que será desenvolvido é muito grande e complexo, e por isso usamos técnicas como dividir-para-conquistar até que tenhamos um conjunto maior de problemas menores, porém de fácil compreensão e definição.

Aí é que começa o problema, muitas vezes quando os alunos precisam definir o problema que vão trabalhar, seja em Projeto de Software ou em Trabalho de Conclusão de Curso, eles apresentam uma frase com a solução do problema sem dizer qual o problema que vai ser resolvido. Para pequenos problemas isso poderia até passar em branco, mas quando falamos de um sistema maior isso é uma situação grave porque a falha na definição do problema pode nos levar a uma solução que não atende ao cliente. Isso acontece porque quando declaramos em uma frase a solução, estamos expressando a solução que nós imaginamos para o problema que entendemos, o que não quer dizer que seja realmente o problema do cliente. Como o problema não foi expressado não temos como confirmar com o cliente se a situação imaginada é a real.

Ok, definido isso agora chegamos ao ponto crucial, se isso não deve ser feito, então o que devemos fazer?

Devemos ter em mente é que antes de começar qualquer definição de solução, devemos ter uma frase que indica o problema a ser resolvido, e o cliente deve reconhecer essa frase como sendo o problema que afeta o processo diário dele. A prática nesse caso é muito importante, quanto mais definições de problemas fizermos melhor ficaremos.

Alguns exemplos de descrições de problemas:

• Muitas pessoas entram na empresa para prestar serviços diversos e não temos qualquer controle de onde essas pessoas vão, quem será responsável por acompanhá-las e horário de saída. (Ao invés de “criar um sistema de controle de visitantes”)

• O controle de pedidos de material de limpeza da empresa é feito manualmente através de uma solicitação em formulário impresso, é difícil obter a quantidade pedida no mês atual e nem tão pouco ter uma média das quantidades pedidas ao longo do ano. (Ao invés de “criar um sistema de controle de compras de produtos de limpeza”)

• Verificar a situação de trânsito nas principais vias da cidade estando na rua. (Ao invés de “criar um sistema de verificação de trânsito”)

Mas qual a importância disso? É simples, a definição do problema pode nos levar em alguns casos a mudar a arquitetura do sistema para usar componentes ou produtos já existentes no mercado como solução (fazer ou comprar eis uma questão), ao passo de que quando definimos a solução isso geralmente nos induz a desenvolver um sistema novo quando em alguns casos bastava mudar o processo do cliente.