Источник: https://koreysha.ru/articles/paradoksalno-no-dobaviv-esche-paru-razrabotchikov-vy-ne-razgruzi/ Язык: русский [← Все статьи](https://koreysha.ru/articles/) УПРАВЛЕНИЕ / КОМАНДЫ # Парадоксально, но добавив еще пару разработчиков, вы не разгрузите команду Виктор Корейша 21 декабря 2021 г. 4 мин чтения В этой статье - [Краткосрочная перспектива](https://koreysha.ru/articles/paradoksalno-no-dobaviv-esche-paru-razrabotchikov-vy-ne-razgruzi/#section-1) - [Среднесрочная перспектива](https://koreysha.ru/articles/paradoksalno-no-dobaviv-esche-paru-razrabotchikov-vy-ne-razgruzi/#section-2) - [Долгосрочная перспектива](https://koreysha.ru/articles/paradoksalno-no-dobaviv-esche-paru-razrabotchikov-vy-ne-razgruzi/#section-3) - [Что же, выхода нет?](https://koreysha.ru/articles/paradoksalno-no-dobaviv-esche-paru-razrabotchikov-vy-ne-razgruzi/#section-4) - [Но ведь как-то команды растут?](https://koreysha.ru/articles/paradoksalno-no-dobaviv-esche-paru-razrabotchikov-vy-ne-razgruzi/#section-5) Представим такую ситуацию в проекте: задач много; команда зашивается; некогда думать и нужно фигачить; до дедлайна время ещё есть, но уже видно, что его недостаточно. Если вам это знакомо, то, вероятно, вы думаете, что вам не хватает парочки сильных мидлов в команду прямо сейчас. Но, скорее всего, это не так. И расширяя команду, вы сделаете только хуже. ## Краткосрочная перспектива Новые люди в проекте затормозят его, а не ускорят. Есть даже шутка: что 2 программиста сделают за 2 дня, то 4 программиста сделают за 4 дня. Во-первых, новых разработчиков нужно погружать в контекст. Показывать особенности ваших процессов, вводить в доменную область, разбираться в архитектуре проекта. Это ещё если нет никаких расхождений по стеку и других сложностей. Причем, нужны не только время и силы «новичков», но и ресурсы команды. Во-вторых, мы увеличиваем количество связей между людьми. Напомню, что оно растет экспоненциально. Для команды из 5 человек – 10 попарных связей, а для 7 уже 21 связь. Команде нужно общаться. Если вы думаете, что у вас схема «звезда», когда каждый разработчик взаимодействует только с PM-ом, то, скорее всего, вы ошибаетесь. В сложных, не детерминированных изначально системах, где в процессе работы принимаются проектные решения, попарное взаимодействие необходимо. В-третьих, размывается ответственность. У «старичков» есть повод спихнуть «душные» задачи и немного расслабиться. Ну а «новички» пока слабо владеют контекстом и морально не принимают на себя ответственность за весь проект в целом. Это происходит даже тогда, когда команда сильно мотивирована. А в нашем случае, вероятно, с мотивацией уже есть проблемы. ## Среднесрочная перспектива «Хорошо» — скажет внимательный читатель. Но ведь все это пройдет через месяц-другой. Если сроки позволяют, то почему бы и не расширить команду? Но за первой волной проблем, придет вторая. У большой команды, окажется, что все не мержится так легко, без единого конфликта, как все привыкли. Код ревью, который был в ответственности одного тимлида становится узким горлышком. Фичи не дробятся на 5 частей так легко, как дробились на две. Короче, всплывут проблемы в организации процесса, которые раньше никого не волновали. И их придется решать, а это дополнительная работа. ## Долгосрочная перспектива «Ну хорошо» — скажет мой воображаемый оппонент — «Но ведь и эти все вопросы решатся, уж через полгода то у нас будет более сильная команда?». И я отвечу что да, будет. Но есть и другая беда — эта более сильная команда будет дороже стоить. Причем не только на сумму зарплаты новых разработчиков. Добавятся накладные расходы, вырастут потери из-за новых процессов. В итоге, бизнес захочет, чтобы эта новая команда делала больше работы. Ну и мы автоматически вернулись в точку А, только теперь в чуть большем масштабе. ## Что же, выхода нет? Просто мы изначально подошли к решению проблемы не стой стороны. Если у вас уже беда в проекте. Если разработчики жалуются, что им вздохнуть некогда. Если вся команда фигачит много, но до результата все дальше и дальше. Значит вы столкнулись с проблемой управления. А такая проблема не решается подкидыванием дров в топку, или, в нашем случае, программистов на проект. Такая проблема решается отстраиванием процессов. А вот как все это правильно диагностировать и что потом делать — предмет другого разговора. ## Но ведь как-то команды растут? Скептик может сказать, что я рублю с плеча. И, если бы все сказанное было правдой, то никакие команды никогда бы не росли. Но, во-первых, реальный рост команд действительно очень ограничен. И все крупные проекты, при достижении определенного масштаба не увеличивают команды до бесконечности, а дробят их на несколько. Хочу обратить внимание скептика, что я обозначил конкретные условия, в которых растить команду без предварительного изменения подхода к управлению, на мой взгляд, плохой план. В других случаях, рост команды не просто возможен, но, иногда, и необходим. Но их мы обсудим отдельно, если будет такое желание. Число попарных связей растёт квадратично — n × (n − 1) / 2: 10 связей для пяти человек и 21 для семи. Впервые опубликовано 21 декабря 2021 г. в [блоге koreysha.ru ↗](https://koreysha.ru/all/paradoksalno-no-dobaviv-esche-paru-razrabotchikov-vy-ne-razgruzi/). Авторский текст сохранён; описанные обстоятельства относятся ко времени публикации. ПРОДОЛЖИТЬ ЧТЕНИЕ ## Рядом по теме [Как я диагностирую проекты, когда они болеютЧитать →](https://koreysha.ru/articles/kak-ya-diagnostiruyu-proekty-esli-oni-boleyut/)[Как сделать процессы прозрачнее?Читать →](https://koreysha.ru/articles/kak-sdelat-processy-prozrachnee/)