Как правильно пишется тимлид

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

Я стал искать информацию в интернете и, кажется, прочитал и просмотрел все, что на тот момент было в доступе о тимлидстве.

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

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

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

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

Эффективность измеряем здесь минимизацией трат времени, энергии и денег.

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

⛔Задачу можно выполнить быстро (в конце концов я могу сам ее выполнить и блокирнуть на это время все остальные).

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

✅Задачу можно выполнить эффективно.

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

Чем же фактически занимается тимлид. Функционал в разных командах может отличаться:

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

Так что делать, если ты хочешь стать тимлидом?

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

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

А какой тимлид у тебя?

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

Должность — тимлид

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

Откуда же появляется разное представление о должности тимлида?

ПРИМЕЧАНИЕ. Здесь и далее я говорю про тимлида только в рамках команды разработки. Догадываюсь, что многое из рассуждений распространяется и на другие команды, во многих видах деятельности.

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

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

ПРИМЕЧАНИЕ. Гиперответственностью я называю случай, когда человек чувствует себя ответственным за обстоятельства, влиять на которые полномочий не имеет. Я не пытаюсь вложить в это качество ни позитивного ни негативного оттенка, лишь констатирую, что в некоторых сотрудниках гиперответсвенность проявляется.

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

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

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

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

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

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

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

Что же конкретно тимлид должен делать?

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

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

Это и есть фронт работ тимлида.

Разберем, что с этим нужно делать.

Лидерство

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

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

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

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

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

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

ПРИМЕЧАНИЕ. Довольно часто несоответствие ответственности и полномочий проявляется в том, что тимлида не включают в процесс принятия решения о приеме кандидата, или не дают возможности исключить сотрудника из состава команды по инициативе тимлида. Притом ответственность за то, чтобы команда справлялась со своими задачами с тимлида никто не снимает. Вот она — вмененная гиперответственность.

В чем же здесь проявляется профессионализм тимлида?

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

Среди способов пополнения кадрами вижу принципиально два подхода:

1. Брать готовых специалистов с рынка труда.
2. Воспитывать кадры самостоятельно.

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

Что же может пойти не так?

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

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

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

Оценка работ

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

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

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

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

Настроения в команде

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

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

Также тимлиду следует соотносить характеры членов команды, если одного зануду команда переварит, то двух, возможно, уже и нет (ничего не имею против зануд, сам зануда еще тот).

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

Заключение

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

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

Интересует мнение разработчиков (в широком смысле — всех, кто работает в составе команд-разработчиков), тимлидов, линейных и проектных руководителей, согласны ли вы с такой декомпозицией роли тимлида? Есть ли у вас какие-либо замечания, дополнения?

Русский[править]

В Викиданных есть лексема тимлид (L170164).

Морфологические и синтаксические свойства[править]

падеж	ед. ч.	мн. ч.
Им.	тимли́д	тимли́ды
Р.	тимли́да	тимли́дов
Д.	тимли́ду	тимли́дам
В.	тимли́да	тимли́дов
Тв.	тимли́дом	тимли́дами
Пр.	тимли́де	тимли́дах

тим—ли́д

Существительное, одушевлённое, мужской род, 2-е склонение (тип склонения 1a по классификации А. А. Зализняка).

Корень: —.

Произношение[править]

• МФА: [tʲɪˈmlʲit]

Семантические свойства[править]

Значение[править]

1. ведущий член команды разработчиков, выполняющий помимо технических функций также менеджерские ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы[править]

Антонимы[править]

Гиперонимы[править]

Гипонимы[править]

Родственные слова[править]

Ближайшее родство

Этимология[править]

От англ. team lead.

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Список переводов

Библиография[править]

Для улучшения этой статьи желательно: Добавить описание морфемного состава с помощью {{морфо-ru}} Добавить пример словоупотребления для значения с помощью {{пример}} Добавить синонимы в секцию «Семантические свойства» Добавить гиперонимы в секцию «Семантические свойства» Добавить хотя бы один перевод в секцию «Перевод»

Всего найдено: 1

Здравствуйте! Скажите, пожалуйста, как правильно: тим-лидер или тимлидер и допустимо ли написание сокращенной формы: тим-лид или тимлид? Заранее благодарю за ответ.

Ответ справочной службы русского языка

Это новые заимствования, и они находятся еще в стадии освоения языком. Именно по этой причине словарями эти слова еще не зафиксированы. Для их дефисного написания оснований нет, поэтому представляется корректным слитное написание: тимлидер и тимлид. Ср. со словом тимбилдинг, кодифицированным в «Русском орфографическом словаре» под ред. В. В. Лопатина и О. Е. Ивановой (4-е изд. М., 2012).  

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

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

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

Обязанности тимлида

В IT-сфере с каждым годом появляются все новые и новые направления – тимлид, техлид, devrel, engineer-менеджер. Технические специалисты получают ещё больше возможностей для развития внутри выбранного профиля. В данной статье мы рассмотрим отличительные особенности тимлида (англ. team leader –руководитель группы). По большому счету, это роль, а не специальность. На место тимлида может встать бэкенд-разработчик, фронтенд-разработчик, QA-инженер.

Поговорим об основных нюансах взаимодействия тимлида с командой.

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

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

Скачать файл

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

Помимо этого, задачами тимлида являются:

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

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

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

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

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

Необходимые компетенции

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

Жесткие навыки

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

Плюс ко всему, он имеет представление о смежных сферах: DevOps, тестирование, архитектура и т.д.

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

Мягкие навыки

Разделим данную категорию навыков на несколько подгрупп:

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

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

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

Алгоритм прокачки навыков

Изучение теории

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

Говоря об учебных материалах, нельзя не отметить книгу «От разработчика до руководителя», которую написал бывший вице-президент Goldman Sachs Камиль Фурнье. Это одно из важнейших пособий для тимлида в сфере IT.

Рекомендуется также ознакомиться с произведением Марины Перескоковой, которая ранее являлась сотрудницей Яндекса, под названием «Мама, я тимлид». Отметим и «Сложные подчиненные» под авторством Максима Батырева. В данной книге вы найдете множество практик отечественных руководителей. На похожую тему был написан еще один труд – «Как пасти котов» (в профессиональной среде котами называют программистов).

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

Практическая работа

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

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

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

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

Путь к должности тимлида в компании

Если все сложится хорошо, то путь будет следующим: Стажер – Джуниор – Мидл – Сеньор – Тимлид. Однако на практике могут возникнуть различные трудности.

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

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

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

Роль тимлида может взять и менеджер, знающий нюансы взаимодействия с клиентами. Однако такое развитие событий, как правило, приводит к провалу. Дело в том, что менеджер не знает тонкостей разработки и, следовательно, не может объективно оценить объем работы, правильно распределив задачи между членами команды.

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

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

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

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

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

Примерная зарплата тимлида в 2023 году

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

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

Рассматривая уровень их заработной платы, стоит отметить, что речь идет о целом ряде специализаций: ‘TeamLead разработки’, ‘TeamLead (Python)’, ‘TeamLead (Java)’, ‘TeamLead (JavaScript)’, ‘TeamLead (PHP)’, ‘TeamLead (C#)’, ‘TeamLead (Golang)’, ‘Backend TeamLead’, ‘Frontend TeamLead’, ‘DevOps TeamLead’ и т.д.

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

К примеру, для Свердловской области он ниже – 161 000 рублей. В Краснодарском крае тимлиды получают около 195 000, в Санкт-Петербурге – 359 000, В Москве – 288 000, а в Новосибирской области – 262 000.

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

Сложности в работе тимлидом

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

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

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

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

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

Андрей Ефремов

Руководитель центра компетенции разработки в Центре Big Data компании МТС Диджитал

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

Чем занимается тимлид

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

Обязанностей и ролей у тимлида много. Но условно их можно разделить на несколько частей.

Первая — формирование своей команды: собеседования, технический онбординг, развитие своих сотрудников.

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

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

Наконец, тимлид выполняет роль координатора — например, между своей группой разработки и другими членами команды (тестировщиками, аналитиками, DevOps-инженерами).

В разных компаниях у тимлида могут быть разные обязанности и роли (я работал в месте, где тимлид совмещал свои обязанности с функциями техлида, архитектора и владельца продукта). Всё зависит от размера команды. Для группы от 5-7 человек точно нужен отдельный лид без дополнительных ролей.

Какие навыки нужны тимлиду

Хард скилы

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

Кроме того, он понимает смежные технические области — DevOps, тестирование, архитектуру и так далее (зависит от проекта). Хотя бы на базовом уровне. Почему это важно?

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

Софт скилы

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

Лидерство

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

Планирование и тайм-менеджмент

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

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

Мне для планирования нравится диаграмма Ганта. А для приоритизации — матрица Эйзенхауэра, вести которую можно в Excel. Но можно использовать Jira, Trello, Google календарь — всё зависит от личных предпочтений.

Коммуникативные навыки

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

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

Эмпатия и рациональность

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

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

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

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

Приведу пример из своей практики. В нашу команду пришёл новый разработчик, сильный и опытный. Я поручил ему разработать сервис. Но он не выполнил задачу в срок, объяснив проблему и сказав, что со всем разобрался и скоро закончит.

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

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

Как всё это прокачивать

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

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

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

1. Выписываю все компетенции, которые мне нужно изучить.
2. Определяю текущий уровень владения каждой и указываю приоритетность — насколько она мне важна.
3. Описываю действия, которые нужно выполнить, чтобы освоить компетенцию.
4. Ставлю дедлайн.

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

Получается такая таблица:

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

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

Сперва нужно дорасти минимум до ведущего специалиста и начать развивать технические знания вширь: изучать архитектуру, тестирование, DevOps и так далее.

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

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

Следующий этап — брать на себя ответственность за общий результат и сопровождать разработку на всех этапах жизненного цикла.

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

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

Вместо вывода

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

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

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

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

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

А что, по вашему мнению, должен уметь тимлид? Делитесь мнениями в комментариях.

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

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

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

1

Чем занимается тимлид

Тимлид руководит командой разработчиков. Обычно он не пишет код (хотя может). Обычно он не думает об архитектуре (хотя может). 

Тимлид:

• Общается с клиентами или бизнес-подразделениями компании.

• Оценивает задачи, сроки каждого этапа, разбивает их на спринты.

• Распределяет нагрузку между разработчиками.

• Следит за тем, чтобы таски закрывались в срок.

• Оценивает решения разработчиков, дает рекомендации. 

• Согласует с заказчиком готовую работу.

Тимлид несет ответственность за проект. Сроки сорваны – виноват тимлид. Хотите добавить еще фичи – разговаривайте с тимлидом (он скажет, что этот спринт уже заблокирован, но, возможно, в следующем возьмутся за вашу фичу – если сможете ее «продать»).

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

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

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

2

Какие навыки нужны тимлиду

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

• Опыт работы от 3-5 лет – и желательно, чтобы он включал опыт руководства хотя бы небольшой командой.

• Опыт проведения код-ревью, менторинга – потому что придется помогать другим разработчикам, подтягивать джуниоров.

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

• Аналитические способности и критическое мышление – для правильной оценки сложности задачи, расстановки приоритетов.

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

• Знание HR – нужно разбираться в кадровой политике, потому что точно придется участвовать в формировании команды и наборе сотрудников.

• Умение мотивировать сотрудников – и вообще общаться с людьми, в том числе предотвращать конфликты.

• Тайм-менеджмент – для выставления реальных сроков решения задач.

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

3

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

В идеальном представлении путь до тимлида выглядит так: Стажер – Джуниор – Мидл – Сеньор – Тимлид.

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

• Если компания большая, а проекты сложные, то стать тимлидом с позиции мидла будет сложно – не хватит экспертности для оценки проекта. Сеньор с прокачанными soft skills в таком случае – идеальный кандидат.
• Обратный пример – стартап или небольшая компания. Здесь тимлидом легко можно стать с позиции мидла. Например, человек работал один, понадобилось расширение, его навыков оказалось достаточно для найма новых разработчиков и настройки рабочего процесса. Был мидлом – стал тимлидом.
• В маленьких командах может не быть формального тимлида. Но если в комнате собрались больше двух разработчиков, которые работают над одним продуктом, то один из них все равно должен быть старшим – тем, на кого ляжет ответственность по принятию решений.

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

4

Чему нужно научиться, чтобы стать тимлидом

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

• переключаться между разными задачами,

• делегировать обязанности,

• распределять нагрузку между членами команды,

• общаться с бизнесом.

Единственный способ понять, сможете ли вы быть тимлидом, – попробовать. Брать на себя больше ответственности, выполнять задачи «под ключ», чаще общаться с продакт-менеджерами, клиентами и бизнес-подразделениями компании, чтобы развить в себе продуктовое мышление.

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

А теперь пришло время для небольшого теста! 

Быть или не быть, вот в чем вопрос… Все о жизни в IT без прикрас.

Рекомендуем