Хабрахабр

Как выявлять и развивать таланты в 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 под паролем или что-то такое. Рекомендация семь плюс-минус два есть, но обычно получается, с кем можно работать более-менее эффективно, это максимум 15-20. Есть 70 человек, по ним хранить подробную информацию физически невозможно. Дальше идет сильное падение качества.

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

Мы же не можем просто выдернуть семь человек. Ирина Федулова: 70 человек уже работают, чем-то заняты.

Вопрос: Суперважный проект.

Нужно поднапрячься и вдобавок к своим обязанностям что-то сделать? Ирина Федулова: И допустим, он временный.

Вопрос: Найти семь человек, найти важный проект и потом их распустить.

Напротив фамилии стоял не цвет штанов, а просто скиллы, то, чем они умеют заниматься, и чем им хотелось бы заниматься, и мы матчили эти скиллы под задачу. Ирина Федулова: На это у нас был список, как раз который формировался из посетителей и участников этого коммьюнити, людей, которым интересно делать что-то дополнительное к своим обязанностям.

Андрей Плахов: Вы про это просто спрашивали людей время от времени?

Ирина Федулова: Да, в процессе внутренних митапов.

Это работает крайне отвратительно. Дмитрий Долгов: У меня опыт ограничен игровой индустрией, но у нас ситуация, что есть суперсрочный проект, давайте на него сдёрнем семь талантливых людей, они за месяц это поправят и вернутся к прямым обязанностям. А если ещё есть необходимость каким-то образом разбираться, погружаться в уже идущий, кем-то начатый проект, какой-то командой, которая не справляется – это скорее сильный демотиватор, чем помощь в разработке. Ситуация, когда человека на проекте сдергивают для решения других задач – само по себе большой стресс.

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

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

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

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

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

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