Почему найм новых разработчиков не всегда помогает ускорить разработку

Решение нанять ещё людей почти никогда не принимается заранее. Мало кто рассчитывает так: через полгода нам понадобится ещё один разработчик, поэтому возьмём его сейчас, спокойно введём в проект, и к нужному моменту он будет готов. На практике всё наоборот. Сначала наступает момент, когда становится понятно, что в сроки мы не попадаем, и уже после этого появляется задача срочно ускориться.

И первое, что приходит в голову, это взять больше исполнителей. Логика здесь простая и на вид безошибочная: если один разработчик делает 10 задач, то два разработчика сделают 20. А значит, чем больше параллельных потоков, тем быстрее мы нагоним.

Вот с этого места и начинаются проблемы.

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

Дальше разберём по порядку, что именно идёт не так.

Начнём с самого найма. Вряд ли у вас есть запас людей, которых можно просто перекинуть с других проектов, поэтому почти наверняка вы будете нанимать снаружи. А времени на это нет: сроки горят уже сейчас. Разгуляться с подбором не получится, вы не можете позволить себе выбирать три месяца, и постараетесь закрыть вакансию в пределах нескольких недель.

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

Теперь про календарь. По рынку средний срок закрытия ИТ-вакансии составляет 45-60 календарных дней. Прибавьте к этому две недели отработки на прежнем месте, и получится, что человек, которого вы начали искать сегодня, выйдет к вам в лучшем случае через два месяца. Проект, который горит прямо сейчас, за эти два месяца либо сгорит, либо как-то доедет сам. То есть в краткосрочной перспективе найм проблему не решает в принципе: к тому моменту, когда человек выйдет, решать будет уже нечего. Вы потратите время руководителя и рекрутера на подбор, который к сроку не успевает.

Кажется, что через неделю новый разработчик начнёт закрывать задачи. Это не так.

Первая неделя уходит на доступы, технику и учётные записи: кому-то нужно выдать права, завести в системах, собрать ссылки, настроить окружение. Это не чья-то нерасторопность, это просто работа, которую кто-то должен сделать.

Дальше человеку нужно разобраться в проекте. Он не знает, что в каком модуле лежит, не видел вашу архитектуру, не понимает, почему решения приняты именно такие. Дальше есть два пути, и оба стоят денег. Либо он разбирается сам, то есть читает код и очень медленно продирается через первые задачи. Либо он идёт к команде, и тогда ваши люди начинают объяснять, где что находится и почему устроено так, а потом ещё и перепроверять за ним. Мощность той команды, которая у вас уже была, в этот момент падает.

Сколько это стоит, можно посмотреть по открытым оценкам. Они расходятся, но порядок понятен. Если считать только явно выделенное на новичка время, получается около 20 часов тимлида, 10-15 часов продакт-менеджера и коллег и около 5 часов HR, то есть 30-40 часов. Если считать всё, что реально уходит у команды, адаптация одного разработчика обходится в 120-150 часов рабочего времени. Тратятся они не разом, а примерно в первые два месяца: руководитель отдаёт новичку около четверти своего времени в первый месяц и около десятой части во второй. Полное вхождение в проект занимает 4-6 недель, полная автономия наступает к третьему месяцу, а в части компаний онбординг растягивается до трёх с половиной месяцев.

Если перевести эти часы в людей, картина становится нагляднее. 120-150 часов, размазанные по первым двум месяцам, это примерно половина одного разработчика, выключенного из работы. То есть, нанимая человека, вы на это время фактически вынимаете из команды половину другого. А на горящем проекте и при слабом подборе выходит и больше: вводящий тратит до двух третей своего времени.

Сложим всё вместе и посчитаем.

Первые два месяца команда работает не в полную силу, потому что часть ресурса ушла на ввод нового человека. Условно, вместо единицы вы получаете половину. Ещё через два месяца новичок начинает что-то закрывать сам, и вы выходите, допустим, на полторы единицы. И только ещё через два месяца команда работает за две.

Теперь вопрос: если до конца проекта у вас оставалось полтора-два месяца и вы хотели нагнать отставание, в какой момент вы его догоняете? Ни в какой. На этом отрезке вы только теряете время.

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

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

Часть работы взаимосвязана: одно нельзя начать, пока не готово другое, две задачи нельзя отдать двум людям, потому что они правят один и тот же кусок, третья ждёт решения по архитектуре. По моей оценке реально распараллелить удаётся не больше 60% работы, а оставшиеся 40% так или иначе выстраиваются в очередь. И если вы уже разложили работу на столько потоков, на сколько она раскладывается, следующий человек не даст ничего, потому что параллелить больше нечего.

Сверху ложатся издержки, которых при меньшей команде не было. Людям нужно чаще синхронизироваться, то есть больше разговаривать. Веток становится больше, их приходится чаще сливать, разруливать конфликты и перепроверять результат. Да и количество связей внутри команды растёт быстрее, чем количество людей: в команде из 3 человек связей 3, из 6 уже 15.

Поэтому плюс один человек никогда не означает плюс единицу производительности. Первый добавленный даёт примерно 0,75, каждый следующий в лучшем случае 0,5, а дальше и того меньше.

Это, пожалуй, главное. Кажется, что проект движется медленно и нужно просто больше рук. При этом никто не разобрался, почему он движется медленно.

А причина может быть совсем не в количестве разработчиков. Процесс может быть выстроен криво. Или где-то есть узкое место, в которое упирается всё остальное, и вы его просто не посмотрели.

Что, если задачи доезжают медленно не потому, что некому писать код, а потому, что медленно проходит ревью? Тогда новый разработчик просто сильнее нагрузит то горлышко, которое уже было узким.

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

Та же история с тестированием. Тестирование прекрасно справлялось с потоком от двух разработчиков. Вы наняли ещё разработчиков, а тестировщиков не наняли. Теперь тестирование встаёт колом, задачи лежат в очереди, разработчики сидят без обратной связи и ждут, когда им вернут ошибки. Скорость не выросла, а зарплатный фонд вырос.

Смотреть на это можно с разных сторон, но вывод один: пока вы не поняли, где именно стоит очередь, добавление людей в начало конвейера скорости не даёт. И считать надо не только то, где очередь стоит сейчас, но и то, где она встанет после того, как вы добавите людей. Любое расширение на одном участке перекладывает нагрузку на следующий, и важно заранее понимать, выдержит ли он.

Чтобы не выглядело так, будто добавлять людей нельзя никогда. Можно, и иногда нужно.

Расширение работает, когда вы организуете отдельный поток работ, а не подсаживаете человека в существующий. Хороший пример: у вас две продуктовые команды и большой поток багов. Вы собираете отдельную команду, которая разбирает баги и чинит их по результатам тестов, чтобы продуктовые команды не тормозили на этом. Вот здесь добавление людей даёт ровно то, чего от него ждут.

Второй сценарий, когда у вас есть пласт второстепенных задач: они достаточно простые, не критичные, и их не нужно жёстко контролировать по качеству. Такой пласт можно отдать новому человеку целиком, и он не будет дёргать команду на каждом шаге.

Общий принцип простой: добавление людей помогает там, где работу можно отделить, а не там, где её нужно делить.

Теперь про то, что реально работает, когда сроки горят.

Признать ограничения проектного треугольника. У любого проекта есть три связанные между собой вещи: объём работ, сроки и бюджет. Это и называется проектным треугольником. Связаны они жёстко, поэтому управлять проектом, ничем при этом не жертвуя, не получится: потянув за один угол, вы обязательно сдвинете другой.

Если объём вы не меняете, то жертвовать остаётся либо качеством разработки, либо количеством ресурса. Про количество ресурса мы только что разобрали, что в короткую оно не работает. Значит, остаётся качество: осознанно взять на себя технический долг и переделать позже. Либо всё-таки вернуться к объёму и сделать меньше.

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

Поискать ресурс внутри. Иногда рядом есть люди, которые уже погружены в проект, но по каким-то причинам задачами не занимаются.

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

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

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

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

Но дальше вы упираетесь ровно в то же самое. Код начинает появляться быстрее, а проверять и принимать его должны те же люди, что и раньше. Цифры это подтверждают: по данным Faros AI, с распространением ИИ-инструментов количество влитых пул-реквестов выросло на 98%, а время на ревью выросло на 91%. То есть производительность генерации удвоилась, а узкое место целиком переехало в приёмку.

Получается та же картина, что и с наймом, только быстрее. Если у вас и без ИИ упиралось в постановку задач и в приёмку результата, то с ИИ упрётся туда же, просто очередь вырастет быстрее.

Поэтому правило здесь то же, что и с новым человеком: отдавайте агентам второстепенное, то, где цена ошибки невелика и где не нужно пристально контролировать качество. А критичное оставляйте там, где у вас выстроен контроль.

За годы работы через меня прошло больше 100 проектов, и одну вещь я могу гарантировать точно. История, когда приходит понимание, что все сроки уже горят, и в проект приходят с требованием срочно дать людей, не работает никогда. При этом начинают почти всегда именно с неё, потому что кажется, что новые руки сейчас всё и спасут.

Добавление ресурса всегда имело смысл ровно в одном случае: когда приходили заранее. То есть когда менеджер заранее понимал, что такой объём работ в текущую команду не помещается, и когда заранее было просчитано, во сколько потоков и как эта работа ляжет. Вот тогда, и только тогда, расширение команды действительно давало ускорение. А когда окончание проекта уже видно и надо заканчивать, не работает точно.

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

Поэтому если погружённого в проект человека у вас нет, не пытайтесь закрыть вопрос расширением команды на короткой дистанции. Ищите узкое место, договаривайтесь про объём и качество, смотрите на свой календарь. А расширять команду стоит тогда, когда на это у вас действительно ещё есть время.