Тимлид (team leader)

Содержание

Оценка своей работы

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

Вы стали тимлидом в чужой команде

Разберем, что делать, если вы только что стали тимлидом в собранной до вас команде, в который вы раньше не работали. С чего начать и как себя вести.

Вы стали тимлидом в своей команде

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

1:1

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

Слухи, новости и обещания

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

Тимбилдинг

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

Ввод нового сотрудника

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

Работа с джунами

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

Чем занимается team leader

Отметим, что тимлид – это должность, а не отдельная профессия. Что входит в обязанности этого специалиста:

• Общение с заказчиком, организация разработки. Team lead помогает программистам решать поставленные перед ними задачи (с высоты своего опыта). Он одновременно и управляет, и сам занимается разработкой. Поэтому должен иметь иметь хороший базис в программировании и навыки менеджера. Он учитывает приоритеты и интересы конкретного заказчика, отслеживает эффективность членов команды в плане бизнес-процессов.
• Наем, обучение и адаптация всех сотрудников. Лидер взаимодействует с менеджерами и эйчарами для закрытия потребности в кадрах, принимает участие в собеседованиях. В маленьких организациях тимлидеры иногда сами занимаются наймом. В больших компаниях эйчары производят первичный отбор, а team lead задействуется для технических собеседований. Он знакомит новичков с принятыми в работе стандартами, самим проектом, инструментарием и кодом. Помогает джуниорам понять бизнес-процессы и роль каждого в них, планирует развитие других сотрудников, мониторит их рост. Благодаря тимлиду обеспечивается соответствие всей команды и отдельных кадровых единиц потребностям бизнеса.
• Помощь коллегам и координация команды. Лидер выполняет не только управленческие функции, он принимает участие в работе над кодом. Руководитель следит, чтобы продукт соответствовал целям, которые поставил заказчик. Осуществляется это путем контроля разработки и координации деятельности команды. Программисты обращаются за помощью к тимлиду, а во время индивидуальных бесед и общих собраний обсуждается ход грядущей работы.

Менеджерские полномочия тимлида:

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

Технические компетенции управленца:

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

Team leader должен четко осознавать, что сейчас происходит с проектом, текущий этап разработки, отклонять/одобрять различные идеи и предложения сотрудников. Он ответственен за микроклимат в коллективе, за то, чтобы все члены команды были работоспособны. Иными словами, он помощник, психолог и друг. Руководитель обеспечивает комфортные условия работы своим подчиненным.

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

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

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

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

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

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

Заработная плата

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

Сколько получает такой специалист? Уровень заработной платы в основном зависит от региона и масштабов компании, где он работает. Разумеется, заработок на крупном предприятии в Санкт-Петербурге или Москве будет выше, чем в небольшой организации на периферии. Сегодня тимлид в среднем может зарабатывать от 160 до 340 тысяч рублей в месяц. По информации, изложенной на сайтах с вакансиями, минимальная зарплата для претендента на эту должность составляет почти 26 000 рублей, а максимальная – немного больше 672 тысяч рублей.

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

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

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

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

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

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

Зарплата, карьера и перспективы

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

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

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

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

В среднем заработная плата тимлидов находится на высоком уровне. Если смотреть в целом по России, то заработок может быть от 80 000 до 250 000 руб.

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

Самая большая зарплата в столице. Москва предлагает специалистам зарплату 100–400 тыс. руб.

В Санкт-Петербурге заработок чуть меньше: от 90 000 до 300 000 руб.

В регионах ситуация примерно одинаковая. Например, в республиках Марий Эл, Татарстан и Якутия, Краснодарском крае, Свердловской и Тюменской областях платят от 70 000 до 230 000 руб. А в Камчатском крае можно найти вакансии с зарплатой выше 300 000 руб.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кого называют тимлид-программистом

Team lead (team leader) командует группой разработчиков. Он управляет командой, занимается организацией и координацией ее действий, мотивацией всех сотрудников. Тимлид также контролирует все этапы формирования продукта. Это посредник между клиентом, руководством и программистами.

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

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

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

Таким образом, тимлид объединяет в себе программиста, менеджера и лидера проекта. Это ключевая фигура в разработке программного обеспечения. Обычно на данную должность берут программиста с большим опытом, высокопрофессиональными знаниями и умениями. Он может находить ошибки в кодах других разработчиков, а затем исправлять их. При этом team lead редко сам занимается написанием кода: его основные задачи – контроль и управление.

Поддержка в Lamoda

Звонки клиентов обслуживает контакт-центр и эта информация дальше переходит в нашу службу поддержки. Под большинство случаев есть набор инструкций куда и с какой проблемой можно обращаться. Также по каждому направлению есть информация о текущем дежурном.

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

Сколько у вас дежурных?

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

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

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

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

Если находится баг прямо на проде — дежурные могут деплоить напрямую?

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

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

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

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

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

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

Для этого специалист должен обладать такими личностными качествами, как:

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

До того как специалиста назначат на должность тимлида, он должен проработать в IT-сфере не менее 5 лет, а также иметь следующие навыки и умения:

1. Аналитические способности.
2. Знания серверных технологий.
3. Готовность к самообучению.
4. Умение учитывать мнение команды.
5. Знания масштабируемости веб-проектов.
6. Способность принимать быстрые и простые решения в стрессовых ситуациях.
7. Умение распределять обязанности внутри коллектива.
8. Навыки и умения в программировании на уровне senior.
9. Оценка и планирование бюджета.
10. Умение рассматривать проблему с разных ракурсов.
11. Навыки наставничества.
12. Умение нести ответственность за работу других людей.
13. Знания языков программирования.
14. Способность учитывать риски.
15. Умение заметить и исправить ошибку.
16. Знания планирования задач.
17. Умение планировать, ставить сроки и укладываться в них.
18. Способность сформировать команду, обучать и мотивировать новых сотрудников.
19. Умение переработки требований заказчика в техническое задание.
20. Знания в области психологии, социологии, менеджмента и кадровой политики.
21. Навыки решения конфликтов и поддержания рабочей мирной атмосферы.
22. Умение распределять нагрузку между членами группы.
23. Знания ведения переговоров.
24. Умение проводить тестирование готового продукта.
25. Навыки контроля всех этапов работы.
26. Умение вести документацию.

В этом состоят только основные требования. Остальные могут быть связаны со сферой деятельности заказчика.

Приведите в порядок встречи один на один

Пример формата записи результатов и договорённостей по итогам встречи

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

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

Выбрасываем все лишнее

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

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

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

У рекрутеров в ходу есть такой мем;)

Стиль спускается каскадно от топ-руководителей

Есть один важный нюанс. Скорее всего, вы не идете на работу в маленький стартап, где вашим руководителем будет сам основатель. Это значит, что у вашего руководителя будет ещё как минимум один руководитель на уровень выше. Если ваш непосредственный руководитель — милейший человек, который всегда «за своих орлов», а его руководитель — авторитарный деспот с усами, то так или иначе вы будете ощущать авторитарную нотку управления на себе. Если кто-то из директоров вздумает установить в офисе камеры и будет лично следить за тем, кто уходит на 15 минут раньше положенного, то никто вам не поможет. Каким бы подходящим ни был ваш тимлид, он будет не в силах спасти вас от бушующего СТО. Именно поэтому при собеседовании нужно задавать вопросы по фреймворку STAR или PARLA, узнавать отзывы бывших сотрудников

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

Какой стиль подходит команде

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

Сколько получают Тимлиды и как найти работу?

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

Так, по Москве уровень зарплаты может достигать 400 тысяч рублей и более, при этом минимальная планка тоже высокая – около 100 тысяч рублей. В других регионах зарплаты гораздо ниже, примерно от 50 до 300 тысяч рублей.

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

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

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

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

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

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

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

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

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

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

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

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

Что надо понять

Вам платят деньги не за то, что вы пишите код

Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше

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

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

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

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

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

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

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

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

Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.

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

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