Em seu artigo Nine Deadly Sins of Project Planning, Steve McConnell nos apresenta uma forma bem interessante de reconhecermos um projeto mal planejado. O autor baseou-se em sua experiência para identificar os “pecados capitais” que frequentemente levam os projetos ao fracasso. Francamente, suspeito que ele andou visitando algumas empresas que eu conheço!
O que se segue abaixo é uma tradução um tanto informal do artigo, isto é, não muito ao pé da letra. Eis os nove pecados capitais do planejamento de projetos:
#1 → Não planejar nada
Um dos erros mais comuns. Não é necessário ser um especialista para planejar. Pessoas pouco experientes já o fizeram com sucesso simplesmente porque tiveram o cuidado de atentar para os requisitos do projeto.
Se tiver de escolher entre um especialista em planejamento que não pensa cuidadosamente sobre o plano e um iniciante na carreira, mas que analisa criteriosamente as necessidades do projeto, é melhor ficar com o último.
#2 → Não planejar todas as atividades necessárias
O pecado número 1 é não planejar, o número 2 é não planejar o suficiente.
Alguns planos de projeto simplesmente assumem que ninguém ficará doente, participará de treinamentos, sairá de férias ou deixará a empresa. Tais planos preparam o projeto para um desastre. Há inúmeras variações neste linha. Por exemplo, não incluir atividades auxiliares tais como criar instalação do software, conversão de dados de versões anteriores e outros tipos de tarefas por vezes irritantes que levam mais tempo do que gostamos de admitir.
Em alguns projetos que estão com o cronograma atrasado, tenta-se recuperar o prazo diminuindo o tempo que foi originalmente planejado para os testes. A justificativa é que provavelmente não haverá tantos erros como a princípio se pensava. Fica como exercício para o leitor imaginar por que então o tempo de testes já não foi menor desde o início. 😉
#3 → Não planejar considerando os riscos
Henry Petroski argumenta que os maiores desastres na construção de pontes ocorrem após períodos de sucesso que dão margem à autoconfiança. Os projetistas tornam-se complacentes e simplesmente copiam os atributos de uma ponte para outra sem atentar-se para os riscos em potencial da nova construção.
Em muitos projetos, a palavra “risco” não é mencionada a menos que estejamos com sérios problemas. Em projetos de software, se não estamos usando essa palavra cotidianamente e incorporando-a em nossos planos, não estamos fazendo bem nosso trabalho. Como disse Tom Gilb: “se você não atacar ativamente os riscos, eles irão atacar ativamente você”.
#4 → Usar o mesmo planejamento em todos os projetos
Algumas organizações familiarizam-se com uma abordagem para executar projetos. Ela é mais conhecida como “o jeito que nós fazemos as coisas por aqui”. As coisas costumam ir bem quando os novos projetos são bem parecidos com os anteriores. Mas, se aparecer algo diferente, essa abordagem vai causar mais problemas do que ajudar.
Um bom planejamento visa necessidades específicas do projeto para o qual ele foi criado. Muitos elementos podem ser reusados, mas deve-se considerar cuidadosamente se os elementos antigos se aplicam ao novo contexto.
#5 → Aplicar modelos de planejamento indiscriminadamente
Um planejamento que alguém realizou chega na forma de um livro ou metodologia e parece funcionar muito bem do jeito que está. Então usa-se este plano genérico indiscriminadamente sem pensamento crítico ou consideração pelas particularidades do projeto.
Exemplos conhecidos são o RUP (Rational Unified Process), o XP (Extreme Programming) e, até certo ponto, meu próprio “Guia de Sobrevivência a Projetos de Software” (Software Project Survival Guide). Esses planos “pré-fabricados” podem ajudar a evitar os pecados #1 e #2, mas não substituem nossa análise das demandas únicas do projeto.
Nenhum especialista externo pode entender as necessidades específicos de um projeto como as pessoas envolvidas diretamente nele. O plano de um especialista deve ser adaptado para as circunstâncias específicas. Felizmente, existem gerentes que estão atentos para esses problemas e usam o senso comum para selecionar as partes dos livros de Engenharia de Software que atendem suas demandas.
#6 → Permitir que o planejamento esteja divergente da realidade
Uma abordagem comum ao planejamento é criar o plano no início do projeto e depois abandoná-lo numa gaveta, juntando poeira até o fim projeto. Quando as condições mudam, o planejamento torna-se irrelevante e, no meio do caminho, o projeto anda sem rumo. Não há mais relação do planejamento com a realidade do projeto.
Isso pode estar relacionado ao pecado #5, pois quando alguém abraça uma metodologia pré-fabricadas algumas vezes torna-se relutante em mudar quando ela não funciona. Eles pensam que o problema está na aplicação, quando, na verdade, está no planejamento.
Um bom planejamento deve ocorrer e ser revisado incrementalmente em todo o projeto.
#7 → Planejar muito detalhadamente logo de início
Alguns gerentes bem intencionados tentam mapear todas as atividades do projeto logo no início. Mas um software consiste num constante desdobramento de decisões, cada fase gera novas pendências para decisões futuras. Como não temos uma bola de cristal, tentar planejar atividades distantes em detalhes é um exercício burocrático tão ruim quanto não planejar nada.
Quanto mais trabalho é despendido em criar planos prematuros, maiores são as chances do plano ser engavetado (pecado número #6). Mas ninguém gosta de jogar seu precioso trabalho fora, então o gerente algumas vezes tentará forçar a realidade do projeto para se encaixar em seus detalhados planos, ao invés de revisar o plano prematuramente detalhado.
Eu penso num bom planejamento de projeto como dirigir a noite com os faróis do carro ligados. Eu posso ter um mapa que me diga como ir da cidade A para a cidade B, mas a distância que posso ver com os faróis é limitada. Em um projeto médio ou grande, um macro planejamento pode mapear todo o projeto. Então micro planejamentos detalhados conduzem o projeto apenas algumas semanas por vez.
#8 → Planejar para correr atrás do tempo perdido
Em projetos que começam a atrasar, um erro comum é planejar para se recuperar depois, correndo para “alcançar” o cronograma. A racionalização típica é: “a equipe passou pela curva de aprendizado no início do projeto, nós aprendemos várias lições duras, mas agora que entendemos o que estamos fazendo devemos conseguir concluir o projeto rapidamente”. Resposta errada!
Uma pesquisa de 1991 em mais de 300 projetos descobriu que dificilmente projetos recuperam-se, pelo contrário, a tendências é atrasar ainda mais. O erro desse raciocínio é que a equipe de desenvolvimento toma decisões importantes no início do projeto, enquanto ainda está aprendendo sobre as aspectos tecnológicos, de negócio, e sobre as metodologias. Nas fases posteriores do projeto, o passo não irá acelerar, mas diminuir na medida em que são colhidas consequências de decisões iniciais erradas e então é necessário investir tempo corrigindo esses erros.
#9 → Não aprender com os “pecados” cometidos anteriormente
O pecado mais mortal de todos é não aprender com os pecados já cometidos. Projetos de software podem levar muito tempo e a memória das pessoas pode ficar enevoada pelo ego e pelo tempo. No fim de um projeto longo, pode ser difícil lembrar todas as decisões iniciais que afetaram sua conclusão.
Uma forma fácil de contornar essa tendência e prevenir-se de pecados futuros é conduzir uma autópsia estruturada do projeto. Uma revisão não vai apagar os pecados passados, mas pode certamente evitar mais erros futuros.
