Почему производительность команды нельзя увеличить только количеством людей

Если вы лид команды и к вам пришел менеджер с предложением нанять еще десяток программистов, то подумайте какую проблему он хочет решить:

1. Освоить ФОТ, что бы в следующем году его не урезали?
2. Создать по команде для каждого из заказчиков?
3. Ускорить разработку?

С первыми двумя вариантами разбирайтесь сами, бог вам судья, но про третий вариант я вот что думаю.

Всем известно что 9 женщин не родят ребенка за один месяц а 10 программистов не сделают фичу в 10 раз быстрей, но как донести эту мысль до того кто пришел с таким запросом?

Во первых давай вспомним про Закон Амдала. Этот закон говорит о том, что масштабировать мощности вычислений за счет распараллеливания программ нельзя бесконечно. Рано или поздно затраты на коммуникацию параллельных вычислений будут "съедать" большую часть пользы от параллельного выполнения. Кстати такой же закон есть в экономике: "закон убывающей отдачи", погугли

Вот визуализация того как растет число связей между людьми с ростом команды:

Если у вас есть один проект, в котором работают 3 программиста, то при добавлении еще 10 вы начинаете терять большую часть времени предыдущих разработчиков на: онбординг, коммуникацию, ревью и срачи за технологии.

Во вторых техдолг. Посмотри на код проекта. Он хорошо структурирован? У вас есть четкие правила именования, паттерны решения типичных задач? Архитектура "говорящая" по заветам Чистой архитектуры? Новому разработчику легко понять ваши правила?

Если нет, то каждый новый разраб будет пытаться дизайнить систему по своему и добавлять все больше хаоса в вашу систему. Чем больше хаоса, тем больше следующий разработчик будет фрустрировать и пытаться его исправить так как привык на прошлом месте. В итоге что? На поддержку проекта будет уходить больше времени, чем на фичи бизнеса. Все это можно называть developer experience (DX). Если он плохой, то разработчики работают плохо - очевидно.

Ну и наконец вспомним о том какие задачи разработчики чаще всего решают. Это проработанные спеки, где бизнес четко понимает цель задачи или это "хотелки" менеджеров без четкой документации и постоянными доработками и уточнениями в процессе?

Представь, что проект с отличным DX и с огромной командой каждый раз тратят время на созвоны с заказчиками для выяснения требований. Затем они переписывают раз за разом логику на основе новых "хотелок" и генерят десятки MR-ов, мешая друг другу и заставляя отдел QA страдать. Как много фичей доедут до прода в таком случае? Вот и я думаю, что не много и нужно ставить "фильтр" на требования, что бы увеличить их качество. Об этом, кстати, упоминается в докладе Безоценочная разработка

Получается, что для того что бы "ускорить команду" надо понять на каком из предыдущих этапов процессы тормозят, а не просто закидывать "ресурсами" отдел разработки.

Если ОЧЕНЬ СИЛЬНО УПРОЩАТЬ, то можно получить вот такую аналогию:

a - проработка задач
b - DX в проекте
c - количество людей

(a + b) * c = капасити команды

a = 0.1; b=0.2; c = 2
капасити 0.6

a = -0.1; b=0.2; c = 2
капасити 0.2

a = -0.1; b=0.2; c = 10
капасити 1

a = 2; b=0.2; c = 2
капасити 4.4

Вот и получается, что задача с ростом капасити довольно сложна и чаще всего связана совсем не с количеством людей, а с выстроенными процессами как в технической, так и в менеджерской плоскости.