Adicionando um novo membro em um projeto atrasado: o mito do homem-hora

Ontem 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.

Tags:

1 Comentário

  1. Leandro Silva 24/09/2006 at 23:07 #

    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…

Deixe uma resposta