Шесть рецептов для начинающего тимлида: как всё успевать и развивать команду

Страх №1. Ты не востребован на рынке

Буду получать меньше, чем сейчас

• 144–294 тыс. рублей, если являетесь профессионалом, который, возможно, менторит пару человек, но едва ли исполняет весь набор функций тимлида.
• 175–357 тыс. рублей, если вы тимлид небольшой команды.
• 225–491 тыс. рублей, если вы тимлид большой команды в 10-30 человек или менеджер менеджеров.

Как победить страх, что ты не востребован на рынке

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

Ходить по собеседованиям не обязательно значит хотеть сменить работу. Это не страшно, за это не наказывают.
Teamlead Roadmap

Стоит ли становиться ведущим программистом

Учитывая высокие требования, задумаешься – а стоит ли стремится стать тимлидом.

Давайте посмотрим, какие есть плюсы в этой должности:
востребованность на рынке (даже если вы решите покинуть насиженное место, найти новую работу будет несложно);
возможность получения ценных связей (в результате общения с заказчиками из самых разных сфер – и этот пункт перекликается с предыдущим);
карьерный рост, в перспективе даже возможность получения доли в компании;
универсальность (специалист учится контактировать с разработчиками и заказчиками, получает административные навыки – все это очень пригодится для развития карьеры);
саморазвитие (необходимо постоянно получать новые знания, а это повышает уровень квалификации);
высокая зарплата.

А какие же тогда минусы:
ненормированный график работы (в большинстве случаев);
постоянные авралы и стрессы;
большая ответственность за свою работу и результат деятельности команды;
иногда необходимо работать без выходных;
придется регулярно переключаться между задачами.

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

Построение масштабируемой схемы. Отход от роли «кольца всевластия»

Одна из самых частых негативных историй, которые я слышу от разработчиков про lead’ов — все интересные куски лид забирает себе. От лидов же получаю другой фидбэк, что самая частая проблема — есть задача и её ВООБЩЕ НИКАК!!!111 нельзя делегировать.Отсюда вытекает ряд проблем.

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

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

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

Профессиональный рост в IT

Рассмотрим типичную IT-компанию. Как и в других отраслях, здесь возможен рост «по горизонтали» и «по вертикали».

Горизонтальный рост — это освоение более широкого стека, близких направлений (например, мобильной разработки) или уход в смежную профессию (в управление проектами, продажи, аналитику).

Вертикальный — это переход на лидерские позиции (техлида, тимлида) или руководящие должности. О нём мы сегодня и поговорим.

Это — обычная схема профессионального роста:

1. junior developer (специалист начального уровня);
2. middle developer (специалист среднего уровня);
3. senior developer (специалист высокого уровня);
4. technical leader (технический лидер);
5. team leader (лидер команды).

Иногда выделяют дополнительные промежуточные ступени, например junior+ (это джун, который совсем чуть-чуть не дотягивает до миддла).

Стать тимлидом можно и раньше — со ступени middle-разработчика.

Senior developer может выбирать направление на свой вкус: стать техлидом, который управляет ходом работ, но больше погружён в архитектуру и качество кода, или же тимлидом, который тоже управляет командой, но более ориентирован на коммуникации. Эти роли одинаково авторитетны. В редких компаниях тимлид может руководить техлидом, но обычно они работают параллельно и на равных.

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

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

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

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

Есть некоторые обобщенные требования к кандидатам на должность. Но стоит сразу отметить, что конкретные зависят именно от особенностей самой компании. Средние следующие:

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

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

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

Знания и навыки

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

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

Что касается знаний и навыков, то для работы тимлидом соискатель должен:

• иметь практический опыт работы в сфере IT;
• обладать аналитическим складом ума;
• знать все технические тонкости веб-разработки;
• понимать процессы бюджетирования (оценка и планирование затрат);
• иметь навыки программиста на высоком уровне;
• знать языки программирования;
• уметь грамотно ставить задачу для сотрудников;
• обладать навыками делопроизводства;
• уметь воплощать желания заказчика в техническое задание для команды;
• оценивать работу сотрудников (мотивация, KPI);
• принимать ответственные решения в сложных и спорных ситуациях.

Повторюсь еще раз – тимлид это и программист, и психолог, и менеджер в одном лице.

Подбор: скоринг

• Бизнес-ориентированность — насколько человек прагматичен, когда целью является результат для бизнеса, а не, скажем, уровень удовлетворённости красотой и изящностью кода. Тимлид должен в первую очередь руководствоваться принципами управления, а не личного комфорта. Простой пример: если бизнесу нужно провалидировать в рамках A/B-теста какую-то концепцию, вероятно, нет смысла делать покрытие кода тестовой группы юнит-тестами, даже если принято покрывать тестами всё, и разработчику нравится писать тесты.
• Коммуникации. В культуре Badoo на коммуникациях построено очень многое, и умение эффективно общаться со всеми — серверниками, тестировщиками, топами, дизайнерами — просто необходимо.
• Уровень мотивации. На мой взгляд, тимлид должен обладать сильной внутренней мотивацией, ведь превращение из разработчика в тимлида — это не переход со ступеньки на ступеньку карьерной лестницы, а перепрыгивание на другую лестницу, стоящую особняком, — лестницу управления. Без сильной мотивации любое развитие — а развитие всегда есть выход из зоны комфорта — будет очень тяжёлым.
• История удачных/неудачных проектов. Сюда же относятся причины провалов проектов (чтобы потом проверять следующие проекты на наличие тех же паттернов провалов).
• Уровень неформального лидерства. Руководитель должен уметь вести за собой сотрудников, мотивировать их на достижение целей. Кроме того, неформального лидера команда легче примет в качестве тимлида.

Шаг номер 0. Зачем?

Итак, вам предложили стать тимлидом или вы сами захотели им стать. Что надо сделать в первую очередь? Хорошенько подумать, а надо ли оно вам.

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

Я общался с многими состоявшимися специалистами в этой профессии и все они говорят примерно одно и то же: 

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

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

Ложные цели, на которые не надо вестись:

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

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

• Повышение уровня ЧСВ. Ничего особо крутого в этой должности нет. Это просто очередная должность чуть выше рядовой. Как ефрейтор или сержант в армии. Вроде лычка есть, но хвалиться особо нечем, и вокруг куча таких же.

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

Где-то нужен полуменеджер-полуразработчик, где-то техлид/архитектор, где-то пипл менеджер и т.д

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

Советую заранее узнать, что же именно от вас требуется. 

Спойлер: 80-90% вакансий на российском рынке — полуменеджер-полуразработчик. Формально говорится, что 60-70% времени надо писать код, а 30-40% менеджерить. При небольших размерах команды и порядочном работодателе это может неплохо работать. Лично у меня где-то сейчас 40 на 60 получается делить код с менеджементом. Хотя я чувствую, как при разрастании команды код отодвигается от меня всё дальше и дальше. 

Однако при недобросовестном или просто непонимающем работодателе, от вас будут ожидать примерно 100% менеджмента и 100% написания кода. Постарайтесь узнать об этом как можно раньше, чтобы СБЕЖАТЬ.

Какие знания и навыки у него должны быть

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

• трудолюбие, целеустремленность;
• адаптивность, гибкость;
• инициативность, креативность;
• самостоятельность, ответственность, пунктуальность;
• коммуникабельность;
• стрессоустойчивость, терпеливость, дипломатичность.

Teamlead должен иметь минимум 5 лет опыта в IT области. Что потребуется ему для успешной работы:

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

И это список только наиболее важных требований. Работа требует навыков работы с Linux based дистрибутивами, знания Agile, PHP, Scrum, MySQL, JavaScript. Могут еще встречаться условия, имеющие отношение к конкретной сфере работы заказчика.

Какие требования чаще всего звучат в описании вакансии тимлида:

• высшее техническое образование (это точно будет преимуществом, но не всегда является обязательным требованием);
• достаточное количество знаний и навыков в своем стэке (их мы перечислили выше);
• умение проводить код-ревью и менторинг;
• опыт работы от 5 лет;
• управленческие навыки.

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

Шаг номер 2. Общий план первоначальных действий

От теории переносимся к практике.

Первым делом необходимо разобраться: кто руководитель, кто заказчики, кто кому подчиняется, а кто нет. Желательно всё записать, а еще лучше составить визуальную схему а-ля mindmap, глядя на которую будет видна общая картина всех отделов и действующих лиц.

Далее, когда вы поняли официальную часть, надо погрузиться в неофициальную.

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

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

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

Какие назначить первые встречи, чтобы во всё это погрузиться?

Первым делом встретьтесь 1 на 1 с руководителем и, используя роадмап тимлида https://tlroadmap.io/, обговорите конкретные ожидания от вашей позиции. Главное помнить, что в роадмапе указано не «всё, что должен знать и делать тимлид», а «всё, что могут требовать от тимлида в разных компаниях», т.е. это объединение подмножеств хотелок из разных компаний. Так что, когда вам начальник скажет: «Ну, вроде выглядит норм, давай-ка всем занимайся,» — вашей задачей будет ему объяснить, что всем заниматься невозможно физически и нужно проанализировать конкретную ситуацию, проект, команду, выделить наиболее важные области, которые вы и возьмете на себя.

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

• взглянуть на текущую ситуацию с разных сторон;

• узнать какую-то историю, которая творилась еще до вас;

• проанализировать самих людей;

• понять ожидания этих людей от вас.

Описание должности

Кто такой тимлид и чем он занимается? Само название имеет английское происхождение (team leader – «лидер команды»). Этот человек – координатор команды разработчиков. Он определяет сферы ответственности своим подчиненным и контролирует их работу, организовывает обучение и обеспечивает возможности профессионального роста для специалистов, а также ведет переговоры с заказчиком.

Тимлид – не профессия, а должность. Лидером команды, как правило, становится программист-разработчик. Соответственно, программист – это профессия, а тимлидер – занимаемая им должность.

Кроме непосредственно профессиональных, на тимлида возложены функции менеджера:

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

Ключевой момент в работе тимлида – мощная мотивация команды и умение вдохновлять ее на успех. Разумеется делать это нужно личным примером.

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

Технические задачи тимлида:

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

Team leader может устроиться на работу в крупную брокерскую или финансовую компанию, бизнес-корпорацию, банк либо в IT-фирму. Интересно, что официальная должность тимлида есть не во всех айти-компаниях. И все же в любой команде должен быть главный. Занять этот пост обычно предлагают самому опытному разработчику или руководителю отдела, в небольшом стартапе – техническому директору или начальнику SEO-отдела. В крупной компании разработчики могут сформировать сразу несколько команд, каждая из которых получит своего формального тимлидера. В таком случае для руководства лидерами команд учреждается дополнительная должность – тимлид тимлидов.

Хорошие и плохие стили

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

Из графика видно, что самый правильный стиль — авторитетный. Однако не спешите делать выводы. На самом деле не всё так однозначно. Во-первых, многие успешные менеджеры были авторитарны. К примеру, 2002 стал очень удачным годом для The New York Times: газета выиграла в в 7 из 13 номинаций Пулитцеровской премии. В том году компанией руководил человек, отличающийся авторитарным стилем – Хауэлл Рейнс. Однако он был смещен со своего поста уже в 2003 году. 

Более близким нам всем примером авторитарного менеджера является Стив Джобс. Хотя на самом деле исследователи не могут четко классифицировать его стиль (и это целый материал для отдельной статьи, доказывающей, что Джобс — хороший менеджер), он ближе всего к авторитарному. Авторитарный стиль — статистически плохой, а значит и Джобс — статистически плохой руководитель. Однако только он смог вывести Apple из кризиса в конце 90-х и обеспечить попадание в топ-3 самых дорогих компаний в мире в 2011 году.

Я могу привести ещё целый список противоречивых авторитарных менеджеров, и все они добивались больших результатов: Марта Стюарт, Винс Ломбарди, Леонард Шеффер, вероятно, к ним можно причислить и Стива Балмера (не слушайте, что человек говорит — следите за его поступками).

Очень легко ошибиться в оценочной интерпретации стилей, глядя на график выше. Тот же авторитарный стиль: по графику он хуже всего влияет на климат внутри команды. Значит ли это, что он худший и его стоит избегать? И да, и нет. Всё зависит от ситуации. У каждого стиля есть свои особенности: сильные и слабые стороны. Есть ситуации, к которым лучше подходит товарищеский стиль, к другим – авторитарный. И даже с точки зрения климата в команде и отношений с руководством, большинство людей ценят свободу, но есть и те, кто хотел бы находиться под руководством сильного лидера, отдающего чёткие, понятные инструкции. 

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

Шаг номер 1. Знание — сила!

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

Про тимлидство существуют сотни статей, видео, книг, курсов и т.д. Фильтровать нужно тщательно.

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

• М. Уоткинс «Первые 90 дней». Хорошая и вдумчивая книга о том, как успешно адаптироваться к переходу на новую должность. Чем заняться в первые 90 дней. И о том, что эта адаптация, как системный процесс, нужна не просто конкретному индивиду, а всей компании в целом.

• Дж. Ханк Рейнвотер «Как пасти котов». Книга для начинающих или будущих управленцев вполне хороша и толкова (пусть и немного стара). Однако для людей с опытом, наверное, будет немного кэпской.

• Ф. Брукс «Мифический человеко-месяц». Расскажет об управлении проектами: как надо, как не надо, и почему 9 женщин за 1 месяц не смогут родить ребенка. Есть мнение, что книга несколько устарела, тем не менее, если вы в этом не очень разбираетесь, то она обогатит вас полезными идеями.

• Э. Голдратт. «Цель. Процесс непрерывного совершенствования». Классический художественный роман, объясняющий на разных примерах теорию ограничения систем. Чтиво интересное и полезное. 

• Д. Ким, К. Бер, Д. Спаффорд. «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему». Очень интересная и поучительная книга, которая в художественном формате рассказывает о том, как в ИТ подразделении улучшают процессы работы, приходят к DevOps идеологии и спасают бизнес.

• Т. ДеМарко «Deadline. Роман об управлении проектами». Еще одна книга в художественном формате. Легкое и интересное чтение об управлении ИТ проектами.

• Т. ДеМарко, Т. Листер «Вальсируя с Медведями». Порекомендовал бы эту книгу для средних и крупных проектов. Излечивает от наивности, открывает глаза на происходящее. Показывает, что случиться может много чего и рассказывает, как с этим жить и работать.

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

• М. Ильяхов, Л. Сарычева «Новые правила деловой переписки». Замечательная книга. Смело её рекомендовал бы и разработчикам, и менеджерам, и вообще примерно всем. О том как в переписке быть толковым, уважительным, приятным и эффективным. Очень многим этого не хватает.

• А. Орлов «Джедайские техники конструктивного общения». Коротко, по делу, с примерами. Однозначно рекомендую. И в работе пригодится, и в быту.

• М. Гоулстон «Как разговаривать с мудаками». Книга придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже:)

• Роадмап тимлида https://tlroadmap.io/ Очень полезный инструмент, который поможет разобраться, какие бывают требования к тимлидам, понять, что с ними делать и как подтягивать свои знания. Также подойдет как хороший инструмент для того, чтобы обговорить со своим руководителем на начальном этапе работы, что же конкретно от вас ожидается.

• Курсерный курс https://www.coursera.org/specializations/product-management Долгий и основательный курс, который покрывает всё про управление проектами. Выявление требований, план рисков, декомпозиция и распределение задач, аджайл техники и прочее. Вы справедливо можете заметить, что этот курс нужен менеджерам проектов, а не тимлидам. Теоритечески — да, а на практике возможно, что если у вас менеджер проекта и есть, то в каких-то деталях он может не очень разбираться. Тогда понадобится ваше участие.

• Регулярные двухнедельные тимлидские конференции от ребят из подкаста Podlodka https://podlodka.io/tlcrew Там много хороших докладов и душевное отзывчивое комьюнити, с которым можно порой пообсуждать в деталях то, за что обычно деньги берут на платных индивидуальных консультациях.

Хобби

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

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

Есть какие-нибудь pet-проекты по разработке?

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

На этом закончилось наше интервью с руководителем направления разработки в Lamoda Александром Афеновым.

Варианты будущего роста

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