Blog do Mister M

A maioria dos projetos de desenvolvimento que falham tem prazos impossíveis. E, quando estes prazos são definidos por um departamento comercial ávido de ganhar sua comissão, a razão disso é óbvia. Infelizmente, porém, quando esta responsabilidade está com os desenvolvedores o resultado não é muito diferente. Como mudar isso?

A verdade é que, para que um cronograma tenha o menor desvio possível é necessário conhecer:

• As funcionalidades a serem desenvolvidas a ponto de desmembrá-las em tarefas;
• O cliente, de modo a saber a qualidade, nível de documentação e detalhes que o mesmo pode solicitar da sua aplicação, bem como a sua disponibilidade;
• Os recursos que farão parte do projeto a ponto de saber a produtividade deles em cada tipo de tarefa, bem como sua freqüência de ausências (problemas de saúde, pessoais etc.);

Contudo, a maioria das pessoas diria que não é possível conhecer nenhum dos três. E isso explica por que os prazos quase sempre estouram :-) Na maioria dos casos, realmente não é possível ter essas informações no nível desejado para se elaborar um cronograma que funcione, mas a idéia é chegar o mais próximo possível deste cenário para que o desvio não seja tão grande ou ainda contornar cenários comuns.

Por exemplo, digamos que a documentação e/ou nível de informações a respeito das funcionalidades é escassa demais. Provavelmente, a melhor alternativa seria desmembrar o projeto em dois: um projeto de análise de negócio e outro de desenvolvimento, sendo que o segundo terá um cronograma apenas quando o primeiro for encerrado. Se isto não for possível, o ideal é mostrar ao cliente a necessidade de obter o máximo possível de informações para que o cronograma (e o orçamento) proposto sejam reais. Se nada disto for possível, a última alternativa é analisar outros softwares semelhantes ao que o cliente está solicitando, fazer as estimativas baseadas neles e deixar claro que o cronograma proposto baseia-se naqueles produtos. Isto talvez faça com que o cliente se expresse a respeito do que quer exatamente, reduzindo ou aumentando o escopo e, conseqüentemente, o cronograma.

É extremamente importante ter as funcionalidades divididas em tarefas, pois isso permite alocar horas ou poucos dias a cada “fração” da funcionalidade, gerando uma precisão muito maior da duração da funcionalidade como um todo, além de permitir entender melhor o que pode ser paralelizado ou agrupado de forma a otimizar o cronograma. Ao fazer isto, geralmente percebe-se que as coisas “simples” vão demorar muito mais do que se esperava inicialmente.

O conhecimento do cliente é importante para determinar a extensão das tarefas e da documentação, mas especialmente para duas coisas: restrições tecnológicas e disponibilidade do cliente. É essencial, para se ter uma estimativa correta, saber quais tecnologias poderão ser utilizadas, bem como que tipo de padrões de código e documentação o cliente possui. Esta pode ser a diferença entre o projeto de três meses e o que leva um ano porque os desenvolvedores têm que lutar diariamente contra limitações dos frameworks ou da versão do JDK que usam ou porque têm que produzir grandes quantidades de documentos que têm de ser quase que completamente alterados a cada vez que o código é modificado.

Em quase todos os projetos é necessário obter informações adicionais do cliente à medida que o desenvolvimento é feito ou para que as funcionalidades já implementadas sejam validadas. Isto costuma ser um problema, visto que o cliente normalmente não se considera parte da equipe do projeto nem acha que depende dele o cumprimento do cronograma. Metodologias como XP motivam o envolvimento contínuo do cliente, mas nem sempre o cliente concorda com este grau de comprometimento com o projeto. Nestes casos, é necessário especificar no cronograma em que pontos a participação do cliente será necessária, por quantas horas, bem como os “pontos de parada”, i.e., pontos em que se o cliente não estiver disponível o projeto fica parado e deixar claro que é responsabilidade do cliente compensar tais falhas.

Uma vez que as tarefas do projeto estão definidas e que sabe-se como o cliente irá influenciar o projeto, o próximo passo é determinar a alocação de recursos para que seja possível determinar o tempo de cada uma delas. O modo ideal de se fazer isso é explicar aos próprios recursos as tarefas que você pretende alocar para eles, a fim de verificar se são realmente capazes de executá-las, bem como solicitar deles o tempo previsto para cada uma delas.

Obviamente, muitas pessoas não tem a mínima noção de quanto tempo realmente levam para cada tarefa. Por isso, o papel de quem faz o cronograma do projeto é ter dois números para auxiliar nesta etapa: a estimativa de horas ideais e o fator de desvio do recurso. As horas ideais são as horas que um determinado recurso mais confiável em estimativas diz que são necessárias para realizar a tarefa. Normalmente, o recurso confiável acaba sendo a própria pessoa que faz o cronograma ou alguém mais sênior na empresa. O fator de desvio do recurso refere-se a quantas vezes mais tempo aquele recurso leva para executar uma tarefa. Isto se deve a diferença de conhecimento, grau de concentração, capacidade técnica, taxa de “compartilhamento” de recurso (quando a pessoa é utilizada em outros projetos/tarefas ao mesmo tempo que faz o seu projeto) e outras razões. Obviamente, ambos os números só podem ser obtidos com a experiência e/ou medição de projetos anteriores. Comparando a estimativa do recurso com a sua estimativa, chega-se ao número de horas ideais e, multiplicando-se esse valor pelo fator de desvio, obtem-se o total de horas que o recurso deverá gastar.

A explicação acima leva em conta algo que a maioria dos que fazem cronogramas esquecem: recursos são pessoas e pessoas são únicas. Não existe Recurso Jr, Pleno e Sr; existe sim o José, a Maria e o João, que mesmo sendo todos plenos, por exemplo, gastam tempos diferentes para a mesma tarefa e que, para tarefas diferentes, não mantém a mesma taxa de eficácia.

Uma vez que se percebe isto, percebe-se também o quão difícil é fazer cronogramas quando os recursos são desconhecidos. A técnica das horas ideais ainda precisa ser utilizada, mas o fator de desvio terá também de ser estimado. A melhor forma de determinar o fator de desvio a usar é calculá-lo com base na média do fator de desvio dos recursos que serão possivelmente usado para a tarefa e decidir se deve-se considerar o pior caso, i.e., que o recurso com o maior fator de desvio será utilizado.

Ao final de tudo isso, usando-se uma ferramenta como o GanttProject, você provavelmente vai descobrir que o projeto vai levar muito mais tempo do que você pensava inicialmente. Ótimo, isso provavelmente também significa que agora você chegou a um cronograma realista. :-) Por mais que este não seja o cronograma que você vai apresentar ao cliente, por medo de ele não aceitar o tempo – o que eu não concordo -, é com este cronograma que você tem que calcular os custos, pois é o real.

Espero ter ajudado em alguma coisa ou ter deixado vocês completamente desesperados… :-)

This entry was posted on quinta-feira, junho 8th, 2006 at 18:33 and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.