Всем привет! Меня зовут Анатолий Панов, я работаю в сфере IT более 15 лет. За это время я прошел путь от разработчика до руководителя группы.
Работал в таких компаниях как Badoo, Lazada. С начала этого года я на Авито.
Я управляю развитием новых проектов и развитием вертикалей «Авто» и «Недвижимость».
В начале работы на Авито передо мной стояла задача собрать три команды разработчиков.
Двое из них уже частично укомплектованы разработчиками, но ни у одного из них не было технического руководителя.
Их нужно было быстро найти и нанять.
Как оказалось, это не так просто.
Помимо основного требования к техническим руководителям быть хорошими разработчиками, они также должны быть хорошими менеджерами, которых найти еще труднее.
Вы можете изучать программирование, сидя дома за компьютером, но чтобы стать хорошим руководителем команды, вам обязательно понадобится практика с реальными людьми.
Найти команду тестировщиков кажется проблематичной.
Сегодня я хотел бы поделиться своим опытом поиска и найма руководителей команды.
Расскажу, с чего начать и какой процесс собеседования я придумал.
С чего начать? Первая мысль, конечно, была: давайте выдвинем внутреннего кандидата.
Но трансформация из функциональных команд в кросс-функциональные, начавшаяся 1,5 года назад, уже «съела» весь резерв.
Изнутри была заполнена только одна позиция, и пришлось нанять еще двух человек.
До этого мне никогда не приходилось иметь дело с наймом руководителей команд. В моих командах они выглядели более традиционно: всегда были ребята, которые хорошо проявили себя в бизнесе, и мы их продвигали.
Оказалось, что процесс найма тимлидов состоит из тех же трех больших этапов, что и найм разработчиков.
- Создайте требование и профиль кандидата.
- Найдите кандидатов на рынке, поймите, кто из них подходит по профилю.
- Проведите личное собеседование.
Создаем профиль кандидата Чтобы начать поиск кандидатов на вакансию, мы должны иметь профиль кандидата, документ, в котором написано, что представляет собой должность, кого мы на нее ищем, цели кандидата, которые будут стоять перед ним в ближайшем будущем, и навыки, которыми он обладает. будет. Мне повезло: у нас уже были общие требования к позиции тимлида.
Ее называют «менеджером по развитию подразделения», или сокращенно TUL (от английского «технический руководитель подразделения»).
Прежде чем поговорить более подробно о требованиях, хотелось бы немного рассказать о том, как работает наша разработка, чтобы было понятно, почему сложились те или иные требования.
Фон
Мы начали с традиционной функциональной структуры.На Авито были команды бэкенд- и фронтенд-разработчиков, мобильные разработчики и тестировщики.
Все стандартно.
Когда нужно было выполнить большую задачу, ее либо декомпозировали, и мелкие части передавались командам и расставлялись по приоритетам внутри компании, либо для этой задачи собирались кросс-функциональные команды.
Со временем это перестало работать.
Расставлять приоритеты становилось все сложнее, команд было больше, и между ними было много общения.
Задачи больше не доходят до производства с той скоростью, которая нам нужна.
Межфункциональные команды
Мы решили перейти к кросс-функциональным командам.Мы называем их единицами.
Они формируются вокруг значительных частей бизнес-функциональности.
Например: мессенджер, реклама, результаты поиска, сама поисковая система.
Подразделение обладает всеми компетенциями, позволяющими довести фичу от стадии идеи до производства с минимальной зависимостью от внешних команд. В него входят как технические, так и продуктовые функции в виде продакт-менеджеров, дизайнеров — всех тех людей, которые готовят нам бэклог.
В каждом отряде есть два типа лидеров.
Первый — руководитель подразделения, его задача — создать резерв для команды и расставить приоритеты.
Он несет ответственность за достижение бизнес-целей.
Второй – именно технический руководитель подразделения.
Он отвечает за то, что делает команда разработчиков, за качество написанного ими кода, за его безопасность, за планирование и достижение целей.
Участвует в формировании бэклога продукта (его задача — найти технические блокировщики и заранее позаботиться об их устранении).
Требования к техническим руководителям
Каким требованиям должен соответствовать такой руководитель? Идеальный технический руководитель:- имеет техническое образование,
- умеет управлять людьми
- знает, как нанять нужных людей,
- имеет понимание, как построить процесс разработки,
- умеет развивать себя и свою команду,
- нацеленность на бизнес-результат,
- умеет планировать и контролировать достижение результатов.
Вы можете спросить: «Все ли ваши команды предъявляют одинаковые требования к лидерамЭ» Конечно, нет. На требования также влияют профиль, деятельность подразделения и его цели.
Команды могут сильно различаться по составу в зависимости от того, насколько велик функционал, за который они отвечают. Несколько примеров, основанных на моей работе.
Первый проект – Домофонд. Изначально в команде должно было быть 12 человек; мы планировали перенести разработку Домофонда из ЮАР в Россию.
Плюс нам пришлось переписать проект с текущего стека технологий (.
NET, Windows Server) на стек Авито, чтобы иметь возможность дальше развивать и поддерживать его самостоятельно.
Мы хотели, чтобы руководитель этого подразделения имел практический опыт руководства коллективом численностью более 10 человек.
Ему нужно было быть хорошим рекрутером и иметь опыт мобильной разработки, ведь у Домофонда было два мобильных приложения, написанных на кроссплатформенном фреймворке Xamarin. 
Вторая команда — «Вертикали SWAT».
Мы сформировали его для поддержки тестирования бизнес-инициатив в вертикалях Авито (Авто и Недвижимость).
Целью команды было быстро создавать небольшие прототипы, проверяя бизнес-гипотезы.
Перед руководителем этой команды стояла задача построить процесс разработки так, чтобы мы могли быстро доставить и протестировать эти бизнес-гипотезы.
Он должен был хорошо понимать процесс запуска MVP и предъявляемые к нему требования.
Мы ищем кандидатов Итак, первый этап пройден.
У нас есть профиль кандидата, с которым мы можем пойти в HR: сказать им, чего мы хотим, сидеть и радостно ждать, пока они принесут нам кучу крутых резюме.
Все ли отлично? Нет. Резюме редко показывает реальные возможности кандидата, его навыки, то, что он умеет. Я такое видел очень часто: в резюме кажется, что это отличный специалист, но на собеседовании понимаешь, что это ошибочное впечатление.
Поэтому на этапе поиска резюме мы просто определяем, хотим ли мы общаться с этим человеком лично или нет. Подходит ли он нашему профилю (который был сформирован на предыдущем этапе) или нет.
Читаем резюме
Что я ищу в резюме? Самое очевидное – это опыт работы.Я смотрел кандидатов минимум год: считаю, что это период, когда человек может получить достаточное количество управленческих ударов и вжиться в эту роль, если он никогда этого не делал.
Часто бывает, что HR приносит «пустое» резюме: есть только список компаний, где человек работал и должностей.
Обычно это происходит потому, что человек активно не ищет работу, а был найден где-то в LinkedIn. Или приносят резюме, похожее на профиль нашего кандидата, но в нем есть информация, которая не говорит ничего конкретного о человеке.
«Я разрабатывал микросервисы», «Я делал такой-то сервис».
Но если компания, где работал кандидат, достаточно известна, то о его навыках можно косвенно судить по общедоступной информации о компании.
И последнее, что дает нам информацию, это то, как сам кандидат пишет о себе, о своих навыках.
Я приведу примеры.
Первый кандидат пишет, что проектировал новую схему шардинга, реализовывал мониторинг, оптимизировал основную базу проекта и перезапускал проект на новой платформе.
Много о технологиях и мало о процессах.
Судя по всему, он хороший техник, но мы не понимаем, умеет ли он управлять командой.
Второй кандидат пишет, что занимался анализом бизнес-требований, подготовкой тендерной документации и сопровождением производственного процесса.
Ничего о технологиях, ничего о команде, все о процессах.
Скорее всего это хороший менеджер.
Третий кандидат занимался управлением командой, занимался техническим анализом архитектуры, исправлением ошибок, работой над разработкой, выступал тренером и набирал людей в команду.
Достаточно сбалансированное резюме.
Похоже, он обладает всеми интересующими нас навыками.
Мне хотелось бы пообщаться с таким человеком лично.
После этого анализа у нас должно быть несколько человек, многие из которых совпадают с профилем нашего кандидата.
Но иногда встречаются люди, по резюме которых кажется, что они нам должны подойти, но мы так и не понимаем, хотим их пригласить или нет — информации недостаточно.
Есть еще два способа получить его.
Проводим скрининг и просим рекомендации
Скрининг – это короткое телефонное собеседование, на котором мы задаем всем кандидатам заранее подготовленные вопросы.На основании ответов мы хотим составить представление о человеке и получить о нем недостающую информацию.
К сожалению, я не могу здесь поделиться какими-либо разработками, потому что блестящая идея о том, что для тимлидов можно проводить отборочные собеседования, пришла ко мне уже после закрытия вакансий.
Но если бы я делал это сейчас, я бы воспользовался советами из книги «Кто.
Решите свою проблему номер 1 Джефф Смарт и Рэнди Стрит. Книга посвящена найму нужных людей и есть отдельная глава о том, как проводить отборочные собеседования, а также большой раздел о формировании требований к вашей должности.
Еще один способ собрать недостающую информацию – рекомендации кандидату.
На этом этапе не стоит задача собрать полную обратную связь от коллег и начальника о том, как кандидат показал себя.
Это можно будет сделать в конце, когда мы уже поговорили с ним лично.
Здесь это просто проверка на адекватность.
Говоря языком обеспечения качества, мы проводим дымовую проверку и проверку вменяемости этого кандидата.
Важная вещь: я делаю это не только для тех кандидатов, чей профиль неполный, а вообще для всех, где я могу это сделать.
Для этого я использую только свою сеть контактов, своих знакомых в этих компаниях или некоторых знакомых коллег.
Это важно, потому что иногда случается, что у кандидата вроде бы хороший профиль, все отлично, но он получает негативные отзывы, к которым стоит прислушаться.
Второй этап завершился.
У нас должен быть список кандидатов, с которыми мы хотим поговорить.
Перейдем к самому интересному – очному собеседованию.
Очное интервью В нашей компании очные собеседования на руководящие должности обычно состоят из трех этапов.
Первый этап личного собеседования
Первый этап — самое обычное собеседование с руководителем и HR. Цель этого этапа — понять, соответствует ли профиль кандидата тому, что нам нужно.Если сравнить наем разработчика и тимлида, то хард-скиллы разработчика очень легко проверяются на экзаменационном собеседовании.
Глядя на то, как кандидат отвечает на вопросы и как он решает проблемы, мы можем судить о его знаниях.
Важно то, что если кандидат знает, как что-то делать, он с большей вероятностью применит это в своей работе.
С тимлидами все по-другому.
Очень часто их жесткие навыки являются мягкими навыками.
Например, способность давать обратную связь — это сложный навык для руководителя команды, но сам этот навык — мягкий навык.
Проверить такие навыки на собеседовании очень сложно.
Мы можем спросить кандидата: «Вы умеете давать обратную связьЭ», и он, конечно же, ответит: «Да, могу».
Мы можем попробовать разыграть с ним ролевую сценку, попросить дать нам обратную связь, но все понимают, что мы на собеседовании, и кандидат, скорее всего, даст нам какой-то социально ожидаемый ответ. Мы никогда не узнаем, сделает ли он то же самое в реальной жизни.
Поэтому для руководящих должностей самое главное смотреть не на теоретические знания, которыми обладает кандидат, а на его реальный практический опыт. Что он делал, какие проблемы решал, с чем столкнулся, как преодолевал трудности.
Теоретические вопросы тоже можно задавать, но только в том случае, если у кандидата по каким-то причинам нет реального опыта решения задач в этой области.
Например, он никогда не нанимал людей; у него был большой отдел кадров, который все за него делал.
Приведу несколько примеров того, о чем спрашиваю на собеседованиях, и расскажу, что мы у них проверяем.
Вопросы о технической подготовке Первый блок состоит из вопросов о технической подготовке кандидата.
Я начинаю с того, что прошу их рассказать о какой-нибудь интересной функции, проекте или чем-то, над чем работал кандидат. Далее, в зависимости от ответов, можно углубиться в детали.
Мы можем спросить, какова была архитектура проекта, чтобы кандидат мог рассказать нам и нарисовать на доске.
Это нужно для того, чтобы увидеть, как он может рассказать о чём-то сложном человеку, не знакомому с этой областью знаний.
С ним можно поговорить о нагрузке, если его проект был сильно загружен и нам интересна эта тема.
Если кандидат рассказывает о том, что это была просто интересная функция продукта, которая была крутой с точки зрения продукта, вы можете конкретно спросить: «Какие сложные технические проекты вы выполнялиЭ» Вопросы о приеме на работу Следующий блок – вопросы, связанные с приемом на работу.
Принимал ли человек когда-либо участие в отборе? Если да, то каков был процесс? Какие вопросы он задает на интервью? Как он проверяет в кандидатах те или иные качества, на что вообще смотрит, каких людей хочет взять в свою команду? Вопросы по управлению людьми Третий блок вопросов касается управления людьми.
Мой любимый вопрос: «Приходилось ли вам когда-нибудь увольнять сотрудниковЭ» Это круто, потому что это сложная и болезненная история для всех участников этого процесса: и для самого тимлида, и для человека, которого он увольняет. И если тимлид уже прошел через это, то это отличный показатель его опыта.
Плюс, скорее всего, в эту историю можно будет углубиться дальше, ведь увольнение вполне может быть недостатком самого тимлида.
Вопросы по разработке Следующий блок посвящен развитию.
Я спрашиваю о том, как был организован процесс в его команде, сам ли он это сделал, или процесс был настроен кем-то сверху.
Соответственно, если он не делал сам процесс, то понимает ли он, почему процесс выглядел именно так? Ну а если кандидата что-то в процессе разработки не устроило, то стоит поинтересоваться, пробовал ли он что-то изменить.
Второй этап очного собеседования
Мы завершили первый этап очного собеседования.Если кандидат проходит его успешно, то мы проводим второй этап очного собеседования с командой и заинтересованными сторонами.
Обе мои вакансии были в продуктовых командах, и для тимлидов таких команд очень важно тесное взаимодействие с владельцем продукта и бизнес-заказчиком.
Поэтому состав участников был именно такой.
Этот шаг может отличаться при приеме на работу в другие команды.
Например, если это платформенная единица и мы хотим, чтобы код писал тимлид, или если мы знаем, что команда не примет лидера, технические навыки которого хуже, чем у ее участников, то необходимо провести углубленное техническое собеседование.
можно проводить здесь, точно так же, как сделано для разработчиков.
Но у меня была продуктовая команда.
Чем первый этап очного собеседования отличается от второго? Во-первых, состав участников разный.
На втором этапе вопросы могут пересекаться с тем, что мы уже задавали кандидатам на первом этапе.
Но поскольку их задают другие люди, с другим опытом, мы получим другую точку зрения на этого кандидата.
Коллеги могут увидеть то, чего не видел я.
Плюс лично для меня это был еще и очень полезный этап с точки зрения поддержания планки найма на необходимом уровне, ведь когда поток кандидатов уменьшается, на собеседования приходит все меньше и меньше людей, возникает соблазн снизить планку.
немного и наконец наймите хоть кого-нибудь, чтобы закрыть позицию.
Но коллеги, которым придется работать с этим человеком, могут вас вовремя остановить и сказать: «Подумайте лучше».
И планка снова поднимается.
Третий этап личного собеседования
Последний этап – защита корпуса.Это тестовое задание для менеджеров.
Идея точно такая же, как и с тестовым заданием для разработчиков: проверить, как кандидат поведет себя в реальной ситуации.
Здесь очень важно привести пример, максимально приближенный к ситуации в вашем коллективе, ведь только тогда вы сможете понять, как поведет себя кандидат, если он придет к вам работать.
Как выглядел мой случай? Покажу на примере проекта Домофонд. 
Основная часть – это текущее описание ситуации в команде, состава, технологий, навыков, проектов, которые сейчас находятся в работе, целей и планов на ближайшее будущее команды и кандидата.
И любые ограничения, если они есть.
Главное, что кандидат должен был осветить в нашем случае — это предложить вариант переноса проекта в стек технологий Авито и аргументировать, почему было выбрано именно такое решение.
Предоставьте схему трансфера и план на первые 100 дней работы.
Ключевые критерии успеха заключались в следующем.
Перенос необходимо было осуществить в течение полугода, максимально используя технологии инфраструктурной платформы «Авито».
Проект должен был остаться в рамках бюджета.
И миграция должна была происходить с заморозкой функций максимум на один спринт. 
Это скриншоты реальной презентации, которую нам защитил кандидат проекта Домофонд. Обычно подготовка к нему занимает около двух недель.
Презентация длится 20-30 минут. Примерно столько же времени мы уделяем сессии вопросов и ответов.
Последний этап завершен.
К этому моменту у нас должен появиться кандидат, которому мы хотели бы сделать предложение.
Это мог бы быть конец.
Но есть еще один этап.
Иногда бывает, что кандидат всем нравится, он очень крутой, мы очень хотим его здесь видеть, но он по каким-то причинам в этом сомневается, или есть какие-то внешние обстоятельства, которые мешают ему принять решение.
Например, ему нужно переехать из другого города, ему нужно перевезти семью, и это для него проблема.
И здесь мы должны помочь ему принять правильное для нас решение.
Я называю это «продажей работы».
У меня был случай, когда все было здорово, кандидат понравился, мы ему понравились, но он не мог определиться с датой выхода.
Он нам сказал: «Я приеду к вам через два-три месяца.
Мне нужно закончить проект, над которым я работаю.
Он очень важный, классный.
Я не уверен, когда мы закончим».
Мы вызвали его в офис на последнюю заключительную встречу, ответили на все вопросы, на которые у кандидата на тот момент не было ответа, обсудили эту ситуацию, договорились, что он сможет помочь своему команде в рабочее время, у него будет возможность сдать проект вместе с В общем, мы были готовы им всячески помогать.
Ему сделали предложение и договорились, что он приедет через месяц.
Он принял предложение.
, ушел.
и в итоге так и не воспользовался нашим предложением, потому что сдали проект в срок.
Заключение В заключение хотелось бы подчеркнуть, что из этого опыта я узнал интересного и полезного.
- Во-первых, если у вас есть желание и возможность обучать и развивать кандидата, то всегда лучше делать это изнутри.
История с внутренним карьерным ростом всегда лучше, чем постоянный найм тимлидов.
- Во-вторых, обязательно нужно пройти отборочное собеседование по телефону.
Эта штука поможет сократить количество кандидатов, которых вы приглашаете на очное собеседование, которые вам явно не подходят.
- В-третьих, для руководящих должностей собеседование на основе опыта гораздо лучше и полезнее теоретического собеседования.
Сложнее лгать об опыте; это лучше показывает, как кандидат будет вести себя в подобных ситуациях в будущем.
- В-четвертых, лично для меня защита корпуса оказалась новым и крайне полезным инструментом.
Я знал, что эти вещи предназначены для кандидатов на руководящие должности в нетехнических областях, но я впервые делал это для ИТ-специалистов, и этот инструмент оказался очень полезным.
Оно может помочь кандидату раскрыть себя и подробно рассказать, какой он видит свою работу в будущем.
Именно защита дела стала решающей в выборе будущего коллеги, ведь его история максимально совпадала с тем, что мы ожидали.
И мы сделали ему предложение.
Спасибо за внимание.
Если у вас есть вопросы, пишите комментарии, я постараюсь на них ответить.
P.S. Эту тему я обсуждал в докладе на Saint TeamLead Conf 2018, здесь слайды .
Для оформления использованы иконки под авторством.
Теги: #HR #Интервью #найм #Управление персоналом #Карьера в IT-индустрии #ИТ-компании #ИТ-компании
-
Чек-Лист Для Подготовки К Ux-Собеседованию
19 Oct, 24 -
О Технических Проблемах И Уведомлениях...
19 Oct, 24 -
Мировая Блогосфера От Technorati
19 Oct, 24 -
Что За Хабравирус!?
19 Oct, 24 -
Вр - Выпуск №37
19 Oct, 24
