Представим такую ситуацию в проекте: задач много; команда зашивается; некогда думать и нужно фигачить; до дедлайна время ещё есть, но уже видно, что его недостаточно. Если вам это знакомо, то, вероятно, вы думаете, что вам не хватает парочки сильных мидлов в команду прямо сейчас. Но, скорее всего, это не так. И расширяя команду, вы сделаете только хуже.

Краткосрочная перспектива

Новые люди в проекте затормозят его, а не ускорят. Есть даже шутка: что 2 программиста сделают за 2 дня, то 4 программиста сделают за 4 дня.

Во-первых, новых разработчиков нужно погружать в контекст. Показывать особенности ваших процессов, вводить в доменную область, разбираться в архитектуре проекта. Это ещё если нет никаких расхождений по стеку и других сложностей. Причем, нужны не только время и силы «новичков», но и ресурсы команды.

Во-вторых, мы увеличиваем количество связей между людьми. Напомню, что оно растет экспоненциально. Для команды из 5 человек – 10 попарных связей, а для 7 уже 21 связь. Команде нужно общаться. Если вы думаете, что у вас схема «звезда», когда каждый разработчик взаимодействует только с PM-ом, то, скорее всего, вы ошибаетесь. В сложных, не детерминированных изначально системах, где в процессе работы принимаются проектные решения, попарное взаимодействие необходимо.

В-третьих, размывается ответственность. У «старичков» есть повод спихнуть «душные» задачи и немного расслабиться. Ну а «новички» пока слабо владеют контекстом и морально не принимают на себя ответственность за весь проект в целом. Это происходит даже тогда, когда команда сильно мотивирована. А в нашем случае, вероятно, с мотивацией уже есть проблемы.

Среднесрочная перспектива

«Хорошо» — скажет внимательный читатель. Но ведь все это пройдет через месяц-другой. Если сроки позволяют, то почему бы и не расширить команду?

Но за первой волной проблем, придет вторая. У большой команды, окажется, что все не мержится так легко, без единого конфликта, как все привыкли. Код ревью, который был в ответственности одного тимлида становится узким горлышком. Фичи не дробятся на 5 частей так легко, как дробились на две. Короче, всплывут проблемы в организации процесса, которые раньше никого не волновали. И их придется решать, а это дополнительная работа.

Долгосрочная перспектива

«Ну хорошо» — скажет мой воображаемый оппонент — «Но ведь и эти все вопросы решатся, уж через полгода то у нас будет более сильная команда?». И я отвечу что да, будет. Но есть и другая беда — эта более сильная команда будет дороже стоить. Причем не только на сумму зарплаты новых разработчиков. Добавятся накладные расходы, вырастут потери из-за новых процессов. В итоге, бизнес захочет, чтобы эта новая команда делала больше работы. Ну и мы автоматически вернулись в точку А, только теперь в чуть большем масштабе.

Что же, выхода нет?

Просто мы изначально подошли к решению проблемы не стой стороны. Если у вас уже беда в проекте. Если разработчики жалуются, что им вздохнуть некогда. Если вся команда фигачит много, но до результата все дальше и дальше. Значит вы столкнулись с проблемой управления. А такая проблема не решается подкидыванием дров в топку, или, в нашем случае, программистов на проект. Такая проблема решается отстраиванием процессов. А вот как все это правильно диагностировать и что потом делать — предмет другого разговора.

Но ведь как-то команды растут?

Скептик может сказать, что я рублю с плеча. И, если бы все сказанное было правдой, то никакие команды никогда бы не росли. Но, во-первых, реальный рост команд действительно очень ограничен. И все крупные проекты, при достижении определенного масштаба не увеличивают команды до бесконечности, а дробят их на несколько.
Хочу обратить внимание скептика, что я обозначил конкретные условия, в которых растить команду без предварительного изменения подхода к управлению, на мой взгляд, плохой план. В других случаях, рост команды не просто возможен, но, иногда, и необходим. Но их мы обсудим отдельно, если будет такое желание.