Как выявлять и развивать таланты в IT: результаты первого Team Leader meetup
Вопрос: Мы тут разговариваем про выявление талантов, и есть разные талантливые люди, которые не факт, что нам в компании нужны. Мальчик с феерической памятью сейчас намочит первые три ряда, прекрасный талант у мальчика.
Есть разные таланты, которые попадают или не попадают в нашу компанию, некоторые нам нужны, некоторые нет.
Как понять, какие таланты нам нужны, и как под их конкретную формулу сделать машинку выявления этих талантов? Вопрос с продолжением.
Дмитрий Долгов: У человека может быть огромное количество талантов, невостребованных в работе. Может, он программист, а ещё замечательно играет на пианино и поёт. В каком-то виде, возможно, оно чуть-чуть применимо к работе, если он занимается озвучкой или чем-то ещё, но во всём остальном, пожалуйста, можно петь сколько угодно в свободное от работы время.
Необязательно у человека должны быть только рабочие таланты и необязательно все его таланты применять.
Андрей Плахов: Я знаю нескольких людей, которые изобрели такую машинку независимо друг от друга, и один из них — ты. Машинка эта выглядит как спецкурс в каком-то вузе. Свой спецкурс можно сделать ровно под выявление талантов, которые нужны.
Дмитрий Долгов: Что не отменяет того, что у меня работают певцы и музыканты.
Андрей Плахов: Безусловно. Мне кажется, ты являешься автором такой машинки. Надеюсь, это не секрет.
Дмитрий Долгов: У меня было замечание касательно обсуждения, что в компаниях, где процессы устаканены, не требуются таланты. Согласен с небольшим контрпримером. Если слесарь работает на станке, вытачивает одни и те же детали, в принципе, какие нужны таланты? Сиди да работай. С другой сторон, потом приходит Форд, смотрит на это и изобретает конвейер.
Андрей Плахов: Уходит из компании в свою.
Дмитрий Долгов: Но можно было бы это сделать и в компании. Даже когда процессы отлажены и все работает, как часы, существует возможность вносить новшества и инновации.
Ирина Федулова: Продолжу тему общения руководителей с подчинёнными. Есть ещё один уровень взаимодействия — горизонтальный — между техническими людьми. У меня была практика, когда организовывались что-то типа митапов, когда технические специалисты для сейлов рассказывали, какие они крутые штуки делали, сейлы говорили, что круто, есть потенциальный клиент, для него давайте запилим штуку. И под это организуется ad-hoc блиц-команда из кусочков людей, и в процессе выявляются таланты. Человек на самом деле писал что-то для мейнфрейма, а тут — бац, оказывается, он прекрасен в data science. Горизонтальные встречи технических специалистов друг с другом. Они рассказывают о том, чем занимаются. А другие рассказывают о том, что им нужно. Такие горизонтальные связи.
Николай Суетин: Есть ещё практика внутрикорпоративной мобильности, о чём Ирина упоминала. Очень полезно, когда человек на три месяца пошёл в сейлзы или маркетинг. Казалось бы, техническому человеку это по барабану, но в результате оказывается, что он узнаёт такие тонкости, о которых раньше не подозревал. И это сильно может даже поменять его карьеру. Эта практика must, не то, что «хочу — делаю, хочу — нет», должен три месяца в год где-то отработать. Начиная с некоторого грейда в некоторых командах рекомендуется.
Дмитрий Долгов: Что касается информационного обмена со встречами один на один, один ко многим, это, безусловно, задача и для выявления, и чтобы узнавать, что так можно было. Информационный обмен — это очень важная составляющая любой компании, любого процесса. По крайней мере, у нас на длительных сроках разработки проектов, когда мы шутим, что на этом проекте разработчики уже начали умирать от старости.
Бывает автобусный коэффициент, когда какого-то ключевого человека сбивает автобус, как сильно будет заторможена или остановлена работа. Бывают ситуации увольнения. Всё, что угодно, бывает. У нас даже были случаи полного расформирования команды и набора новой команды для продолжения работы.
Информационный обмен — не только устное общение. Обязательно нужно документировать всеми доступными способами, это необходимо банально для того, чтобы проект мог развиваться и жить в течение долгого времени. Думаю, это не только для игр актуально, наверняка и в долгоиграющих сервисах Яндекса это необходимо.
Касательно «а что, так можно было». У человека в любой задаче есть возможность вскочить на ступеньку выше, чем это описано в задаче. Вопрос «а что, так можно было?» можно переформулировать так: «разрешено все, что не запрещено». В любой разработке существуют некие ограничения. Грубо говоря, есть стартовая точка, где мы находимся, и мы хотим получить проект, который находится где-то выше. Наше идеальное продвижение к нему вперед: получили задание, сели работать, через два года выдали замечательный сервис или отличную игру.
По факту получается не так. Этот путь — сложная линия, которая приведет нас либо в эту точку, либо где-то рядом. Часто бывает, что во многих ситуациях разработки или действий отдельных людей, они нас не приближают к точке решения, а уводят далеко. Чтобы этого не происходило, существуют ограничения, которые надо ставить, чтобы не принимались неправильные плохие решения. Это может быть во всем: использование методологий, языков, middle ware, использование системы документооборота, контроля версий — что угодно, во всех этих случаях бывают ограничения. А дальше всё, что не запрещено, разрешено. Любые действия сотрудников, которые поднимают нас на ступеньку и приближают к решению проекта, являются однозначно полезными, должны быть обсуждены и зафиксированы как лучшие практики.
Вопрос: Здесь разговор больше об индивидуальных качествах разработчика. Но они же не по отдельности работают, а вместе. Что вы думаете о такой ситуации: есть три человека, они по отдельности работают плохо, а вместе — хорошо, или наоборот.
Сергей Бережной: Ровно это я имел в виду, когда говорил про искусственную кладку, что каждая ситуация уникальна и людей прежде всего мы подбираем гранями друг к другу. И конъюнктура того, что у нас открылось место тим-лида в какой-то команде, совсем не означает, что этот тим-лид должен обладать компетенциями руководителя и всё. Конъюнктура от команды к команде может отличаться. Там люди, условно, более инициативные и прокачанные в какой-то области, там менее. В зависимости от этого тим-лид, которого мы поставим на это место, должен обладать разными компетенциями. И дело не только в тим-лиде. Просто открылась вакансия в команде, и в зависимости от того, как распределены компетенции других участников команды, в чём они сильнее, в чем слабее, эту новую дырочку нужно занимать разным человеком. Как раз это я называю гибкостью и эффективностью. Если мы будем смотреть на эти вакансии как на абстрактные вещи, мы потеряем какой-то процент эффективности.
Вопрос: Как вы узнаете, сработаются они или нет?
Сергей Бережной: Интуитивным экспертным мнением. Подумаю, насколько они друг к другу подходят, на основе опыта подобных экспериментов, с кем раньше этот человек срабатывался, и с кем срабатывались те, к кому я его подселяю. Длительное наблюдение, история.
Александр Горный: Тут работает универсальный менеджерский тул — спросить. «Вася, тебе понравилось прошлый раз работать с Петей?» — «Да, было офигенно». И Петю спросить — «Было офигенно». Значит, сработались, результат был хороший. А если один говорит, что Петя все завалил, а я все делал, а тот на Васю валит — значит, не сработались. Всегда так. В лоб спрашиваешь, получаешь ответ. Конечно, бывают градации между идеальной сработанностью и несработанностью. Сравниваешь. Они же не скрывают. Это не тайна, которую надо узнать. Это надо спросить и узнать ответ.
Ирина Федулова: И в конце концов можно понаблюдать за происходящим. Ещё случай из практики, когда было четыре человека, над похожими проектами работали два и два. Мы видим, что-то не клеится, мы решили их переставить по-другому два на два, и сразу пошло. Просто понаблюдать.
Александр Горный: Не совсем согласен. Наблюдать надо очень внимательно. Ругающаяся пара может быть очень хорошо сработана. А молчащая может как понимать друг друга с полуслова, так и просто ненавидеть, поэтому не говорить.
Ирина Федулова: Я за результатом наблюдала.
Дмитрий Долгов: Снова эти секретные менеджерские списки, характеристики людей, информация о том, с кем и как успешно они работали в предыдущих задачах. Но все зависит от специфики задач. Ставить на рутинную задачу двухмесячной давности четырех лидов с ярко выраженными характеристиками склонностью к обучению, принципиально разными подходами к концепции архитектуры разработки софта — это смерти подобно, они скорее разбегутся через неделю с матами. С другой стороны, поставить на этот проект четырех слабых джуниоров — они не смогут склеить.
При таких вещах надо учитывать большое количество вещей. У меня были реальные истории, когда люди в команде разбегались банально из-за разных политических взглядов, вплоть до этого. Под каждую задачу надо собирать, открывать свои секретные блокноты, смотреть, как работает Петя и Вася, с кем работают лучше, подбирать лидов и непосредственных исполнителей в пропорции один лид на пятерых джуниоров, смешать, но не взбалтывать, и так далее, решать такую комбинаторную задачу.
Алексей Шаграев: Тоже расскажу историю, хочется подсыпать дровишек в этот вопрос. Бывает ещё так, что люди поодиночке классные, а вместе вообще жесть какие классные. Есть у меня девлид бэкенда, девлид фронтенда, дизайнер и менеджер. Все они — замечательные люди, я вижу, они с открытой душой, любят слушать других и всё такое. Думаю, было бы классно, если бы они друг друга учили, общались, чтобы они всё время рассказывали, что делают, вырабатывали общие планы.
Это привело к тому, что дизайнер придумал, условно, JSON на фронтенд, тот реализует дизайн, с этим пользователи взаимодействуют… В итоге дизайнер придумал формат ответа бэкенда для фронтенда, чтобы как можно больше разных визуальных элементов мы могли запускать в продакшен, проверять в экспериментах, которые ложатся во множество возможных концепций. Переход позволил большое количество экспериментов запускать с бэкенда, это очень быстро, дизайнер в процессе это понял, придумал такой формат, который позволил все его идеи реализовать.
Андрей Плахов: А как такого результата достигли? Сидели в одной комнате, ходили вместе обедать? Что повлияло?
Алексей Шаграев: Люди разных специальностей и при этом все успешные, если их оставить в одной комнате, обязательно подерутся, каждый считает себя гением, и с ним сложно спорить. Поэтому начало было таким, что каждый из них всем другим рассказывал, что они делают и какое здесь обоснование, и в процессе нужно было, чтобы был авторитетный человек, который расскажет, что то, что те ребята говорят, это не ерунда, это разумно. И когда они проникаются пониманием, почему что-то делается конкретным образом, у них это взаимопроникновение происходит.
Вопрос: По поводу списка талантливых сотрудников. На каком уровне они работают? Если ты руководитель, у которого 70 человек в подчинении, и тебе нужно собрать команду из 7 человек, все списки у тебя хранятся, у тим-лидов собственные, у руководителей тим-лидов собственные, а потом только наверху эти списки скрещиваете.
И в каком именно формате эти списки хранят? Вася, 2007 год, работал с этим-то. Как ими пользоваться, когда у тебя 70 человек в подчинении, и информация о каждом растёт каждый месяц, кажется, это все неуправляемо.
Александр Горный: У меня максимум было 150 подчиненных. Информация о том, кто из них талантлив и в чём, у меня хранилась просто в голове в формате, что когда в задачу попадает Петя, то всё офигенно быстро делается, а когда попадает Вася, то всё делается офигенно быстро, но потом надо два раза переделывать.
У тим-лидов, конечно, была примерно та же информация, но более точная и качественная. И важно, какое решение надо было принять. Либо надо раздать новую задачу, тогда, если она рядовая, она до меня не доходит, а если не рядовая, у меня в голове есть несколько кандидатов, я их посажу с тим-лидами. Если надо кого-то поднять — то же самое. Никакого монстроидального Excel не было.
Алексей Шаграев: У меня нет таких списков, я верю во всех людей. Еще я считаю списки довольно опасной штукой, потому что бывает так, что люди зарабатывают какую-то репутацию и невозможно от неё отделаться. Бывает, что Петя плохо сделал проект Х, прошло пять лет, он делает совсем другое, а у меня засело в голове, как он мне тогда напортачил. Мой мозг должен быть свободен от этого. Мне важно, кем он является прямо сейчас. Поэтому хранить за 500 лет историю всех успехов и провалов сотрудников и предъявлять им, что они недостаточно талантливы и три года назад что-то не то делали… Не хочу такого.
Вопрос: Поскольку мне по роду занятий приходится вести интервью, мы в обязательном порядке разговариваем с кандидатами об их провалах. Good weather doesn«t make good sailor. Невозможно научиться чему-то, не ошибавшись. Каждый админ в обязательном порядке однажды грохнет продакшеновую базу. Нам нужен кто-то, кто уже грохнул.
Сергей Бережной: По иерархии поднимаешь. Количество подчиненных семь плюс-минус два и плюс-минус каждый руководитель про своих подчиненных в таких терминах должен знать очень подробно без всякого Excel. Ты можешь знать чуть менее подробно, как Саша сказал, и когда наступает момент принятия решения, вы собираетесь в комнате, озвучиваете задачу и принимаете решение. И если кому-то интересна моя рекомендация, сэкономьте свое время на составлении таких списков, они не помогут, они не позволят вам эффективно принимать решение, на мой взгляд.
Дмитрий Долгов: Поскольку я произнёс словосочетание «секретные списки», поясню, что это совершенно не означает записей в блокноте, в Excel под паролем или что-то такое. Это информация, которая может быть как-то классифицируема, начиная с грейда, хобби и основных скиллов человека, она может быть представлена в голове. Есть 70 человек, по ним хранить подробную информацию физически невозможно. Рекомендация семь плюс-минус два есть, но обычно получается, с кем можно работать более-менее эффективно, это максимум 15–20. Дальше идет сильное падение качества.
Если необходим какой-то ресорт команды, если это не люди прямого подчинения, а по какой-то иерархии, то это либо задача руководителя этой группы, либо моя совместная с ними задача, чтобы разобраться, каким образом переформатировать тот или иной блок.
Ирина Федулова: 70 человек уже работают, чем-то заняты. Мы же не можем просто выдернуть семь человек.
Вопрос: Суперважный проект.
Ирина Федулова: И допустим, он временный. Нужно поднапрячься и вдобавок к своим обязанностям что-то сделать?
Вопрос: Найти семь человек, найти важный проект и потом их распустить.
Ирина Федулова: На это у нас был список, как раз который формировался из посетителей и участников этого коммьюнити, людей, которым интересно делать что-то дополнительное к своим обязанностям. Напротив фамилии стоял не цвет штанов, а просто скиллы, то, чем они умеют заниматься, и чем им хотелось бы заниматься, и мы матчили эти скиллы под задачу.
Андрей Плахов: Вы про это просто спрашивали людей время от времени?
Ирина Федулова: Да, в процессе внутренних митапов.
Дмитрий Долгов: У меня опыт ограничен игровой индустрией, но у нас ситуация, что есть суперсрочный проект, давайте на него сдёрнем семь талантливых людей, они за месяц это поправят и вернутся к прямым обязанностям. Это работает крайне отвратительно. Ситуация, когда человека на проекте сдергивают для решения других задач — само по себе большой стресс. А если ещё есть необходимость каким-то образом разбираться, погружаться в уже идущий, кем-то начатый проект, какой-то командой, которая не справляется — это скорее сильный демотиватор, чем помощь в разработке.
Если такой проект возникает, туда нужно либо переводить людей на постоянку, либо набирать новых, либо брать одного толкового, чтобы он собирал команду. Чтобы не было такой игры в домино. Я несколько раз лично даже на своей шкуре испытал, что такое переброс с проекта на проект, и это очень плохое менеджерское решение.
