AnnaMikhailov
New member
Помню проект, который мы тянули почти год: переписывали старый монолит на нормальную архитектуру. Сроки уже поехали, заказчик нервничал, и на планёрке прозвучало классическое: давайте усилим команду, найдём ещё трёх разработчиков и догоним. Мне тогда казалось, что это очевидная арифметика: было четыре человека, станет семь, значит скорость вырастет почти вдвое.
Реальность оказалась жестокой. Первый месяц новые ребята не закрыли ни одной задачи, зато отняли время у тех, кто вводил их в курс дела. Второй месяц дал пару мелких правок, но принёс конфликты в системе контроля версий, дублирующие решения и бесконечные вопросы в чате. Скорость команды не выросла, а упала примерно на треть. Я сидел вечером над доской задач и не понимал, куда уходят силы.
Потом я наткнулся на мысль Фреда Брукса из книги про мифический человеко-месяц: добавление людей в проект, который уже опаздывает, делает его ещё более опоздавшим. Звучит как шутка, но за этим стоит простая механика. Новый человек не начинает работать сразу, он сначала учится: изучает код, инфраструктуру, историю решений, процессы. И учит его не абстрактный тьютор, а самые опытные люди в команде, те самые, которые и делают основную работу.
Второй механизм — коммуникация. Когда в команде четыре человека, связей между ними немного, и все в курсе, кто чем занят. Когда их семь, количество каналов общения растёт нелинейно: больше согласований, больше встреч, больше пересечений в одних и тех же файлах. Третий механизм — размер задачи. Не всякую работу можно распараллелить: если десять человек одновременно правят один и тот же модуль, они будут мешать друг другу, а не помогать.
При этом я не хочу сказать, что нанимать людей бесполезно, это было бы неправдой. Через полгода та самая команда из семи человек обгоняла прежнюю четвёрку в разы. Просто кривая выглядит как яма: сначала провал, потом рост. Беда в том, что в горящем проекте никто не готов ждать полгода, а руководство обычно ждёт результат уже к следующему спринту.
Позже я видел и обратный пример. Мы добавили двух разработчиков не в критический релиз, а на отдельный, хорошо изолированный сервис. У нас уже были нормальные описания проекта, локальный запуск одной командой и понятный набор первых задач на неделю. Новые люди вышли на самоокупаемость за две недели, и почти никто из ядра команды не отвлёкся надолго.
Из этого я вынес для себя несколько практических правил. Не усиливать команду в момент пожара, если проект уже горит: сначала стабилизировать и разгрести долги. Добавлять людей волнами, а не всех сразу, чтобы наставник успевал за ними. Готовить вход заранее — документацию, простые задачи, внятный онбординг. Считать не только скорость команды, но и время наставников, потому что это реальная стоимость. И честно отвечать себе на вопрос, можно ли вообще распараллелить работу или она упирается в одного человека.
А как было у вас? Приходилось ли вам вводить новых людей в команду прямо в разгар дедлайна — и что из этого вышло? Расскажите, у кого онбординг прошёл гладко, а у кого получилась та самая яма, из которой потом всё равно выросли нормальные результаты.
Реальность оказалась жестокой. Первый месяц новые ребята не закрыли ни одной задачи, зато отняли время у тех, кто вводил их в курс дела. Второй месяц дал пару мелких правок, но принёс конфликты в системе контроля версий, дублирующие решения и бесконечные вопросы в чате. Скорость команды не выросла, а упала примерно на треть. Я сидел вечером над доской задач и не понимал, куда уходят силы.
Потом я наткнулся на мысль Фреда Брукса из книги про мифический человеко-месяц: добавление людей в проект, который уже опаздывает, делает его ещё более опоздавшим. Звучит как шутка, но за этим стоит простая механика. Новый человек не начинает работать сразу, он сначала учится: изучает код, инфраструктуру, историю решений, процессы. И учит его не абстрактный тьютор, а самые опытные люди в команде, те самые, которые и делают основную работу.
Второй механизм — коммуникация. Когда в команде четыре человека, связей между ними немного, и все в курсе, кто чем занят. Когда их семь, количество каналов общения растёт нелинейно: больше согласований, больше встреч, больше пересечений в одних и тех же файлах. Третий механизм — размер задачи. Не всякую работу можно распараллелить: если десять человек одновременно правят один и тот же модуль, они будут мешать друг другу, а не помогать.
При этом я не хочу сказать, что нанимать людей бесполезно, это было бы неправдой. Через полгода та самая команда из семи человек обгоняла прежнюю четвёрку в разы. Просто кривая выглядит как яма: сначала провал, потом рост. Беда в том, что в горящем проекте никто не готов ждать полгода, а руководство обычно ждёт результат уже к следующему спринту.
Позже я видел и обратный пример. Мы добавили двух разработчиков не в критический релиз, а на отдельный, хорошо изолированный сервис. У нас уже были нормальные описания проекта, локальный запуск одной командой и понятный набор первых задач на неделю. Новые люди вышли на самоокупаемость за две недели, и почти никто из ядра команды не отвлёкся надолго.
Из этого я вынес для себя несколько практических правил. Не усиливать команду в момент пожара, если проект уже горит: сначала стабилизировать и разгрести долги. Добавлять людей волнами, а не всех сразу, чтобы наставник успевал за ними. Готовить вход заранее — документацию, простые задачи, внятный онбординг. Считать не только скорость команды, но и время наставников, потому что это реальная стоимость. И честно отвечать себе на вопрос, можно ли вообще распараллелить работу или она упирается в одного человека.
А как было у вас? Приходилось ли вам вводить новых людей в команду прямо в разгар дедлайна — и что из этого вышло? Расскажите, у кого онбординг прошёл гладко, а у кого получилась та самая яма, из которой потом всё равно выросли нормальные результаты.