Fred Brooks aprendeu da forma difícil: mais programadores podem atrasar ainda mais um projeto

Nos anos 1960, a IBM respondeu a um projeto de software atrasado do mesmo jeito que muitos gestores ainda respondem hoje: colocando mais gente. Fred Brooks viu a equipe passar de mil pessoas e aprendeu uma das leis mais contraintuitivas da engenharia de software.

Brooks comandava o trabalho do sistema operacional do IBM System/360, um dos projetos de computação mais ambiciosos da época. O hardware precisava servir a uma família inteira de máquinas. O software precisava tornar essas máquinas úteis. O cronograma estava escorregando.

A IBM adicionou pessoas. Depois adicionou mais.

O projeto não acelerou magicamente.

Brooks resumiria a lição numa frase:

“Adicionar mão de obra a um projeto de software atrasado o atrasa ainda mais.”

Isso virou a Lei de Brooks.

O erro é tratar pessoas como unidades de tempo intercambiáveis

Em uma planilha, a conta parece linear. Se uma pessoa precisa de doze meses, duas deveriam precisar de seis e quatro, de três.

Isso só funciona quando o trabalho pode ser dividido de forma limpa e todos começam em velocidade máxima.

Software raramente funciona assim.

Um engenheiro novo precisa aprender arquitetura, ferramentas, convenções, decisões anteriores, bugs já descobertos e tudo aquilo que ninguém documentou porque “todo mundo sabe”.

Alguém precisa transferir esse contexto — normalmente alguém que já está no caminho crítico.

A equipe ganha uma pessoa e temporariamente perde parte do tempo de outra.

A comunicação cresce mais rápido que o headcount

Duas pessoas têm uma relação para coordenar. Três têm três. Quatro têm seis. Dez podem ter quarenta e cinco relações em pares.

Nem toda dupla precisa se reunir, mas cada pessoa nova cria interfaces: decisões de design, fronteiras de ownership, merge conflicts, dependências de deploy, reviews e premissas que precisam continuar alinhadas.

O trabalho se divide entre mais mãos enquanto o sistema de coordenação fica mais caro.

Alguns trabalhos nem podem ser paralelizados

O ponto de Brooks não era simplesmente que reuniões são ruins.

Há tarefas com uma sequência inevitável. Não se depura completamente um comportamento ainda não implementado. Não se integra com segurança componentes cujas interfaces ainda mudam. Não se valida uma correção de produção antes de entender a falha.

Adicionar pessoas a uma tarefa sequencial não divide o calendário. Pode apenas colocar mais coordenação ao redor de algo que continua precisando acontecer em ordem.

Isso não significa que equipes pequenas sejam sempre melhores

A Lei de Brooks é repetida de forma simplista demais. Projetos grandes precisam de organizações grandes. O próprio System/360 estava muito além da escala de uma equipe pequena.

A pergunta não é se pessoas ajudam. É quando ajudam.

Se o trabalho é independente, as interfaces são estáveis, o onboarding é barato e as pessoas chegam antes da crise, capacidade extra pode ser extremamente valiosa.

Se o projeto já está atrasado porque a arquitetura é confusa, a integração falha ou ninguém concorda sobre o que significa “pronto”, dez pessoas novas podem apenas multiplicar a incerteza.

Headcount não corrige um modelo mental ausente.

A IA cria a mesma ilusão em uma nova escala

Hoje os “novos membros” nem precisam ser humanos.

Agentes de programação com IA podem gerar código, testes e pull requests em enorme velocidade. Um gestor pode olhar esse output e sentir que a capacidade foi multiplicada da noite para o dia.

Mas alguém ainda precisa revisar mudanças, entender como o código gerado interage com o sistema existente, decidir quais abstrações merecem ficar, resolver conflitos e responder quando produção se comporta de forma diferente do prompt.

Gerar trabalho pode ficar mais rápido do que integrar entendimento.

É a Lei de Brooks com roupa moderna.

Antes de adicionar pessoas, pergunte o que realmente está atrasado

O trabalho é divisível? Uma nova pessoa pode assumir uma parte independente sem sincronização constante?

A arquitetura está estável o suficiente para ser ensinada? Se os veteranos não conseguem explicá-la, onboarding espalha confusão.

Quem vai treinar os novos? Conte esse tempo de verdade.

O gargalo é código ou decisão, testes, integração, clareza de produto ou deploy?

A capacidade extra chegará antes do prazo ou depois que o custo de coordenação consumir o tempo restante?

Brooks não aprendeu sua famosa lei em uma sala de aula. Aprendeu gerenciando software para um dos sistemas mais importantes da IBM e vendo uma resposta intuitiva ao atraso tornar a coordenação ainda mais difícil.

Na próxima vez que um projeto de software estiver atrasado, pergunte antes de contratar mais cinco pessoas: faltam mãos — ou falta clareza?

Fontes

• Computer History Museum — Frederick P. Brooks Jr.
• IBM — história do System/360, incluindo o problema de software e a Lei de Brooks
• Addison-Wesley / Pearson — The Mythical Man-Month
• Fred Brooks — No Silver Bullet
• Imagem destacada — Fred Brooks; copyright SD&M, CC BY-SA 3.0 via Wikimedia Commons. Adaptada para 16:9; a obra derivada permanece sob CC BY-SA 3.0.