Особенности задач тимлида, или Что именно значит «управлять командой»

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

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

Привет! Меня зовут Вячеслав Бенедичук, я наставник на курсе «Архитектура программного обеспечения» в Яндекс Практикуме. В IT я уже более 25 лет, из них суммарно более восьми лет я занимался управлением командами на различном уровне. Я решил систематизировать свой опыт в формате статей, и это первая публикация из цикла о работе тимлида.


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

Немного контекста: в бизнесе есть два ключевых направления карьеры: individual contributor (индивидуальный исполнитель) и manager (управляющий).

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

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

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

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

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

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

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

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

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

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

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

Подбор и адаптация персонала

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

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

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

Планирование работ и распределение задач

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

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

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

Мотивация и стимулирование

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

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

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

Это требует развитых софтскилов, а также различных инструментов и шпаргалок.

Самый сильный инструмент —- прямой разговор 1:1 с сотрудником. И это не шутка. Встречи 1:1 позволяют понять, чем дышит команда, какие проблемы возникают у сотрудников. Они позволяют построить доверительные отношения и дают людям возможность рассказать в частном порядке то, о чём они не сказали бы публично на командной встрече.

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

Коммуникация

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

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

Люди по-разному реагируют на трудности: кто-то сразу задаст вопрос и решит проблему за 10 минут, а кто-то может потратить на неё часы или даже дни. Задача тимлида — выстроить культуру открытого общения, чтобы никто не боялся обращаться за помощью.

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

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

Ещё одна важная роль тимлида — представлять команду в коммуникациях с другими подразделениями. В крупных проектах, где задействовано несколько команд, он может участвовать в Scrum of Scrums, синхронизировать работу с другими отделами и помогать команде взаимодействовать с бизнесом. Кроме того, тимлид часто берёт на себя часть задач системного аналитика — собирает и уточняет требования заказчиков, а затем передаёт их в команду.

Координация и контроль

План составлен, задачи распределены, команда замотивирована, атмосфера доверительная. Казалось бы, всё уже прекрасно. Но возникает ряд важных вопросов: «В каком состоянии сейчас находятся работы по проекту? Какие задачи выполнены, какие нет? Достаточно ли качество? Попадаем ли мы в сроки? Если нет, то почему и что с этим можно сделать?»

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

Оперативное управление работой, контроль за текущим статусом задач, оценка результатов, обратная связь и корректирующие действия — это всё зона ответственности тимлида. 

Развитие и обучение

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

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

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

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

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

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


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

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

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

@vbenedichuk
21.03.2025 12:01 UTC
Первоисточник

Комментарии

@dkfbm
21.03.2025 11:34 UTC
0

В целом толково, но вот с этим я бы поспорил:

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

С каких пор ПМ – должность без подчинённых? Может, и существуют такие структуры, но мне до сих пор не встречались. В частности, те самые тимлиды в норме и есть подчинённые ПМ.

@vbenedichuk
21.03.2025 13:22 UTC
+4

Привет.

Это не совсем так.
Проектный менеджер и тимлид это роли. Они могут пересекаться, но чаще нет.
Так же нужно разделять функциональное и проектное управление.
Тимлидом/непосредственным руководителем для тимлида в разработке обычно является руководитель подразделения к которому он относится (Lead Backend, CTO и т.д.)

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

Существуют варианты, когда ПМ выполняет роль тимлида. Это называется проектной оргструктурой (не путать с проектной организацией работы).
Она в основном характерна для консалтинговых компаний, в которых ПМ собирает команду контракторов под проект.

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


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

При этом, в ветке ПМов есть свои тимлиды, обычно это CPO или Lead PM. У них есть подчиненные.

21.03.2025 13:44 UTC
0

Это не совсем так.

Видимо, где как. Я в качестве ПМ проработал лет 25 – и всегда тимлиды были в моём непосредственном подчинении, я их сам подбирал, сам назначал з/п, потом ставил задачи, контролировал исполнение и т.д. Речь о долгосрочных проектах.

21.03.2025 14:17 UTC
+1

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

@zuekliza
22.03.2025 22:57 UTC
+1

Я ПМ уже 7 лет, за это время 3 компании сменила - везде была как самостоятельная единица без подчинённых. На последнем месте вообще матричная орг структура, некоторые Лиды исполняли роль чисто согласовать заявку на доступ и подтвердить таймшит в системе, и особо не в курсе были, чем человек на проекте занимается. Таких лидов я привлекала только в случае решения каких-то орг моментов (например если есть проблемы с человеком или нужно было привлечь для решения конфликтный ситуации где мои компетенции заканчивались).

@ZoRDoK
21.03.2025 14:10 UTC
+2

Я встречал в основном варианты, когда номинальным "начальником" выступает всё же ПМ. А ТЛ – первый среди равных. При наличии обеих ролей ПМ – точка входа для менеджмента, бизнеса, менее "технических" интересантов, других ПМ. А ТЛ – для архитекторов, программистов из других отделов. Отчего обязанности и ожидания разнятся от компании к компании. Хотелось бы в статье увидеть эту роль более очерченной, но увы, много реверансов в сторону "эти обязанности разделяются с ПМ, но на более высоком уровне" и без конкретики, об этом самом уровне. Еще сложнее получается с появлением техлидов, но это отдельная история.

@vbenedichuk
21.03.2025 14:25 UTC
+1

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

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

@
24.03.2025 08:14 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
@DenisTrunin
25.03.2025 16:20 UTC
0

Удовольствие же доставляет написание "правильного" кода. И в этом же самая идея, что становясь тимлидом можно влиять на написание кода другими людьми и допустим внедрять практики которые нравятся вам конкретно, делая код более "правильным". Как бонус - еще и брать часть интерестных задач для себя(в большинстве компаний думаю от тим лида будут требовать 50 на 50 загрузки менеджер-исполнитель).

Вообще в статье бы неплохо упомянуть Teamlead Roadmap, по сути то там более полное описание https://tlroadmap.io/

25.03.2025 16:28 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
25.03.2025 16:52 UTC
0

Поверьте, у принципала это получается ничуть не хуже.

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

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

25.03.2025 17:19 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
@arcmon
24.03.2025 09:32 UTC
+2

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

@vbenedichuk
24.03.2025 09:39 UTC
0

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

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

@kimisa
25.03.2025 07:35 UTC
0

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

@DenisTrunin
25.03.2025 16:29 UTC
0

Кстати вопрос, за 8 лет работы, делали ли вы коммиты в Тимлид роадмап и использовали ли его сами? https://github.com/tlbootcamp/tlroadmap

@try1975
28.03.2025 18:04 UTC
-1

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