Хабрахабр

Фантастические тимлиды и где они обитают

Меня зовут Анатолий Панов, я работаю в ИТ уже больше 15 лет. Всем привет! Работал в таких компаниях как Badoo, Lazada. За это время прошел путь от разработчика до руководителя тимлидов. Руковожу разработкой новых проектов и разработкой для вертикалей Авто и Недвижимость. С начала этого года я в Авито.

Две из них были уже частично укомплектованы разработчиками, но ни в одной из них не было технического руководителя. В начале работы в Авито передо мной стояла задача собрать три команды разработки. Их нужно было быстро найти и нанять.

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

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

Но начавшаяся 1,5 года назад трансформация из функциональных команд в кроссфункциональные уже «съела» весь резерв. Первая мысль, конечно же, была такой: давайте запромоутим внутреннего кандидата. Только одну позицию удалось закрыть изнутри, еще двух человек предстояло нанять.

У меня в командах они появлялись более традиционным способом: всегда были ребята, которые показывали себя хорошо в деле, и мы повышали их. До этого мне не приходилось заниматься наймом тимлидов.

Оказалось, что процесс найма тимлидов состоит из тех же трех больших этапов, что и найм разработчиков.

  • Составить требование, профиль кандидата.
  • Найти кандидатов на рынке, понять, кто из них подходит к профилю.
  • Провести очное интервью.

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

Она называется «руководитель разработки юнита», или сокращенно TUL (от английского technical unit leader). Чтобы запустить поиск кандидатов на вакансию, у нас должен появиться профиль кандидата, документ, в котором написано, что за позиция, кого мы на нее ищем, цели кандидата, которые будут стоять перед ним в ближайшее время, и навыки, которыми он будет обладать.
Мне повезло: у нас уже были сформированы общие требования на позицию тимлида.

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

Предыстория

В Авито были группы разработки бэкенда, фронтенда, мобильные разработчики, тестировщики. Мы начинали с обычной функциональной структуры. Когда нужно было сделать какую-то большую задачу, она либо декомпозировалась, и маленькие кусочки спускались внутрь команд и приоритезировались внутри, либо под задачу собирались кроссфункциональные команды. Всё стандартно. Всё сложнее становилось приоритезировать, команд становилось больше, было много коммуникации между ними. Со временем это перестало работать. Задачи перестали долетать до продакшна с нужной нам скоростью.

Кроссфункциональные команды

Мы называем их юнитами. Мы решили перейти к кроссфункциональным командам. Например: мессенджер, подача объявлений, поисковая выдача, сам движок поиска. Они образуются у нас вокруг значимых частей бизнес-функциональности. В него входят и технические функции, и продуктовая в виде менеджеров продукта, дизайнеров — всех тех людей, которые нам подготавливают бэклог.
У каждого юнита есть два типа руководителей. Юнит содержит в себе все компетенции для того, чтобы дотащить фичу от этапа идеи до продакшна с минимальными зависимостями от внешних команд. Он отвечает за достижение бизнес-целей. Первый — юнит лидер, его задача заключается в том, чтобы сформировать бэклог для команды и приоритезировать его. Он отвечает за то, что делает команда разработки, за качество кода, который они пишут, за его безопасность, за планирование и достижение целей. Второй — это как раз-таки технический руководитель юнита. Участвует в формировании продуктового бэклога (его задача заключается в том, чтобы найти технические блокеры и заранее позаботиться об их устранении).

Требования к техническим лидерам

Идеальный технический лидер: Каким требованиям должен соответствовать такой руководитель?

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

Можно спросить: «Неужели у всех ваших команд одинаковые требования для руководителей?». Получается, наш TUL — это чуть больше, чем тимлид в обычном этом понимании. На требования также влияют профиль, то чем юнит занимается, его цели. Конечно, нет. Пара примеров на основе вакансий, которые у меня были. Команды могут сильно отличаться по составу в зависимости от того, насколько велик функционал, за который они отвечают.

Команда уже со старта должна была быть 12 человек, мы планировали перенести разработку Domofond из Южной Африки в Россию. Первый проект — это Domofond. NET, Windows Server) на стек Авито, чтобы дальше можно было развивать и поддерживать его собственными силами. Плюс мы должны были переписать проект с нынешнего стека технологий (. Он должен был уметь хорошо нанимать, и у него должен был быть опыт мобильной разработки, потому что у Domofond было два мобильных приложения, написанных на кроссплатформенном фреймворке Xamarin. Мы хотели, чтобы руководитель этого юнита имел практический опыт руководства командой больше 10 человек.

Мы формировали её для того, чтобы поддержать тестирование бизнес-инициатив в вертикалях Авито (Авто и Недвижимость). Вторая команда — это Verticals SWAT. У руководителя этой команды была задача выстроить процесс разработки так, чтобы мы эти бизнес-гипотезы могли быстро доставлять и тестировать. Задача этой команды была в том, чтобы быстро делать маленькие прототипы, тестируя бизнес-гипотезы. Он должен был хорошо понимать процесс запуска MVP и требования к нему.

У нас есть профиль кандидата, с которым можно идти в HR: рассказать им, что мы хотим, сидеть и с радостью ждать, когда нам принесут кучу классных резюме. Итак, первый этап закончился.

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

Читаем резюме

Я смотрел кандидатов от года: считаю, что это тот срок, когда человек может набить достаточное количество менеджерских шишек и вжиться в эту роль, если он никогда этим не занимался. На что я смотрю в резюме?
Самое очевидное — опыт работы.

Обычно такое бывает, потому что человек активно не ищет работу, его нашли где-то на LinkedIn. Очень часто бывает так, что HR приносит «пустое» резюме: там только список компаний, в которых человек работал, и должности. «Я занимался разработкой микросервисов», «я делал сервис такой-то». Либо приносят резюме, похожее на наш профиль кандидата, но в нём информация, которая ничего о человеке конкретного не говорит. Но если компания, в которой работал кандидат, довольно известная, то косвенно о его навыках можно судить по публичной информации о компании.

Приведу примеры. И последнее, что даёт нам информацию — то, как сам кандидат пишет про себя, про свои навыки.

Очень много про технологии и мало про процессы. Первый кандидат пишет, что он занимался проектированием новой схемы шардинга, внедрением мониторинга, оптимизацией основной БД проекта, перезапуском проекта на новой платформе. Видимо, это хороший технарь, но нам не понятно, умеет ли он управлять командой.

Ничего про технологии, ничего про команду, всё про процессы. Второй кандидат пишет, что занимался анализом бизнес-требований, подготовкой конкурсной документации, сопровождением производственного процесса. Скорее всего это, хороший менеджер.

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

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

Проводим скрининг и запрашиваем рекомендации

По ответам мы хотим составить представление о человеке, получить недостающую информацию о нем. Скрининг — это короткое интервью по телефону, где мы задаём всем кандидатам заранее подготовленные вопросы. Но если бы я делал это сейчас, то я бы воспользовался советами из книги «Кто. К сожалению, здесь никакими наработками поделиться не смогу, потому что светлая мысль о том, что скрининг-интервью можно проводить для тимлидов, мне пришла уже после того, как вакансии были закрыты. Книга посвящена найму правильных людей и там есть отдельная глава, посвященная тому, как делать скрининг-интервью, а также большой раздел, посвященный формированию требований для вашей позиции. Решите вашу проблему номер 1» Джеффа Смарта и Рэнди Стрит.

На этом этапе нет задачи собрать полноценный фидбэк от его коллег и начальника о том, как кандидат себя проявил. Ещё один способ собрать недостающую информацию — рекомендации на кандидата. Здесь это просто проверка на адекватность. Это можно будет сделать в конце, когда мы уже поговорим с ним лично. Важная вещь: я делаю это не только для тех кандидатов, у которых профиль неполный, а вообще для всех, где я могу это сделать. Если говорить в терминах QA, то мы делаем smoke test и sanity check этого кандидата. Это важно потому что иногда бывает, что кандидат вроде бы с хорошим профилем, всё здорово, но на него приходит негативный фидбэк, к которому стоит прислушаться. Для этого я использую только свою сеть контактов, своих знакомых в этих компаниях, либо каких-то знакомых коллег.

У нас должен появиться список кандидатов, с которыми мы хотим пообщаться. Закончился второй этап. Переходим к самому интересному — к очному интервью.

У нас в компании очные интервью на менеджерские позиции обычно состоят из трех этапов.

Первый этап очного интервью

Задача этого этапа — понять, соответствует ли профиль кандидата тому, что нам нужно. Первый этап — это самое обычное интервью с руководителем и HR.

Глядя, как кандидат отвечает на вопросы, как он решает задачи, мы можем судить о его знаниях. Если сравнивать найм разработчика и тимлида, то у разработчика его хардскиллы очень легко проверяются экзаменационным интервью. С тимлидами все по-другому. Важно то, что если кандидат знает, как что-либо делать, скорее всего, он будет применять это в своей работе. Например, умение давать обратную связь — это хардскилл для тимлида, но сам скилл — это софтскилл. У них очень часто хардскиллы являются софтскиллами. Проверить такие умения на интервью очень тяжело.

Мы можем попробовать с ним проиграть ролевую сценку, попросить его дать нам обратную связь, но все понимают, что мы находимся на интервью, и кандидат, скорее всего, будет давать нам какой-то социально ожидаемый ответ. Мы можем спросить кандидата: «Умеешь ли ты давать обратную связь?», и он, конечно, ответит: «Да, умею». Поэтому для менеджерских позиций важнее всего смотреть не на теоретические знания, которые есть у кандидата, а на его реальный практический опыт. Мы никогда не узнаем, будет ли он поступать так же в реальной жизни. То, чем он занимался, какие проблемы он решал, с чем он сталкивался, как он преодолевал трудности.

Например, он никогда не нанимал людей, у него был большой HR-департамент, который все делал за него.
Приведу несколько примеров того, что спрашиваю я на собеседования, и расскажу, что мы проверяем этим. Теоретические вопросы тоже можно задавать, но только в том случае, если по каким-то причинам у кандидата не было реального опыта решения задач из этой области.

Вопросы про технический бэкграунд

Я начинаю с того, что прошу рассказать о какой-то интересной фиче, проекте, о чем-то, чем кандидат занимался. Первый блок — это вопросы про технический бэкграунд кандидата. Можно спросить о том, какова была архитектура проекта, чтобы кандидат нам рассказал, порисовал на доске. Дальше в зависимости от ответов можно углубляться в детали. Можно поговорить с ним про нагрузку, если его проект был высоконагруженным, и нас интересует эта тема. Это нужно чтобы посмотреть, как он умеет рассказывать о чем-то сложном человеку, который не знаком с этой областью знаний. Если кандидат рассказывает о том, что это была просто интересная продуктовая фича, которая была классной с точки зрения продукта, можно целенаправленно спросить: «Какие сложные технические проекты вы делали?».

Вопросы про найм

Доводилось ли человеку заниматься подбором? Следующий блок — вопросы, связанные с наймом. Какие вопросы он задаёт на собеседованиях? Если да, то как выглядел процесс? Как он проверяет те или иные качества у кандидатов, на что он вообще смотрит, каких людей он хочет нанимать себе в команду?

Вопросы про управление людьми

Мой любимый звучит так: «Приходилось ли вам увольнять сотрудников?». Третий блок вопросов — про управление людьми. И если тимлид уже проходил через это, то это отличный показатель его опыта. Он классный, потому что это тяжелая и болезненная история для всех участников этого процесса: и для самого тимлида, и для человека, которого он увольняет. Плюс, скорее всего, в этой истории можно будет еще покопаться, потому что увольнение вполне может быть недоработкой самого тимлида.

Вопросы про разработку

Я спрашиваю про то, как был устроен процесс в его команде, делал ли он его сам, либо процесс был поставлен кем-то сверху. Следующий блок — про разработку. Ну, а если что-то в процессе разработки кандидата не устраивало, то стоит спросить, пытался ли он что-то изменить. Соответственно, если сам процесс он не делал, то понимает ли он, почему процесс выглядел именно так.

Второй этап очного интервью

Если кандидат его проходит успешно, то второй этап очного интервью мы проводим с командой и стейкхолдерами. Закончили с первым этапом очного интервью. Поэтому состав участников был именно такой. Обе мои вакансии были в продуктовые команды, а для тимлидов таких команд очень важно тесное взаимодействие с владельцем продукта (product owner) и бизнес-заказчиком. Например, если это платформенный юнит и мы хотим, чтобы тимлид писал код, или если мы знаем, что команда не примет лидера, у которого технические скиллы хуже, чем у её участников, то здесь может проводиться глубокое техническое интервью, точно такое же, как делается для разработчиков.
Но у меня была продуктовая команда. При найме в другие команды этот этап может отличаться. Во-первых, другой состав участников. Чем отличается первый этап очного интервью от второго? Но поскольку их задают уже другие люди, с другим опытом, то мы получим другую точку зрения на этого кандидата. На втором этапе вопросы могут пересекаться, с тем, что мы уже спрашивали кандидатов на первом этапе. Плюс для меня лично это был еще очень полезный этап в плане поддержания планки найма на нужном уровне, потому что когда поток кандидатов уменьшается, на интервью приходит все меньше и меньше людей, есть соблазн чуть-чуть понизить планочку и взять наконец хотя бы кого-нибудь, чтобы закрыть позицию. Коллеги могут увидеть что-то, чего не увидел я. И планка поднимается обратно. Но коллеги, которым придётся вместе с этим человеком работать, могут тебя вовремя остановить и сказать: «Подумай получше».

Третий этап очного интервью

Это такое тестовое задание для менеджеров. Последний этап — это защита кейса. Здесь очень важно давать пример, максимально приближенный к тому, какая ситуация сложилась у вас в команде, потому что только тогда вы сможете понять, как же кандидат будет себя вести, если он к вам придет работать. Идея ровно такая же как с тестовым заданием для разработчиков: проверить, как кандидат будет себя вести в реальной ситуации. Покажу на примере проекта Domofond. Как выглядел кейс у меня?

И какие-то ограничения, если они есть. Основная часть — это текущее описание ситуации в команде, состав, технологии, навыки, проекты, которые сейчас в работе, цели и планы на ближайшее будущее для команды и кандидата.

Представить roadmap переноса и план на первые 100 дней работы.
Ключевые критерии успеха были такими. Основные вещи, которые кандидат должен был осветить в нашем кейсе — это предложить вариант переноса проекта на стек технологий Авито, аргументировать, почему было выбрано именно такое решение. Проект должен был остаться в рамках бюджета. Перенос нужно было закончить в течение шести месяцев, максимально использовать инфраструктурные платформенные технологии Авито. И миграция должна была пройти с фича-фризом длиной в максимум один спринт.

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

К этому моменту у нас должен появится кандидат, которому мы бы хотели сделать оффер. Последний этап закончен. Например, он должен переехать из другого города, ему нужно перевозить семью, и это для него проблема. На этом можно было бы и закончить… Но есть еще один этап.
Иногда так бывает, что кандидат всем понравился, он очень классный, мы очень хотим видеть его у себя, но он по каким-то причинам сомневается, либо есть какие-то внешние обстоятельства, которые мешают ему принять решение. Я называю это «продать вакансию».
У меня был случай, когда все было классно, кандидат нам понравился, мы ему понравились, но он не мог определиться с датой выхода. И здесь мы должны помочь ему принять правильное для нас решение. Мне нужно доделать проект, над которым я работаю. Он говорил нам: «Я приду к вам через два-три месяца. Я не уверен, когда мы закончим». Он очень важный, классный. Выдали ему оффер, договорились, что он придёт через месяц. Мы позвали его в офис на последнюю финальную встречу, ответили на все вопросы, которые были у кандидата на тот момент неотвеченные, проговорили эту ситуацию, договорились о том, что он сможет в рабочее время помогать своей команде, у него будет возможность сдавать проект вместе с ними, в общем, мы всячески готовы были содействовать. Он оффер принял, вышел… и в итоге так и не воспользовался нашим предложением, потому что они сдали проект в срок.

В заключение я бы хотел подчеркнуть то, что я вынес для себя из этого опыта интересного и полезного.

  • Во-первых, если у вас есть желание и возможности учить и растить кандидата, то лучше всегда это делать изнутри. История с внутренним карьерным ростом всегда лучше, чем вы будете постоянно нанимать тимлидов.
  • Во-вторых, надо обязательно делать скрининг-интервью по телефону. Эта штука поможет сократить количество кандидатов, которых вы зовете на очное интервью, и которые вам явно не подходят.
  • В-третьих, для менеджерских позиций интервью на основе опыта — гораздо лучше и полезнее, чем теоретическое интервью. Про опыт сложнее соврать, он лучше показывает то, как кандидат будет вести себя в подобных ситуациях в будущем.
  • В-четвёртых, лично для меня защита кейса оказалась новым и крайне полезным инструментом. Я знал, что такие штуки делают для кандидатов на менеджерские позиции в нетехнические области, но для ИТ-специалистов я делал это впервые, и инструмент оказался очень полезен. Он может помочь кандидату раскрыть себя, подробно рассказать, как он видит свою работу в будущем. Именно защита кейса стала решающей в выборе будущего коллеги, потому что его рассказ максимально точно совпал с тем, что мы ожидали. И мы сделали ему оффер.

Спасибо за внимание. На этом всё. Если у вас появятся вопросы, пишите комментарии, я постараюсь на них ответить.

S. P. Эту тему я раскрывал в докладе на Saint TeamLead Conf 2018, вот слайды.
Для оформления использованы иконки под авторством Becris и Freepik на Flaticon.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть