A busca pelo culpado de um projeto fracassado e o dilema do prisioneiro
Autor: Executive Consultoria Jr. | Publicado: 2013-10-25T13:49:00-03:00


Neste artigo, Roney Médice reforça a necessidade das equipes discutirem as falhas de projetos de forma madura































&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; *Por Roney Médice






O caminho contemporâneo para se colocar uma ideia em prática dentro de uma empresa é a criação de um projeto cujo objetivo é levantar as atividades necessárias e relevantes para que um objetivo final seja alcançado. Esse processo desde a concepção da ideia e a entrega do produto final é realizado através de um planejamento estratégico que conhecemos como projeto.



Não é meu intuito fazer definições ou trazer conceitos do PMBOK (Project Management Body of Knowledge – que é um conjunto de práticas em gerência de projetos) e sim, debater uma visão gestora sobre a consequência de um projeto fracassado no que diz respeito a “apontar” um ou vários culpados, fazendo um paralelo com o dilema do prisioneiro.



As melhores práticas de gerenciamento de projeto são fundamentais para que o administrador da empresa ou o responsável pelo projeto consiga trilhar um caminho padrão em sua atividade, mas acima de tudo, as melhores práticas não vão ditar se o caminho a ser seguido é correto ou não. Apenas, vão ajudar a diminuir os problemas do dia a dia na execução do projeto e aumentar as chances de sucesso da execução do pleito.



Entretanto, sabemos que nem sempre os projetos criados dentro de uma empresa tem um final feliz ou pelo menos com um resultado esperado. Diversos fatores podem influenciar no desenvolvimento de um projeto e dependendo da equipe que estiver a frente dessa empreitada, pode não conseguir alterar o resultado negativo de um projeto.



Quanto temos um resultado negativo de um projeto, que ao final não atendeu as expectativas geradas na fase de planejamento ou por sua execução conter diversas falhas operacionais que inviabilizam a execução do projeto, é normal procurar os responsáveis pelo resultado negativo para que algumas soluções possam ser levantadas ou simplesmente para realizar as temidas “punições” aos responsáveis.



Claro que cada projeto deve estar vinculado a um Gerente de Projeto, que é o gestor líder do projeto em andamento e sem sombra de dúvida, eu diria que ele tem uma “responsabilidade objetiva” quanto ao resultado final. Todavia, podemos ter autores diretos que influenciaram para o fracasso de um projeto e não necessariamente o líder do projeto teria a culpa unilateralmente.



Por exemplo, em um projeto de desenvolvimento de sistema, pode ser que o gerente do projeto não saiba nada sobre programação e que confie na equipe de programadores para que o sistema final tenha sucesso em sua implementação e assim, o projeto tenha um sucesso esperado.



Contudo, ao final da programação e passada a fase de homologação, só foi detectado um problema gravíssimo de vulnerabilidade ou problema de integração entre alguns módulos a partir do momento que o sistema passou a ser utilizado pelo cliente final. A princípio, o projeto foi concluído com sucesso mas com a descoberta do problema, dependendo das circunstâncias, o sistema tem que ser abortado o seu uso para evitar prejuízos futuros. Isso é o que eu chamo de um projeto fracassado, quando inviabiliza o produto com a descoberta de um problema.



E nesse momento, quem é o culpado pelo fracasso desse projeto? O gestor do projeto que não conseguiu mensurar essa possibilidade de erro na integração entre os módulos? Os programadores que não testaram a contento conforme as melhores práticas de desenvolvimento de software? Os analistas de sistemas do projeto que não souberam realizar corretamente o diagrama de fluxo de dados? A quem culpar?



Essa busca pelo culpado eu faço uma comparação com o dilema do prisioneiro, um problema clássico da teoria dos jogos (em que cada jogador, de modo independentemente, quer aumentar ao máximo a sua própria vantagem sem lhe importar com o resultado do outro) e pode ser comparado em que dois suspeitos são presos por um crime, mas não existe uma prova fundamental para que se possa incriminar um deles. Com isso, é oferecido vantagens pessoais para cada um deles, de forma separado, e sem saber que a mesma vantagem está sendo oferecido ao outro, para que o mesmo atribua o crime ao outro e assim, conseguir o benefício com a exclusão da culpa.



Será que ao invés de cada um tentar colocar a culpa no outro, não é melhor realizar uma cooperação e achar uma melhor saída para evitar apontar determinados culpados e o prejuízo final ser ainda maior?



No primeiro momento, atribuir a culpa ao outro poderia trazer uma vantagem pessoal mas ainda acredito que se todos cooperassem, o resultado final seria melhor. Mas como no dilema do prisioneiro, em que o ponto chave é incentivar individualmente que cada um delate o outro, existem diversos projetos fracassados que vivemos um dilema de prisioneiro nas equipes: ninguém quer aceitar para si o fracasso do projeto.&nbsp; Sempre há necessidade de se culpar o outro.





FONTE: LG SISTEMAS.