В крупнейших технологических компаниях изменения редко происходят быстро — особенно когда речь идет о базовых процессах: о выборе технологий и подходах к найму управленцев. Но Илье Масандилову, Development Sector Lead в Yandex Go, удалось доказать, что трансформации возможны и в масштабах корпорации.
Он стал амбассадором внедрения языка программирования Golang в сервисах Yandex Go, что ускорило разработку и повысило её предсказуемость. Кроме того, Илья активно участвовал во внедрении новой секции собеседований для менеджеров, которая теперь используется по всей компании. В интервью IT-World он рассказывает, как ему удалось структурировать работу команд, изменить процессы найма и онбординга и почему софт-скиллы для него важнее хард-скиллов.
Вы пришли в Яндекс Go B2B в момент активного роста. С какими вызовами в процессах разработки и управления командами вы столкнулись в первую очередь?
Для меня главной сложностью стала хаотичность процессов. В моей команде было 16 разработчиков, которые коммуницировали с десятком проджект- и продакт-менеджеров — но не было ни разделения на команды, ни устоявшихся процессов. При этом мне предстояло увеличить команду в 2-3 раза. Пообщавшись с бизнесом, я понял, что основные проблемы — это непредсказуемость разработки, не соблюдение дедлайнов и отсутствие возможности заранее оценить пул задач. Единственным структурирующим процессом была ежедневная встреча на 20 минут, где каждый рассказывал о своих задачах — но этого было недостаточно. Главным вызовом для меня стала задача структурировать работу команды и сделать процессы предсказуемыми. Вскоре мне удалось продумать процессы для команды и добиться прозрачности разработки, чтобы можно было четко оценивать сроки и ресурсы. А также я перевел всю разработку новых сервисов на простой и современный язык программирования Golang, что дало возможность быстрее выполнять задачи и допускать меньше ошибок.
Как вы определяли зоны применения Golang в Яндексе: был ли это выбор для отдельных сервисов или долгосрочная ставка на экосистему языка?
В 2022 году в RideTech (такси и каршеринг) всё еще писали веб-сервисы на С++ и Python. С++ — довольно сложный для разработчиков язык, с ним трудно работать и долго отлаживать в случае багов. Python более простой, но ненадежный и потребляет много ресурсов. Поэтому современные разработчики чаще используют более продвинутые языки. Видимо, до меня в RideTech не было людей с достаточным энтузиазмом, чтобы убедить руководство найти более оптимальное решение для разработки, и поэтому именно я стал амбассадором Golang в компании. Сейчас вся моя команда из 50 человек использует этот язык для разработки сервисов Яндекс Go. По поводу выбора именно этого языка — безусловно, я делал долгосрочную ставку на его экосистему. У меня не возникало ни малейших сомнений в том, что Go принесет профит всему направлению. Но не все были со мной согласны — и мне пришлось убеждать в своей правоте большое количество стейкхолдеров. Я приводил для этого формальные доказательства, искал документацию, проводил тесты для сравнения с Python и C++.
Как было принято решение перейти на Go, и как вы выстраивали процесс адаптации нового языка для целых команд?
С моим руководителем мы договорились о том, чтобы переписать готовый сервис на Golang и проверить, насколько имеющаяся инфраструктура подходит для этого языка. По результатам эксперимента я провел ряд доработок используемого в Яндексе Go фреймворка, добавил в нашу экосистему некоторое количество линтеров и провел инфраструктурные доработки — так, чтобы новые сервисы на Golang вписывались в текущую экосистему Яндекса. В итоге удалось доказать, что новый фреймворк отлично работает с нашими задачами, и я убедил руководство дать мне возможность разработки на Golang в моей зоне ответственности. Так было написано несколько «боевых» сервисов. После этого, увидев отличные результаты, руководство согласилось расширить эксперимент — и позволить всем желающим в RideTech писать новые сервисы на Golang. У меня при этом была роль ментора: помогать командам, ревьюить сервисы, наблюдать за их работой. Сначала я отобрал около 10 команд, которым разрешили работать с Golang. Важным условием стало то, чтобы новые сервисы на этом языке не были критичны для основного цикла заказа такси. Когда стало ясно, что они отлично выдерживают нагрузку, и в них не происходит инцидентов, мы постепенно стали внедрять Golang в более критичные инструменты. Адаптация команд произошла легко. Так как я сумел обосновать преимущества языка, разработчики с энтузиазмом приняли нововведение. Оказалось, что обучиться Golang можно довольно быстро. Уже на второй месяц специалисты работали с новым фреймворком с той же скоростью, что и на Python, и даже выше. При этом сборка, тестирование и обслуживание сервисов стали гораздо быстрее и удобнее. Еще один неочевидный плюс — использование Golang улучшило наш hr-бренд. Многие опытные разработчики предпочитают этот язык, поэтому возможность работы с Golang добавила очков карьере в нашей компании. По словам рекрутеров, внедрение Golang увеличило количество откликов на вакансии на 25-30%.
Очевидно, такие проекты требуют высоких софт-скилов и коммуникативных навыков, с чем у инженеров часто бывает непросто. Вы специально развивали эти качества?
Единственное обучение по софт-скиллам, которое я проходил — это несколько уроков у тренера по актерскому мастерству для публичных выступлений. Я всегда предполагал, что у меня хорошо развита эмпатия — и убедился в этом на внутреннем тестировании для руководителей Яндекса. Я стараюсь разговаривать с людьми на их языке, становлюсь на их позицию и пытаюсь оценить ситуацию с их точки зрения. Это очень помогает мне, в том числе, и в работе. Например, когда я продвигал использование Golang, то понимал, что для специалистов технической компании важны цифры. Поэтому постарался найти статьи и исследования, которые аргументировали бы мою точку зрения. И в итоге всё получилось.
Если говорить о найме и онбординге, расскажите, как появилась идея с новой секцией для собеседований менеджеров, и что вы делали для ее внедрения в масштабе Яндекса?
Я масштабировал свою команду и для более простого управления разделил ее на три части. После этого необходимо было решить, кого назначать руководителями каждой из частей. Оценив подчиненных, я понял, что на роль руководителя подходит только один человек, а остальных необходимо было нанимать. И вот погрузившись в процессы найма я увидел проблему: поток кандидатов на руководящие должности в нашу компанию был низким, а сами кандидаты — не самыми качественными. Такая же ситуация была в других подразделениях, и я решил ее проанализировать и выяснить, в чем дело. Основной причиной низкого потока кандидатов к нам было большое количество технических секций. Но не было отдельных собеседований, чтобы понять, каким образом эти люди управляют подчиненными и какие тактики используют. У меня появилась мысль, что процесс найма нужно менять, чтобы сделать его более эффективным. С этой идеей я отправился к своему руководителю, который тогда недавно пришел в Яндекс. Он активно поддержал меня, и в качестве эксперимента мы решили сократить количество технических секций и ввести новую менеджмент-секцию для потенциальных управленцев. Мой руководитель написал первую версию дополнительных вопросов для кандидатов — она и легла в основу новой секции. Эта секция получилась очень эффективной — я лично проводил первое собеседование и узнал множество деталей о кандидате и его поведении, скрытых мотивах, возможных проблемах в дальнейшем взаимодействии. Более того, так вышло, что один из моих руководителей уже работал с этим специалистом и подтвердил мои выводы о нем. Так мы решили использовать новую секцию внутри всего RideTech, сократив количество технических собеседований. Это повысило интерес кандидатов, потому что мало кому из менеджеров нравится их проходить — в их карьере их и так уже было немало. А рекрутеры отметили, что уровень нанимаемых сотрудников значительно вырос. При этом оказалось, что в остальном Яндексе тоже были не полностью удовлетворены текущими процессами найма руководителей — и примерно в то же время разработали новый подход к оценке кандидатов на такие позиции. И тогда возник вопрос, чей подход эффективнее. Я сходил на секции других направлений, а их представители — на наши интервью. Мой руководитель активно защищал наш подход среди других руководителей Яндекса. В итоге текущий процесс найма на руководящие позиции крайне приближен к нашему варианту.
Какие изменения вы заметили в качестве нанятых менеджеров и в культуре управления командами после внедрения новой секции собеседований?
Главное — в разы вырос поток хороших кандидатов на руководящие должности. Изменение подхода к найму сработало как реклама для соискателей, которых раньше отпугивало большое количество технических собеседований. Новая секция позволяет отмечать руководителей, которые действительно умеют работать с людьми, решать конфликты, брать ответственность за проект, ставить цели и договариваться с другими подразделениями. Также мы сразу можем увидеть и отрицательные черты — например, конфликтность. Раньше такие качества заметить было сложно, так как основное внимание уделялось техническим навыкам кандидата. А если мы нанимаем хороших руководителей с развитыми софт-скиллами — то и вся команда становится сильнее. Так мы быстрее достигаем своих целей и развиваемся.
Если обобщить ваш опыт — какие принципы найма и онбординга инженеров и менеджеров вы считаете универсальными, работающими в любой крупной технологической компании?
Я уделяю большое внимание софт-скиллам — навыкам коммуникации, умению решать конфликты и выстраивать диалог. Также я смотрю на способность и желание обучаться, и конечно на амбициозность. Я считаю, что это важнее, чем хард-скиллы, потому что технические навыки всегда можно наработать в процессе. Бывает, что при прямых вопросах, например, о конфликтных ситуациях, кандидаты стараются уйти от ответа или рассказывают только часть истории. Поэтому мы действуем немного издалека — просим рассказать о рабочем кейсе и спрашиваем, как вел себя кандидат, какие решения он принимал, как общался с командой и т.д. В результате беседы мы узнаем множество интересных деталей, по которым потом делаем выводы. По моему опыту, первое впечатление о кандидате часто бывает ошибочным. Поэтому я советую проводить полноценные интервью с вопросами о софт-скиллах, чтобы составить правильный портрет сотрудника.