Чем отличается сто от тимлида

«Тимлид делает так, чтобы команде было комфортно работать вместе, а творческое начало не угасло»

Мы продолжаем цикл публикаций про ИТ-профессии. В этот раз мы поговорили с Ксенией, тимлидом в отделе технической экспертизы IBS. Она рассказала о том, каково быть Team leader’ом на проекте и какими качествами нужно обладать, чтобы эффективно управлять группой разработчиков.

9.8K открытий

Team leader (тимлид) — это IT-специалист, который управляет командой разработчиков, владеет технической стороной, принимает участие в работе над архитектурой проекта, занимается ревью (проверкой) кода, а также разработкой некоторых особо сложных заданий на проекте.

Чем занимается Team Leader

— Какова роль тимлида на проекте?

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

Главная цель: сделать так, чтобы всей команде было комфортно работать вместе, а творческое начало не угасло.

— Чем этот функционал отличается от руководителя группы?

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

— Тебе бы хотелось объединить эти две роли? Или тебе комфортно именно в том функционале, который у тебя есть?

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

— Сколько у тебя человек выходит?

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

— Можешь назвать три качества, которыми должен обладать хороший team leader?

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

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

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

— Какие решения тебе обычно приходится принимать?

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

— А самое приятное решение?

— Самое приятное решение — это когда мы всё успели и можно немного пораньше кого-то отпустить.

IBS. Рабочий день

— Что тебе нравится в работе больше всего?

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

— Чем сейчас занимаешься в IBS?

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

— Ты в IBS пришла сразу на должность тимлида или уже выросла внутри компании?

— В IBS я пришла в 2013 году с должности тимлида на позицию разработчика. То есть я на предыдущем месте работала с группой. Но она была достаточно маленькая, около 5 человек. И тимлидом группы я здесь стала, наверное, только в конце 2018-го. Мы принимали проекты, которые готовятся к внедрению, и один из модулей, самый крупный, достался мне.

— Как ты вообще пришла в IT?

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

— Из чего состоит твой обычный рабочий день?

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

— После того как ты стала тимлидом, ощутила нехватку свободного времени?

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

Собеседования

— Ты довольно активно ведешь себя на собеседованиях. Что ты чувствуешь, когда приходится оценивать других?

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

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

— Может быть, у тебя есть какие-то истории об этом?

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

— У тебя есть нелюбимые вопросы на собеседовании?

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

— Технологические. В основном я сейчас веду собеседования, которые относятся к Java. Я спрашиваю по Java Core, по Spring, по Hibernate. И по ключевым знаниям, которые нам нужны для конкретных вакансий.

— А можешь вспомнить самое необычное собеседование?

— Необычное собеседование было со специалистом с хорошим бэкграундом и резюме: работа с математическими методами, работа на кафедре одного из очень успешных ВУЗов. И все собеседование он не давал поговорить собеседующим. Рассказывал о себе, о матметодах и о кафедре, о студентах. Мы не успели за час ему задать ключевые вопросы. В итоге его не взяли, но он в конце сказал, что мы ему понравились и он готов у нас работать

Как стать Team Leader’om. Образование

— Что ты читаешь, чтобы быть в курсе последних трендов?

— Блоги, Habr, смотрю разные семинары.

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

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

И это важные нюансы, которые при незнании сказываются на производительности кода, на каких-то малозаметных деталях. Поэтому это полезно.

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

— Ты упомянула, что твое образование смежное с IT-сферой. Можешь рассказать подробнее?

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

Когда я сама ходила по собеседованиям, у меня всегда спрашивали: «Почему у вас гуманитарное образование, а вы пришли к нам на должность программиста?». На самом деле мое образование, условно говоря, на 50% гуманитарное и на 50% техническое. Оно связано с автоматическим переводом, с гуманитарными науками в области IT.

— А что ты можешь порекомендовать тем, кто хочет стать тимлидером?

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

Team Lead vs Tech Lead. В чем разница и зачем разделять эти роли

Привет, я Олег Абрамов, VP of Engineering в продуктовой компании iDeals Solutions. Хотел бы поделиться опытом и своими взглядами на особенности управления процессами в IT-компаниях. А именно рассказать подробнее о том, чем отличаются роли Team Lead и Tech Lead и какие функции и задачи могут быть с ними связаны. Прежде всего это будет интересно тем, кто работает в растущих командах или задумывается о карьерном росте на позиции разработчика. А также тем, кого волнуют вопросы эффективного управления в продуктовых компаниях.

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

Иллюстрация Алины Самолюк

Кем управляем

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

В условно «плохой» команде чаще наблюдается линейный рост: общая работа не отличается от суммы индивидуальных результатов. Может быть и хуже — когда люди вообще начинают мешать друг другу. Или же при обсуждении задач члены команды не дополняют и не критикуют (в здравом смысле) решения друг друга. Например, при сложностях у фронтенд-инженера его бэкенд-коллеги уходят в режим «это не мое дело, это „его“ задача, у меня другие проблемы и другие дела».

В такой команде синергия идей никогда не возникнет. Но практика показывает: коллективный разум и анализ часто превосходит индивидуальный, а мастера-одиночки — скорее исключение, чем правило.

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

Например, как-то у нас возник вопрос по поводу скачивания «тяжелых» файлов в разрабатываемом дополнении к нашей системе. Более опытные коллеги предложили два варианта решения инженеру, перед которым стояла эта задача. Он решил исследовать проблему с нуля и увидел недостатки в обоих решениях. Инвестировав дополнительное время, он нашел третий, оптимальный подход. Коллеги его поддержали. В итоге в релизе решение дало существенное ускорение и улучшило пользовательский опыт. Таким образом, порой out of box thinking дает продуктивные результаты — как с точки зрения бизнеса, так и с точки зрения технологий.

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

Какие вызовы появляются с масштабированием

Когда в команде три человека — условно [Tech/Team] Lead и пара Middle — скорее всего, сложностей с управлением не возникнет. Здесь лид «и швец, и жнец, и на дуде игрец». На нем и собственноручная разработка решений, и ревью кода других, и управление командой.

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

Давайте посмотрим на реальный кейс. Команда Lead’a Алекса занялась сложным проектом, руководство регулярно спрашивает о сроках. Сам он раньше никогда не планировал на среднесрочную перспективу — например, на месяц-два. В итоге Алекс вместо кодинга погружается в оценку и планирование, вместо анализа локальных технических изменений — в учет рисков. Как результат, все меньше кода пишет сам.

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

Логичный следующий этап — найти в команду инженера с лидерскими качествами, который бы «остался в технологиях». Такой специалист помог бы развивать и поддерживать техническое качество решений команды — Tech Lead. Сам же Алекс, если хорошо справляется с управлением людьми и проектами, становится Team Lead.

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

Кто такой Tech Lead

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

В разных компаниях нагрузка и функции могут отличаться. Условно занятость Tech Lead можно описать так:

• времени он проводит за написанием кода.
• архитектура, прототипы будущих решений, глубинная проработка технических рисков и проекция их на время (совместно с Team Lead).
• Оставшееся время — code review, менторинг и skill-sharing внутри команды.

Второй и третий блоки, собственно, составляют сущность роли техлида, где она начинает сильно отличаться от Senior. Давайте разберем их подробнее. Основная задача техлида — обеспечивать качественную техническую проработку и реализацию продукта. Что именно стоит считать «техническим лидерством»?

• Создание общей технологической канвы команды: архитектура, системный дизайн, технологические best-practices.
• Работа с техническими рисками и проблемами в процессе разработки: поиск, решение, минимизация трудозатрат.
• Профессиональная прокачка команды: от консультирования и менторства до тематических дискуссий среди коллег по техническим вопросам, качественного code review.

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

Кто такой Team Lead

Эта позиция имеет смысл уже в разросшейся команде — от 5 человек. Здесь управление связано с непрерывной коммуникацией как с разработчиками, так и с коллегами из других команд, с менеджментом ожиданий, ресурсов и изменений. С ростом коллектива транзакционные издержки растут, поэтому взваливать эти функции на техлида или старшего разработчика будет непродуктивно. И в здоровых командах, где следят за эффективностью, появляется Team Lead.

Если сравнить команду разработчиков с кораблем (не «Титаником»), то техлида можно назвать главным механиком, который обеспечивает надежную работу всего судна. Тимлид же в этом случае — капитан: он прокладывает курс и следит за слаженной работой команды и механизмов.

Что может входить в его задачи в продуктовой компании?

• Погружение в бизнес-аспект: ты не можешь поставить задачу, если сам ее не понимаешь.
• Кросс-командная и кросс-функциональная коммуникация: постоянное выравнивание направлений работы и избавление от неопределенности.
• Создание процессов и повышение слаженности работы команды: неструктурированность — главный враг растущих организаций.
• People management — оценка, планирование, распределение задач, проведение one-to-one встреч, решение возникающих конфликтов, мотивация коллег, решение рутинных вопросов с отпусками, отгулами и овертаймами.
• Обратная связь и развитие команды: каждый человек хочет развиваться, даже самый сеньорный сеньор. Именно Team Lead должен поддерживать и давать реализовывать эти стремления.
• Найм, on- и offboarding: Team Lead должен искать и «растить» топовых teammates, помогать им быть эффективными и не бояться расставаться с теми, кто не подходит.

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

Как мы управляем разработкой в iDeals

В iDeals мы уже прошли этап горизонтальной структуры, когда каждая функция (BE, FE, QA) имела своего Team Lead, и пришли к вертикальным кросс-функциональным командам. Эта тема требует отдельной статьи, поэтому здесь опишу ситуацию вкратце.

Итак, сейчас в каждой команде у нас Back-end Engineers, Front-end Engineers, Engineers. В среднем — Как правило, команда состоит из Senior/Middle+ специалистов, которые достаточно автономны решений принимается самостоятельно).

Глава этой команды — Engineering Manager. Это человек с опытом в разработке (как правило — Back-end/Full Stack в прошлом), хорошо понимает контекст построения решений end-to-end, но предпочитает вертикальный рост в компании, а не горизонтальный. Фактически он имеющий инженерный бэкграунд Team Lead. Но от этого термина мы решили избавиться, потому что на рынке он имеет разные значения и зачастую создает неправильные ожидания.

Engineering Manager опирается на Seniors/Tech Leads, отвечает за итоговые показатели, процессы разработки и объединение контекстов всех трех функций (FE, BE, QA) в команде для принятия оптимальных решений. Кроме того, people management задачи: у него есть все рычаги для обеспечения лучших результатов работы команды и необходимый уровень автономности.

Такой подход позволяет нашим Engineering Managers и оставаться в поле технологий, и прокачивать управленческие скиллы, чтобы на всех уровнях улучшать процесс создания решений своей командой.

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

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

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

А как, с вашей точки зрения, должны выглядеть задачи техлида и тимлида? Поделитесь в комментариях!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Кто такой тимлид и как вырасти до этой должности

Слово «тимлид» произошло от английского team leader или team lead — лидер команды. Этот специалист координирует деятельность команды разработчиков, распределяет сферы ответственности, взаимодействует с заказчиком, планирует и организует обучение специалистов.

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

Связь с заказчиком и организация разработки в интересах бизнеса

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

Тимлид — одновременно опытный программист и хороший менеджер.

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

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

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

HR-процессы: наём, адаптация и обучение сотрудников

Тимлиды участвуют в HR-процессах: найме, адаптации и обучении сотрудников. Лидер планирует кадровые потребности команды вместе с HR-специалистами и руководителями. Тимлиды проводят собеседования и участвуют в них.

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

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

Обучение сотрудников — ещё одна сфера ответственности лидера команды. Тимлид планирует развитие новичков и опытных специалистов, следит за их прогрессом. Лидер обеспечивает профессиональное соответствие команды в целом и её отдельных членов потребностям бизнеса.

Обратите внимание, сфера ответственности тимлида не ограничивается хард-скилами. Хороший лидер уделяет внимание развитию мягких навыков членов команды.

Читайте также Интервью тимлида Evrone Дмитрия Матвеева. Дмитрий рассказывает о своём рабочем распорядке, сферах ответственности, требованиях к джуниору и других интересных вещах.

Разработка: координация команды и помощь сотрудникам

Тимлидер не фокусируется исключительно на управленческой деятельности. Он остаётся практикующим разработчиком, который знает код проекта, участвует в работе над ним. Как отмечалось выше, team lead обеспечивает соответствие продукта целям заказчика. Для этого он координирует деятельность команды, участвует в разработке, в том числе пишет код, если хочет и успевает.

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

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

Промежуточный итог: team lead работает на стыке разработки и менеджмента. Он обеспечивает взаимодействие команды с заказчиком, участвует в HR-процессах. Лидер команды координирует работу программистов, помогает им решать задачи. Он сам участвует в разработке.

Где работают и сколько зарабатывают тимлиды

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

В больших компаниях разработчики объединяются в несколько команд. В каждой команде может быть формальная должность тимлидера. В компаниях с большим количеством команд может работать формальный или неформальный тимлид тимлидов. Этот человек руководит лидерами команд.

По состоянию на конец февраля 2020 года на hh.ru тимлидов ищут как крупные и известные компании, так и небольшие региональные организации. Вот несколько компаний, которые публиковали объявления о поиске лидеров команд:

• Mindbox.
• Эквид.
• BeeJee.
• Carbon Soft.
• BestDoctor.

В конце февраля работодатели предлагают тимлидам от 160 000 до 340 000 рублей в месяц. На hh.ru в большей части вакансий для лидеров команд зарплата не указана.

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

Какие требования предъявляют работодатели к кандидатам на позицию тимлида

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

Вот обобщённые требования к кандидатам на позиции тимлида. Они составлены по итогам анализа опубликованных на hh.ru вакансий:

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

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

• умение принимать решения;
• умение обучать;
• аналитические способности;
• способность мотивировать сотрудников;
• критическое мышление.

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

Составьте свое первое резюме: Вы можете бесплатно опубликовать свое резюме в нашем сервисе «Хекслет-CV» и получить советы по его улучшению от разработчиков и HR-менеджеров

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

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

Александр Шакун: начинающему в целом стоит стремиться быть «самым глупым в комнате»

О собеседнике: Александр Шакун , team Lead в osome.com , двигаю кнопки в стартапах с 2016 года.

Дмитрий Дементий: Какую роль в профессиональной жизни начинающего разработчика играет тимлид? Или перефразирую: почему стажёру или джуниору надо плотно общаться и дружить в профессиональном плане с тимлидом?

Александр Шакун: Не уверен, что могу тут поделиться каким-то уникальным опытом, я никогда не был тимлидом в командах с начинающими разработчиками. Думаю что начинающему в целом стоит стремиться быть «самым глупым в комнате» и общаться со всеми, кто рядом, набираться опыта.

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

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

Конечно для тимлида к этому добавляется некоторое количество административных обязанностей, таких как наём и мотивация, эти вещи остаются на мне.

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

А. Ш.: Понятия не имею, никогда к этому не стремился. Пришёл на новую работу, начал делать задачки. Формировалась команда под новый продукт, меня определили в неё. Надо было работать много, быстро и качественно. У меня получалось.

Моё поведение, моё представление о работе не меняется в зависимости от того, тимлид я или нет. Стараюсь делать задачи быстро, не жертвуя при этом качеством. Стараюсь интересоваться продуктом: что, зачем и для кого мы делаем. Готов работать на любой части проекта, где нужен. Ладно, лендосы, пожалуй, верстать не готов.

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

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

Д. Д.: Тимлид нужен в любой команде, или где-то можно обойтись без этого специалиста? Возможно, роль тимлида может сыграть какой-то другой сотрудник?

А. Ш.: В идеале здорово, когда члены команды одинаково сильно вовлечены и помогают компании двигаться вперед. Зачастую так не бывает, у людей могут быть разные интересы и разные стремления. Это нормально. В такой ситуации полезно, когда есть человек, который собирает разрозненные мнения воедино, помогает команде сфокусироваться и достичь цели. Может быть, его назовут тимлидом, может быть нет 🙂

Д. Д.: Тимлид — больше менеджер-организатор или разработчик с глубокой экспертизой? На что больше тратит времени тимлид: на работу с кодом или общение с другими программистами?

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

Д. Д.: Есть ли у вас как у тимлидера пожелания к будущим джуниорам или советы? Каким должен быть джун, чтобы вы его взяли на работу?

А. Ш.: Мы не нанимаем джунов, так что на второй вопрос не могу ответить. Что касается советов, то я тут не открою никаких тайн. Будьте готовы много работать, будьте готовы брать на себя ответственность, умейте радоваться победам и делать выводы из поражений 🙂

Виталий Прокурат: у джуна в первую очередь должен быть интерес к работе

О собеседнике: Прокурат Виталий , team Lead в Минском центре разработки компании Wargaming . Больше 10 лет опыта в веб-разработке .

Дмитрий Дементий: Какую роль в профессиональной жизни начинающего разработчика играет тимлид? Или перефразирую: почему стажёру или джуниору надо плотно общаться и дружить в профессиональном плане с тимлидом?

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

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

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

На самом деле, взаимодействие с тимлидом полезно не только начинающим разработчикам, но и разработчикам уровня middle и senior.

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

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

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

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

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

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

Вопросы которые могут в этом помочь:

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

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

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

Д. Д.: Тимлид нужен в любой команде, или где-то можно обойтись без этого специалиста? Возможно, роль тимлида может сыграть какой-то другой сотрудник?

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

В команде, где три и более разработчиков, я считаю, нужен тимлид.

Д. Д.: Тимлид — больше менеджер-организатор или разработчик с глубокой экспертизой? На что больше тратит времени тимлид: на работу с кодом или общение с другими программистами?

В. П.: Большая часть времени уходит на общение с другими разработчиками:

• обсуждение рабочих вопросов по текущим задачам и code review внутри команды;
• митинги с разработчиками из других команд по обсуждению совместных задач;
• работа с бэклогом и приоритизация задач.

Времени писать полноценный код нет, иногда есть возможность сделать какой-то прототип или исправить найденный баг.

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

Д. Д.: Есть ли у вас как у тимлидера пожелания к будущим джуниорам или советы? Каким должен быть джун, чтобы вы его взяли на работу?

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

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

Заключение: вырасти можно, но джуниорам придётся запастись терпением

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

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

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

Ведущий разработчик, управляющий сотрудниками в проекте.

Анастасия Хамидулина
Автор статьи
21 февраля 2023 в 11:31

Тимлид — это специалист, который отвечает за команду разработчиков из пяти — девяти человек. Чтобы им стать, недостаточно просто пройти обучение. Ведь это ступень карьерного роста, а не профессия. Руководить командой может только разработчик с большим опытом за плечами и развитыми личностными качествами.

Что входит в задачи тимлида

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

Функции тимлида делят на управление кадрами и управление разработкой. Как менеджер он выполняет такие задачи:

�� Общается с клиентами.

�� Определяет бюджет, количество задач и сроки.

�� Участвует в подборе сотрудников.

�� Создает систему мотивации.

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

�� Распределяет задачи между специалистами.

�� Следит за качеством продукта.

�� Решает проблемы, которые появляются при разработке.

�� Участвует в тестировании.

�� Управляет задачами в смежных сферах вроде маркетинга и дизайна.

Тимлид в любом направлении должен обладать развитыми личными качествами. Этому учат на курсах Skypro, например «Python-разработчик». В программе есть блоки, которые позволят развить навыки командной работы и коммуникации, научат планировать задачи и распределять их между коллегами.

Задачи тимлида тестировщиков из вакансии на Хабр Карьера

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

Сергей Иванов
Ведущий разработчик (команда маркетинга и продаж).

Какие нужны навыки и знания

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

��️ Языки PHP, JS, MySQL.

��️ Базовые знания в DevOps, архитектуре и тестировании.

��️ Умение работать с фреймворками и библиотеками.

Навыки, которые нужны для должности Java-тимлида в вакансии на Хабр Карьера

Личные качества тимлида

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

�� Лидерские качества

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

�� Навыки делегирования

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

�� Знание современных трендов

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

�� Аналитический склад ума

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

На курсе Skypro, например «Аналитик данных», не только учат профессиональным навыкам, но и развивают личные качества студентов, которые потом пригодятся для работы в команде. В будущем именно они позволят стать хорошим тимлидом.

Как стать тимлидом

До должности тимлида можно дорасти, работая программистом или аналитиком в компании. Согласно исследованию Хабра, 63% российских компаний выбирают тимлидов из своих работников. Идеальный путь специалиста в этом случае будет выглядеть так:

Стажер — младший специалист — специалист — тимлид.

Исследование Хабр 2020 года

Разберем путь от специалиста до тимлида по шагам:

1. Станьте ведущим специалистом в своей сфере, будь то аналитика, разработка ПО или игр. Это станет прочной базой: работодатели обычно ищут тимлидов с опытом работы от пяти лет.
2. Начните погружаться в смежные технические сферы: изучите архитектуру приложений и сайтов, тестирование, веб-дизайн.
3. Управляйте проектами в своей компании и берите ответственность за итоговый результат. Например, можете курировать разработку и помогать с планами релиза и тестирования.

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

Полное погружение в маркетинг: новая работа через 9 месяцев
Оставляем доступ к материалам навсегда

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

Сергей Иванов
Ведущий разработчик (команда маркетинга и продаж).

Начать карьеру проще с онлайн-университетом Skypro. Освоите IT-специальности, даже если совсем нет релевантного опыта. Среди курсов: «Веб-разработчик», «Аналитик данных», «Инженер по тестированию» и другие востребованные профессии. Все программы соответствуют требованиям тысяч работодателей к новичкам. За поиск работы переживать не придется: гарантию трудоустройства фиксируем в договоре.

2 ноября 18:00 МСК
Как без опыта и навыков гарантировано перейти на удаленную работу в 2023 году

Карьерный рост

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

�� Менеджер проектов

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

Главное отличие от тимлида: не занимается технической реализацией проекта.

��‍�� Менеджер продукта

Отвечает за создание новых продуктов, изучает поведение аудитории и продумывает, какие функции нужно добавить в сервис. Задача менеджера — найти баланс между запросами пользователя, целями бизнеса и самой разработкой.

Главное отличие от тимлида: проводит исследования.

��‍�� IT-консультант

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

Главное отличие от тимлида: постоянно меняет компании.

��️ Старший разработчик

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

Можно начать путь с frontend-разработки после курса Skypro «Веб-разработчик». Через несколько лет прокачать навыки в бэкенде и перейти в фулстек-разработку.

Главное отличие от тимлида: занимается непосредственно разработкой.

��‍�� CTO (технический директор)

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

Главное отличие от тимлида: управляет большими командами.

Плюсы профессии

➕ Работа в сфере управления

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

➕ Высокие зарплаты

Средняя зарплата тимлида в России на 2022 год — 266 000 ₽. Многие предложения предусматривают удаленную работу.

Зарплата тимлида в вакансии «СберЛогистики»

Зарплата тимлида в вакансии «Поток.Диджитал»

➕ Возможность вырасти в старшего разработчика

Если вам по душе техническая работа, а не курирование команды, то должность тимлида может стать хорошим трамплином к следующему карьерному шагу. Средняя зарплата ведущего разработчика в России — 230 000 ₽ в месяц, а еще такие специалисты востребованы за рубежом.

Минусы профессии

➖ Большая ответственность

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

➖ Многозадачность

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

➖ Переработки

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

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

Сергей Иванов
Ведущий разработчик (команда маркетинга и продаж).

Главное: кто такой тимлид и как им стать

1. Тимлид — это ведущий разработчик, который управляет командой менее опытных специалистов. Он обсуждает проект с клиентом, участвует в подборе кадров, ставит цели сотрудникам. Иногда сам пишет код.
2. Плюсы этой профессии: прокачка профессиональных навыков и личных качеств, работа с людьми, мощные проекты для портфолио, высокая оплата и востребованность на рынке.
3. Тимлиду нужно иметь большой опыт в разработке и управлении проектами, а еще обладать лидерскими качествами. Работодатели ищут специалистов, которые работают в сфере не менее пяти лет.
4. Лидер команды может стать топ-менеджером, IТ-консультантом, ведущим разработчиком или техническим директором.