Tornando-se um líder Ágil - Parte 2

Como acabar com um projeto em nove passos

Se você já passou por projetos que:

• Simplesmente não deu certo


• Foi cancelado e você nem foi avisado


• Foi um desastre de proporções nababescas


• Atrasou por meses, com orçamento estourado e seus cabelos brancos


• Acabou com seu cabelo de tanto stress

Este texto não serve para você... muito provavelmente por o que escreverei você já deve saber...

Bem, com a experiência de quem já passou por projetos assim, Steve McConnell escreveu sobre Nove pecados que não se deve cometer, caso queira que seu projeto seja um sucesso. (não foi o caso de um projeto que participei...). Engraçado, mas o artigo que li é de 2001, mas completamente atual! Que coisa, será que até quando vamos acreditar nos velhos paradigmas??? Quantos projetos mais devem ir por água abaixo?

Vamos lá: (Fonte: The nine Deadly Sins of Project Planning, 2001) (versão online)

1- Planejamento Nenhum!
Obviamente, sem planejamento, não há projeto que se sustente... ou melhor, talvez possa existir por algum tempo, mas efetivamente ele ruirá por não conseguir suportar os encargos que um projeto desse tipo possui. Nota mental: encontre profissionais que saibam planejar e não seguir planos.

2- Falha ao levar em conta todas as atividades do projeto
Não planejar o suficiente. Não menospreze problemas que podem ocorrer durante o percurso do projeto. NUNCA crie planos irreais em que se assume que o projeto estará lindo e maravilhoso não importante o que ocorra com sua equipe, seu sistema, a tecnologia envolvida...
Extremamente importante levar em consideração: versões antigas do projeto, o tempo de setup para deploy da aplicação, a falta de testes suficientes, a motivação e comprometimento da equipe...
Problemas devem ser corrigido no momento em que eles surgirem em sua frente!

3- Falhar ao planejar levando em consideração o risco
Tudo bem se você não gosta de Desenvolvimento Ágil, mas acreditar que a melhor coisa a fazer é deixar para se preocupar com riscos de projeto só quando for tarde demais é burrice! Neste ponto o fato que nós tentarmos priorizar as tarefas, realizando as mais importantes primeiro, é que saimos na frente no controle de riscos. Assim, os pontos mais críticos do sistema são resolvidos primeiro e possuem acompanhamento diário, aliviando a vida de todos.

4- Utilizar o mesmo planejamento para todo projeto
JOGUE FORA A EXPRESSAO: "Esta é a forma que fazemos as coisas aqui na empresa"!!!!!!!!!!!!
Cada projeto deveria ser único, ou você terá grandes problemas em adequar tudo ao seu Modelo Unificado de Projetos...
Este tipo de atitude funcionará muito bem enquanto os projetos forem semelhantes. No momento em que um projeto novo, com escopo e necessidades novas surgir, você estará encrencado.
Não digo para criar um modelo de gerenciamento completamente novo para cada projeto da empresa, mas deixar esse mesmo modelo flexível às especificidades que cada projeto possui. Isso inclui, por exemplo, não tratar um projeto Web da mesma forma que se trata um projeto Desktop.

5- Utilizar modeos empacotados indiscriminadamente
Seguir princípios não quer dizer que não se possam fazer ajustes à realidade do projeto. Acreditar que comprar o livro sobre eXtreme Programming e utilizá-lo a risca vai ser o máximo é assinar o atestato de fracasso.
Identifique necessidades, estude soluções e aplique as melhores práticas de forma coordenada, para que tudo possa ser validade em seu ambiente... e o mesmo serve para o RUP, CMMI, PRINCE2, etc

6- Permitir que o planejamento se torne divergente da realidade
Um procedimento comum em projetos é criar um plano inicial e tentar seguí-lo na medida do possível. E independentemente do que ocorra, tentar manter este mesmo plano no decorrer do projeto...

7- Planejar com muitos detalhes de início
Fato: REQUISITOS MUDAM
Poderíamos discutir por horas aqui, mas não vou fazer isso, deixarei que a experiência de vocês fale por si só.
Além do óbvio disperdício de tempo e recursos que existe ao se planejar com muitos detalhes de início, eu acredito que o maior problema dessa abordagem é o descontrole emocional que isso pode causar numa equipe. Imagine-se trabalhando numa especificação por 6 meses, e então durante o primeiro mês de desenvolvimento descobre-se que a tecnologia ou os requisitos não vão atender à demanda. Todo seu trabalho será jogado fora e refeito... quem não gostaria de um bom saco de pancadas para evitar os pensamentos homicidas neste momento?

8- Planejar pela compensação
Não acredito em curva de aprendizado durante o planejamento. Seja consistente e realista ao traçar um planejamento para adesão de novas metodologias, novas pessoas e novos projetos. Se você planejar supondo que a equipe compensará o tempo perdido, certamente acabará com um projeto atrasado. Já passei por um projeto desses, é frustrante...

9- Não aprender com as experiências passadas
Um projeto que participei, como programador, em que TODOS envolvidos com o desenvolvimento me disseram a mesma coisa: "Que droga, está acontecendo exatamente como nos outros projetos, vai dar tudo errado"...
Aceite o desafio da mudança! Credite na experiência dos projetos, faça sessões de retrospectivas... somente assim pode evitar a repetição de erros conhecidos... é o que dizem: "erra é humano, mas persistir no erro..."

Até mais!