Чем занимается team lead
Должность — тимлид
Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.
От разработчиков, проработавших долгое время в рамках одной компании или даже одной команды чаще услышишь четкое мнение о том, кто такой тимлид и в чем заключаются его обязанности. Повидавшие же разные проекты разработчики и менеджеры постепенно приходят к пониманию, что тимлид может заниматься много чем, какая-то деятельность лучше вписывается в его роль, какая-то хуже, и уже не готовы давать точное определение роли тимлида.
Откуда же появляется разное представление о должности тимлида?
ПРИМЕЧАНИЕ. Здесь и далее я говорю про тимлида только в рамках команды разработки. Догадываюсь, что многое из рассуждений распространяется и на другие команды, во многих видах деятельности.
Мне доводилось видеть тимлидов исполняющими роли руководителя проекта, системного аналитика, тестировщика, дизайнера, проектировщика интерфейсов, архитектора, даже специалиста по поддержке пользователей.
На практике, в здоровых организациях, по моим наблюдениям, роль тимлида обычно занимают разработчики, которые более других чувствуют ответственность за судьбу разрабатываемого продукта, нередко перерастающую в гиперответственность, чем умело пользуется руководство.
ПРИМЕЧАНИЕ. Гиперответственностью я называю случай, когда человек чувствует себя ответственным за обстоятельства, влиять на которые полномочий не имеет. Я не пытаюсь вложить в это качество ни позитивного ни негативного оттенка, лишь констатирую, что в некоторых сотрудниках гиперответсвенность проявляется.
Именно за счет этой гиперответствености тимлид берет на себя ту деятельность, для которой нет выделенной должности и, постепенно, эти обязанности закрепляются за ним и, как следствие, за его должностью. В это время остальные сотрудники тоже привыкают к таким обязанностям тимлида, закрепляя в сознании именно такой набор обязанностей для любого другого тимлида.
Конечно, описанное касается не только роли тимлида, и, в той или иной степени, картина верна для любой должности в любой деятельности, но должность тимлида среди тех, что наиболее подвержены описанному эффекту.
Какая же деятельность для тимлида родная?
Что должен уметь сотрудник, какими качествами обладать для того, чтобы быть хорошим тимлидом, а только потом хорошим архитектором или аналитиком?
Самое простое определение, которое я могу дать для роли тимлида звучит так: «тимлид — интерфейс команды разработки».
Он отвечает за все, за что отвечает команда, для этого у него есть полномочия формировать команду и использовать ее членов по своему усмотрению для решения задач команды.
Если на команду возлагается ответственность за проектирование системы, то тимлид должен позаботиться о том, чтобы кто-то систему спроектировал. Команда ответственна за разработку интерфейса пользователя — тимлид определяет кто в команде это сделает. И это справедливо для любой задачи команды: ответственен за ее выполнение в глазах внешнего для команды мира тимлид.
Что же конкретно тимлид должен делать?
Разберем, что с этим нужно делать.
Лидерство
«Нужно чтобы члены команды были согласны выполнять поручения» — так себе формулировка, но изящнее сложить не удалось. Имеется в виду то, что сотрудник должен принимать задачи в работу с намерением довести их до конца. Сотрудник не отказывается брать задачи в работу просто игнорируя указания, или ссылаясь на «кривость решения», не саботирует, по-тихому занимаясь своими делами, а принимается за задачу с намерением ее выполнить. Как заставить человека захотеть выполнить задачу? Способов много, от принуждения угрозой физического насилия до обещания поездки на девкон. Это то самое качество, что я определяю «лидерством».
Компетентность команды
ПРИМЕЧАНИЕ. Довольно часто несоответствие ответственности и полномочий проявляется в том, что тимлида не включают в процесс принятия решения о приеме кандидата, или не дают возможности исключить сотрудника из состава команды по инициативе тимлида. Притом ответственность за то, чтобы команда справлялась со своими задачами с тимлида никто не снимает. Вот она — вмененная гиперответственность.
В чем же здесь проявляется профессионализм тимлида?
Как всегда скоростью и качеством решения задачи обеспечения команды компетентными сотрудниками.
Качество в данном случае тем выше, чем дешевле обходятся компании сотрудники (и не только зарплату считаем) при условии соблюдения их уровня компетенции, достаточного для решения задач. В некоторых случаях скорость в приоритете, в некоторых качество.
Среди способов пополнения кадрами вижу принципиально два подхода:
1. Брать готовых специалистов с рынка труда.
2. Воспитывать кадры самостоятельно.
Остальные, так или иначе, — комбинации этих двух. Крайний случай первого — только хантинг экспертов в требуемых областях, второго — найм только из стажерских программ. Правильного способа нет, а крайности, как и везде, часто свидетельствуют о некоем сбое. Тимлид как раз тот человек, который должен найти подходящий компромисс в конкретной ситуации с учетом ее развития.
Нельзя дать ответ на общий вопрос «как обеспечить команду достаточно компетентными специалистами», можно найти его решение только в рамках конкретного проекта на конкретном предприятии. Можно только сказать, что тимлид при разработке этого решения должен учитывать характер задач в проекте, срочность поставленных задач, значимость (impact) срыва сроков, планы и тенденции развития проекта, состояние рынка труда, доступность специалистов на рынке, сложность обучения специалистов своими силами.
Оценка работ
Чтобы не взять на себя обязательств, с которыми команда не сможет справиться, команде приходится оценивать свои ресурсы, чаще всего речь идет только о доступном рабочем времени членов команды. Ответственнен за исполнение обязательств командой разработки тимлид. Вне зависимости от того, как именно производится оценка работ в команде: каждый оценивает свою задачу, или все вместе оценивают все задачи, или все задачи оценивает кто-то один в команде, за оценку отвечать будет тимлид. Из этого следует, что тимлид имеет полномочия вмешаться в любую из оценок и изменить ее по своему усмотрению, это бывает полезно на практике, когда мнения членов команды расходятся. Более того, команда разработки, в лице тимлида, также берет на себя обязательства по исполнению планов, если ставить задачи команде в организации принято планами. В частном случае итеративных методов разработки команда (говоришь «команда» — подразумеваешь «тимлид») берет на себя ответственность за выполнение всех задач взятых в итерацию.
В современных подходах к разработке менеджмент не лезет в дела команды разработки, не говорит им как решать задачу, кому именно из состава команды решать задачу. Менеджменту важно лишь, чтобы команда выполнила задачу в оговоренный срок, а как это произойдет — неважно. Интересно, что о распределении задач между участниками умалчивает даже популярная методология Scrum, предоставляя команде «самой решать», кто за что возьмется. Когда-то я выяснял для себя, а как же происходит распределение задач на практике, и меня удовлетворил чей-то ответ, что в любой команде рано или поздно найдется лидер, который возьмет на себя инициативу по решению конфликтных ситуаций в распределении задач. Аргумент в пользу того, что распределение задач между участниками — также задача тимлида.
Как ни удивительно, оценка, планирование и распределение задач — обязанность, которая выполняется легко, если тимлид успешно справляется с другими обязанностями. Для этого в его распоряжении есть компетентные сотрудники, которые мотивированы на выполнение задач, они легко справятся с оценкой и выполнением задач. Тимлиду нужно только организовать процесс оценки и распределения задач командой, чтобы затем контролировать его. Как именно это сделать — существуют готовые решения в виде методологий разработок.
ПРИМЕЧАНИЕ. Если не знаете какую методологию выбрать в обычных условиях — берите Scrum. Потому что он прост, определен вплоть до мелочей и довольно хорошо работает даже без адаптации под команду и организацию.
Настроения в команде
Как минимум, для того, чтобы задачи решались, нужно чтобы члены команды могли общаться друг с другом без взаимного раздражения.
Казалось бы, простая задача? Далеко не так! Если между сотрудниками назрел конфликт, то во многих случаях его можно разрешить только исключением кого-то из участников из состава команды. Но на предотвращение конфликта тимлид вполне в силах повлиять, тут универсальных советов не дать, кроме одного: нельзя замалчивать конфликты, при любом инциденте нужно реагировать, как именно реагировать — зависит от конкретных обстоятельств.
Также тимлиду следует соотносить характеры членов команды, если одного зануду команда переварит, то двух, возможно, уже и нет (ничего не имею против зануд, сам зануда еще тот).
Ну а чтобы «повысить эффективность взаимодействия между членами команды» есть такая дисциплина как «тимбилдинг», я весьма скептически к ней отношусь, может сказывается тот факт, что не видел я хороших тимбилдеров в деле.
Вообще хотел обойтись без этого пункта, но совсем про него не упомянуть нельзя.
Заключение
Итак, у тимлида есть родные его должности обязанности, все они касаются того, чтобы обеспечить работоспособность команды, то есть способность выполнять поставленные перед командой задачи. Все остальное — это то, что тимлид взваливает на себя добровольно (или принудительно) дополнительно, но не всегда это плохо. Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет. Думаю многие из разработчиков знакомы с такой ситуацией, когда оставив интенсивно разрабатываемый проект на несколько месяцев, по возвращению обнаруживаешь лишь редкие знакомые элементы в новой архитектуре системы. Однако, согласно рассуждениям выше, непосредственная разработка не входит в число родных обязанностей тимлида, в некоторых проектах она может быть необоснованна.
В реальном мире тимлид не брошен один для решения всех этих задач, ему помогают руководители, коллеги соседних департаментов. На практике часто эта помощь перерастает в принятие решений за тимлида, такие моменты должны настораживать, так как фактически его обязанности переходят к другим сотрудникам. Бороться с этим или смириться — решать вам, но обращать внимание на реальное положение дел уж точно стоит.
Интересует мнение разработчиков (в широком смысле — всех, кто работает в составе команд-разработчиков), тимлидов, линейных и проектных руководителей, согласны ли вы с такой декомпозицией роли тимлида? Есть ли у вас какие-либо замечания, дополнения?
Что должен делать тимлид: роли, обязанности и навыки
Тимлид (Team Lead) – специалист, который руководит командой разработчиков. Это должность, а не профессия. Нельзя пройти курсы и стать лидером команды. Единственный путь – это получение опыта и наращивание профессиональных компетенций.
Чем занимается тимлид
Тимлид руководит командой разработчиков. Обычно он не пишет код (хотя может). Обычно он не думает об архитектуре (хотя может).
Общается с клиентами или бизнес-подразделениями компании.
Оценивает задачи, сроки каждого этапа, разбивает их на спринты.
Распределяет нагрузку между разработчиками.
Следит за тем, чтобы таски закрывались в срок.
Оценивает решения разработчиков, дает рекомендации.
Согласует с заказчиком готовую работу.
Тимлид несет ответственность за проект. Сроки сорваны – виноват тимлид. Хотите добавить еще фичи – разговаривайте с тимлидом (он скажет, что этот спринт уже заблокирован, но, возможно, в следующем возьмутся за вашу фичу – если сможете ее «продать»).
На тимлиде также лежат обязанности по формированию команды, онбордингу, поддержанию рабочей атмосферы. Нагрузка может быть разной. В одних компаниях тимлиды закрывают весь цикл найма разработчиков – от поиска и собеседования до онбординга и менторинга. В других компаниях тимлиды подключаются только на этапе финального собеседования с кандидатом и принимают решение о том, выдавать ли оффер.
От тимлида во многом зависит, будут ли разработчики расти профессионально. Решать эту задачу можно разными способами: проводить код-ревью, обсуждать код на индивидуальных или общих встречах, заниматься парным программированием.
У хорошего тимлида джуниоры быстро растут до мидлов. У плохого – занимаются формошлепством месяцами и не понимают, как их работа помогает бизнесу.
Какие навыки нужны тимлиду
Должность тимлида находится на стыке разработки и менеджмента. Поэтому бизнес ждет от него мощных хард- и софт-скиллов.
Опыт работы от 3-5 лет – и желательно, чтобы он включал опыт руководства хотя бы небольшой командой.
Опыт проведения код-ревью, менторинга – потому что придется помогать другим разработчикам, подтягивать джуниоров.
Умение принимать решения и брать на себя ответственность – все, что происходит с проектом, становится головной болью тимлида.
Аналитические способности и критическое мышление – для правильной оценки сложности задачи, расстановки приоритетов.
Навыки делегирования – чтобы грамотно распределять задачи между членами команды.
Знание HR – нужно разбираться в кадровой политике, потому что точно придется участвовать в формировании команды и наборе сотрудников.
Умение мотивировать сотрудников – и вообще общаться с людьми, в том числе предотвращать конфликты.
Тайм-менеджмент – для выставления реальных сроков решения задач.
Тимлид должен быть экспертом в том стеке, который использует команда. Необязательно быть лучшим во всем – это просто невозможно. Но в случае форс-мажора лидер должен быть способен заменить любого члена команды хотя бы на уровне поддержания жизнеспособности проекта.
Как стать тимлидом
В идеальном представлении путь до тимлида выглядит так:
В неидеальной жизни дорога может быть куда более сложной. Но многое зависит от размера компании и сложности проекта. А еще – от навыков человека. Не каждый сеньор может и хочет становиться тимлидом. Не всем нравится управлять людьми, общаться с бизнес-подразделениями и клиентами.
Тимлидом могут назначить и менеджера, который отлично умеет работать с клиентами. Но это ошибка, из-за которой пострадает процесс разработки. Если среди разработчиков не найдется неформальный лидер, то работа встанет. Менеджеру, который не имеет опыта в разработке, не удастся правильно оценить объем работы и распределить задачи.
Чему нужно научиться, чтобы стать тимлидом
Чтобы стать тимлидом, разработчику нужно развивать в себе менеджерские компетенции. Придется научиться:
переключаться между разными задачами,
распределять нагрузку между членами команды,
общаться с бизнесом.
Единственный способ понять, сможете ли вы быть тимлидом, – попробовать. Брать на себя больше ответственности, выполнять задачи «под ключ», чаще общаться с продакт-менеджерами, клиентами и бизнес-подразделениями компании, чтобы развить в себе продуктовое мышление.
«Быть» – новый подкаст от команды Timeweb, в котором участвуют представители различных айтишных профессий. Вы узнаете, чем они занимаются, какие навыки для этого нужны и что им доставляет наибольшее удовольствие в работе. Первый выпуск подкаста посвящен вопросам тимлидинга.
Чем занимается тимлид?
Всем привет! Несколько дней назад мы поговорили с Олегом Мельником о том, кто такой техлид. Прочитать интервью можно тут.
Мы решили продолжить тему и в этот раз поговорили с Олегом про такую роль у разработчиков как тимлид. То, что из этого вышло, читайте под катом.
Олег Мельник
Technical Lead в компании Proxify, а также преподаватель в OTUS
— Чем занимается тимлид, какова его роль в организации проекта?
—Почему-то мало кто замечает, что тимлид выполняет важную задачу при работе над проектом. Все разработчики – творческие личности со своим видением того или иного аспекта разработки, поэтому они нуждаются в человеке, который смог бы направить их энергию в нужное русло, помочь с распределением задач и урегулирования разногласий между аналитиками и разработчиками.
Бывают моменты, когда аналитики и разработчики не сходятся во мнениях, это частое явление. Все же аналитики – это бизнесмены, тогда как разработчиков интересует именно техническая часть проекта. Для этого и существует тимлид – сделать командную работу максимально комфортной для каждого сотрудника, чтобы творческий потенциал не угасал.
— Какая разница между тимлидом и руководителем группы?
—Единственная разница лишь в подходе, так как задача руководителя – управлять сотрудниками, заниматься их развитием и решать стратегические задачи, стоящие перед всем подразделением. Тимлид – человек, ответственный за определенный проект, и его цель – завершить разработку в срок, не теряя высоких показателей качества.
— Не задумывался об объединении данных ролей? Или все-таки работа тимлида более комфортна?
— Руководитель, конечно, более почетная должность, но сейчас у нас разрабатывается очень большой и сложный проект, состоящий из трех отдельных модулей, и я являюсь тимлидом для всех команд. Поэтому перспектива совмещать текущую должность с руководством меня не интересует в данный момент.
— А сколько человек работает над проектом?
— Непосредственно участвуют в разработке 17 человек, но, если считать тестировщиков и аналитиков, то примерно 30.
— Какими качествами должен обладать тимлид?
— Прежде всего, гибкостью. Работы всегда будет много, поэтому требуется найти оптимальный подход при работе над каждым проектом, чтобы успеть в сроки и не увязнуть в нем. Еще тимлид должен уметь общаться с подчиненными для того, чтобы понять, как лучше выполнить ту или иную задачу. Даже если коллега неправ, то не нужно давить на него, а лучше попытаться объяснить, в чем он не прав, рассказать о минусах и плюсах.
Также помогает твердость характера, чтобы уметь отстоять свою позицию и при этом не нанести ущерб разработке проекта. Идеальный тимлид – это человек, который ранее работал непосредственно аналитиком или разработчиком. Он сможет проанализировать прошлые ошибки на основе своего опыта, чтобы не допускать их в дальнейшем.
—Что обычно приходится решать тимлиду?
— Распределение задач между сотрудниками, команд между модулями. Составление сроков реализации, но самое сложное – это планы срочных задач, когда необходимо настроить команду на возможные переработки в нерабочее время и сверхнагрузку.
— Были ли приятные решения?
— Да, когда мы успевали по срокам и даже немного перевыполняли план, поэтому иногда принималось решение отпустить сотрудников домой немного раньше.
— Что больше всего нравится в данной профессии?
— Работа с командой, состоящей из разных по опыту и квалификации людей. Это позволяет учитывать разные мнения насчет выполняемой задачи и учиться чему-то новому у коллег. Люди больше заинтересованы в работе, когда есть, с кем обсудить вопрос или даже поспорить насчет направления разработки проекта.
— Чем занимаешься в данный момент?
— Работаю над очень сложным проектом, по которому ведется основная разработка. Там очень много работы, поэтому стараемся не отвлекаться от нее. Кстати, работает над данным проектом самая большая проектная группа в компании.
— В текущей компании ты изначально приступил к обязанностям тимлида или развивался внутри коллектива, чтобы заслужить должность?
— Ранее я работал в другой компании и смог взять на себя обязанности тимлида, но команда разработчиков состояла всего из 5 человек. Пришел на текущее место работы в 2019 году, но с «низов», то есть на вакансию разработчика. Мне понадобилось проработать 1 год, чтобы вновь стать тимлидом.
— Как вообще очутился в IT-сфере?
— Изначально при выборе специальности выбрал IT сферу. И сразу после института решил продолжить свою жизнь связанную с ИТ, из-за чего стал работать на разных должностях в данной области. Если бы не вышло стать разработчиком, то, думаю, нашел бы себя в аналитике или в devOps-е.
— Как проходит рабочий день тимлида?
— Ощущаешь ли нехватку свободного времени в связи с работой на такой должности?
— Разумеется, когда необходимо выполнять большое количество задач одновременно и всегда беспокоиться по поводу сроков сдачи проекта, то времени становится намного меньше. Однако, вместо выполнения монотонного кодинга, тимлид каждый день сталкивается с новыми трудностями и ищет способы их преодоления.
— Ты принимаешь участие в собеседованиях? Какую активность проявляешь и что чувствуешь, когда необходимо оценивать других людей?
— Да, подбор сотрудников в команду – это одна из моих задач. Обычно стараюсь не перегибать и оцениваю будущих коллег исключительно по знаниям и навыкам. Однако, собеседование дает только 20% информации о кандидате, лучший способ оценить его способности – испытательный срок, так как именно он покажет, каковы реальные навыки человека, бывает и с неожиданной стороны.
— Есть ли примеры таких ситуаций?
— Запомнилось два случая, но не в данной компании, а на прошлом месте работы. В первом случае кандидат продемонстрировал хорошие знания в требуемой области, смог даже выстроить корректную цепочку рассуждений. Однако в ходе испытательного срока он не смог выполнить ни одной задачи. Но бывают и обратные случаи – из человека не мог вытянуть и двух слов, но в ходе работы он смог показать высокие результаты и выполнить все задачи в срок. Такое тоже было в предыдущей компании.
— Есть ли нелюбимые вопросы на собеседовании? Какие?
— Практически любой вопрос, связанный с психологией. Мне всегда было неприятно, когда задают вопросы по поводу черт характера, кем я вижу себя спустя 2 года работы в компании и так далее. Это только вводит человека в ступор, так как ему нужно подобрать правильный ответ в голове. Лично мне важнее и интереснее знать его знания в программировании, а не то, кем он будет через столько-то лет. Особенно, когда большинство IT-специалистов – это интроверты.
— Какие же тогда любимые?
— Исключительно технические. В данный момент веду собеседования, которые связанны с PHP. Задаю те вопросы, которые обычно относятся не столько к данному языку программирования, сколько к архитектуре проекта, шаблонам проектирования и т.д.
— Какое самое нестандартное собеседование запомнилось?
Материал подготовлен в рамках курса «Team Lead». В преддверии старта курса приглашаем всех желающих на бесплатный демоурок с очень непростой темой «Как правильно увольнять человека».
Кто такой тимлид и как вырасти до этой должности
Продолжаем цикл статей о профессиях в отрасли IT. Сегодня говорим о тимлиде: кто это, чем занимается, сколько зарабатывает, как стать тимлидом и почему этот специалист — лучший друг джуниора.
Кто такой тимлид и чем он занимается
Слово «тимлид» произошло от английского team leader или team lead — лидер команды. Этот специалист координирует деятельность команды разработчиков, распределяет сферы ответственности, взаимодействует с заказчиком, планирует и организует обучение специалистов.
Обратите внимание, тимлид — не профессия, а должность. Лидерами команд разработчиков становятся программисты-разработчики. В данном случае программист — профессия, а тимлидер — должность.
Связь с заказчиком и организация разработки в интересах бизнеса
Содержание этого пункта зависит от конкретной организации и даже от конкретной команды. Если обобщать, тимлидер помогает команде разработки решать поставленные задачи. Этот специалист одновременно разрабатывает сам и занимается управлением.
Тимлид — одновременно опытный программист и хороший менеджер.
Как отмечалось выше, лидер команды играет роль связующего звена между заказчиком и разработчиками. Под заказчиком в данном случае подразумевается владелец бизнеса и топ-менеджеры в продуктовых компаниях или представители клиента в заказной разработке.
Тимлид организует работу команды с учётом интересов и приоритетов заказчика, обеспечивает соответствие продукта интересам бизнеса, следит за эффективностью команды в контексте бизнес-процессов. Здесь сфера ответственности тимлида как минимум частично пересекается со сферой ответственности проектного менеджера.
HR-процессы: наём, адаптация и обучение сотрудников
Тимлиды участвуют в HR-процессах: найме, адаптации и обучении сотрудников. Лидер планирует кадровые потребности команды вместе с HR-специалистами и руководителями. Тимлиды проводят собеседования и участвуют в них.
Конкретная роль тимлидера в найме зависит от масштабов компании. В небольшой организации этот специалист может заниматься наймом полностью самостоятельно: искать кандидатов, проводить первичные и технические собеседования и так далее. В крупных организациях первичный отбор берут на себя эйчары, а team lead подключается на этапе технических собеседований.
Тимлид организует онбординг нового сотрудника. Он знакомит новичков с проектом, кодом, инструментами и принятыми стандартами. Лидер команды помогает джуниору понять бизнес-процессы и роль разработчика в них. В больших компаниях и командах team lead привлекает к онбордингу новичков других разработчиков.
Обучение сотрудников — ещё одна сфера ответственности лидера команды. Тимлид планирует развитие новичков и опытных специалистов, следит за их прогрессом. Лидер обеспечивает профессиональное соответствие команды в целом и её отдельных членов потребностям бизнеса.
Обратите внимание, сфера ответственности тимлида не ограничивается хард-скилами. Хороший лидер уделяет внимание развитию мягких навыков членов команды.
Читайте также Интервью тимлида Evrone Дмитрия Матвеева. Дмитрий рассказывает о своём рабочем распорядке, сферах ответственности, требованиях к джуниору и других интересных вещах.
Разработка: координация команды и помощь сотрудникам
Тимлидер не фокусируется исключительно на управленческой деятельности. Он остаётся практикующим разработчиком, который знает код проекта, участвует в работе над ним. Как отмечалось выше, team lead обеспечивает соответствие продукта целям заказчика. Для этого он координирует деятельность команды, участвует в разработке, в том числе пишет код, если хочет и успевает.
Тимлиды помогают выполнять задачи другим членам команды. Этот пункт реализуется разными способами: от обсуждения кода на общих митингах до индивидуальных бесед, код-ревью, парного программирования и так далее.
Теперь вы знаете, почему новичкам важно найти общий язык с тимлидом: от эффективности взаимодействия с этим человеком зависит, как джуниор адаптируется в коллективе и сможет ли он развиваться и прогрессировать.
Промежуточный итог: team lead работает на стыке разработки и менеджмента. Он обеспечивает взаимодействие команды с заказчиком, участвует в HR-процессах. Лидер команды координирует работу программистов, помогает им решать задачи. Он сам участвует в разработке.
Где работают и сколько зарабатывают тимлиды
Формально должность тимлида есть не во всех IT-компаниях. Тем не менее практически в каждой команде есть сотрудник, который играет роль лидера. В зависимости от масштабов и внутренней структуры организации, это может быть самый опытный разработчик, руководитель отдела, даже технический директор или CEO в небольших стартапах.
В больших компаниях разработчики объединяются в несколько команд. В каждой команде может быть формальная должность тимлидера. В компаниях с большим количеством команд может работать формальный или неформальный тимлид тимлидов. Этот человек руководит лидерами команд.
По состоянию на конец февраля 2020 года на hh.ru тимлидов ищут как крупные и известные компании, так и небольшие региональные организации. Вот несколько компаний, которые публиковали объявления о поиске лидеров команд:
В конце февраля работодатели предлагают тимлидам от 160 000 до 340 000 рублей в месяц. На hh.ru в большей части вакансий для лидеров команд зарплата не указана.
Промежуточные итоги: тимлидеры нужны работодателям разного масштаба: от крупных компаний в Москве и Санкт-Петербурге до небольших организаций в регионах.
Какие требования предъявляют работодатели к кандидатам на позицию тимлида
В этом разделе пойдёт речь о хард- и софт-скилах, которыми должен обладать кандидат на должность лидера команды. Как вы помните, team lead работает на стыке разработки и менеджмента. Поэтому он должен хорошо разбираться в своём стэке, быть опытным программистом. Также лидер команды должен быть хорошим управленцем.
Вот обобщённые требования к кандидатам на позиции тимлида. Они составлены по итогам анализа опубликованных на hh.ru вакансий:
Практически во всех вакансиях упоминаются софт-скилы. Чаще всего встречается требование уметь общаться и организовывать коммуникации между членами команды. Вот другие софт-скилы, которые должны быть у кандидатов:
Промежуточный итог: работодатели видят на позиции team lead специалиста с сильной экспертизой в своём стэке. Также кандидат должен иметь опыт управления и мягкие навыки, необходимые для руководства командой.
Составьте свое первое резюме: Вы можете бесплатно опубликовать свое резюме в нашем сервисе «Хекслет-CV» и получить советы по его улучшению от разработчиков и HR-менеджеров
Слово профессионалам: чем занимаются тимлиды, как вырасти до этой должности, зачем новичкам нужно плотно общаться с лидером команды
Попросили действующих тимлидеров рассказать об особенностях работы, карьерном росте и взаимодействии с командой.
Александр Шакун: начинающему в целом стоит стремиться быть «самым глупым в комнате»
О собеседнике: Александр Шакун, team Lead в osome.com, двигаю кнопки в стартапах с 2016 года.
Дмитрий Дементий: Какую роль в профессиональной жизни начинающего разработчика играет тимлид? Или перефразирую: почему стажёру или джуниору надо плотно общаться и дружить в профессиональном плане с тимлидом?
Александр Шакун: Не уверен, что могу тут поделиться каким-то уникальным опытом, я никогда не был тимлидом в командах с начинающими разработчиками. Думаю что начинающему в целом стоит стремиться быть «самым глупым в комнате» и общаться со всеми, кто рядом, набираться опыта.
Свою задачу вижу в том, чтобы стать максимально ненужным. Буду считать свою миссию выполненной, когда все члены команды будут достаточно прокачаны, чтобы:
Конечно для тимлида к этому добавляется некоторое количество административных обязанностей, таких как наём и мотивация, эти вещи остаются на мне.
Д. Д.: Как разработчики вырастают до должности тимлида: что они изучают, что делают для того, чтобы достигнуть этой карьерной ступени?
А. Ш.: Понятия не имею, никогда к этому не стремился. Пришёл на новую работу, начал делать задачки. Формировалась команда под новый продукт, меня определили в неё. Надо было работать много, быстро и качественно. У меня получалось.
Моё поведение, моё представление о работе не меняется в зависимости от того, тимлид я или нет. Стараюсь делать задачи быстро, не жертвуя при этом качеством. Стараюсь интересоваться продуктом: что, зачем и для кого мы делаем. Готов работать на любой части проекта, где нужен. Ладно, лендосы, пожалуй, верстать не готов.
Д. Д.: Должность тимлида кому-то подходит, кому-то не подходит. Как человеку понять, что в будущем из него получится хороший тимлид, и что можно и нужно стремиться к этой роли?
А. Ш.: Тут я сошлюсь на опыт своих гораздо более опытных знакомых, занимавших позиции тимлидов и руководителей разработки. Важно иметь эмпатию, балансировать между качеством технической реализации и скоростью поставки продуктовых фич, уделять внимание членам команды, их желаниям, помогать их развитию. И в тоже время вовремя расстаться тоже важно.
Д. Д.: Тимлид нужен в любой команде, или где-то можно обойтись без этого специалиста? Возможно, роль тимлида может сыграть какой-то другой сотрудник?
А. Ш.: В идеале здорово, когда члены команды одинаково сильно вовлечены и помогают компании двигаться вперед. Зачастую так не бывает, у людей могут быть разные интересы и разные стремления. Это нормально. В такой ситуации полезно, когда есть человек, который собирает разрозненные мнения воедино, помогает команде сфокусироваться и достичь цели. Может быть, его назовут тимлидом, может быть нет 🙂
Д. Д.: Тимлид — больше менеджер-организатор или разработчик с глубокой экспертизой? На что больше тратит времени тимлид: на работу с кодом или общение с другими программистами?
А. Ш.: Я думаю, что нет универсального ответа. В разные этапы развития команды тимлид может быть и разработчиком, и организатором, и арбитром, и проводником в разных соотношениях.
Д. Д.: Есть ли у вас как у тимлидера пожелания к будущим джуниорам или советы? Каким должен быть джун, чтобы вы его взяли на работу?
А. Ш.: Мы не нанимаем джунов, так что на второй вопрос не могу ответить. Что касается советов, то я тут не открою никаких тайн. Будьте готовы много работать, будьте готовы брать на себя ответственность, умейте радоваться победам и делать выводы из поражений 🙂
Виталий Прокурат: у джуна в первую очередь должен быть интерес к работе
О собеседнике: Прокурат Виталий, team Lead в Минском центре разработки компании Wargaming. Больше 10 лет опыта в веб-разработке.
Дмитрий Дементий: Какую роль в профессиональной жизни начинающего разработчика играет тимлид? Или перефразирую: почему стажёру или джуниору надо плотно общаться и дружить в профессиональном плане с тимлидом?
Виталий Прокурат: Тимлид в жизни начинающего разработчика играет роль ментора. Следит за уровнем сложности задач с которыми работает джун. Даёт своевременную обратную связь об успехах или неудачах. Помогает джуну разобраться с рабочими вопросами. Советует, какую литературу почитать: книги или ссылки на статьи по профильной теме.
Интерес тимлида в том, чтобы джун как можно быстрее разобрался в проекте и вышел на приемлемый уровень задач, которые он может делать самостоятельно. Это может быть баг-фикс, какие-то инфраструктурные задачи, связанные с мониторингом приложения или логированием. Также уверенная работа над задачами, в которых хорошо проработаны требования и понятно, что делать.
При взаимодействии с тимлидом начинающему разработчику стоит также давать обратную связь: сообщать, что у него получается хорошо, а что не очень. Какого типа задачи нравятся больше. Это общение позволит джуну быстрее развиваться и быстрее закрывать пробелы в знаниях, а тимлиду позволит быстрее ориентироваться в том, как построить процесс обучения и развития.
На самом деле, взаимодействие с тимлидом полезно не только начинающим разработчикам, но и разработчикам уровня middle и senior.
Д. Д.: Как разработчики вырастают до должности тимлида: что они изучают, что делают для того, чтобы достигнуть этой карьерной ступени?
В. П.: Для того, чтобы стать тимлидом, разработчику нужно развить в себе менеджерскую оставляющую. Научиться часто переключаться с одной задачи на другую. Научиться распределять и планировать свое время. Уметь просто «на пальцах» объяснить, как работает та или иная функциональность.
Сейчас существует большое количество тренингов. По people-менеджменту, тайм-менеджменту, стресс-менеджменту, конфликт-менеджменту и прочие. Разработчику нужно прикинуть свои сильные и слабые стороны и посетить какой-либо тренинг. Как правило, это занимает не так много времени: в среднем от одного до нескольких дней. В некоторых компаниях, особенно в крупных, есть обучение и развитие сотрудников. Рекомендую им воспользоваться.
Могут помочь не только тренинги, но и профильные конференции. Нужно посмотреть несколько топовых докладов с конференции TeamLeadConf, чтобы иметь представление, с чем придётся столкнуться на позиции тимлида.
Д. Д.: Должность тимлида кому-то подходит, кому-то не подходит. Как человеку понять, что в будущем из него получится хороший тимлид, и что можно и нужно стремиться к этой роли?
В. П.: На самом деле, нужно просто пробовать. На текущей позиции стараться брать на себя больше ответственности, начинать вести задачи «под ключ». Это когда разработчик сопровождает задачу через все этапы. Анализ требований, проработка решения, разработка (написание кода), тестирование и релиз. Проделав несколько таких упражнений, нужно запросить обратную связь от коллег, от руководителя и менеджера проекта.
Вопросы которые могут в этом помочь:
Если отзывы положительные, всё хорошо. Может быть несколько отзывов, по которым можно понять, что нужно улучшать. Также разработчик на этом этапе может сам понять, подходит для него такая работа или нет.
Я сторонник постепенного погружения в новую роль. Когда легко можно вернуться обратно, если не получается или не нравится. Думаю, что «внезапные» назначения на роль тимлида разработчика, который к этому не готов, случаются очень редко.
Д. Д.: Тимлид нужен в любой команде, или где-то можно обойтись без этого специалиста? Возможно, роль тимлида может сыграть какой-то другой сотрудник?
В. П.: Я думаю, что в маленьких командах можно обойтись без выделенной должности тимлида. К примеру в команде из двух разработчиков и одного тестировщика. В этом случае один из двух разработчиков будет старшим разработчиком, и на него ляжет ответственность по принятию решений.
В команде, где три и более разработчиков, я считаю, нужен тимлид.
Д. Д.: Тимлид — больше менеджер-организатор или разработчик с глубокой экспертизой? На что больше тратит времени тимлид: на работу с кодом или общение с другими программистами?
В. П.: Большая часть времени уходит на общение с другими разработчиками:
Времени писать полноценный код нет, иногда есть возможность сделать какой-то прототип или исправить найденный баг.
Все же я считаю, что тимлид ближе к разработчику с глубокой экспертизой. Так как каждый день приходится сталкиваться с техническими вопросами, взвешивать варианты решения и выбирать, какой из них подойдет лучше. Следить за тем, чтобы в команде использовались одинаковые подходы для решения типовых задач. Есть конечно и менеджерские функции, но их меньше.
Д. Д.: Есть ли у вас как у тимлидера пожелания к будущим джуниорам или советы? Каким должен быть джун, чтобы вы его взяли на работу?
В. П.: Так как мы говорим о джуне, то ожидать наличие опыта работы и хороших знаний в предметной области не стоит. У джуна в первую очередь должен быть интерес к работе. Он должен хотеть научиться чему-то новому. При наличии этих двух качеств можно брать кандидата.
Многие компании проводят различного рода курсы или стажировки для новичков. Для компании это хороший способ отбора кандидатов. Так как есть несколько месяцев, на протяжении которых сотрудники компании работают с новичками и могут выбрать из группы тех, кто наиболее подходит. Новичкам же следует подготовится к таким курсам. Почитать теорию, попробовать что-то сделать самостоятельно, какой-то домашний проект. Это всегда будет плюсом как на собеседовании, так и при отборе на курсы.
Заключение: вырасти можно, но джуниорам придётся запастись терпением
Позицию тимлида занимают опытные разработчики, которые умеют управлять командами. Эта должность предполагает работу на стыке программирования и менеджмента. Если хотите дорасти до должности лидера команды, прокачивайте хард- и софт-скилы, учитесь общаться с другими сотрудниками, погружайтесь в бизнес-процессы и старайтесь разбираться в продуктах, над которыми работаете.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях