Contratar mais desenvolvedores para aumentar a entrega resolve?

Quando a entrega atrasa, a resposta mais comum é abrir vagas. Às vezes funciona, mas dependendo, pode até piorar, porque quem já entrega tem que parar para ensinar quem está chegando. Este guia ajuda quem decide o orçamento a descobrir se a contratação resolve o problema ou só muda ele de lugar.

Em resumo

• Contratar mais desenvolvedores só acelera a entrega quando o limite do time é capacidade, e não prioridade, dependência, revisão ou dívida técnica.
• Quem entra consome tempo de quem já entrega, então o ritmo do time costuma cair antes de subir.
• A Lei de Brooks, de 1975, descreve esse efeito: acrescentar gente a um projeto atrasado pode atrasá-lo ainda mais.
• Contratar tende a compensar quando o trabalho pode ser dividido, o time está de fato no limite e existe processo para receber a pessoa.
• Antes de abrir a vaga, vale checar o gargalo, o preparo do onboarding e o tempo que o projeto ainda tem pela frente.
• Medir capacidade com dados evita decidir por impressão.

O reflexo de pedir mais gente

Quando uma entrega importante atrasa, o raciocínio parece óbvio: se o time não dá conta, falta gente. A conta no papel também parece simples: mais uma pessoa, mais uma fatia de trabalho entregue por semana.

O problema é que essa conta supõe duas coisas: que a pessoa nova entra produzindo no primeiro dia e que o trabalho pode ser dividido sem custo. Na prática, nenhuma das duas costuma ser verdade. O resultado é uma decisão cara, que leva meses para ser desfeita, tomada com base numa impressão sobre o time e não numa leitura do que de fato limita a entrega.

Antes de contratar: qual é o gargalo real?

Capacidade é só uma das causas possíveis para uma entrega lenta, e a que mais pede contratação. A tabela abaixo ajuda a separar o sintoma que o líder vê da causa provável.

Sintoma que o líder vê	Causa provável	Contratar resolve?
O roadmap não cabe no tempo e o time vive no limite, sem folga para imprevistos	Falta de capacidade	Pode resolver, se o trabalho puder ser dividido
Muita coisa começada e pouca terminada	Prioridades demais ao mesmo tempo	Não: reduza o que roda em paralelo
O time espera outra área, uma aprovação ou uma decisão	Dependências entre times	Não: mais gente aumenta a fila
Código pronto parado à espera de revisão	Revisão como gargalo	Raramente: o limite passa a ser quem revisa
Toda mudança simples demora e quebra outra coisa	Dívida técnica	Não sozinha: quem chega herda o mesmo atrito

O custo escondido de quem chega

Em 1975, Frederick Brooks publicou o livro The Mythical Man-Month com uma observação que ficou conhecida como Lei de Brooks: acrescentar gente a um projeto de software atrasado o atrasa ainda mais. Segundo o resumo do Umbrex, há três motivos.

• Onboarding: quem chega primeiro consome capacidade em vez de somar. Pessoas experientes param para passar contexto, convenções e conhecimento do negócio.
• Comunicação: os canais possíveis entre pessoas crescem mais rápido que o time. Um time de 5 pessoas tem 10 canais possíveis; com 6, são 15. Mais canais significam mais alinhamentos, reuniões e chances de ruído.
• Trabalho que não se divide: decisões de arquitetura, integração e depuração complexa dependem de poucas pessoas e acontecem em sequência. Mais gente não as paraleliza.

O tempo até a pessoa nova render também não é curto. Em artigo de 25/08/2021, a Built In relata times que levaram de sete a nove meses para deixar novos contratados totalmente produtivos. O prazo varia muito com o produto, a documentação e o apoio disponível, mas a mensagem para quem decide é clara: o retorno da contratação não chega no mês seguinte, e o custo chega antes.

Quando contratar funciona de fato

Nada disso significa que contratar seja um erro. Significa que a contratação funciona melhor quando algumas condições estão presentes.

• A capacidade está esgotada de forma sustentada, e não só em um pico. O time entrega o que consegue, o backlog cresce e não há fila de revisão nem espera por outras áreas explicando o atraso.
• O trabalho pode ser dividido. Há itens independentes no backlog, que uma pessoa nova consegue pegar sem depender de três colegas.
• O projeto tem tempo pela frente. O investimento de onboarding precisa de meses para se pagar. Cory Rylan, em artigo de 07/04/2020, sugere ampliar o time depois que arquitetura, convenções e práticas de teste estão estabelecidas, porque isso reduz o tempo de adaptação de quem entra.
• Existe onboarding preparado. Documentação atualizada, um mentor definido e primeiras tarefas pequenas fazem a curva subir mais cedo. A Built In destaca onboarding estruturado, documentação viva e comunicação assíncrona como práticas que encurtam esse prazo.
• O perfil do profissional combina com a necessidade. Para uma tarefa que exige pouco contexto, um especialista pontual pode render mais que um contratado que precisa aprender o produto inteiro.

Roteiro de decisão: contratar, esperar ou resolver o gargalo

As perguntas abaixo seguem uma ordem. Se a resposta for “não” em alguma etapa, o caminho muda antes de a vaga ser aberta.

1. O limite do time é capacidade? Se não, resolva primeiro o gargalo (prioridades, dependências, revisão ou dívida técnica).
2. O trabalho pode ser dividido? Se não, mais gente não acelera. Reveja escopo ou arquitetura.
3. O time tem folga para ensinar nas próximas semanas? Se não, espere passar a janela crítica ou considere um perfil de pouco contexto.
4. O onboarding está pronto? Se não, prepare documentação, mentor e primeiras tarefas antes de abrir a vaga.
5. Todas as respostas foram “sim”? Então contratar tende a fazer sentido. Acompanhe o ritmo do time nas quinzenas seguintes para saber se a curva realmente subiu.

Perguntas frequentes

Contratar mais desenvolvedores acelera a entrega?

Só quando o limite do time é capacidade e o trabalho pode ser dividido. Se o atraso vem de prioridades demais, dependências, revisão parada ou dívida técnica, uma pessoa nova tende a aumentar a fila. Nas primeiras semanas, ela também consome tempo de quem já entrega, então o ritmo costuma cair antes de subir.

Quanto tempo leva para um novo desenvolvedor começar a produzir?

Depende do produto, da documentação e do apoio disponível. A Built In relata, em artigo de 25/08/2021, times que levaram de sete a nove meses para deixar um novo contratado totalmente produtivo. O caminho mais seguro é olhar as suas contratações anteriores e planejar com o seu próprio prazo, não com uma média de mercado.

O que é a Lei de Brooks?

É a ideia, formulada por Frederick Brooks no livro The Mythical Man-Month (1975), de que acrescentar pessoas a um projeto de software atrasado pode atrasá-lo ainda mais. O motivo é o custo de integrar quem chega e o aumento da comunicação, que consomem a capacidade de quem já estava produzindo.

Como saber se meu time precisa de mais gente ou de menos fricção?

Compare o que o time entrega com o que consegue sustentar. Se as pessoas estão no limite e o backlog tem itens independentes, falta capacidade. Se há muito trabalho começado e pouco concluído, filas de revisão ou espera por outras áreas, o problema é de fluxo, e contratar não resolve.

Contratar perto de um prazo ajuda?

Raramente. Quanto mais perto do prazo, menos tempo o investimento em onboarding tem para se pagar. Nesses casos, costuma funcionar melhor reduzir escopo, proteger o time de interrupções ou trazer um perfil especializado em uma tarefa que exija pouco contexto, em vez de formar alguém novo.

Próximo passo

A decisão fica mais segura quando capacidade deixa de ser opinião. O Devint, plataforma de avaliação de desempenho de times de desenvolvedores, acompanha as dimensões de ritmo de entrega e registro de horas do DevScore – nosso sistema de pontuação – o que ajuda a separar falta de capacidade de problemas de fluxo e a ver o efeito de uma contratação nas semanas seguintes. Veja como o Devint lê a capacidade do seu time de tecnologia.

Fontes consultadas

• Brooks’ Law, Umbrex (consultado em 03/11/2026)
• Brooks’ Law and software development teams, Cory Rylan, DEV Community, 07/04/2020 (consultado em 03/11/2026)
• Artigo sobre produtividade de novos desenvolvedores, Kristen Buchanan, Built In, 25/08/2021 (consultado em 03/11/2026)
• Frederick P. Brooks Jr., The Mythical Man-Month, 1975 (citado a partir das fontes acima)