Nove Pecados Capitais de Planejamento de Projetos

Agile & Project Management

Planejamento-Estratégico

Nos dias atuais muitas necessidades de mercado tem trago consigo grandes mudanças no que se refere à maneira como gerimos o desenvolvimento de software em geral. Acompanho várias listas de discussão e percebo o quanto a disparidade de opiniões sobre este tema é grande.

Mesmo assim, existem alguns pontos que a meu ver são imutáveis. São alguns dos pecados que levaram projetos ao fracasso no passado e que continuam a fazer vítimas ao longo dos anos. Por mais que surjam novas técnicas e paradigmas, alguns pontos requerem atenção máxima de todos os responsáveis pelo processo de planejamento do software.

Pensando nisto, estou disponibilizando um texto do Steve McConnell entitulado: Nine Deadly Sins of Project Planning! Algo como: Nove Pecados Capitais de Planejamento de Projetos. O texto original segue na sessão de links.

1. Sem Planejamento algum

De longe o problema mais comum em planejamento é não ter planejamento algum, sendo este pecado facilmente evitável. Uma pessoa não precisa ser um especialista na área para criar um planejamento eficiente. Tenho visto inúmeros projetos planejados por amadores que tem se saído bem simplesmente pelo fato das pessoas nocomando terem considerado cuidadosamente as necessidades específicas do projeto. Forçado a escolher entre um especialista em planejamento de projetos que não pensa cuidadosamente através de seu plano ou um amador na área que tenha exaustivamente avaliado suas necessidades, eu apostaria no amador todas as vezes.

2. Falha ao contabilizar as atividades do Projeto

Se o Pecado Mortal #1 é não ter planejamento algum, o Pecado Mortal #2 é não planejar o suficiente. Alguns planos de projetos são criados assumindo que ninguém no time dedesenvolvimento ficará doente, terá treinamentos, férias ou sairá da empresa. As atividades principais são geralmente subestimadas em grande nível. Planejamentos criados assumindo condições irreais como estas levarão projetos ao desastre.

Existem inúmeras variações deste tema. Alguns gestores negligenciam ao contabilizar atividades secundárias como o esforço necessário para configurar sistemas, converter dados de versõesanteriores, realizar cortes para novos sistemas,realizar testes de compatibilidade e outros tipos detrabalhos chatos que necessitam de mais tempo emprojetos do que gostaríamos de admitir.

Alguns projetos que terminam dentro do planejamento reduzindo o ciclo de testes originalmente planejado; a razão para tal é que provavelmente não existirão muitos defeitos para serem detectados ou corrigidos. (Determinar o porque - se for realmente o caso- não se costuma planejar um ciclo menos de testes no primeiro momento é deixado como um exercício ao leitor.)

3. Falha ao Planejar por riscos

Em Design Paradigms, Henry Petroski argumenta que, no arquitetura de pontes, as falhas mais espetaculares foram normalmente precedidas de períodos de sucesso que levaram ao prazer na criação de novos designs. Arquitetos de pontes mal sucedidas estavam tão iludidos em copiar os atributos de pontes bem sucedidas que não prestavam atenção suficiente em cada uma das potencialidades de falha para as novas pontes.

Para projetos de software, esquivar-se constantemente de falhas é tão importante quanto simular o sucesso. Em muitos contextos, a palavra “risco” não é mencionada a menos que o projeto já esteja em grandes problemas. Em software, o gestor do projeto que não utiliza a palavra “risco” todos os dias e não incorpora o gerenciamento de riscos em seu plano provavelmente não está realizando seu trabalho. Como Tom Gilb diz: “Se você constantemente não atacar os riscos de seu projeto, eles irão constantemente atacar você”.

4. Utilizar o mesmo plano para todos os projetos

Algumas empresas crescem envoltas em uma forma particular de conduzir os projetos de software, que é conhecida como “o jeito que fazemos as coisas por aqui”. Quando esta abordagem é utilizada, a empresa tende a ir bem enquanto o projeto se parecer com os antigos projetos.

5. Aplicar Indiscriminadamente Planejamentos Pré-fabricados

Um primo próximo do Pecado Mortal #3 é reutilizar um plano genérico criado por outra pessoas em aplicar seu próprio julgamento ou sem considerar suas necessidades únicas de projeto. “O plano de alguém” normalmente chega na forma deum livro ou uma metodologia que um gestor aplica em teoria. Exemplos mais atuais incluem Rational Unified Process, Extreme Programming, em algum ponto (apesar de minhas melhores intenções de fazer o contrário) meu próprio Software Project Survival Guideeo CxOnede minha empresa. Estes planos pré-fabricados podem ajudar a evitar os Pecados Mortais#1 e #2, mas não são um substituto para a tentativa de otimizar o planejamento de um projeto para suas principais necessidades.

Nenhum especialista de fora pode compreender as necessidades específicas de um projeto tão bem quanto as pessoas diretamente envolvidas nele. Gestores deveriam sempre deixar o planejamento “dos especialistas” para suas circunstâncias específicas. Felizmente, tenho visto que gestores que tem a real consciência dos problemas envolvidos em planejamento para lerem livros de engenharia de software também possuem suficiente bom senso para serem seletivos sobre que partes de um plano pré-fabricado poderiam funcionar.

6. Permitir que um Planejamento fuja à Realidade do Projeto

Uma abordagem comum para o planejamento é criar um plano no início do projeto e então colocá-lo no armário e deixá-lo acumular poeira apenas para lembrança. À medida que as condições do projeto mudam, o plano torna-se invariavelmente irrelevante, e, ao chegar à metade, o projeto correrá livre de formas, sem nenhuma relação real entre o planejamento inicial e realidade doprojeto. Este Pecado Mortal é exacerbado pelo Pecado Mortal #5- gestores que levantam a bandeira de metodologias pré-fabricadas são muitas vezes relutantes à mudança de seu modelo mental quando isso não funciona. Eles pensam que o problema está na aplicação do planejamento quando, de fato, o problema é o próprio planejamento. Bons planejamentos de projeto devem evoluir através do projeto.

7.Planejar em Muitos Detalhes Muito Cedo</strong> </span></p>

Alguns gestores bem intencionados tentam mapear todo o valor das atividades de um projeto muito cedo. Mas um projeto de software consiste em um grupo de decisões constantemente desconhecidas, e cada fase de um projeto cria dependências para as futuras decisões. Uma vez que ninguém possui bola de cristal, tentar planejar atividades distantes em muitos detalhes é um exercício de burocracia tão ruim quanto não ter nenhum planejamento.

Quanto mais trabalho houver em criar prematuramente planos detalhados, mais facilmenteo planejamento se tornará arquivável (Pecado Mortal#6). Ninguém gosta de desperdiçar trabalhos anteriores, e gerentes algumas vezes tentam forçar arealidade do projeto encaixar em seu primeiro planejamento, ao invés de laboriosamente revisar seu plano prematuro.

Eu imagino um bom planejamento de projetos como dirigir à noite com as lanternas ligadas. Podem existir mapas que dirão como ir da Cidade A a Cidade B, mas a distância que posso ver em detalhes através de meus faróis é limitada. Em projetos de médio ou grande porte, planejamento deve ser mapeado fim-a-fim cedo no projeto. Detalhamento e micro planejamento deve geralmente ser conduzido apenas algumas semanas por vez, e deve ser guiado na forma “just in time”

8. Planejando para alcançar no futuro

Para projetos que trabalham em atraso, um erro comum é planejar para recuperar o tempo perdido no futuro. A racionalização típica é que “A equipe estava escalando a curva de aprendizado no início do projeto. Nós aprendemos muitas lições na maneira mais difícil. Mas agora nós entendemos o que estamos fazendo, e seremos capazes de finalizar o projeto rapidamente.”. Resposta Errada! Uma pesquisa realizada em 1991 em mais de 300 projetos encontrou que projetos dificilmente recuperam o tempo perdido - eles tendem a ficar ainda mais atrasados. A fluxo desta racionalização é que equipes de software fazem suas principais decisões no início do projeto - o momento em que novas tecnologias, novas áreas de negócio e novas metodologias são menos compreendidas.

À medida que a equipe progride para as fases mais adiantadas do projeto, a velocidade não aumenta; ela irá diminuir à medida que encontrar as consequências do erros cometidos mais cedo e investirá tempo tentando corrigirtais erros.

9. Não aprender com os Pecados de Planejamentos Antigos

O Mais Mortal de todos os pecados é não aprendercom os pecados anteriores. Projetos de Software podem durar muito tempo, e a memória das pessoas pode ser preenchida com egos e a própria passagem do tempo. No final de um longo projeto, pode ser difícil recordar todasas decisões anteriores que afetaram sua conclusão. Uma forma fácil de conter esta tendência e prevenir futuros pecados mortais é conduzir uma retrospectivapost mortem. Tal processo estruturado pode não apagar os pecados passados de um projeto, mas pode certamente ajudar a prevenir os pecados dos futuros.

Espere que tenham gostado e até a próxima!

  1. Texto original: http://www.stevemcconnell.com/ieeesoftware/eic19.htm
  2. Referência: http://www.visaoagil.com/

Author's profile picture

Vitor is a computer scientist who is passionate about creating software that will positively change the world we live in.

MVP Azure - Cloud Architect - Data science enthusiast


7 minutes to read