Команда из шести разработчиков, один новый инженер с окладом в 2,5 раза выше среднего и полгода до управленческого провала. Именно так выглядит найм рок-звезды в сценарии, который разбирает Habr / Карьера: вместо ускорения продукта компания получает bus factor, просевшее ревью и увольнения внутри команды. Для российского IT это болезненно знакомая история: рынок все еще любит искать спасителя, когда системе нужен не герой, а нормальная инженерная среда.
В колонке OTUS независимый эксперт Андрей Бирюков описывает почти учебниковый кейс. У компании был флагманский продукт и команда из шести мидлов; скорость разработки была приемлемой, но старый модуль трейдинга тормозил развитие. Тимлид, пришедший ускорять работу, нашел кандидата с 12-летним опытом, бэкграундом в крупной западной компании и репутацией инженера, который решает алгоритмические задачи быстрее всей панели интервьюеров. Ради него согласовали зарплату в 2,5 раза выше средней по команде. Ставка была простой: человек за три месяца вытащит тяжелый модуль, а дальше подтянет остальных.
На старте все выглядело почти идеально. За первые две недели новый сотрудник нашел два критических бага в старой системе, которые никто не замечал годами. Дальше началась та часть истории, которую компании любят замечать слишком поздно. Инженер отказался писать документацию, объясняя это примерно в духе «код сам все расскажет тем, кто умеет читать». Его код-ревью сводились к формуле «перепиши с нуля», без аргументов и без попытки чему-то научить коллег. Джуниор, попросивший помощи, получил ответ в стиле «я не репетитор». Через пару месяцев модуль работал, но изменять его мог только автор: архитектура оказалась слишком закрытой, код слишком плотным, а обсуждение решений слишком токсичным для остальной команды.
Самый неприятный эффект в таких историях не в том, что «звезда» ведет себя резко, а в том, что команда постепенно перестает быть командой. По сценарию из материала два сильных инженера уволились, потому что атмосфера стала невыносимой. Остальные начали молчать на планерках и реже предлагать идеи. То есть компания получила не плюс одного сверхпроизводительного разработчика, а минус несколько людей, которые раньше тянули продукт без спецэффектов. Через полгода сам герой истории работал уже по 60 часов в неделю, потому что все завязалось на него одного. Уволить его страшно: никто не понимает новый модуль. Оставить тоже страшно: можно потерять остатки команды.
Главный тезис Бирюкова в том, что ошибка здесь не в «плохом характере гения», а в управленческом сбое. Тимлид перепутал личную продуктивность с командной ценностью. На интервью проверяли алгоритмы, но не проверяли наставничество, готовность к документации, реакцию на чужую критику и способность работать в паре. Первый тревожный сигнал появился уже на второй неделе, когда новый разработчик отказался от документации, но это списали на темперамент сильного специалиста. Еще одна системная ошибка — отсутствие правил онбординга. Никто не проговорил, что в этой команде код без пояснений не считается завершенной работой, а ревью без объяснений не считается ревью. В такой пустоте сильный одиночка почти неизбежно навязывает свою модель: быстро, сложно, в одиночку.
Цифры в этой истории особенно полезны тем, кто привык считать только скорость поставки фич. Автор прямо раскладывает цену найма рок-звезды по понятным метрикам. Если весь модуль держится на одном человеке, уход такого сотрудника стопорит проект минимум на 2–4 недели. Скорость принятия pull request у обычных разработчиков, по описанному сценарию, падает на 50%: часть задач блокируется саркастичным ревью, часть времени уходит на попытки разобраться в чужой архитектуре. Один такой найм рок-звезды способен вытолкнуть из команды еще 2–3 сильных инженеров за полгода, а замена каждого обходится в 3–6 месячных окладов. Добавим сюда выгорание самой «звезды», которая через 6–9 месяцев либо срывается, либо уходит туда, где ей пообещают еще более амбициозную изоляцию.
Практическая часть материала полезнее самого драматичного кейса. Бирюков предлагает довольно приземленный фильтр для собеседований: спрашивать не только про сложные системы, но и про то, как кандидат объяснял тему младшему коллеге, что делал для читаемости кода через год и как реагировал на справедливую критику в ревью. Ответы в стиле «я просто скинул ссылку на документацию» или «меня обычно не критикуют, потому что я пишу хорошо» он предлагает считать красными флагами. Дальше — тест реальностью в первые недели: отношение к командным стандартам, манера разговора с джуниором, готовность к парному программированию. Если человек сразу говорит «я быстрее один», руководителю стоит хотя бы признать, что он нанимает не усилитель команды, а автономный риск.
Если ошибка уже совершена, рецепт у автора жесткий, но логичный. Сначала — прямой разговор и три обязательных правила: ревью без личных нападок, документация для публичных модулей и отказ от позиции «помогать коллегам не моя работа». Затем — привязка к измеримым целям: документация на ключевые части системы, несколько внутренних обучающих сессий, ограничение времени ревью, а также тайм-бокс на 4–6 недель, после которого руководитель смотрит не на харизму сотрудника, а на состояние команды. Если метрики не улучшаются, увольнение оказывается менее болезненным вариантом, чем продолжение эксперимента. Для рынка, где сильного инженера по-прежнему легко перепутать с хорошим командным игроком, это, пожалуй, главный вывод: в зрелой разработке важен не тот, кто пишет быстрее всех, а тот, после кого система и люди не становятся хрупкими.
Российские компании еще долго будут охотиться за редкими сильными разработчиками, особенно в архитектурно сложных зонах вроде highload, финтеха и старых критичных модулей. Вопрос уже не в том, нужен ли бизнесу очень сильный инженер, а в другом: умеет ли компания проверять, усиливает ли он команду или просто делает ее зависимой от себя.