Conflitos de interesse no desenvolvimento de sistemas
Publicado; 18/07/2005 Arquivado em: CFGIGOLÔ 2 ComentáriosA impressão que tenho aqui é que a responsabilidade profissional é bem mais exigida. Você tem que ser muito competente para entrar, se estabilizar e crescer no mercado americano. Claro que no Brasil e em qualquer outro lugar do mundo deve ser e é assim também. No entanto aqui existe uma concorrência e uma exigência muito maior dos e entre os profissionais. Além de existir uma responsabilidade intangível e muito subjetiva do que você deve ou não fazer mesmo que seja explicito ou não no escôpo de um projeto.
Algumas vezes os chefes lhe criticam por você fazer alguma funcionalidade que é “commom sense” em um projeto. E em outro que não estava especificado essa funcionalidade e você não fez lhe criticam por não ter feito. No primeiro caso talvez o cliente nem tenha percebido essa funcionalidade e não reclamou e nem elogiou a existência dela. No outro caso o cliente reclamou a falta dela (a funcionalidade) e dai o seu chefe vem e lhe critica pela falta dela mesmo ele não tendo especificado que ela era necessária no projeto que ele fez e não lhe consultou em nenhum momento da elaboração do mesmo.
Então eu chego a conclusão que o que importa não é só o que o seu chefe projeta ou o que cliente cobra que você deveria ter feito (depois do serviço estar terminado). O que importa é tentar fazer todos felizes com o resultado do projeto mesmo com o conflito de interesses entre o programador, analista, chefe e o cliente!
Assim, fico imaginando como os outros profissionais da área de Tencnologia da Informação, no Brasil ou em outro pais, gerenciam esses conflitos de interesses. Como fazem para que os projetos tenham sucesso e que ninguem termine frustrado ao final?
Definição clara e exagerada de escopo e principalmente: saber dizer não. E isso inclui todas as nuances possíveis do “saber dizer”.
Alex, concordo que seria ótimo se pudessemos sempre ter um projeto que especificasse absolutamente o que o cliente e o chefe imagina que seria a solução perfeita. Acontece, que na maioria das vezes, pelo menos onde trabalho, o cliente não sabe o que exatamente ele quer ou não sabe informar para o projetista o que ele quer e nem o gerente do projeto sabe e/ou tem tempo para coletar todas as informações necessárias e detalhadas do projeto.
Dessa forma, muita coisa que fazemos é “common sense”. Que com a experiência prática aprendemos que mesmo não estando claramente determinada no projeto temos que codificar tal funcionalidade pois mais cedo ou mais tarde o cliente ou o chefe vai exigi-la e cobra-la como sua responsabilidade mesmo ela não estando determinada em nenhuma proposta, projeto ou documentação.
Concordo que saber dizer não é um fator primordial. Eu mesmo uso uma técnica muito simples e eficaz de dizer “se” no lugar de “não”. Principalmente quando converso com o gerente do projeto encarregado de fazer a proposta e o projeto para o cliente. Fazendo ele ver as implicações das coisas projetadas por outra ótica que por um motivo ou outro ele não viu.
Ai é que acho está realmente a solução para esse problema. Não no fato de saber dizer não. Isso é apenas um dos fatores parta solução. Que é a conversa, o diálogo, a comunicação entre todos os envolvidos no processo. Infelizmente, ou felizmente, isso não é fácil. Principalmente se existe uma hierárquia de um lado (cliente) e do outro (nós, empresa de desenvolvimento). Problemas como aquele do “telefone sem fio” que obervavamos quando eramos criança. Ou da interpretação equivocada das mesmas palavras. Ou, o pior de tudo a falta de comunicação parcial ou total entre as pessoas encarregadas em desenvolver a solução.
Acredito que só com o dialógo honesto e aberto entre essas pessoas problemas com o projeto podem ser solucionados e resolvidos para a felicidade geral. O cliente tem que saber que nem ele sabe realmente o que quer ou não sabe informar exatamente o que quer até ver alguma coisa pronta. O gerente do projeto tem que saber que um projeto raramente vai se tornar exatamente a solução que o cliente deseja (e muitas vezes o cliente deseja hoje pode ser diferente amanhã).
As soluções, são passiveis de erros (bugs), falhas de propósito e evolução. As soluções, os sistemas são elaborados por humanos e portanto possuem defeitos, que na maioria das vezes podem ser corrigidos. Possuem funcionalidades que podem ser melhoradas. Todos, cliente, gerentes, analistas e programadores, sabendo disso precisam forçar um dialogo amigavel, claro e consciente de que a única certeza é que ninguem e nenhum sistema é perfeito. Mas lutamos e trabalhamos por isso!