Planejamento sim, planos nem tanto

O tema planejamento e, principalmente os planos associados, sempre assombram a área de Engenharia de Software. Estamos sempre perseguidos pelas falhas nos planos, prazos não cumpridos, orçamento que sai dos trilhos, funcionalidades ausentes ou implementadas com falhas no produto final, baixa qualidade, e vamos adiante. Claro, não é nenhum privilégio da nossa área, todas as demais áreas sofrem com o mesmo problema. Há várias máximas sobre o assunto, por exemplo In preparing for battle, I have always found that plans are useless but planning is indispensable (Na preparação para uma batalha, sempre acho que planos são inúteis mas planejamento é essencial), atribuída ao ex-presidente estadunidense Dwight Eisenhower. Uma outra de que até gosto mais, atribuída a Sir Winston Churchill: It is always wise to look ahead, but difficult to look further than you can see (É sempre sábio olhar adiante, mas dificil olhar além de onde você consegue ver).

Recentemente, li uma entrevista com o Jim Collins, festejado consultor de empresas e  autor de livros sobre negócios (Exame 1030, 5/12/2012, comemorativa dos 45 anos da revista). O título da entrevista é exatamente Esqueça os planos!, e o contexto é a instabilidade na economia global e o aparecimento de muitas incertezas, que afetam o planejamento e os planos de longo prazo. Mas, professor, aprendemos na escola a fazer planos, usar EAP – Estrutura analítica de projeto ou WBS – Work breakdown structure, cronograma, prazos, tempos, gráfico de Gantt, MS Project e mais um monte de ferramenta similar! Não serve prá nada, está tudo errado?

http://www.me.umn.eduNão é bem assim, claro. Olhando para as máximas acima, em particular para a atribuída a Sir Winston Churchill, as coisas ficam mais claras: não adianta tentar enxergar além do que é possível enxergar com a informação disponível no momento. Além deste ponto, estaremos lidando com o desconhecido, com riscos altos, com falta de informação, e não há técnica para lidar com isso a não ser arriscar (ou gastar uma fortuna para conseguir mais informação e diminuir os riscos). Ou não arriscar, e esperar (muito) até que a situação fique sob controle, mais informação esteja disponível, etc. Quando estamos falando de investimento em ações, por exemplo, onde há maiores riscos é onde possivelmente estarão os maiores ganhos e também as maiores perdas, e não há como decidir com base em certeza. Só é possivel decidir com base em incerteza (se houver dados para isso) ou tendências, e até usar simulação para tentar enxergar um pouco adiante. E não há como esperar por mais informação, a decisões devem ser tomadas imediatamente, sob risco. O mesmo acontece em situações de guerra, que é o alvo da máxima atribuída a Dwight Eisenhower: tem jeito de fazer um plano detalhado? dificilmente, porque a próxima decisão certamente só será tomada quando forem conhecidos pelo menos em parte os resultados da decisão anterior. Não tem como atacar o inimigo e fugir ao mesmo tempo…

O conhecimento na área de Riscos é fundamental para entender e saber lidar com essas situações. Por exemplo, um dos elementos de risco em projetos de software é a experiência com projetos semelhantes. Se a equipe tem experiência anterior com a área do projeto, então ele apresenta risco baixo, e aí sim, é possível fazer um plano mais detalhado com poucas chances de dar errado. Mas, e se a equipe não tem experiência nenhuma com o projeto, e a gerência assume a responsabilidade de levá-lo adiante assim mesmo? Neste caso o risco aumenta demais, e a equipe tem que usar técnicas que possibilitem gerenciar melhor esse risco. Por exemplo, Métodos Ágeis e o RUP-Rational Unified Process podem ser usados de maneira iterativa-incremental. Significa que é possivel ir desenvolvendo o projeto por incrementos, gerenciando melhor o risco em cada incremento, melhorando a curva de aprendizagem da equipe e preparando-a melhor para a próxima iteração. E aí os planos são detalhados a cada nova iteração, para um horizonte de tempo mais curto e com menores chances de um erro grave de avaliação.

Bom, para a Engenharia de Software a origem de tudo isso é o Modelo de Desenvolvimento em Espiral, introduzido pelo Barry Boehm em 1986 como uma alternativa ao modelo Cascata, que era o existente na época e suficiente para lidar com os problemas de desenvolvimento de software até então. O que o modelo Espiral tem de muito relevante, é a introdução explícita do conceito de desenvolvimento incremental, e da Análise de Risco antes de dar o próximo passo no Planejamento. Hoje a área de Risco faz parte do conhecimento em Gerência de Projetos, estando fortemente presente no modelo PMBOK (Project Management Body of Knowledge) e nos modelos de maturidade organizacionais mais adotados, como o CMMI e mpsBR.

Postagens relacionadas: Sandy, lições em avaliação de riscos; Riscos e a disponibilidade de informação

(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com)

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Marcado com:
Publicado em Economia, Engenharia de Software, Qualidade de processo de software em Micro e Pequenas Empresas

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: