Менеджмент и Управление 02.08.2020

Тимлид: что это за профессия, обязанности специалиста, зарплата

20 мин.

Кто такой Team Lead в команде разработчиков?

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

Зачем нужны тимлиды

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

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

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

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

Где работают и сколько зарабатывают тимлиды

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

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

По состоянию на конец февраля 2020 года на hh.ru тимлидов ищут как крупные и известные компании, так и небольшие региональные организации. Вот несколько компаний, которые публиковали объявления о поиске лидеров команд:

  • Mindbox.
  • Эквид.
  • BeeJee.
  • Carbon Soft.
  • BestDoctor.

Тимлиды нужны как в крупные, так и небольшие компании

В конце февраля работодатели предлагают тимлидам от 160 000 до 340 000 рублей в месяц. На hh.ru в большей части вакансий для лидеров команд зарплата не указана.

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

История профессии

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

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

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

Особенности профессии

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

Team leader нужен в банках, крупных компаниях, занимающихся финансами и брокерством, корпорациях.

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

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

Обязанности

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

  • Заключение договора с клиентом, обсуждение всех деталей, поиск компромисса.
  • Работа с договорами, различной документацией.
  • Производить оценку обьемов и масштаба работ, бюджета, сроков выполнения работ.
  • Расставление приоритетов, планирование больших и маленьких задач.
  • Делегирование полномочий внутри коллектива таким образом, чтобы получить максимальную эффективность.
  • Планирование релизов и своевременный их выпуск.
  • Функции продюсера в управлении проектом, дизайнерские работы, грамотный маркетинг, разработка.
  • Общительность, и налаживание контактов с каждым сотрудником, мотивирование персонала, обеспечение профессионального роста каждого.
  • Мотивация, нужно показывать все на своем примере, быть образцом для своих сотрудников.
  • Умение переделать бизнес-идею руководства в техническое задание для разработчиков.
  • Ответственность за качество проекта, технологию его реализации.
  • Написание ревью кода.
  • Тестирование, проверка проекта, разработка его дизайна.
  • Уметь понять и разобраться в поломке, при надобности – усовершенствовать проект.
  • Написание технической документации.
  • Участие в процессе формирования команды.
  • Программирование архитектуры.
  • Выбор наиболее подходящей и эффективной технологии для рабочего задания.
  • Обьяснение общих идей каждому сотруднику команды.
  • Выбор исполнителя из команды, подходящего для определенной задачи.
  • Выгружать изменения на сервер.
  • Обмен опытом между членами команды, с целью повышения эффективности, понимания и навыков.
  • Оптимизация работы, проведение внутрикомандных совещаний.
  • Ведение отчетов перед заказчиками в течении всего этапа проведения работа.
  • Контролировать проект на предмет его соответствия заданным техническим параметрам.
  • Оценка и поддержка предложений от других участников проекта.

Личностные качества:

  • Аналитический состав ума
  • Ответственность
  • Пунктуальность
  • Трудолюбие
  • Дипломатичность
  • Инициативность
  • Нахождение простых способов решения сложных заданий
  • Техническая грамотность (владение серверными технологиями и дистрибутивами)
  • Нацеленность на результат
  • Быстрое принятие решений в сложных ситуациях.

Чем тимлид отличается от сеньора и других программистов

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

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

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

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

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

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

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

Для этого нужно, чтобы:

  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. Потому что он прост, определен вплоть до мелочей и довольно хорошо работает даже без адаптации под команду и организацию.

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

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

Как им стать

Как правило, тимлиды — это бывшие сеньоры.

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

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

Кроме своей области программирования тимлид должен знать и уметь:

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

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

Сколько зарабатывает тимлид

Мы посмотрели зарплаты тимлидов в разных направлениях на начало 2020 года и вот что выяснили:

  • Фронтенд — 208 тысяч .
  • Бэкенд-разработка — 188 тысяч .
  • Фулстек — 172 тысячи .
  • Десктоп-разработка — 216 тысяч .
  • Разработка мобильных приложений — 228 тысяч .

Профессиональный рост в IT

Рассмотрим типичную IT-компанию. Как и в других отраслях, здесь возможен рост «по горизонтали» и «по вертикали».

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

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

Это — обычная схема профессионального роста:

  1. junior developer
    (специалист начального уровня);
  2. middle developer
    (специалист среднего уровня);
  3. senior developer
    (специалист высокого уровня);
  4. technical leader
    (технический лидер);
  5. team leader
    (лидер команды).

Иногда выделяют дополнительные промежуточные ступени, например junior+ (это джун, который совсем чуть-чуть не дотягивает до миддла).

Стать тимлидом можно и раньше — со ступени middle-разработчика.

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

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

Личные качества тимлида

Сергей, старший инженер и партнёр kt.team

«Будущего тимлида видно сразу: это открытые, общительные люди. Месяц назад в нашу команду пришёл новый senior-разработчик, и я уже вижу — он будет хорошим тимлидом.
Важное качество такого человека: самостоятельность одновременно с умением работать в команде. Будущие тимлиды могут сами решить мелкие проблемы и не беспокоят других по пустякам. При необходимости могут сами собрать нужные данные, запросив их у коллег или проект-менеджера, задать правильные вопросы.
При этом у них развито чувство ответственности — им можно доверить задачу и „забыть”, они не подведут».

По версии LinkedIn, главные soft skills 2019 года:

  • креативность;
  • умение убеждать;
  • умение сотрудничать;
  • адаптивность;
  • умение управлять временем.

Это касается не только разработчиков: в списке учтён спрос на навыки самых высокооплачиваемых специалистов.

Плюсы и минусы

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

  • Универсальность, приобретение навыков администратора.
  • Высокая оплата.
  • Высокая востребованность.

К минусам:

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

  • https://javarush.ru/groups/posts/2815-kapitan-koderskoy-komandih-i-glavnihy-reshaljhjshik-kto-takoy-team-lead-i-chto-on-delaet
  • https://thecode.media/teamlead/
  • https://ru.hexlet.io/blog/posts/kto-takoy-timlid-i-kak-vyrasti-do-etoy-dolzhnosti
  • https://profitworks.com.ua/professii/professii-v-it-sfere/team-leader
  • https://delai-vibor.com/timlid.html
  • https://habr.com/ru/post/269097/
  • https://zen.yandex.ru/media/code/kto-takoi-timlid-on-je-lead-5ef90a056ca51851535cd499
  • https://zen.yandex.ru/media/id/5de8a5395d636200b075e410/iz-djuniora-v-timlida-kak-uspeshno-razvivatsia-v-it-5dea51d2f73d9d00ae93dc0a
[свернуть]
Оцените статью
Понравилась статья?
Комментарии (0)
Комментариев нет, будьте первым кто его оставит

Комментарии закрыты.