Adicionando um novo membro em um projeto atrasado: o mito do homem-hora
Por Paulo Silveira em 15/08/06Ontem fui almoçar com alguns desenvolvedores da Nextel e da 2RP Informática, no Súbito da avenida Paulista (creio que as palavras que mais se ouvem naquele restaurante são Lasagna, Oracle, .NET e Java).
Durante a digestão das massas conversamos sobre os assuntos que estão na boca do desenvolvedor: frameworks, servidores de aplicação antigos, as brigas com o DBA, o super aquecimento do mercado Java e atrasos nos projetos.
A questão girou em torno de adicionar mais pessoas em um projeto que já está atrasado. Lembro-me de anos atrás o Michael ter conversado comigo sobre esse assunto, e só depois vim a ler The Mythical Man-Month, um livro com diversos ensaios sobre engenharia de software e gerenciamento de projetos.
Em um dos principais ensaios, o qual o entitula, Fred Brooks disserta a respeito do mito do homem-hora (em inglês homem-mês, mas aqui no Brasil o termo usual das consultorias é medido em horas, por isso escolhi essa tradução).
Desse livro cunharam a lei de Brooks:
Adicionar desenvolvedores para um software atrasado deixa-o mais atrasado ainda.
Não vou entrar em detalhes, apesar do ensaio ser bem curto, mas o autor critica severamente o hábito de mensurar projetos através da quantidade de homens-horas que este irá levar. Ele começa com um exemplo de um projeto com cronograma de 4 meses e 3 programadores, e que depois de um mês de trabalho, percebe-se que há a necessidade de mais um mês. As opções então são mostradas: atrasar o projeto ou segurar o projeto e colocar mais pessoas (e você vai ficar surpreso de quantas pessoas a mais serão necessárias para isso). Fortemente indicado, o livro já tem 25 anos e há uma edição comemorativa com alguns ensaios reescritos.
a velha história que os gerentes de projetos não entendem nunca: “três mulheres juntas não dão a luz a uma criança em três meses”.
O problema é que na grande maioria das vezes o projeto se atrasa não por falta de produtividade, mas por motivos de definições que não foram feitas no tempo que deveriam ser feitas e por requisitos que surgem no meio do caminho, enquanto alguém de um lado diz: “Mas não tinha essa funcionalidade, não falamos sobre isso”; e do outro: “Está claro a necessidade de isso, tem certeza que não falamos sobre isso em nenhuma reunião? Eu disse que precisaria dessa funcionalidade”.
But… esse é o mundo dos projetos de construção de software – que as vezes mais complicam do que ajudam. rs…
Comment by Leandro Silva — September 24, 2006 @ 11:07 pm