Хабрахабр

Классный тимлид ответит за сервис

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

— Чем ты занимаешься и какое отношение имеешь к тимлидам?

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

Но на текущий момент у меня в группе в общей сложности порядка 50 человек, из которых семеро — тимлиды разной специализации: верстальщики, дизайнеры, разработчики, менеджеры, аналитики. Что касается тимлидов, то сам я никогда им не был, сразу стал руководить службой.

— Какую роль тимлиды играют в Яндексе?

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

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

Какие из них важнее? — Чтобы все это совмещать, нужны какие-то специфические качества?

Да, это должны быть классные ребята.

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

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

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

— Тимлид — это естественный путь развития разработчика?

Но есть и другие. Это один из возможных путей развития разработчика.

— Каких качеств не хватает кандидатам, которые претендуют на роль тимлида?

Многие хорошие разработчики мыслят в терминах задач: мне ставят задачи, я их решаю, причем делаю это хорошо, за это меня надо оценивать. По моему опыту, у них есть проблемы с тем, чтобы осознать, какие решения они могут принимать, а какие нет.

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

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

— При таком масштабном взгляде на проблему не конфликтует ли тимлид с ролью product owner-а?

Руководитель сервиса (тимлид) и product owner — это все-таки разные роли. По-моему нет. Тем более, что само наличие product owner-а не означает, что всем остальным надо вырвать мозги и не думать. Даже если в коллективе обе они существуют в форме раздельных людей, конфликтуют они крайне слабо. Здорово, когда вся команда думает о продукте и помогает product owner-у хорошо решать свою задачу.

Но руководитель обязан обладать и собственным стратегическим видением того, как сервис должен развиваться в будущем. Если говорить с позиции руководителя сервиса, то product owner — это человек, который помогает ему двигать сервис как тактически, так и стратегически. Путь не так важен, главное, чтобы видение все-таки было (и именно у руководителя сервиса). Это видение он получает либо через работу с product owner-ом, либо через взаимодействие с командой.

— В Яндексе тимлид — это руководящая или инженерная должность?

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

— В Яндексе есть команды, где роли тимлида, техлида и product owner распределены между разными людьми?

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

— Есть ли что-то, помимо управления людьми, что обязательно должен знать тимлид?

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

Ему придется искать себе помощника в команде, а может и снаружи, например, в лице своего руководителя. Тимлид в любом случае не сможет уметь всего, что нужно уметь тимлиду.

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

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

И что при этом важно для тимлида, с чего стоит начать? — Может ли тимлид прийти в команду со стороны?

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

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

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

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

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

— Какой ты видишь смысл в посещении TeamLead Conf?

Мне кажется, что в посещении конференций для тимлидов и разработчиков есть несколько смыслов.

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

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

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

— О чем ты будешь рассказывать на сентябрьской конференции?

Например, у меня был разработчик, который под моим началом из джуниора стал тимлидом, а потом ушел руководителем службы в другое подразделение Яндекса. В моей жизни было несколько человек, которых я воспитал как тимлидов, и затем они ушли на повышение в разные подразделения нашей большой компании и даже за ее пределы. С другой стороны, были и ребята, которые этот путь не прошли: закончили где-то посередине и не развиваются дальше. То есть я несколько раз проходил этот путь с разными людьми, и я прошел его сам с собой. Именно про это я и постараюсь рассказать так, чтобы это было максимально полезно, чтобы разные люди могли взять это знание себе на вооружение, а их карьера стала более подвижной (особенно если у них есть с этим проблема). И, как мне кажется, я знаю какое-то количество вещей, которые отличают первых от вторых.

Изучайте другие доклады про тимлидов и для тимлидов в расписании конференции Saint TeamLead Conf.

Там же появятся и видео новой конференции, но через несколько месяцев. Материалы весенней TeamLead Conf в полном объеме выложены на нашем YouTube-канале. Подписывайтесь, если не хотите пропустить.

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

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

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

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

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

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