Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Карьера в IT: должность Team Lead

Rubber ducks image via Shutterstock.

Данный материал открывает цикл «Карьера в IT», посвященный описанию разных профессий внутри сферы разработки ПО. В этот статье мы поговорим о первой пост-сеньоровской ступеньке IT-карьеры — позиции team lead.

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

По статистике ДОУ, средний возраст украинских тимлидов — 28 лет, средний опыт работы — 6,5 лет, средняя зарплата — $2800.

Обязанности

Тимлид — это нечто среднее между проектным менеджером и квалифицированным девелопером.

На проектах есть две lead роли: менеджерская — PM, и техническая — System Architect. Тимлид отчасти выполняет обе роли, но акцент его обязанностей направлен на менеджмент (акцент на техническую часть — это tech lead).

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

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

Под техническую роль: участие в написании технической документации, выбор технологий для проекта, разработка архитектуры, R&D, code review, менторинг джуниоров, проведение технических собеседований, грамотное вовлечение новых членов команды в рабочий процесс, ответственность за техническую часть проекта.

Типичный рабочий день тимлида включает в себя:
· рассмотрение новых задач и их распределение
· стендап с командой
· митинги
· программирование
· архитектурные вопросы
· code review

«70% — организационные вопросы и коммуникация, 30% — непосредственно технические вопросы».
«Написание кода — мало. Чтение кода — много».

Достоинства и недостатки

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

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

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

«Ответственность не всегда соответствует полномочиям и инструментарию».

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

Как стать тимлидом и куда идти дальше?

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

Ключевые качества: трудолюбие, ответственность, проактивность, общительность, пунктуальность.

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

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

Если говорить о конкретных цифрах, то среди 1822 бывших украинских тимлидов база данных LinkedIn находит 852 проектных менеджеров и 346 системных архитекторов.

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

P.S. Отдельное спасибо за помощь в написание статьи 8 украинским тимлидам, которые поделились с DOU таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.



Остальные статьи цикла:
Карьера в IT: должность Software Architect
Карьера в IT: должность Project Manager
Карьера в IT: должность CTO
Карьера в IT: должность QA engineer
Карьера в IT: должность QA Automation engineer
Карьера в IT: должность Бизнес-аналитик
Карьера в IT: должность Системный администратор
Карьера в IT: должность Data Scientist / Machine Learning Engineer
Карьера в IT: должность Technical Writer
Карьера в IT: должность Delivery Manager
Карьера в IT: должность Software Product Manager

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному8
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Суть тим лида (отбрасывая «лидов», которые получили титул за выслугу лет или просто потому, что умненькие) — это то, что раньше ты отвечал за себя-хорошего, и всех интересовали ТВОИ личные знания и навыки. А тут резко речь начинает идти не о тебе, а о твоей команде. И судить о тебе будут по результатам команды, а не твоим собственным. Как твои люди работают, какой у них перформанс, какая квалификация и т.д. И что ты «торчишь» уже не за себя, а за других людей, которые тебе могут даже не нравится, но все равно ты за них отвечаешь. И процесс ты им должен ставить, и отношение к работе прививать, и за лажу бить по рукам. Быть просто «умненьким» тут недостаточно. Нужно быть лидером, иметь свое мнение и уметь это мнение доводить до других (а зачастую — навязывать). Уметь коммуницировать в команде и с заказчиком за всю команду. Уметь брать на себя ответственность. И при этом быть экспертом в технической области, авторитетом для членов команды.
Это совсем не просто, если по-честному, а не «за выслугу лет». И именно поэтому тим-лиды получают лучше «чистых» менеджеров аналогичного ранга.

120 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Раз уж некрокомментируют, то добавлю 5 копеек:

1. Не надо путать team lead и tech lead.
Team lead скорее административное, чем техническое. И лестницы этих двух направлений карьеры вообще-то параллельны.
Советский подход, когда лучшего учёного ставят ректором, или лучшего врача — главврачом, и они убивают свои карьеры административными проблемами — давно неадекватен.
И этими двумя не ограничиваются — у аналитиков или у PO свои лестницы.

2. Team lead в плане распределителя задач с обратной связью лучше получается из QA (и является закономерным продолжением карьеры из QA), чем из программиста. Программисту лучше действительно идти в суперэксперты или архитекторы.

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

как эти 2 предложения вообще оказались рядом? ты забыл о чем писал?

ты забыл о чем писал?

Нет.

как эти 2 предложения вообще оказались рядом?

Что тебе непонятно?

Статья на 3-ку. Еле еле раскрывает эту должность. 8 тим-лидов поделелились с DOU таинствами своей профессии — что за вранье. В статье нет информации указывающей на это

У кого-то был опыт ухода с пути менеджера на тех путь обратно, например с Engineering manager, VP, CTO, Head, Director назад в Tech Lead, Staff, Principal, Architect?
Очень было бы интересно узнать подробности.

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

Ответственность не всегда соответствует полномочиям и инструментарию
это беда — прогибы и перегибы.

Суть тим лида (отбрасывая «лидов», которые получили титул за выслугу лет или просто потому, что умненькие) — это то, что раньше ты отвечал за себя-хорошего, и всех интересовали ТВОИ личные знания и навыки. А тут резко речь начинает идти не о тебе, а о твоей команде. И судить о тебе будут по результатам команды, а не твоим собственным. Как твои люди работают, какой у них перформанс, какая квалификация и т.д. И что ты «торчишь» уже не за себя, а за других людей, которые тебе могут даже не нравится, но все равно ты за них отвечаешь. И процесс ты им должен ставить, и отношение к работе прививать, и за лажу бить по рукам. Быть просто «умненьким» тут недостаточно. Нужно быть лидером, иметь свое мнение и уметь это мнение доводить до других (а зачастую — навязывать). Уметь коммуницировать в команде и с заказчиком за всю команду. Уметь брать на себя ответственность. И при этом быть экспертом в технической области, авторитетом для членов команды.
Это совсем не просто, если по-честному, а не «за выслугу лет». И именно поэтому тим-лиды получают лучше «чистых» менеджеров аналогичного ранга.

(а зачастую — навязывать)
Это уже не «лидер» — это «насяльника аднака».

А кто сказал, что лид — это просто и весело?
Он и есть насяльника, мы же не в песочке играем и не в квест бегаем. Ему за это как бы деньги платят ;-),

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

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

Важно понимать: есть люди, которым можно передать понимание. Этим — достаточно просто дать именно понимание, их не надо гнуть и ломать. Если не умеете дать понимание — вы не на своем месте. Эти люди хорошо видны. А есть люди, которые не понимают. Эти точно так же хорошо видны. И нам с ними не по пути — от таких лучше избавляться на всех этапах от джуна до архитектора. Другой вопрос, что при встрече таких людей уже на ролях «я — насяльника!» — а на этих ролях они также обязательно встречаются. Здесь уже надо решать, вести с ними дело или нет. Но это уже совсем другая история.

А «вдохновлять и мотивировать» всех надо. Просто мотивация — у всех разная. Точнее, здесь рассмотрены две самые основные группы. Каждому своё. (к)

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

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

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

Дійсно цікаво про таке почитати. Краще на таке не підписуватись. Ідеальна роль — це буде Тех-лід. Те ж саме, але із акцентом на девелопмент. Менеджмент тут нікого не цікавить.

А взагалі дуже цікаво було почитати — аффтар піші єщьо =)
Серйозно.

окей, аффтар сегодня же выходит с творческого кризиса и идет писать про architect..)

Как то однобоко получилось. Самих «лидов» спросили, что они о себе красивых думают. А вот мнение простых трудовых обывателей забыли. Пусть бы они высказали все что думают :)

по сути написанного — к моему сожалению, те Team Lead которые были опрошены, самого главного в своих обязанностях и не назвали! но я верю в лучшее ...

И что по Вашем мнению самое важное?

Самое вожное, Егор, чтобы стать тим лидом — нужно чтобы были люди, которые хотят, прям мечтают, чтобы ты (именно ты) их лидил. :-)
Найдете таких людей — будете лидом. Не найдете — не будете. :-)
Все, в принципе, несложно.

Самое вожное, Егор, чтобы стать тим лидом — нужно чтобы были люди, которые хотят, прям мечтают, чтобы ты (именно ты) их лидил. :-)
Не путайте лидера и лида. То что вы написали относится к лидеру. А про лида следует сделать исправление:
нужно чтобы были люди, которые хотят, прям мечтают, чтобы ты __лидил команду которой они платят бабло__

Осталось найти по команде всем мечтающим о лидских погонах — и будет всем счастье :-)

Как будто кто-то хотел что бы ты руководил ими. Это твои работодатели захотели что бы ты принял управление на себя и поставили команду перед фактом. Ты так говоришь кто-то спрашивает сотрудников кого бы они хотели видеть своим руководителем. Сказали Шкурупий/Шкляров/Бойчук берем Скокова на должность ПМ’а вот и стал ты пм’ом.

Вот так вот взяли, и прям сказали! :-) А я вот, раз сказали — так сразу годным ПМ-мом и стал...
Троллю, чо. ;-)

У Вас, либо описание Dev Lead, а не Team Lead, либо уберите «программирование \ писание кода \ и тд тп» из прямых обязанностей.

Имеется в виду Team Lead команды девелоперов

И Вы считаете он должен быть обязательно разработчиком?

Team Lead команды девелоперов — да
соответственно, Team Lead команды QA — тестировщиком

в Украине нет чётких официальных формализаций этих должностей, но тут подразумевалось именно это.

Не соглашусь... Но, статья Ваша — Вам и карты в руки :)
Было бы неплохо оговорить в статье что это случай для Dev team и что Lead из разработчиков :)

по идее, у QA тоже самое, за исключением программирования?

Если строго делить на команды Dev и QA с лидами, вышедшими из этих команд, то да. Но зачастую бывают и миксы... QA, например, может руководить командой разработчиков и тестеровщиков. Я бы в статье обобщил, что Lead выполняет задачи по своей специализации: Dev — программирование, ревью кода, архитектура и т.д., а QA — тестирование, процессы и т.п.
Но опять же, бывают и еще более страшные миксы, так как многие IT-шники становятся совсем универсальными и могут выполнять что угодно :) ... Скорее всего все зависит от компании, ее уставов, размера проекта и размера команды.

Team Lead команды девелоперов
Team Lead команды QA

А ничего, что разработчики и тестировщики составляют единую проектную команду? ;) А два тим лида в одной команде — это, примерно, то же самое, что и две женщины на одной кухне ))

единую проектную команду?
С чего это вдруг?
А два тим лида в одной команде
Да хоть с десяток. Зависит от размера команды. Если команда — 2 человека, включая самого «пупер-лида», а другой из которой — тот самый «единой команды QA» — даже здесь все равно каждый отвечает за свою часть работы и не лезет со своими «лидерскими качествами» на другую. А все общие вопросы решаются сообща по формально или негласно выработанным протоколам: привет скрам в виде ежедневного петтинга-только-никто-не-знает-что-и-зачем-там-делать-вообще.

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

Очень многие «лиды» очень быстро забывают, что главное в проекте — это проект, а не сам лид и даже не команда.

все общие вопросы решаются сообща по формально или негласно выработанным протоколам

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

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

Ну и менее клинических проявлений антагонизма «разработчики-тестировщики» при схеме dev lead / qa lead видел предостаточно

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

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

оспариваете саму цель как «много читал, но мало видел, зато видел обратное»

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

Например, вы пишете:

На основании чего было решено, якобы это таки «лиды»? По лычкам, выданным насяльника

вероятно, намекая при этом, что по хорошим делам «лычки» должны были достаться людям с соответствующим уровнем зрелости, soft skills и т.п.

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

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

Одно другому не противоречит, если я правильно понимаю? Хотят — действительно, многие, а вот могут — далеко не все из них. И, наверное, есть и такие, кто могут, но не хотят :)

дополнить еще и синергетическим эффектом от «а также _достаточного_ количества людей, желающих чтобы лидами становились конкретные люди, а не вообще»

Если я правильно вас здесь понял, и речь идет о «блате» и прочих подковёрных интригах — то, как раз, в IT компаниях этого на порядки меньше, чем в прочих корпоративных структурах, и, тем более, государстве Украина :)

«Насяльника» в IT компании и рад бы ставить лидами самых толковых и ответственных, но нередко оказывается в ситуации из мультфильма «Остров сокровищ» — «Возьмите лучших из худших»

К слову о других структурах. Страшнее, когда то же самое происходит в авиации — читал недавно обсуждение катастрофы Боинга в Казани, и, выяснилось, что командир воздушного судна (!) имел лишь минимально необходимое количество часов налёта. А ведь в пилоты, и, тем более, КВСы, по блату не берут — это вам не штаны в офисе протирать, человеческие жизни за спиной.

Лидер — это не монарх и не «авторитет» и не диктатор.

А вот с этим — согласен. Лидер — объединяющее звено, организующее команду в единое целое. Но как в единое целое команду могут объединить два лида — искренне не понимаю.

искренне не понимаю.
Это уже не мои проблемы.

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

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

Есть другие точки зрения и есть их реализации. Но это не мои точки зрения — в данном конкретном случае они меня никак не задевают и не есть моей проблемой. Правильно я говорю?

ОК, принято. Мне, конечно же, было бы интересно узнать про ваш опыт в данном вопросе, но это ваше право — делиться им или нет.

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

Логично для этого частного случая...

Для каждодневного частного случая. Да.

В общем, интроверты (особенно глубокие) идут лесом, как я понимаю.

Обидно, досадно, но ладно.

В техлиды скорее идут, или в синьоры.

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

Валентина, обратите внимание на вот эти вот стандарты:
www.apkit.ru/...s/standarts.php

Подозреваю, многие вещи там описаны.

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

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

Согласен. Еще один вариант — когда нужно что-то сделать _срочно_, в режиме тушения пожара. Но таких случаев не так много.

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

А вот когда команда разноуровневая (Jun/Mid/Sen), то все же надо чтобы ими командовал сержант тим лид, назначая таски по принятой в проекте/компании политике. Дабы хитрые «деды» сеньоры не хапали себе легкие таски, рассичтанные на «салабонов» джунов :)

Дабы хитрые «деды» сеньоры не хапали себе легкие таски, рассичтанные на «салабонов» джунов :)
Это уже от команды зависит) У меня как раз команда довольно разношерстная, но я уверен, что такого не будет даже при самостоятельном подборе тасков.
средняя зарплата — $2800
Маловато будет, норм миддл столько же может получать.

«Норм Миддл» может получать и в 2 раза меньше, и что?
Есть понятие «статистики» и «среднего». Но вы видимо с ними не знакомы.

ЗЫ:
Когда ум отдельно взятых славян наконец начнёт понимать что правила строятся на бОльшей выборке данных, а не отдельно взятых исключениях типа «А вот у меня тут чувак получает в 2 раза больше» и так далее.

Маша спит со всеми, а Света девственница, в среднем они обе шлюхи.

Размеры вашей выборки поразительны, а главное так по теме, но как стёб над статистикой — отлично :)

Невероятно точно описана моя работа! Согласен со всем на 100%!

Если на проекте хороший тимлид, то ПМ не нужен. Нужен Program (или Technical) Manager на несколько проектов. То есть в общем случае ПМ — существо бесполезное. Вот вам и развитие карьеры.

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

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

Это все тот же вариант. Работу делают люди. Как эти люди называются — не важно.

Хотя может в этом и проблема — в уверенности, что если назвать «ведущего программиста» senior-ом, руководителя отдела — teamlead-ом, а гендира — СЕО — то в команде сразу все наладится.

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

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

О способе выбора роли — я ничего не говорил. Но не зависимо от метода выбора — назначение сверху или самоорганизация — название должности ни на что не влияет.

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

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

конечно. В скраме нужен только скрам-мастер и то, просто как фасилитатор.

Если команда сильная, кто-то возьмет на себя роль тимлида/техлида/ПМ

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

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

Наоброт. «Признавать» можно тех, кто на голову выше («не формальный» или «признаваемый», «авторитетный»). Если приблизительно такой же — то «фомально поставленный», влияние минимально (ибо не авторитет).

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

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

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

Описанное выше — смесь обязанностей Tech Lead, Team Lead и PM.
Видимо в каждой компании всё по разному, особенно в небольших командах.
Как по мне краткое описание в Википедии раскрывает суть: en.wikipedia.org/...iki/Team_leader
А дальше всё индивидуально.

Также статье не хватает диаграммы, в которой была бы отражена вся команда, место Team Lead-а в ней и связи (или их отсутствие) с каждым из тим мемберов.

Диаграмма — интересная идея, в следующей статье серии (про архитекторов) подумаю над этим
А тут есть ссылка на карту карьеры — dou.ua/.../karta-kariery

На проектах есть две lead роли: менеджерская — PM, и техническая — System Architect.
Ребят, нужно было либо придумать и описать роль «тимлид», либо вообще не писать эту статью. А то у вас получился реально винегрет из PM-ных и архитекторских обязанностей.
у вас получился реально винегрет из PM-ных и архитекторских обязанностей

А оно на самом деле так и получается, особенно если PM — нетехнический. И, в этом есть свои плюсы, так как нетехнический PM может, взамен, иметь гораздо более прокачанные soft & negotiation skills (с чем, зачастую, дело обстоит весьма грустно и ПМов, выросших из технарей)

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

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

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

Ну а сколько и каких ролей выполняет человек с лычкой «тимлид» — это уже совсем другая история.

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

Может и так. Хотя два сениор разработчика на проекте могут быть, а двух «решающих» — очевидно нет.

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

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

А как же ж лидерские амбиции авторитета? Они же ж будуть страдать в случае необходимости обосновывать необоснованные решения.

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

А если руководитель часто спускает решение сверху, то тому может быть три обьяснения:
1) Он нереально крут (и самовлюблен)
2) Он скоро нахватается фейлов и будет уволен
3) У вас нет полной информации о методе принятия решений.

В противном случае, команда будет постоянно зацикливатся на пустяках
Мы все еще говорим о качественной команде или уже о реальном наборе джунов проданных заказчику в качестве 23-летних синьоров с «лидом имеющим право решать» во главе?

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

ЗЫ: И, кстати, совершенно не факт, что будет будет уволен «авторитет-руководитель». Это — один из характерных пунктов проявления безнадежных проектов.

А вот «авторитет» — именно что зацикливается на пустяках и неумеет договариваться и находить компромиссы.
Именно поэтому, крутого спеца плохо ставить руководителем — он будет продвигать свои решения(хотя по началу это выглядит хорошо).

Но и без признания — ты будешь говорить очень умные вещи, а тебя просто не будут слушать — все таки мы очень зависимы от мнения «авторитетов»

Глупости. «Крутого спеца» и «будет продвигать свои решения» — это противоположные характеристики. И, опять таки, вопрос «признания» в команде равных не стоит — это априори выходит из определения «команды равных». «Крутым спецам» нет нужды в «признании авторитетов» для признания эффективным того или иного решения, предложенного в т.ч. кем-то другим. Более того: как раз «крутые спецы» и более чем склонны предлагать одинаковые или очень подобные решения одной и той же задачи. Равно как и признать более эффективное решение просто исходя из понимания сути этого решения без «упора на авторатите». Это — одинаковые решения одинаковых задач — кстати, еще одно отличие специалистов от людей случайных, пусть и амбициозных. Последние как раз тяготеют к самым разнообразным, вычурным, нежизнеспособным, и вообще не являющимся решениями «решениям». Это как у Толстого: все счастливые люди счастливы одинаково, и только несчастные несчастны каждый по-своему.

Вернитесь в реальность. На практике не бывает однозначно лучших решений. Да и спецы отнюдь не лишены амбиций.

Да, количество разума — величина постоянная.

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

в цитаты прямо, абсолютно согласен

На практике часто такой винигрет и есть. В общем случае TL = TechL + PM, пропорции разнятся по конторам и проектам.

если говорить о жизни — то у каждой компании свой «салат». Поэтому имеет смысл расписывать роли(которые постоянны), а не должности.

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

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

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

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

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

Так почему бы в «статье» в издании национального уровня не описать как раз правильный подход (в сад идут все без исключения желающие оспорить «а реальность с 23-летними синьорами»), вместо этой бессмысленной ерунды под амбициозным титулом «карьерный рост в нашем местечковом ИТ»?

О чем вообще эта «статья»?

Ну так статья не о «дележе опытом» а об реалиях жизни)
Если описывать «правильный подход» — то это просто другого толка статья нужна.
Да и миллион таких и без того в инете... слава богу чего чего, а разных методик\практик и прочего — навалом. Было бы желание читать

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

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

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

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

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

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

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

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

Тимлид — это именно не роль, это именно должность. Роли описаны в сумбурном винегрете

Типичный рабочий день тимлида

Более того, около 106% отечественных «23-летних синьоров на должности тимлида» по ролям сказать толком ничего не могут. В лучшем случае, они умеют программировать. Точнее же они «когда-то программировали что-то в начале своей карьеры». И ко всем техническим вопросам они имеют ровно такое же отношение. К организационным, впрочем, тоже. Основной критерий, которым они обладают — амбиции.

«Если не умеешь делать и не умеешь учить — руководи» (к)

Вот, в частности:

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

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

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

Кустарщина чистой воды.

Тим лид — это адвокат команды, ПМ — адвокат проекта и заказчика.

очень хорошее саммари ко всему комментарию. согласен

Все опрошенные ребята позиционировали свою должность именно так...

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

А если исходить из ролей, то бывают и PM-teamlead, и techlead-teamlead, и архитектор-teamlead. Да что там, в стартапах и CEO-teamlead не редкость. Но глупо же всех смешивать?

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

Если все так делают — то это нормально, правда? :)
Впрочем статью легко исправить — нужно просто изменить заголовок на
Карьера в IT: должность Team Lead (как оно в есть в Украине)

Миллионы леммингов не могут ошибаться. (к)

Підписатись на коментарі