Toda a nossa escola de gerência de projetos tradicional vêm da escolha de gerência de projetos da engenharia. Como exemplo, cito o PMI, talvez a escola mais difundida e aceita de gerenciamento de projetos de TI no Brasil e EUA. O PMI foi criado ainda no final dos anos 60 e seus membros iniciais eram pessoas de engenharia civil. Na escola de engenharia, o paradigma de planejamento detalhado e acompanhamento minuncioso deste planejamento é o modelo mental ainda usado no nosso seculo XXI.
Na área de TI, copiamos este modelo e também as ferramentas (como o Project ou o Primavera). Entretanto, algo parece errado. Quantos projetos eu já acompanhei (como participante, observador ou como executor do cronograma) onde a nossa inabilidade de montar e seguir um plano detalhado foi tornada aparente (e frustante). Várias vezes me questionei - “Algo está errado, mas não sei muito bem o quê”.
Felizmente, parecem existir evidências fortes que estamos usando o modelo errado para atacar um problema comum em TI, que é como gerenciar projetos e obter sucesso.
Gostaria de compartilhar um artigo que li na IEEE, de um autor de renome (Walker Royce) na área de gerenciamento de projetos e que lança luz neste tema - Successful software management style: Steering and balance. Embora controverso, devemos realizar algumas análises sobre a essência de projetos de software. Projetos de software, de forma geral, possuem as seguintes características (identificadas por Walker Royce):
- Não existem leis físicas ou de propriedades de materiais para restringir as soluções aos seus problemas. A restrição está na imaginação humana, restrições econômicas e desempenho da plataforma física que hospedará o software. Sistemas embutidos, obviamente, são excecões.
- Tudo pode ser mudado em um projeto de software - planos, pessoas, financiamentos, marcos, requisitos, desenhos e testes. Praticamente tudo é negociável.
- Métricas e medidas para produtos de software normalmente são melhor avaliadas através de modelo de valor percebido pelo usuário do que modelos clássicos de engenharia como custo e produção. Aspectos de qualidade são muitas vezes subjetivos como por exemplo manutenabilidade, confiabilidade e usabilidade.
Concordo em linhas gerais como esta análise. Uma outra força neste aspecto é o tempo de vida de uma arquitetura de software. Em um recente artigo na InfoQ, Sadek Drobi conjectura que uma arquitetura expira em dez anos - “Architecture Life Span:Implications on Business and how to build more Long-lasting Architecture“. Após este período, as manutenções se tornam cada vez mais caras e o sistema deve ser refatorado em uma nova arquitetura, sob o risco de gerar cada vez mais prejuízos para o negócio. Esta força mostra como a inventidade humana e inovações dificultam a aplicação de leis comuns em engenharia civil como por exemplo “Fazer para durar”.
A conclusão, que eu concordo, é que a melhor metáfora para a construção de softwares é a concepção de um filme. Precisamos, como apontado por Walker Royce, de arquitetos qualificados (diretores), analistas (roteiristas), engenheiros de software (equipe de produção, atores, editores, dublês) e gerentes de projeto (produtores). Entretanto, a metáfora técnica é que a disciplina de gerência de projetos é regida pela disciplina software economics ao invés da disciplina de software engineering. As decisões diárias de gerentes de projetos de software são dominadas por julgamentos de valor, relações de custo benefício, fatores humanos, tendências macro-econômicas, forças de mercado e pressões gigantescas de tempo. A escola de Software Economics, que tem como um de seus mentores Barry Boehm, pode ser definida como a escola científica de desenho de software fundamentada em modelos formais de valores e criação de valores em condições de incerteza, informações incompletas e competição.
O planejamento iterativo (ou planejamento em duas fases) no processo unificado é um escolha de gerência de projetos muito mais adaptável a esta realidade. O planejamento iterativo define planos em alto nível para as etapas de um projeto e somente realiza o planejamento detalhado para a etapa atual. Neste contexto, podemos incluir o SCRUM aqui também. O SCRUM nos ajuda a organizar a dinâmica de eventos variáveis e lidar com as exceções (impedimentos) que vivemos (enquanto gerentes de projetos) em uma iteração (etapa) específica de um projeto. Coloco, então, o SCRUM como um complemento natural ao planejamento iterativo do RUP.
A escola de metologias ágeis de gerenciamento de projeto Extreme Project Management (XPM), embora sem menção explícita a metáfora de filmes, usa princípios similares para o planejamento e acompanhamento de tarefas.
Começamos a observar o nascimento de ferramentas mais adequadas a este paradigma. Apesar de considerar ferramentas como o Primavera ou o MS Project excelentes, não as considero adequadas para o gerenciamento de projetos de TI. Estamos usando um martelo para bater em algo que não é um prego!
Uma versão mais leve do artigo do Walker Royce está disponível aqui no portal da DeveloperWorks da IBM. Recomendo fortemente a leitura deste artigo. São idéias valiosas (embora polêmicas), mas que me parecem descrever melhor a nossa realidade de projetos de TI.
Artigos mais detalhados e referências para os interessados nas escolas alternativas de gerência de projeto estão abaixo:
- Planejamento Iterativo - Planning an Iterative Project.
- SCRUM - Scrum it Now na Prática
- XPM - Extreme Project Management
Finalmente, deixo também uma coleção de publicações sobre a escolha chamada Software Economics, referenciada por Walker Royce em seu artigo.
No comments:
Post a Comment