Planejamento e Acompanhamento de Projetos de Software
(artigo originalmente publicado na revista Developer's Magazine - edição impressa - Junho/2003, revisado em Outubro/2005 )
    Por Álvaro D'Alessandro

Os Principais Problemas Típicos

1a Tormenta: “Por que planejar se tudo tende a mudar durante o projeto?”

Entre aqueles que classificam qualquer atividade que não seja de codificação ou testes como sendo "burocracia" ou "perda de tempo", essa é uma das perguntas mais freqüentes e em muitos casos é reflexo de uma crença pessoal fortíssima.

Apesar da resposta estar contida na própria pergunta e por mais óbvio que seja, ainda há quem ignore ou simplesmente não percebe a importância do planejamento.

O primeiro passo para a mudança de cultura é passar a enxergar o trabalho segundo os conceitos de "projeto" e entender os benefícios dessa nova postura. Em uma definição simples, um projeto é um esforço com início e fim definidos, que visa produzir ou melhorar algo e envolve recursos finitos. Seja um esforço para desenvolvimento de um software novo, ou para uma "manutenção" ou mesmo de aquisição de pacotes de software, etc, qualquer caso pode constituir um projeto.

O segundo passo é aceitar algumas certezas da vida: a primeira delas é o fato de que as coisas mudam e mudam sempre. Isso de modo algum é exclusividade do mundo de tecnologia. Porém, à medida que repetimos a execução de uma atividade, (produção de software, por exemplo) nos tornamos mais capazes de identificar os riscos recorrentes associados ao trabalho em questão e por conseqüência natural podemos tomar atitudes que reduzam o risco, desde que nos planejemos para tal (sabe aquela fábula da "cigarra e a formiga"? Pois é um bom exemplo de planejamento e também da falta dele) e que haja acompanhamento sobre aquilo que foi planejado, para que na ocorrência de mudanças as atitudes apropriadas possam ser tomadas. Outra certeza é que há alguém esperando resultados (de preferência bons) em função do seu projeto e que os resultados devem ser tão tangíveis quanto sejam possíveis de serem medidos.

Portanto, já que sempre existe risco associado ao projeto (em maior ou menor escala), já que os requisitos certamente irão mudar ao longo do tempo e principalmente, já que a execução desse projeto deve apresentar resultados para as partes interessadas, é fundamental planejar e acompanhar o projeto, registrando sua evolução, bem como os problemas ocorridos, soluções encontradas e resultados obtidos.

 

2a Tormenta: “Por que planejar se eu já sei o que tem que ser feito?”

Infelizmente temos, em geral, a "mania" de superestimar a capacidade de execução e subestimar os problemas. Some-se a isso a informalidade assombrosa que ronda o desenvolvimento de software juntamente com a desorganização da maioria dos profissionais de tecnologia e pronto: o circo está armado! O único problema é que nesse "circo" o espetáculo não é nada agradável.

O parágrafo anterior introduz a idéia do tripé que precisa ser desmontado, formado por:

-          Otimismo excessivo

-          Informalidade

-          Perda de informação

Para desmontar esse "tripé do mal", deve-se atacar as causas. Uma vez que o "otimismo excessivo" pode ser classificado como algo até certo ponto subjetivo, variável e dependente do profissional, é mais interessante abordarmos as questões da "informalidade" e da "perda de informação", pois a solução em ambos os casos é a definição de processos.
Um profissional bastante experiente pode até ser capaz de realmente "saber o que tem que ser feito" e, entendendo a extensão das atividades associadas, executar suas tarefas de modo organizado e dar prazos passíveis de cumprimento. Porém, nem um projeto nem uma Organização envolvem apenas um indivíduo.
O caráter coletivo e contínuo da atividade de produção de software justifica a necessidade da definição de processos para guiar o relacionamento entre a área de tecnologia e a(s) área(s) solicitante(s), diminuindo a informalidade e trazendo como benefício principal o aumento de comprometimento e envolvimento mútuo rumo a obtenção de soluções.

Pela mesma razão é necessário definir processos para estimar a complexidade e o tamanho do software, entre outros fatores, e criar, por exemplo, uma "base histórica" que seja alimentada continuamente e registre informações reais de produtividade versus "previsões", permitindo obter estimativas mais confiáveis e servir como parâmetro para identificação de possíveis desvios já no momento de planejamento (uma espécie de termômetro para identificar o "nível de otimismo", ou seja, uma alternativa viável para reduzir a subjetividade inerente ao ser humano).

 

3a Tormenta: “É mais burocracia! Já não dá tempo hoje, imagina tendo que fazer tudo isso!”

A preocupação é bem representada por uma pergunta muito comum no início de movimentos de melhoria de processos: "Quanto essas atividades de planejamento e acompanhamento vão onerar os projetos?"

A primeira resposta, genérica e talvez um pouco "rústica", seria: "Bem menos do que continuar trabalhando do modo atual". Porém, independentemente do caráter "silvícola" dessa resposta, é importante compreender a essência da afirmativa: o retorno é obtido em médio/longo prazo e uma vez obtido, internalizado pela equipe e percebido pelos usuários, dificilmente será descartado.

A essência de modelos como o CMM e CMMI é "construir a partir do lado certo", trabalhar do modo "correto" (como deveríamos trabalhar caso houvesse uma estrutura de processos bem definidos). Para isso são recomendadas algumas práticas e agrupadas segundo assuntos inerentes à produção de software (Planejamento, Acompanhamento, Requisitos, Garantia de Qualidade, entre outras).
Se a objetividade e o aumento da capacidade de execução são os princípios de um modelo que foi criado há quase duas décadas e se na prática há inúmeros exemplos de implementações que funcionam, trazendo resultados expressivos (tangíveis e intangíveis), será que não vale a pena quebrar a resistência e procurar a melhoria?

A Área de Processo (PA)

Na verdade tratam-se formalmente de duas áreas chave: “Planejamento do Projeto” e “Acompanhamento e Supervisão do Projeto”. Dada a grande relação entre as atividades e princípios das duas áreas e a baixa maturidade observada na vida prática, pode-se abordá-las de modo conjunto.

A PA de Planejamento do Projeto visa garantir que existem processos para planejamento e que a execução destes processos permite obter estimativas sobre o tamanho, complexidade, estabelecer compromissos entre os envolvidos, identificar os riscos associados ao projeto e definir um plano de trabalho exeqüível para o projeto.
A PA de Acompanhamento e Supervisão visa garantir que as atividades de acompanhamento existem e são realizadas para que haja visibilidade sobre o progresso do projeto e para garantir que, na ocorrência de desvios em relação ao que foi planejado, possam ser tomadas atitudes apropriadas, sempre mantendo os compromissos estabelecidos entre os envolvidos no projeto.

Estas duas áreas "andam de mãos dadas" e em termos práticos envolvem, entre outras atividades:

-          Definição dos processos e da técnica usada para estimativas

-          Definição do nível de formalidade associado ao processo como um todo, incluindo os artefatos gerenciais, métodos de registro de ocorrências e periodicidade do acompanhamento

-          Definição das “categorias de projetos” desenvolvidos pela Organização

-          Escolha do(s) ciclo(s) de vida

-          Definição das estratégias e processos para gerenciamento de riscos

Como em qualquer iniciativa de melhoria, a forma de execução (o "como fazer") é variável, existindo apenas um conjunto de práticas obrigatórias que devem ser atendidas (o “que deve ser feito”).
Essa independência é que permite que uma Organização de qualquer tamanho, utilizando qualquer técnica apropriada, possa planejar e acompanhar seus projetos de software de modo satisfatório.
Conclusão

O Planejamento e Supervisão de Projetos de Software são fundamentais em qualquer Organização que queira obter resultados tangíveis e melhorar tanto seus processos quanto seus produtos finais. Sobretudo é importante que as duas áreas sejam contempladas em conjunto, ou seja, não adianta nada efetuar um planejamento se não for seguido de acompanhamento e é ainda pior tentar estabelecer procedimentos de acompanhamento em projetos não planejados ou mal planejados. 

O sucesso na adoção deste tipo de processo depende das premissas adotadas (assumir a importância dos processos), da visão e modo de implantação (não querer que a mudança ocorra “da noite para o dia”) e do envolvimento dos profissionais para que haja quebra da resistência em relação ao que é “novo e desconhecido”, que naturalmente existe.
Havendo envolvimento, disposição para mudar e uma boa estratégia, qualquer Organização pode obter resultados positivos expressivos em conseqüência da adoção de processos que visam aumento de qualidade, previsibilidade e capacidade de execução.

 

Álvaro D'Alessandro é Sócio-Diretor da OAT Solutions e atua nas áreas de Gerenciamento de Projetos, Engenharia de Software e Qualidade de Software.

Pode ser contatado pelo e-mail alvaro.dalessandro@oatsolutions.com.br.