company_banner

Фантастические тимлиды и где они обитают

    Всем привет! Меня зовут Анатолий Панов, я работаю в ИТ уже больше 15 лет. За это время прошел путь от разработчика до руководителя тимлидов. Работал в таких компаниях как Badoo, Lazada. С начала этого года я в Авито. Руковожу разработкой новых проектов и разработкой для вертикалей Авто и Недвижимость.


    В начале работы в Авито передо мной стояла задача собрать три команды разработки. Две из них были уже частично укомплектованы разработчиками, но ни в одной из них не было технического руководителя. Их нужно было быстро найти и нанять.


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


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



    С чего начать?


    Первая мысль, конечно же, была такой: давайте запромоутим внутреннего кандидата. Но начавшаяся 1,5 года назад трансформация из функциональных команд в кроссфункциональные уже «съела» весь резерв. Только одну позицию удалось закрыть изнутри, еще двух человек предстояло нанять.


    До этого мне не приходилось заниматься наймом тимлидов. У меня в командах они появлялись более традиционным способом: всегда были ребята, которые показывали себя хорошо в деле, и мы повышали их.


    Оказалось, что процесс найма тимлидов состоит из тех же трех больших этапов, что и найм разработчиков.


    • Составить требование, профиль кандидата.
    • Найти кандидатов на рынке, понять, кто из них подходит к профилю.
    • Провести очное интервью.

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


    Составляем профиль кандидата


    Чтобы запустить поиск кандидатов на вакансию, у нас должен появиться профиль кандидата, документ, в котором написано, что за позиция, кого мы на нее ищем, цели кандидата, которые будут стоять перед ним в ближайшее время, и навыки, которыми он будет обладать.
    Мне повезло: у нас уже были сформированы общие требования на позицию тимлида. Она называется «руководитель разработки юнита», или сокращенно TUL (от английского technical unit leader).


    Прежде чем поговорим подробнее про требования, я бы хотел рассказать немножко о том, как у нас устроена разработка, чтобы было понятно, почему сложились определённые требования.


    Предыстория


    Мы начинали с обычной функциональной структуры. В Авито были группы разработки бэкенда, фронтенда, мобильные разработчики, тестировщики. Всё стандартно. Когда нужно было сделать какую-то большую задачу, она либо декомпозировалась, и маленькие кусочки спускались внутрь команд и приоритезировались внутри, либо под задачу собирались кроссфункциональные команды. Со временем это перестало работать. Всё сложнее становилось приоритезировать, команд становилось больше, было много коммуникации между ними. Задачи перестали долетать до продакшна с нужной нам скоростью.


    Кроссфункциональные команды


    Мы решили перейти к кроссфункциональным командам. Мы называем их юнитами. Они образуются у нас вокруг значимых частей бизнес-функциональности. Например: мессенджер, подача объявлений, поисковая выдача, сам движок поиска. Юнит содержит в себе все компетенции для того, чтобы дотащить фичу от этапа идеи до продакшна с минимальными зависимостями от внешних команд. В него входят и технические функции, и продуктовая в виде менеджеров продукта, дизайнеров — всех тех людей, которые нам подготавливают бэклог.
    У каждого юнита есть два типа руководителей. Первый — юнит лидер, его задача заключается в том, чтобы сформировать бэклог для команды и приоритезировать его. Он отвечает за достижение бизнес-целей. Второй — это как раз-таки технический руководитель юнита. Он отвечает за то, что делает команда разработки, за качество кода, который они пишут, за его безопасность, за планирование и достижение целей. Участвует в формировании продуктового бэклога (его задача заключается в том, чтобы найти технические блокеры и заранее позаботиться об их устранении).



    Требования к техническим лидерам


    Каким требованиям должен соответствовать такой руководитель? Идеальный технический лидер:


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

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


    Первый проект — это Domofond. Команда уже со старта должна была быть 12 человек, мы планировали перенести разработку Domofond из Южной Африки в Россию. Плюс мы должны были переписать проект с нынешнего стека технологий (.NET, Windows Server) на стек Авито, чтобы дальше можно было развивать и поддерживать его собственными силами. Мы хотели, чтобы руководитель этого юнита имел практический опыт руководства командой больше 10 человек. Он должен был уметь хорошо нанимать, и у него должен был быть опыт мобильной разработки, потому что у Domofond было два мобильных приложения, написанных на кроссплатформенном фреймворке Xamarin.



    Вторая команда — это Verticals SWAT. Мы формировали её для того, чтобы поддержать тестирование бизнес-инициатив в вертикалях Авито (Авто и Недвижимость). Задача этой команды была в том, чтобы быстро делать маленькие прототипы, тестируя бизнес-гипотезы. У руководителя этой команды была задача выстроить процесс разработки так, чтобы мы эти бизнес-гипотезы могли быстро доставлять и тестировать. Он должен был хорошо понимать процесс запуска MVP и требования к нему.


    Ищем кандидатов


    Итак, первый этап закончился. У нас есть профиль кандидата, с которым можно идти в HR: рассказать им, что мы хотим, сидеть и с радостью ждать, когда нам принесут кучу классных резюме.


    Всё здорово? Нет. Резюме редко показывает реальные возможности кандидата, его навыки, что он умеет делать. Я наблюдал такое очень часто: по резюме кажется, что это классный специалист, но на интервью ты понимаешь, что это ошибочное впечатление. Поэтому на этапе поиска резюме мы просто определяем, хотим ли мы с этим человеком общаться лично или нет. Подходит он нам по профилю (который сформирован на прошлом этапе), или нет.


    Читаем резюме


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


    Очень часто бывает так, что HR приносит «пустое» резюме: там только список компаний, в которых человек работал, и должности. Обычно такое бывает, потому что человек активно не ищет работу, его нашли где-то на LinkedIn. Либо приносят резюме, похожее на наш профиль кандидата, но в нём информация, которая ничего о человеке конкретного не говорит. «Я занимался разработкой микросервисов», «я делал сервис такой-то». Но если компания, в которой работал кандидат, довольно известная, то косвенно о его навыках можно судить по публичной информации о компании.


    И последнее, что даёт нам информацию — то, как сам кандидат пишет про себя, про свои навыки. Приведу примеры.



    Первый кандидат пишет, что он занимался проектированием новой схемы шардинга, внедрением мониторинга, оптимизацией основной БД проекта, перезапуском проекта на новой платформе. Очень много про технологии и мало про процессы. Видимо, это хороший технарь, но нам не понятно, умеет ли он управлять командой.



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



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


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


    Проводим скрининг и запрашиваем рекомендации


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


    Ещё один способ собрать недостающую информацию — рекомендации на кандидата. На этом этапе нет задачи собрать полноценный фидбэк от его коллег и начальника о том, как кандидат себя проявил. Это можно будет сделать в конце, когда мы уже поговорим с ним лично. Здесь это просто проверка на адекватность. Если говорить в терминах QA, то мы делаем smoke test и sanity check этого кандидата. Важная вещь: я делаю это не только для тех кандидатов, у которых профиль неполный, а вообще для всех, где я могу это сделать. Для этого я использую только свою сеть контактов, своих знакомых в этих компаниях, либо каких-то знакомых коллег. Это важно потому что иногда бывает, что кандидат вроде бы с хорошим профилем, всё здорово, но на него приходит негативный фидбэк, к которому стоит прислушаться.


    Закончился второй этап. У нас должен появиться список кандидатов, с которыми мы хотим пообщаться. Переходим к самому интересному — к очному интервью.


    Очное интервью


    У нас в компании очные интервью на менеджерские позиции обычно состоят из трех этапов.


    Первый этап очного интервью


    Первый этап — это самое обычное интервью с руководителем и HR. Задача этого этапа — понять, соответствует ли профиль кандидата тому, что нам нужно.


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


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


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


    Вопросы про технический бэкграунд


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


    Вопросы про найм


    Следующий блок — вопросы, связанные с наймом. Доводилось ли человеку заниматься подбором? Если да, то как выглядел процесс? Какие вопросы он задаёт на собеседованиях? Как он проверяет те или иные качества у кандидатов, на что он вообще смотрит, каких людей он хочет нанимать себе в команду?


    Вопросы про управление людьми


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


    Вопросы про разработку


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


    Второй этап очного интервью


    Закончили с первым этапом очного интервью. Если кандидат его проходит успешно, то второй этап очного интервью мы проводим с командой и стейкхолдерами. Обе мои вакансии были в продуктовые команды, а для тимлидов таких команд очень важно тесное взаимодействие с владельцем продукта (product owner) и бизнес-заказчиком. Поэтому состав участников был именно такой. При найме в другие команды этот этап может отличаться. Например, если это платформенный юнит и мы хотим, чтобы тимлид писал код, или если мы знаем, что команда не примет лидера, у которого технические скиллы хуже, чем у её участников, то здесь может проводиться глубокое техническое интервью, точно такое же, как делается для разработчиков.
    Но у меня была продуктовая команда. Чем отличается первый этап очного интервью от второго? Во-первых, другой состав участников. На втором этапе вопросы могут пересекаться, с тем, что мы уже спрашивали кандидатов на первом этапе. Но поскольку их задают уже другие люди, с другим опытом, то мы получим другую точку зрения на этого кандидата. Коллеги могут увидеть что-то, чего не увидел я. Плюс для меня лично это был еще очень полезный этап в плане поддержания планки найма на нужном уровне, потому что когда поток кандидатов уменьшается, на интервью приходит все меньше и меньше людей, есть соблазн чуть-чуть понизить планочку и взять наконец хотя бы кого-нибудь, чтобы закрыть позицию. Но коллеги, которым придётся вместе с этим человеком работать, могут тебя вовремя остановить и сказать: «Подумай получше». И планка поднимается обратно.


    Третий этап очного интервью


    Последний этап — это защита кейса. Это такое тестовое задание для менеджеров. Идея ровно такая же как с тестовым заданием для разработчиков: проверить, как кандидат будет себя вести в реальной ситуации. Здесь очень важно давать пример, максимально приближенный к тому, какая ситуация сложилась у вас в команде, потому что только тогда вы сможете понять, как же кандидат будет себя вести, если он к вам придет работать. Как выглядел кейс у меня? Покажу на примере проекта Domofond.



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


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



    Это скриншоты реальной презентации, которую нам защищал кандидат проекта Domofond. Обычно на подготовку к ней нужно около двух недель. Презентация занимает 20-30 минут. Примерно столько же времени мы отводим на сессию вопросов и ответов.


    Последний этап закончен. К этому моменту у нас должен появится кандидат, которому мы бы хотели сделать оффер. На этом можно было бы и закончить… Но есть еще один этап.
    Иногда так бывает, что кандидат всем понравился, он очень классный, мы очень хотим видеть его у себя, но он по каким-то причинам сомневается, либо есть какие-то внешние обстоятельства, которые мешают ему принять решение. Например, он должен переехать из другого города, ему нужно перевозить семью, и это для него проблема. И здесь мы должны помочь ему принять правильное для нас решение. Я называю это «продать вакансию».
    У меня был случай, когда все было классно, кандидат нам понравился, мы ему понравились, но он не мог определиться с датой выхода. Он говорил нам: «Я приду к вам через два-три месяца. Мне нужно доделать проект, над которым я работаю. Он очень важный, классный. Я не уверен, когда мы закончим». Мы позвали его в офис на последнюю финальную встречу, ответили на все вопросы, которые были у кандидата на тот момент неотвеченные, проговорили эту ситуацию, договорились о том, что он сможет в рабочее время помогать своей команде, у него будет возможность сдавать проект вместе с ними, в общем, мы всячески готовы были содействовать. Выдали ему оффер, договорились, что он придёт через месяц. Он оффер принял, вышел… и в итоге так и не воспользовался нашим предложением, потому что они сдали проект в срок.


    Заключение


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


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

    На этом всё. Спасибо за внимание. Если у вас появятся вопросы, пишите комментарии, я постараюсь на них ответить.


    P.S. Эту тему я раскрывал в докладе на Saint TeamLead Conf 2018, вот слайды.
    Для оформления использованы иконки под авторством Becris и Freepik на Flaticon.

    Авито
    322,00
    У нас живут ваши объявления
    Поделиться публикацией

    Комментарии 50

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

      пять балов, чо…
        +1

        Ну, к сожалению, это так, да.
        Это ни сколько не уменьшает важности уметь программировать, систематизировать и проектировать. Но эти люди… они везде, и они все чертовски разные.

          0
          Сперва набирают «домашних» программеров
          Потом к ним ищут тимлида на 200К+
          Получают супер софт
          Недорого
          Профит
          +4
          Гуманитарий, что взять…
          Не проводил, походу, по 60 часов в неделю у белой доски в жарких спорах и поиске решений…
            +1

            А если перефразировать, лиду нужен специфический опыт — работа с людьми, и ему точно не научиться дома, он должен уметь правильно систематизировать все задачи, планировать, контролировать и программировать в общем случае не обязан, но может и точно мог). Это бывший сеньер, который ещё имеет навыки управления работой, людьми,… И этому можно научиться в основном только через реальный опыт. У нас есть 10 отличных программеров, но компетенция и Лида обладает один, максимум два. Это большая проблема

            +10
            Второй — это как раз-таки технический руководитель юнита. Он отвечает за то, что делает команда разработки, за качество кода, который они пишут, за его безопасность, за планирование и достижение целей.
            Интересно, как такой лид команды из сборной солянки бэкенда, фронтенда и разрабов под мобилки следит за качеством кода всех подопечных? Не говоря уж про безопасность, что является отдельной большой темой. Там скорее всего не один репозиторий. Он в каждом проводит тщательное ревью? Да на команду из 12 человек на это просто времени не хватит.
              –1
              Отвечает != лично сам руками делает. В данном случае задача TULа позаботиться о том чтобы код был качественный, а способов это сделать может быть много, например: ревьюить самому если есть экспертиза, иметь в команде по сильному разработчику нужных функций которые отвечают за ревью, договориться с коллегами из смежных или платформенных команд о кросс-ревью и т.п.
              Для обеспечения безопасности тоже есть свои практики и инструменты, например практика Security Champions. В дополнение к этому есть отдельная команда со специалистами по безопастности которая может сделать аудит по запросу, но для этого TUL должен к ним прийти с этим запросом :)
                +2
                Отвечает — контролирует. Адекватно контролировать такое количество разных технологий (2 мобильных, фронт, бэк (в количестве стэка авито) — это новый уровень фулстэка. Но нужны еще навыки ПМ/Лида (на уровне техлида). -> Архифулстэк.
                И отдельное НО
                договориться с коллегами из смежных или платформенных команд о кросс-ревью и т.п.
                Другие команды — это неконтролируемая сфера. У них может быть релиз, авария и тд. и им не до ревью ваших фич. Плюс они вне контекста проекта, и оптимальность решений могут оценить только на уровне кода, но не на уровне взаимодействия с другими элементами проекта.
                  +2
                  Отвечает — контролирует

                  Это так, но вот дальше следствие из этого не совсем корректное. Как я писал выше, можно контролировать все лично, если есть экспертиза и время. А можно выстроить процесс так, что этим будет заниматься человек у которого есть нужная экспертиза. И тут много разных вариантов в зависимости от ситуации в компании и окружения.

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

                  Согласен, это очевидный минус такого решения :) Но бывают ситуации когда это работает.
                    +1
                    А можно выстроить процесс так, что этим будет заниматься человек у которого есть нужная экспертиза.
                    Если так, то это самое что ни на есть обычное руководство. Менеджмент. Тут нет ничего чтобы требовало специальных технических навыков (хотя в целом конечно хорошо их иметь, если это не отвлекает от главных целей), непонятно почему он тут назван «техническим руководителем юнита», почему это должен быть отдельный человек и зачем ему сколь-либо глубокий технический бэкграунд. Как итог, это попросту менеджер, а не тимлид. Название дано неверное.

                    Судя по абзацу,
                    Третий кандидат занимался управлением командой, делал технический анализ архитектуры, исправлял ошибки, разработкой занимался, играющий тренер, набирал людей в команду. Достаточно сбалансированное резюме. Выглядит так, как будто все те навыки, которые нас интересуют, у него есть.
                    Вы зачем-то совмещаете должность архитектора, техлида, менеджера. Ну что, удачи в поисках!
                      +2
                      Если так, то это самое что ни на есть обычное руководство. Менеджмент. Тут нет ничего чтобы требовало специальных технических навыков

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

                      Вы зачем-то совмещаете должность архитектора, техлида, менеджера.

                      Архитектора точно не совмещаем. А чем по вашему техлид отличается от менеджера?
                        +2
                        …Не сможет заниматься их развитием, не сможет оценивать результаты их работы, не сможет оценить технические решения которые предлагает команда…
                        В то же время комментарием ранее:
                        А можно выстроить процесс так, что этим будет заниматься человек у которого есть нужная экспертиза.
                        Опять же остаётся непонятно зачем для этого отдельный человек для всех направлений сразу (и как ещё всё это успевать), когда очевидно что специализирующиеся на чём-то одном люди сделают это лучше. Пресловутые техлиды или тимлиды технического толка, архитекторы. Отдельно для бэкенда, отдельно для фронтенда, отдельно для мобильной разработки и так далее.
                          +1
                          зачем для этого отдельный человек для всех направлений сразу (и как ещё всё это успевать), когда очевидно что специализирующиеся на чём-то одном люди сделают это лучше

                          Потому что у нас кроссфункциональные команды, которые помогают нам быстрее и лучше разрабатывать продукт. Я про это отдельно писал в статье.
                          Да у нас требования к TULам более высокие, чем к обычным функциональным тимлидам. Но такая структура имеет свои плюсы по сравнению с функциональным делением.
              0
              А теперь будут слайды…
              teamleadconf.ru/spb/2018/abstracts/3876Internal Server Error
                0
                Утром работала).
                Сейчас перевыложим на Гитхаб.
                  0
                  Обновили, спасибо.
                    +5
                    Sorry, something went wrong. Reload?

                    Короче, понятно все с вашими домашними программерами и тимлидами…
                      0

                      это где так? по ссылке от rafinirovannoe всё нормально открывается

                        +1
                        А что там?
                        Я вижу надпись 20.3 MB и котейку-лоадер
                        Предполагаю, что 20.3 MB pdf-a вызывают таймаут у браузера при коннекте меньше 1Mb/s
                          0

                          это не вина Avito, а особенность GitHub — он большие файлы не грузит в просмотр и там есть кнопка "Download" для загрузки:

                            +6
                            То есть вины Авито никакой нет, что мы тут всей толпой не можем понять как их слайды смотреть?
                            И то что все эти слайды с котятами можно было в 2-3 мегабайта засунуть без визуальной потери качества?
                            Это все вина GitHub-a, я правильно понял?
                            Вы тоже у них тимлидом работаете?
                              +2

                              0) вы — не толпа
                              1) (ответный переход на личности) простите, как вы работаете удалённо, если проблема загрузить 20Мб и незнанием взаимодействия с достаточно распространённым VCS-ресурсом?
                              2) нет, я не работаю у них тимлидом. И вообще, в настоящее время, у них не работаю.

                                0
                                0) кроме меня тут и у других людей недоумение
                                1) я вам показал ошибку — Sorry, something went wrong. Reload?
                                Она была и наверняка не только у меня. Это ошибка по определению, ее быть не должно. И мне кажется Авито должна заботиться не только обо мне с моим коннектом, но и о людях на 3G.
                                3) все равно лицо заинтересованное, как видно по комментам
                      +3
                      UPD: Презентация (4,8 МБ) на Github.
                  0

                  кхм. А разве не "Доставка" первая переписывалась на "технологии Avito" и тому подобное в 2017 году?

                    0
                    Да, над доставкой в 2017 году работали. А что не так? В статье вроде не говорится что Domofond был первопроходцем в миграции.
                      0

                      цитата:


                      Первый проект — это Domofond.

                      не надо пацанов из Доставки забывать :) Я хоть уже и не там, но помню кого первым в "жернова" перемолки отправили

                        0
                        Там в предыдущем абзаце подводка:

                        Пара примеров на основе вакансий, которые у меня были.

                        Первый проект — это Domofond.
                          +1

                          ложечка нашлась

                    +1
                    Развелось каких-то совершенно невменяемых профессий — евангелисты эппл, тимлиды, друиды андроида.
                    Софт тем временем превращается в совершенно неюзабельное гуано.
                      +1
                      ответьте себе на вопрос, что является целью компании.
                        +4
                        Конечно же создание иерархических структур управления, сильно напоминающих секты.
                        Разве может быть что-то ещё?
                      +4

                      тим лид — это когда пытаешься сократить тех лида и пм-а до 1 человека, чтобы в итоге платить меньше?

                        0
                        ПМ — это кто? Проектный Менеджер или Продуктовый Менеджер?
                          +2
                          Согласен с Gemorroj, немного можно смягчить формулировку, но суть останется та же.
                          Хотя могу и на вашу сторона встать и придумать десятки ситуаций почему «так» более эффективно и оправдано.
                          Отвечая на ваш вопрос: ПМ или ПМ, то ответ может быть неожиданным для вас, но «Вам виднее». Я сталкивался и Project Manager и с Product Manager разница небольшая. Все зависит от организации и продукта. Чисто теоретически разница между ними только в том что ПрожектМ имеет более конкретные цели и более жесткий дедлайн и по окончании проекта вроде как можно умывать руки. А ПродактМ в свою очередь типа ведет продукт бусконечно долго из года в год и из спринта в спринт. А в остальном из квалификация одинаковая и отбирать кандидатов надо примерно по одним и тем же критериям. Это мое мнение. Буду рад услышать каково ваше.
                          Возвращаясь к первоначальному замечанию, мне тоже кажется что происходит постоянная и порой не очень понятная трансформация терминов и ролей. Тот круг обязанностей что вы описываете я бы тоже скорее отнес к роли Прожект Менеджера нежели к техлиду. Но так было и раньше когда стали появляться первые DevOps раньше были админы, кодеры, техлиды, синьоры а теперь есть новый класс ДевОпсов и они уже делятся и почкуются внутри нового класса специалистов и порой действительно трудно сказать как отличить одно от другого.
                            +1
                            Я спрашивал, потому что Продукт Менеджер у нас как раз есть и это отдельный человек и роль. В статье есть картинка со структурой команды. Эта позиция у нас называется Unit Leader и он как раз отвечает за продуктовую составляющую, сбор болей и потребностей пользователей, за наполнение бэклога нужными инициативами чтобы бизнес достигал своих целей, за постановку квартальных и годовых целей и т.п. А задача Technical Unit Leader чтобы команда разработки качественно и в срок доставляла задачи из бэклога до пользователей.
                            А Проектные Менеджеры обычно бывают в компаниях где разработчики поделены на функции (бэк, фронт, qa и т.п.) и для разработки какой-то фичи нужно собрать из них команду и управлять разработкой проекта. Обычная матричная структура вобщем. Но в таких компаниях другие процессы и конечно будут другие требования к тимлидам.
                        +2
                        А мне интересно, насколько реалистичны (и, соответственно, нужны в природе) «планы на ближайшие 100 дней»? Есть хоть один человек, который с уверенностью скажет, что сколь угодно подробное планирование «на N дней» вместо «роадмапа» на «квартал» там, «год» не было пустой тратой времени?
                          0
                          «планы на ближайшие 100 дней» — тут да, была не очень удачная формулировка. Мы просили сделать «роадмап» на квартал + хотели услышать что человек планировал лично, как менеджер, делать в первые месяцы работы.
                          +7
                          Тестовое задание на 2 недели с диаграммами ганта, человечками, ФОТ, план на 100 дней для проекта на 6 месяцев (100 дней, не 3 месяца, чувствуете разницу?), расчет бюджета на переход.

                          Вы хотите ПМа не тимлида.
                          Если человек вам бюджет проекта сможет расчитать не ожидайте от него каких либо подвигов в коде. Это диаметрально противоположные области интересов.
                            +2
                            «2 недели» это столько нам обычно называли сами кандидаты в среднем. Мы не ставили жестких сроков, хоть два месяца готовься, хоть 1 день.

                            Про расчет бюджета в поставленных задачах ничего нет :) Только в описании текущей ситуации, чтобы у кандидатов было понимание про то на какую команду можно расчитывать.

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

                            Вы хотите ПМа не тимлида.

                            Нет, я не хочу ПМа :) Мне был нужен технический руководитель. Хороший технический руководитель не junior уровня, должен учитывать в своих планах расходы на сервера, людей и ПО. Не обязательно в деньгах, но в штуках точно.

                            Если человек вам бюджет проекта сможет расчитать не ожидайте от него каких либо подвигов в коде.

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

                              Возможно он имел ввиду планирование фиче беклога, как в скраме и разбиение фич на задачи для спринт бэклога, там вполне себе можно на пол года вперёд расписать количество спринтов, но потом корректировать по завершению каждого спринта. Это как раз задача тим Лида, ПМ не сможет разбить фичи на задачи по 4-8 часов, надо и архитектуру понимать и что от чего зависит и как правильно распаллелить.

                              0
                              Фантастические тимлиды и где они обитают

                              Какая толстая отсылка к почти одноимённому фильму. Вы что-то имеете против тимлидов?
                              Для тех кто вдруг не в курсе о чём я
                              Название почти одноимённого фильма: «Фантастические ТВАРИ и где они обитают»
                                0
                                Отсылка есть, второго смысла никакого нет. Если вы тимлид и вас это оскорбило, прошу прощения.
                                  +1

                                  Они же там, в кино, удивительно классные и очень редкие…

                                  +4
                                  Спасибо за интересную статью!
                                  Про фантастических тимлидов тема раскрыта, про «где обитают» не совсем.

                                  Не могли бы вы осветить (в тех пределах, что позволяет коммерческая тайна), как у вас получилось найти столько кандидатов, чтобы их можно было отсеивать по критериям «не написал в резюме про то, как управлял коммандой»?
                                  И как вам удалось замотивировать кандидатов 2 недели делать тестовое задание?
                                  Сколько времени занял найм?

                                  Я работаю в Минске. Тут рынок труда, конечно, поменьше, чем в Москве. Но, предполагаю, что ситуация в общем схожая. С такими критериями позиции закрывались бы настолько долго, что могли стать не актуальными. Даже на интересном проекте с высокими зп и вкусными печеньками.
                                    +1
                                    как у вас получилось найти столько кандидатов, чтобы их можно было отсеивать по критериям «не написал в резюме про то, как управлял коммандой»?

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

                                    И как вам удалось замотивировать кандидатов 2 недели делать тестовое задание?

                                    2 недели это «грязное» время. Реально люди же работают, занимаются своими делами, поэтому времени на подготовку уходит не так много. Кандидатов мы никак особо не мотивировали, все с пониманием относились к тестовому заданию. Мне кажется потому что все понимают, что позиция менеджерская, и цена ошибки при найме достаточно высока, поэтому с понимаем относятся.

                                    Сколько времени занял найм?

                                    Сейчас точно не скажу, но где-то 3-4 месяца на каждую позицию.
                                      +1

                                      Почему вы не создаете удаленные команды? Возможно было бы проще найти сотрудников.

                                        0
                                        Почему вы не создаете удаленные команды? Возможно было бы проще найти сотрудников.

                                        Для новых офисов в других городах мы еще не достаточно большие, нам проще помогать кандидатам с релокацией в Москву.
                                        А для полностью распределенных команд мы пока морально не готовы. С ними нужно работать по другому, а у нас все процессы заточены сейчас на то что со всеми нужными людьми ты либо сидишь рядом, либо можешь пообщаться лично.
                                        Ну и 3-4 месяца для поиска руководителя это не так много, мне кажется. Я сомневаюсь что в распределенную команду мы бы нашли человека быстрее.
                                    +1
                                    Трудно найти тимлидера хорошего, так как в разработке все часто меняется, постоянно появляются новые технологии и пока человек доучиться до тимлидера появятся новые технологии, на которых опять человек зависает и не дослуживается выше.
                                    Во-вторых многие раньше уходят из разработки, чем дорастают до руководился, либо меняют технологии внутри профессии чтобы поддержать разнообразие. Это слишком скучная, асоциальная и не подходящая и не благородная профессия чтобы её рассматривать на всю жизнь.
                                      +1
                                      То что вы описываете больше похоже на путь разработчика, чем руководителя. Принципы управления программистами меняются не так быстро и сейчас все еще актуальны книжки написанные в 70-е годы. Например тот же Брукс и его Мифический человеко-месяц.
                                      Ну и тимлид это не обязательно лучший разработчик в команде. Если есть желание быть тимлидом, то не надо в него расти качая знания в новых технологиях. Там нужны совсем другие навыки.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое