Um Projeto Fracassado - TI Especialistas
abr 30, 2012 Ξ Deixe um comentário
Apesar de gostar de escrever e de compartilhar conhecimento e experiência, após receber o convite para participar deste seleto grupo de colunistas do site, pensei "qual assunto abordar neste artigo inicial?".
Resolvi este pequeno dilema inicial ao ler, mais uma vez, o "Poema em Linha Reta" de Álvaro de Campos (heterônimo de Fernando Pessoa). Se você ainda não leu, leia.
O poema já começa de uma forma instigante:"Nunca conheci quem tivesse levado porrada. Todos os meus conhecidos têm sido campeões em tudo."
Portanto resolvi me juntar ao Álvaro de Campos e em vez de falar sobre o que poderia ser feito ou sobre um modelo de qualidade ou até um case de sucesso, falarei sobre um fracasso retumbante.
Antes de iniciar, um pouco do que está por trás do meu currículo: sou formado em Engenharia da Computação com Ênfase emEngenharia de Software na UMESP.
Tenho alguns bons anos nesta caminhada junto às boas práticas, modelos de qualidade e frameworks. Já implantei CMM, CMMI, MPS.BR e ISO. Já participei de projetos com o objetivo de implantar processos face ao que prega a biblioteca ITIL e na implantação de Escritório de Projetos. Obtive as certificações ITIL e CObIT Foundation em um período de um mês. Obtive a certificação PMP e depois obtive a certificação ITSM (também chamada, informalmente, de ITIL Master ou apenas ITIL Manager).
Mas nada disso, experiência, background acadêmico e certificações, impediu que eu cometesse os mais básicos dos erros: não definir bem o escopo, não gerenciar os riscos e não gerenciar stakeholders.
Primeiro projeto na empresa (sem datas/nomes), único PMP do PMO e com a missão de gerenciar um projeto de melhorias em sistema existente. Não era um sistema complexo, pois ele não tinha uma montanha de regras de negócio, era muito conhecido (demandante usava o sistema cotidianamente) e o fornecedor escolhido para construir tinha um histórico muito bom em projetos passados. Piece of cake, diriam os americanos.
A coisa começou a desandar quando o fornecedor perdeu um dos seus líderes técnicos, restando outro, competente, mas que se viu com vários projetos na mão. Depois a organização perdeu um líder técnico e que desenvolvia também, responsável por outro projeto no mesmo sistema. O meu projeto incorporou os requisitos que faltavam serem desenvolvidos do dele.
Foi quando caí na armadilha mais básica de todas: fui resolvendo os problemas entrando em acordo com os stakeholders sem documentar nada e fui descobrindo que a área que deveria conhecer o sistema, pois era usuária principal, tinha acabado de mudar de comando. Portanto o gestor e o seu time não conheciam tão bem assim. Já o fornecedor, corresponsável pela documentação, estava equilibrando vários pratos e acabou não documentando nada também.
O resultado disso foram as constantes discussões para estabelecer as regras, defini-las corretamente, ou corrigi-las. Tudo isso sem documentação sendo atualizada. Os impactos não foram avaliados corretamente, tínhamos uma dependência de um sistema externo de uma empres apública, que entrou em greve, tivemos constantes trocas de requisitos e tudo isso só na palavra, o que para mim era o suficiente.
Para mim. Para alguns outros não é, portanto um stakeholder começou a pedir mais coisas do que havíamos combinado e sempre perguntava, quando eu dizia que não fazia parte do escopo, onde isso estava escrito.
O projeto simples virou um bicho-de-sete-cabeças. Atrasou muito, o fornecedor teve estresses e "sujou" seu passado, pois acabou atrasando outros projetos também, eu me estressei com o projeto e com a área demandante, não tive o apoio necessário da alta gerência e ainda me vi obrigado a ouvir "ué, você não é PMP?". Sim, sou, mas não sou perfeito e nem mágico.
Eu poderia jurar que já sabia estas lições aprendidas, mas pelo visto ainda não havia absorvido. Não adianta você ser um ás da negociação se não documentar tudo, não adianta pular etapas só porque você julga que o projeto será simples, entenda bem os stakeholders para saber gerenciá-los, fechar e defender o escopo é uma arte necessária e gerenciar riscos é fundamental. No mínimo é isso que precisamos tirar do fracasso. Uma lição para não repeti-lo mais.