Тимлид: что это за профессия + заработная плата и вакансии для специалистов it сферы

Кто такой Тимлид?

Описание профессии тимлид начну, пожалуй, с уточнения: это не специальность, а должность, или административная единица по другому, исключительно в сфере IT.

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

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

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

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

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

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

Какая же деятельность для тимлида родная?

1. члены команды были согласны выполнять поручения,
2. достаточно компетентны для этого,
3. обладали достаточными ресурсами (в первую очередь — временем),
4. могли ужиться вместе.

Лидерство

с намерением

1. Проявлять искреннюю личную заинтересованность в успехе проекта. В современной команде разработчиков все видят все, что делают остальные, как делают, насколько стараются. Разработчики с большей охотой пойдут за тем, кто сам вовсю старается ради успеха проекта, даже если этот кто-то и формальной власти то не имеет, из желания помочь. Такой лидер легко удерживает инициативу, пока не выдохнется или не потеряет интерес к проекту.
2. За счет знания технологий и устройства проекта лучше всех в команде. К таким лидерам тянутся заинтересованные в профессиональном росте разработчики, они часто именно за этим и приходят в проект. Логично, что при достижении разработчиками уровня лидера, если других факторов нет, лидер теряет инициативу, что на практике выражается постоянной критикой решений, порой приводит к игнорированию распоряжений или скрытым саботажам.
3. Способен добиться уважения окружающих за счет личных качеств. Когда человек объективен, справедлив, последователен, сотрудники могут полагаться на такого человека и его решения. Однако для того, чтобы команда разглядела эти качества в потенциальном лидере требуется время, за которое лидерство захватит кто-нибудь другой. Этот фактор наиболее устойчив к различного рода переменам в команде.
4. Умение эксплуатировать настроения отдельных членов команды, заставляя действовать по своему плану (кино Filth сразу вспомнилось www.imdb.com/title/tt1450321). Видел таких лидеров, даже немного поработал в профессиональной юности сдуру, но вовремя сбежал. Очевидно, что опытными специалистами, знающими себе цену, долго не поманипулируешь.
5. Применение административных мер, предоставляемых формальной властью, для того, чтобы заставить сотрудников выполнить обязательства. Если этот фактор лидерства единственный, то это явный пример системы отношений «я — начальник, ты — дурак». Работает также на довольно ограниченном множестве сотрудников.

Компетентность команды

1. Типовая ошибка — найм недостаточно компетентных сотрудников в силу неумения выявить профессиональные качества кандидата. Простые примеры — это неумение или боязнь задать правильные вопросы на собеседовании, смещение акцента на эзотерические особенности технологий, а не на их практическую сторону. Последствия ожидаемы — кандидат не справляется со взятыми командой обязательствами, следовательно и тимлид тоже.
2. Другая крайность — найм только экспертов. Чтобы не ошибиться в найме после набития шишек, или из желания собрать команду мечты, тимлид тщательно отбирает только не уступающих в знаниях ему самому кандидатов. Так как такая манера больше свойственна лидерам-экспертам, то ценз получается довольно высоким. Кандидаты ищутся долго, затраты на подбор растут, задачи проекта не решаются, а у тимлида есть отличная отговорка — нет специалистов. Но даже когда команда собрана оказывается, что звезды с рутинными задачами готовы мириться, но хотелось бы задач с вызовом (challenge) и каждому, а вот пойти мусор подмести в проекте никому не хочется. Да и обстановка какая-то напряженная становится, как известно у 4-х архитекторов 8 мнений, большинство из них правильные, хоть и противоречат друг-другу.
3. Еще типичный пример — игнорирование потребности в привлечении в команду сотрудников других специальностей, например фронтендщика, эксперта в определенной БД, проектировщика интерфейса и т.д. Часто такое происходит просто из-за непонимания того, что такой специалист в команде нужен. В итоге команда суровых бэкендщиков разрабатывает кое как работающий фронтенд в своем проекте, команда разработчиков месяцами бьется с оптимизацией PostgreSQL, ну и мой любимый случай — психбольница в руках пациентов.
4. Пример сложнее — неравномерность найма, взял пачку джуниоров, чтобы два раза не вставать, а они как начали код писать так, что ревьювить команда не успевает, да еще подходят вопросы всякие задают непрерывно, ломают что-то постоянно.
5. Или наоборот, работаем, концентрируемся на задачах, найм на потом откладываем, как внезапно уходит кто-то из ключевых сотрудников, другой в отпуске/болеет/забрали в другой проект, а на смену никого из подрастающего поколения нет. Скажете, что мол, ситуация неожиданная? Так вот к такой ситуации тимлид всегда должен быть готов, заранее продумывая как он поступит в случае потери того или иного члена команды. А еще лучше если он отношения построит так, чтобы заранее узнать о таком исходе.

Про ошибку найма и ответственность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Советы будущим тимлидерам

Какие рекомендации можно дать тем, кто хочет стать хорошим тимлидом:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кому не подходит должность

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

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

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

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

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

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

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

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

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

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

Алгоритм подбора подходящего руководителя

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

1. Какие из стилей предпочитаете лично вы, как сотрудник?

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

3. Какой стиль будет подходить команде через год, два, пять (зависит от того как на долго вы собираетесь с ней остаться)?

4. Какой стиль использует руководитель?

5. Способен ли он менять свой стиль?

О том, как ответить на эти вопросы мы поговорим ниже, а пока разберемся, как интерпретировать ответы:

1. Запишите ответ на первый вопрос, скорее всего у вас выйдет несколько предпочтительных стилей.

2. Стили из вопросов 2-4 должны быть из списка ваших предпочтительных.

3. Ответы на вопросы 2 и 4 должны совпадать.

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

Поддержка: контроль

1. На встречах с тимлидом при обсуждении любых вопросов постоянно проверять его понимание сказанного: «Расскажи мне, как ты понял», «Объясни своими словами» и т. д.
2. Постоянно «обнажать инструментарий»: «Смотри, я тебя подвёл к решению задачи наводящими вопросами, но решил её ты сам. Видишь, как мой коучинг работает на тебе — он так же сработает на ребятах». Хорошо бы добавить личный пример.
3. Выделять больше времени на встречи с лидом, чем раньше тратилось на общение с каждым разработчиком. У меня на общение с тимлидами уходит как минимум полтора часа в неделю, плюс куча небольших синхронизационных обсуждений.

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

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

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

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

В большинстве случаев тимлидом становятся после приобретения профессионального статуса senior, т. е. став экспертом в своем деле, способным оценить весь проект в целом.

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

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

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

Самостоятельное обучение

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

• Том ДеМарко “Deadline. Роман об управлении проектами”
• Джефф Сазерленд “Scrum. Революционный метод управления проектами”
• Патрик Ленсиони “Пять пороков команды”
• Роман Матвеев “Наставничество. Метод Петра Кузнецова”
• Патрик Ленсиони “Смерть от совещаний”
• Роберт Кийосаки “Богатый папа, бедный папа”
• Джон Медина “Правила мозга”

Со списком книг о профессии тимлид можно ознакомиться на блоге.

Онлайн-курсы

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

1. Удобный формат. Когда, где и как быстро проходить курсы – индивидуальный выбор ученика.
2. Структурированная и собранная в одном месте информация.
3. Готовое портфолио по окончании курса.

Популярные платформы Skillbox, Нетология, SkillFactory, Otus, City Business School и Академия АйТи предлагают свои курсы для будущих тимлидов:

• Практический онлайн-курс “TeamLead”
• Онлайн-интенсив “Бизнес и управление”
• Интенсив “Тимлид разработки”

На блоге iklife.ru можно найти обзор лучших курсов по Team Lead и выбрать подходящий для себя.

Как сделать, чтобы стул не сгорел раньше

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

• Начинаете работать намного больше, чтобы успеть и как разработчик, и как team lead. Обычно это ведет к перегоранию.
• Работаете столько же, сколько и раньше. В итоге не успеете сделать и фичи, и задачи лида.

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

Именно поэтому нужно четко регламентировать, зачем вам программировать, сколько времени и что это даст отделу и в целом компании. Если речь идет о 30% времени, в течение которых вы будете проектировать архитектуру общих решений, библиотек или стандартов — одно дело. Это поможет не заниматься рутинными задачами, не забыть код и смотреть на него более глобально. Но если вам говорят о 70% или 90% времени, то люди просто не понимают, зачем им нужен team lead. Или заранее планируют, что вы будете работать больше 40 часов. Можете либо аргументированно объяснить, как сделать лучше, либо просто ответить отказом. Лучше всего поговорить об ожиданиях.

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

• люди не понимают, чем вы занимаетесь;
• вы и сами не понимаете, чем занимаетесь и что нужно сделать. Находитесь в совершенно неконтролируемом хаосе.

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

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

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

Автоматизируйте.Плюс различного рода оптимизации в виде CI/CD/статических анализаторов, кодогенераторов, базовых либ и так далее. Всё это экономит нам время в будущем.

Заключение

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

Я думаю, что по аналогии с военными, нам — заказчикам, также страшно при поиске нового персонала. Нам закрадывается мысль: «Если я возьму плохого, кто отвечать будет?» И в следствии защитной реакции мы придумываем себе волшебные слова «серебряные пули» в надежде что они сами по себе решат все наши проблемы. Кандидаты сами будут понимать подходят они или нет и откликаться будут только действительно классные и нужные ребята.  И подобно тем военным, мы выстреливаем в интернет слова: Middle, Senior, 2 года коммерческой разработки, Spring Boot, Nodejs, Angular, Kubernates. 

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

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

А именно — формализовать минимальные технические требования и прояснять их еще до встречи с HR или заказчиком.