Привет, я Иван Самсонов, продакт-менеджер в прикладных исследованиях ВКонтакте. Последние шесть лет так или иначе нанимаю людей, и согласен, что «наш успех как менеджеров — не более чем результат того, насколько хорошо мы умеем выбирать сотрудников». Расскажу, как на этапе собеседования увидеть в человеке звезду (или будущую звезду), привлечь его в свою команду и помочь реализоваться. И поделюсь пятью принципами работы с такими специалистами, которые я сформулировал для себя и которые помогают мне укреплять команду и вместе с ней добиваться крутых результатов, действительно соответствующих топ-уровню. У нас в команде много действующих проектов и идей о том, как машинное обучение может улучшить опыт пользователей ВКонтакте. Чтобы реализовывать эти проекты и двигать новые, нам нужны самые высокоэффективные ребята. Это не значит — сразу синьоры. Такими звёздами могут быть и джуны, и мидлы. Это всё кандидаты категории A — в чём их фишка, сейчас расскажу и покажу на примерах. Эта статья написана по мотивам моего выступления на конференции TeamLead Conf — можно посмотреть видео доклада или послушать его в формате подкаста, если вам так удобнее.  В своей практике я часто опираюсь на методологию, которую почерпнул из книги «Кто. Решите вашу проблему номер 1» и адаптировал для задач в нашей области, то есть для найма в IT-команду и менеджмента в ней. До этого, нанимая без этой системы, я просто страдал. А теперь в моей практике нет гадания: «Взять этого кандидата или другого?», «Нравится мне этот соискатель или нет?». Я нанимаю по строгой методологии, и однозначно определяю, если человека «надо брать прямо сейчас» — как правило, это и есть кандидат категории A. Это те самые 10% людей, которые могут решить 90% задач, которые вы ставите перед ними.  Как я вижу три главных признака спецов из А-категории: они проактивны; самостоятельны; product’ивны — именно от слова product, потому что эти ребята суперзаточены на бизнесовые результаты. Они хотят не просто выполнять задачи, а понимать, зачем они это делают, какую ценность фича должна иметь для пользователя. И тогда они смогут предложить лучшие технические решения для реализации. Сравним на примере подходы А- и В-ребят.  Представим: есть явная задача. Например, пришёл к нам продакт из команды сообществ и сказал: «Нужно сделать классификатор комментариев: с помощью нейронки распределять на токсичные и нормальные. Хотим, чтобы администраторы сообществ получали список таких реплик и решали, как с ними быть дальше — оставлять или удалять, чтобы в паблике всем было комфортно». Задача понятна.  Что делали бы разработчики из категории В? Попросили бы разметку данных, взяли бы какую-нибудь open-source модель, дообучили её на разметке и отдали в прод. Хорошо, если это устроило бы заказчика. Если же нет, они объясняли бы, что «очень сложно докручивать и улучшать модель, давайте оставим как есть, она же закрывает часть потребностей». Ну да, задача в принципе выполнена: у админов сообществ есть инструмент для работы с токсичными комментами, таска в джире закрыта, ответственные выполнили свою работу. Что сделали ребята из категории А? Пошли к продакту сообществ и выяснили, что на самом деле нужно. Точно ли админам необходимо выявлять разные токсичные комментарии или они хотят, чтобы в их паблике просто не было мата, — и тогда достаточно прикрутить словарик, чтобы ловить такие выражения? Выяснили, что нужно выявлять разные токсичные высказывания: продакт объяснил почему, показал метрики. Дальше ребята подумали — а что такое токсичность? Это и оскорбления, и призывы к насилию, и враждебные высказывания на религиозные и другие темы — и ещё куча разной токсичности. Что мы хотим выявлять и показывать админам в пабликах? Вместе с продактом разобрались, что включить в классификатор. Пока собиралась разметка, всё-таки попробовали прикрутить словарик с матом и стоп-словами, чтобы протестировать: нужно ли, работает ли метрика, помогает ли продукт пользователям?  По ходу поняли, что словарик закрывает часть болей, но в целом нужен более проработанный продукт. Продолжали его пилить, помогали размечать данные, чтобы учитывать разные кросс-валидации и другие факторы. В общем, A-ребята глубоко включились как эксперты и сопровождали все процессы в задаче — чтобы получить чистые данные, которые позволят сделать качественную модель. Потом они её обучили, за несколько итераций докрутили параметры, добились необходимого качества и вывели в прод. Что из этого получилось, смотрите в статье коллег. Если поставить тезисы двух подходов рядом, то разница становится ещё более очевидной:  В-ребята сделали, что было заявлено на старте, закрыли задачку, они молодцы. А-спецы докопались до сути; расписали, как это всё будет работать; применили свою экспертность, помогли смежникам; довели фичу до прода. Их не остановило, что это дольше, требует больше усилий. Они поняли, как принести пользу, и сделали это для пользователей и коллег. Как я определяю А-категорию: они всегда стараются сделать максимально крутой продукт и сознательно «причиняют добро». Неважно, кто они: пиарщики, маркетологи, разработчики — кто угодно. Крутых айтишников часто хантят по рекомендациям. Ещё до интервью и оффера вы можете знать, какие у человека заслуги на прошлых проектах, как круто он питчил идеи, тащил и запускал всё на свете, тимлидил и вообще был всяческим молодцом. Можно ли рассчитывать, что всё это автоматически переедет в вашу компанию? Не всегда. Точнее — для этого надо создать условия, и начинать с этим лучше заранее. На практике я вижу, что от рекомендаций всегда стоит делать поправку на адаптацию. Новый сотрудник попадает в незнакомую культуру, должен освоиться в процессах компании, понять принятые подходы, въехать в задачи, притереться с руководителями и коллегами. Независимо от категории новичка, на новом месте он начинает со старта, врабатывается. Но как быстро он войдёт в устойчивый период и не перегорит ли сразу, уже зависит и от него, и от его новой команды. Мы хотим, чтобы ребята, которые к нам приходят, в идеале почти сразу включались в задачи, потом долго были в категории А и отлично перформили. И для этого мало просто знать, что на предыдущем месте они так могли.  Задача менеджера — так подобрать и зарядить специалиста, чтобы он работал с комфортом, а компания получала максимум пользы. Расскажу, как мы выбираем A-ребят и погружаем в задачи, чтобы в итоге мы друг другу максимально подошли. Если коротко: Составляем «Лист целей»: формулируем для себя и кандидата, какая у него будет основная задача. Формируем «Лист ожиданий»: рассказываем, каких действий и результатов ждём от нового коллеги в ближайшие полгода-год.  Составляем список навыков под конкретные задачи, которые предстоит решать специалисту. Именно этих скилов мы ждём от кандидата и их оцениваем на собеседовании.  Теперь на примере: недавно мы нанимали продакта по искусственному интеллекту. Вот как сформулировали для него цель, ожидания и нужные скилы. Основная задача: с помощью машинного обучения причинять пользователю максимум добра. Что это значит: я хочу увидеть, как человек стремится понять задачу и принести пользу. Значит, его размышления и действия должны показывать, как он ориентируется на пользователя. А ещё мне важно увидеть, что у кандидата широкие знания новых технологий: какие существуют, как работают, как решают разные задачи. Ожидаемые результаты: что должен сделать этот продакт за свои первые 6–8 месяцев ВКонтакте.  Выделить топ-3 среди фич на рынке, оценить их. Довести две до MVP и хотя бы одну вывести в прод. Обновить детектор ненормативного содержания на картинках — практическая задача, которую кандидат может обдумать между собеседованиями и понять, насколько она ему интересна и по силам. Договориться о решении этих задач и ресурсах. Ведь сделать ML-модель — это только 30–40% от выполнения задачи. Ещё 60% и по времени, и по затратам — это бэк, фронт, плюс нужно договориться с пиаром и маркетологами, обсудить всё с кучей продактов и смежников. И главное — запланировать под это ресурсы со всеми причастными командами. Чтобы все были в курсе и уже заряжены, когда будет готова моделька. Список навыков, которые потребуются в работе. Вот условный бланк, который мы готовим при поиске продакта. Выписываем сюда умения, нужные для сформулированных выше задач. По этим пунктам оцениваем кандидатов. Как это работает? У каждого пункта одинаковый вес. Оценки ставят несколько собеседующих: можно проводить одно интервью вместе или разделить между собой несколько встреч с кандидатом. Потом собираемся и обсуждаем, почему получились такие оценки: где справедливо поставить 7, а где 3. Все оценки по 10-балльной шкале, кроме последней — вайба. Это такое ощущение на уровне культуры, которое подсказывает, впишется ли человек в вашу команду. И здесь либо «да», либо «нет», то есть 1 или 0.  Почему важно оценивать не только скилы, но и вайб? Каким бы крутым ни был кандидат, если он не вольётся в команду и ваши ребята не найдут с ним общий язык, ничего путного не выйдет. Более того, команда может пострадать. Так что лучше сразу отпустить его в мир, пусть приносит пользу там. Когда видите, что кандидат собрал от 8 баллов и выше по всем параметрам, и понимаете, что это ваш человек по духу… пора вспомнить, что такой кандидат чаще всего сам выбирает работодателя. А значит, сейчас вы должны сделать так, чтобы он остался в вашей команде.  Есть лайфхак, который я придумал, когда приходилось много бороться за продактов и ML-разработчиков. После собеседования, когда мы уже поговорили о деньгах, я спрашиваю: «Что ещё ты хочешь, кроме денег?» Ответы всегда очень интересные. Кто-то, например, хочет, чтобы у него было супер-пупер-кресло, какое-то конкретное. Другие вместо подставок на мониторе требуют лапы, потому что любят вертеть экран по-разному. Кто-то хочет летать на море в воркейшен на две недели в году. В целом ответы расходятся на два типа, и работать с ними тоже стоит по-разному: Либо это что-то важное для кандидата, не суперзатратное для компании и вы как менеджер можете об этом договориться. Сделайте это. Так покажете, насколько ориентированы на своих сотрудников. Предложите им заботу, которой они не видели в других местах. Это подкупает даже самых крутых ребят. Либо вы поймёте, что запрос кандидата неконструктивный — например, когда запрашивают кресло за миллион рублей (всерьёз, без шуток). Дальше вы выбираете — или идёте на это, или сворачиваете на этом этапе собеседования. И последнее про наём: не медлите, когда нашли своего кандидата-звезду. Делайте оффер одним днём, нанимайте сразу же. Пауза даже в один-два дня может кончиться тем, что человек примет предложение другой компании. И потом даже суперусловия от вас не помогут — такие люди ответственные и честные, останутся где пообещали. Обсуждайте истинную продуктовую задачу. Я уже говорил об этом, но это действительно правило № 1 в работе с А-ребятами. Обсуждайте, в чём на самом деле задача. Не просто «сделать синюю кнопочку на экране», а «кнопочку, которая поможет приводить больше друзей на страницу юзера, вот почему это важно для него, вот метрики, вот исследования». Так разработчики включаются в процесс, высказывают мнения, предлагают технические решения — и в итоге помогают сделать для пользователя даже больше полезного, чем предполагалось. А ещё это работает на бренд компании: когда ваш разработчик будет с кем-то общаться, он сможет классно пропитчить идею или поделиться кейсом. Именно потому, что заинтересован, знает свою роль и понимает всю картину — что и зачем делалось. Создавайте горизонтальные связи. А-спецы хотят быстро давать и получать фидбэк, спрашивать напрямую и слышать ответы от экспертов. Поэтому вы как менеджер не должны становиться единственной точкой входа и выхода информации. Бывает так, что в задачах с другими командами цепочка становится слишком длинной: у разработчика есть вопросы, вы их принимаете, несёте другому менеджеру, тот кому-то в своей команде, а потом такой же путь проходит ответ. Не надо так. Знакомьте своих ребят с другими техническими командами, маркетингом, пиаром, с кем только можете. Пусть общаются напрямую: так задачи делаются быстрее и зачастую лучше. А если потребуется помощь или совет — напомните, что вы всегда рядом. Делитесь задачами и ходите в гости. Это мой лайфхак против bus factor — риска, что проект просядет, если в нём разбирается только один человек и он уходит в отпуск, заболевает или увольняется. Так вот, мы ходим в гости в проекты друг друга. Прямо выделяем две недели в квартал, когда разработчик может порешать задачи в другом направлении прикладных исследований. Например, человек из компьютерного зрения попробует поработать в NLP. Конечно, над понятной и не самой сложной задачей, с помощью ментора. Или даже пусть это будет просто демо с глубоким разбором. Всё равно проект становится прикрыт ещё одним специалистом. А сам разработчик не застопоривается на своих задачах, расширяет кругозор. Давайте пространство обстучать мысли. Классная идея по задаче может прийти в любое время — и вечером, и в выходной. При этом вовлечённым ребятам важно, чтобы на их мысли давали фидбэк. Раньше бывало, что разработчики могли позвонить мне, например, в субботу вечером с продуктовой идеей, мы её обсуждали, а за воскресенье они её докручивали и в понедельник уже выкатывали, чтобы посмотреть. Сейчас мы ушли от звонков и других частных пингов. Вместо этого создали несколько чатов по направлениям, например Computer Vision, ML, просто флудилку с мемасами и ещё несколько рабочих пространств. Туда человек в любое время может закинуть идею, и ему ответят. Во-первых, потому что наверняка ещё кто-то не спит. Во-вторых, мы установили несколько сессий, когда ребята точно заходят поотвечать в эти чаты — днём, вечером, ночью, кому когда удобно. Так что любая идея получит ответ, и это может быть просто: «Ок, классно, можно сделать» или «Не, это не работает, вот почитай в статье почему». Быстрая обратная связь хорошо мотивирует. Собирайте банк челленджей. Классные разработчики умеют на 100% фокусироваться на задачах. Одно условие: эти задачи должны быть интересным челленджем для них. И если в команде вдруг не нашлось такой задачи, разработчик может отвлечься на какой-нибудь стартап друга Сергея. Потому что там что-то новое, полезное для мира, и технологии можно по-новому покрутить. Получится, что задачам компании ваш крутой сотрудник будет уделять меньше времени, пока не доработает свою часть этого стартапа — ведь мозгами он там. Чтобы этого избежать, мы с другими продактами ВКонтакте каждый квартал составляем список задач-челленджей. Например, я могу дать своим ребятам какие-то мощные задачи от соседней команды на Python или на C. Получается сохранять фокус внутри компании, если предлагать много клёвых задач. Когда не нужно нанимать звёзд? Когда нет потока задач их уровня. Если задачи в основном понятные и типовые, с ними лучше справятся B-ребята: они умеют просто хорошо делать свою работу. И тут «просто» — это тоже не всегда просто. Эти принципы помогают нам сохранять в команде крутых ребят и усиливаться новыми A-сотрудниками. В завершение как раз хочу сказать про удержание звёзд: это история, конечно, про конкурентную вилку оплаты — но и не только про деньги. Что ещё делать менеджеру, чтобы его талантливые разработчики горели, но не перегорали, и хотели оставаться в компании: Быть зонтиком от фигни — не давайте своим ребятам утопать в рутине и слишком мелких для них вопросах. Если видите, что кто-то слишком закопался и заскучал, подкидывайте небольшие командировки, учебные проекты. Подсвечивать успехи каждого — да, не так часто бывают большие запуски, где кто-то сильно выделился. Но хотя бы раз в месяц подведите итоги и покажите, где человек был хорош. Даже если вам кажется, что вы высасываете из пальца эту похвалу, — поверьте, она очень важна. Иногда быть душнилой, чтобы фичи выходили в прод. Выкатка — это сложный процесс с тестами, отвалами; бывает, что что-то не работает, кто-то продолбался — ну вы поняли. Могут опуститься руки. Поэтому помогайте разработчикам дойти до конца, чтобы их работа увидела свет во что бы то ни стало. Это то, что мотивирует больше всего остального.  Ещё, когда я выступал на TeamLead Conf с этой темой, меня спросили — можно ли выращивать в команде A-спецов? То есть делать так, чтобы B-ребята становились звёздами. Я ответил, что решает среда в команде. Сужу по себе: кажется, на прошлом месте я был в категории В — просто делал свою работку. А ВКонтакте, где большая часть команды — это А-специалисты, я сам подтянулся к их уровню. Когда рядом все горят желанием сделать круче и лучше, заботятся о пользователях и друг о друге — это задаёт такую планку в команде, на которую все ориентируются.