что такое тим лидер
Что такое быть Team Leader
Всем привет! Меня зовут Артур Дементьев, я бы хотел поделиться личным опытом и написать несколько статей о том, что из себя представляет менеджмент в IT. А также рассказать о том, на какие грабли наступал и каких ошибок можно было избежать. Все статьи я буду писать, основываясь на своём опыте работы в разных IT-компаниях, в которых я начинал как Team Leader (TL) команды из нескольких человек. В одной из них с нуля вырастил маленький отдел в большую IT-структуру и дорос до CTO.
Проблемы есть во многих компаниях, часто люди допускают ошибки. Именно общение с ними сподвигло меня на написание статьи. В ближайшем времени, я постараюсь продолжить публикации. Надеюсь, они будут полезны TL, CTO, руководителям департаментов или тем, кто только собирается ими стать. А начну я с рассказа о том, что такое быть Team Leader, это будет взгляд изнутри.
Тут сразу стоит сделать отступление. Есть разные компании:
Как становятся Team Leader
Есть два стандартных пути к позиции TL:
Какой бы путь вас ни привёл к новой должности, но теперь вы будете меньше кодить и управлять людьми.
Перемены в деятельности
Итак, что нового появится в вашей жизни с того момента, как вы превратились из разработчика в TL? Несомненно, вы будете больше участвовать в обсуждениях и присутствовать на совещаниях. Зато вы сможете не тратить время на рутинные задачи, а делегировать их коллегам. Также придётся больше заниматься code review. Возможно на вас упадут договора и выставления счетов в бухгалтерию. Вроде бы жизнь удалась, и вы добились цели.
Но эйфория проходит довольно быстро, и вы практически начинаете гореть. Происходит примерно следующее: поток задач нескончаем, их надо решать или делегировать, следить, что пишет команда. Надоедливые менеджеры всё время что-то хотят и постоянно зовут на совещания. «Им заняться что ли больше нечем?» — думаете вы. Начальство же жмёт со сроками, а из команды внезапно ушёл человек, и искать замену вам. Ещё и жена звонит. В общем, вы становитесь раздражительным и близки к перегоранию. В таком режиме реально прожить максимум год.
Как выжить в таком аду? Как остальные справляются? Основная проблема в выходе из зоны комфорта. Вы в новом мире, старые правила не действуют. Конечно, выход есть, но найти надо его надо самому, в каком-то смысле сломать себя и осознать кое-что новое.
Что надо понять
Есть несколько вещей, которые надо осознать. И чем раньше вы это сделаете, тем лучше и легче вам станет жить.
Одни минусы. Есть ли плюсы?
Да! И их намного больше минусов. Теперь у вас есть ресурсы, которыми вы управляете. А значит у вас больше средств для достижения результата, то есть решения задач бизнеса. Именно этого он от вас и ждёт.
Я бы сделал сравнение с футбольной командой. Вы как молодой тренер команды, у каждого игрока есть свои сильные и слабые стороны. Если вы будете управлять ими без учёта особенностей каждого, то вряд ли что-то сможете выиграть. Но став настоящим лидером команды, вы должны суметь превратить слабые стороны ваших коллег в сильные ради победы.
Вы можете нанимать не очень опытных людей, но за полгода превращать их в крутых специалистов, которые будут тянуть проект вверх. Помните, что у вас в арсенале есть крутые подходы, например, Scrum или Kanban, которые могут обратить мучительную разработку в хорошо отлаженный процесс для всех его участников.
Также вам открывается огромное поле для экспериментов. У вас появляются ресурсы для поиска и проб новых решений. Это надо делать обязательно, что-то сработает и принесёт успех. Ищите пути, которые будут полезны и команде, и бизнесу. Серебряной пули нет, вам придётся найти своё решение, которое будет работать в конкретных условиях.
Используйте опыт и стройте эффективные системы отбора сотрудников. Также мотивируйте и развивайте команду. И не забывайте о развитии себя: читайте книги, слушайте лекции, ходите на конференции. В конце концов просто общайтесь с людьми и делитесь опытом. В итоге вы построите сильнейшую dream team.
Если ещё не поняли, то со временем осознаете, что самый важный ресурс — это люди. Оставайтесь с ними коллегами, а не начальником и подчинёнными. Будьте единым механизмом, помогайте им, а они будут помогать вам.
Team Leader — это не суперпрограммист, это лидер, который может из любых ресурсов, несмотря ни на что, собрать крутую команду и принести прибыль компании. Вот чем эта работа по-настоящему классная.
Лично для меня высшая похвала, когда приходят люди и говорят: «Ни фига себе какой вы сервис запилили! Ещё и с такой маленькой командой!». После этого ты понимаешь, что всё было не зря. И это даёт сил делать проект ещё лучше. Так сказать, выиграть с ребятами свой чемпионат.
Для тех, кто уже завтра идёт на собеседование
Стоит рассказать и о вакансиях на позицию TL. Как я и писал выше, компании бывают разные, в них разные задачи. На собеседовании попытайтесь понять, кто всё-таки нужен работодателю, чтобы ваши ожидания совпали с реальностью. Особенно смешно, когда в компании нет чёткой иерархии, и всё должно висеть на одном человеке. Обычно в их вакансиях есть фраза: «Придётся программировать 70–80% времени. Я бы советовал избегать таких предложений. Либо на вас хотят сэкономить, либо руководство вообще не понимает зачем им нужен TL. Конечно, каждый случай индивидуален, но всё же есть грани разумного. В конечном итоге человек перегорит и уйдёт, так как жить в стрессе всё время нельзя.
Подходите к выбору места с пониманием того, что хотите получить. Помните, что собеседование проводят не только с вами, но и вы с компанией. Не стесняйтесь и задавайте вопросы, выясняйте всё. Лучше узнать всё заранее, чем потом оказаться в бездне. Можно даже попросить познакомиться с командой, послушать, что говорит ваш будущий коллектив. Цена ошибки высока: неправильное место может отбить всю охоту развиваться дальше и не даст попасть в этот удивительный мир.
Выводы
Выбор стать TL должен быть осознанным решением, а не просто, потому что вам надоело писать код или хотите зарплату повыше. TL — это первая ступенька в IT-менеджменте. На этом этапе можно понять, нравится вам это или нет. И если нет, то всегда можно вернуться в разработчики. Но учтите, если вы долго проработаете TL, то уйти назад может быть сложно. TL не так много пишет код, мир вместе с технологиями сильно меняется, опыт теряется. Может получиться, что вы вернётесь назад, и придётся долго навёрстывать упущенное.
Безусловно это очень интересная работа. Вам придётся сломать своё мышление и начать думать по-новому. И, конечно, покинуть зону комфорта. Но зато вы получите бесценный опыт управления, сможете строить команды и добиваться результатов для компании.
Всё описанное выше приходит с опытом. Учебники и курсы не научат вас быть TL. Но зато смогут помочь обойти немалое количество граблей.
Что должен делать тимлид: роли, обязанности и навыки
Тимлид – это снежинка. При детальном рассмотрении в каждой компании тимлид принимает разную форму. Где-то от него ждут только передвижения задач по доске, где-то – наймов и увольнений, а где-то просят одновременно проектировать архитектуру, ставить бизнес-цели и думать о болях пользователей продукта. На самом деле все обстоит еще сложнее. Различия встречаются не только между разными компаниями, но и даже в рамках команд, находящихся в одном офисе.
Это становится особенно заметно, когда компания сталкивается с одним из следующих вопросов: как собеседовать тимлида, как оценивать его работу, как составить ему план развития. Тимлиды тоже довольно много фрустрируют – они не понимают, насколько их текущий опыт работы останется релевантным при переходе в новую компанию, какие пробелы в знаниях и навыках существуют и как их можно заполнить. Короче говоря, куда не посмотришь, везде с тимлидами как-то сложно.
С этой проблемой столкнулись и мы со Стасом Цыгановым. Но в этот раз вместо того, чтобы обойтись простым решением текущих проблем, мы захотели подойти к вопросу фундаментальнее, собрать информацию об ожиданиях от тимлидов в разных компаниях и обобщить ее в единую общую модель. И, кажется, у нас получилось.
Роадмап
Роадмап содержит в себе два раздела:
Эту модель можно использовать как угодно – для составления собственного плана развития, для формирования должностных инструкций в компаниях, для составления вакансий или проведения собеседований. Учтите, что скорее всего вам нужны не все ветви потенциального развития – и это нормально.
Почему роадмапу можно верить
Основная проблема, о которой я уже упоминал – это разница в восприятии роли тимлида в разных компаниях. При составлении общей модели нельзя было опираться только на наш опыт работы в Авито, Туту и Рамблере. Нужно было исследовать больше компаний.
Начали мы со сбора информации, создав рабочую группу из десятка человек, которые поделились информацией о том, кто такой тимлид в их случае. В этой группе приняли участие руководители разработки как из российских, так и зарубежных компаний, как из небольших стартапов, так и очень крупных заведений. Первый брейншторм подтвердил нашу изначальную гипотезу. Несмотря на большое количество различий, все ожидания и обязанности можно было обобщить в несколько отдельных кластеров-ролей.
Дальше мы ушли детально прорабатывать каждую роль, разделяя ее на ветки и листья с непосредственными обязанностями тимлида, стараясь одновременно не перегрузить роадмап и не сделать его слишком абстрактным. Каждая из обязанностей связана с описанием в базе знаний, которое раскрывает следующие секции:
Получившуюся структуру мы валидировали через серию интервью с руководителями разработки из разных компаний. На интервью мы задавали серию вопросов, чтобы узнать все обязанности тимлида в компании, и одновременно отмечали их на своем роадмапе. В конце получившуюся модель мы показывали интервьюируемому и проводили финальную валидацию. Судя по результатам, мы практически ничего не упустили.
Как роадмап использовать
Для компании
Для тимлида
Работа над роадмапом только начинается – мы делаем первый релиз и нам очень важно собрать еще больше фидбэка:
Пишите комментарии к статье, issues на GitHub и предложения в наш чат!
Должность — тимлид
Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.
От разработчиков, проработавших долгое время в рамках одной компании или даже одной команды чаще услышишь четкое мнение о том, кто такой тимлид и в чем заключаются его обязанности. Повидавшие же разные проекты разработчики и менеджеры постепенно приходят к пониманию, что тимлид может заниматься много чем, какая-то деятельность лучше вписывается в его роль, какая-то хуже, и уже не готовы давать точное определение роли тимлида.
Откуда же появляется разное представление о должности тимлида?
ПРИМЕЧАНИЕ. Здесь и далее я говорю про тимлида только в рамках команды разработки. Догадываюсь, что многое из рассуждений распространяется и на другие команды, во многих видах деятельности.
Мне доводилось видеть тимлидов исполняющими роли руководителя проекта, системного аналитика, тестировщика, дизайнера, проектировщика интерфейсов, архитектора, даже специалиста по поддержке пользователей.
На практике, в здоровых организациях, по моим наблюдениям, роль тимлида обычно занимают разработчики, которые более других чувствуют ответственность за судьбу разрабатываемого продукта, нередко перерастающую в гиперответственность, чем умело пользуется руководство.
ПРИМЕЧАНИЕ. Гиперответственностью я называю случай, когда человек чувствует себя ответственным за обстоятельства, влиять на которые полномочий не имеет. Я не пытаюсь вложить в это качество ни позитивного ни негативного оттенка, лишь констатирую, что в некоторых сотрудниках гиперответсвенность проявляется.
Именно за счет этой гиперответствености тимлид берет на себя ту деятельность, для которой нет выделенной должности и, постепенно, эти обязанности закрепляются за ним и, как следствие, за его должностью. В это время остальные сотрудники тоже привыкают к таким обязанностям тимлида, закрепляя в сознании именно такой набор обязанностей для любого другого тимлида.
Конечно, описанное касается не только роли тимлида, и, в той или иной степени, картина верна для любой должности в любой деятельности, но должность тимлида среди тех, что наиболее подвержены описанному эффекту.
Какая же деятельность для тимлида родная?
Что должен уметь сотрудник, какими качествами обладать для того, чтобы быть хорошим тимлидом, а только потом хорошим архитектором или аналитиком?
Самое простое определение, которое я могу дать для роли тимлида звучит так: «тимлид — интерфейс команды разработки».
Он отвечает за все, за что отвечает команда, для этого у него есть полномочия формировать команду и использовать ее членов по своему усмотрению для решения задач команды.
Если на команду возлагается ответственность за проектирование системы, то тимлид должен позаботиться о том, чтобы кто-то систему спроектировал. Команда ответственна за разработку интерфейса пользователя — тимлид определяет кто в команде это сделает. И это справедливо для любой задачи команды: ответственен за ее выполнение в глазах внешнего для команды мира тимлид.
Что же конкретно тимлид должен делать?
Разберем, что с этим нужно делать.
Лидерство
«Нужно чтобы члены команды были согласны выполнять поручения» — так себе формулировка, но изящнее сложить не удалось. Имеется в виду то, что сотрудник должен принимать задачи в работу с намерением довести их до конца. Сотрудник не отказывается брать задачи в работу просто игнорируя указания, или ссылаясь на «кривость решения», не саботирует, по-тихому занимаясь своими делами, а принимается за задачу с намерением ее выполнить. Как заставить человека захотеть выполнить задачу? Способов много, от принуждения угрозой физического насилия до обещания поездки на девкон. Это то самое качество, что я определяю «лидерством».
Компетентность команды
ПРИМЕЧАНИЕ. Довольно часто несоответствие ответственности и полномочий проявляется в том, что тимлида не включают в процесс принятия решения о приеме кандидата, или не дают возможности исключить сотрудника из состава команды по инициативе тимлида. Притом ответственность за то, чтобы команда справлялась со своими задачами с тимлида никто не снимает. Вот она — вмененная гиперответственность.
В чем же здесь проявляется профессионализм тимлида?
Как всегда скоростью и качеством решения задачи обеспечения команды компетентными сотрудниками.
Качество в данном случае тем выше, чем дешевле обходятся компании сотрудники (и не только зарплату считаем) при условии соблюдения их уровня компетенции, достаточного для решения задач. В некоторых случаях скорость в приоритете, в некоторых качество.
Среди способов пополнения кадрами вижу принципиально два подхода:
1. Брать готовых специалистов с рынка труда.
2. Воспитывать кадры самостоятельно.
Остальные, так или иначе, — комбинации этих двух. Крайний случай первого — только хантинг экспертов в требуемых областях, второго — найм только из стажерских программ. Правильного способа нет, а крайности, как и везде, часто свидетельствуют о некоем сбое. Тимлид как раз тот человек, который должен найти подходящий компромисс в конкретной ситуации с учетом ее развития.
Нельзя дать ответ на общий вопрос «как обеспечить команду достаточно компетентными специалистами», можно найти его решение только в рамках конкретного проекта на конкретном предприятии. Можно только сказать, что тимлид при разработке этого решения должен учитывать характер задач в проекте, срочность поставленных задач, значимость (impact) срыва сроков, планы и тенденции развития проекта, состояние рынка труда, доступность специалистов на рынке, сложность обучения специалистов своими силами.
Оценка работ
Чтобы не взять на себя обязательств, с которыми команда не сможет справиться, команде приходится оценивать свои ресурсы, чаще всего речь идет только о доступном рабочем времени членов команды. Ответственнен за исполнение обязательств командой разработки тимлид. Вне зависимости от того, как именно производится оценка работ в команде: каждый оценивает свою задачу, или все вместе оценивают все задачи, или все задачи оценивает кто-то один в команде, за оценку отвечать будет тимлид. Из этого следует, что тимлид имеет полномочия вмешаться в любую из оценок и изменить ее по своему усмотрению, это бывает полезно на практике, когда мнения членов команды расходятся. Более того, команда разработки, в лице тимлида, также берет на себя обязательства по исполнению планов, если ставить задачи команде в организации принято планами. В частном случае итеративных методов разработки команда (говоришь «команда» — подразумеваешь «тимлид») берет на себя ответственность за выполнение всех задач взятых в итерацию.
В современных подходах к разработке менеджмент не лезет в дела команды разработки, не говорит им как решать задачу, кому именно из состава команды решать задачу. Менеджменту важно лишь, чтобы команда выполнила задачу в оговоренный срок, а как это произойдет — неважно. Интересно, что о распределении задач между участниками умалчивает даже популярная методология Scrum, предоставляя команде «самой решать», кто за что возьмется. Когда-то я выяснял для себя, а как же происходит распределение задач на практике, и меня удовлетворил чей-то ответ, что в любой команде рано или поздно найдется лидер, который возьмет на себя инициативу по решению конфликтных ситуаций в распределении задач. Аргумент в пользу того, что распределение задач между участниками — также задача тимлида.
Как ни удивительно, оценка, планирование и распределение задач — обязанность, которая выполняется легко, если тимлид успешно справляется с другими обязанностями. Для этого в его распоряжении есть компетентные сотрудники, которые мотивированы на выполнение задач, они легко справятся с оценкой и выполнением задач. Тимлиду нужно только организовать процесс оценки и распределения задач командой, чтобы затем контролировать его. Как именно это сделать — существуют готовые решения в виде методологий разработок.
ПРИМЕЧАНИЕ. Если не знаете какую методологию выбрать в обычных условиях — берите Scrum. Потому что он прост, определен вплоть до мелочей и довольно хорошо работает даже без адаптации под команду и организацию.
Настроения в команде
Как минимум, для того, чтобы задачи решались, нужно чтобы члены команды могли общаться друг с другом без взаимного раздражения.
Казалось бы, простая задача? Далеко не так! Если между сотрудниками назрел конфликт, то во многих случаях его можно разрешить только исключением кого-то из участников из состава команды. Но на предотвращение конфликта тимлид вполне в силах повлиять, тут универсальных советов не дать, кроме одного: нельзя замалчивать конфликты, при любом инциденте нужно реагировать, как именно реагировать — зависит от конкретных обстоятельств.
Также тимлиду следует соотносить характеры членов команды, если одного зануду команда переварит, то двух, возможно, уже и нет (ничего не имею против зануд, сам зануда еще тот).
Ну а чтобы «повысить эффективность взаимодействия между членами команды» есть такая дисциплина как «тимбилдинг», я весьма скептически к ней отношусь, может сказывается тот факт, что не видел я хороших тимбилдеров в деле.
Вообще хотел обойтись без этого пункта, но совсем про него не упомянуть нельзя.
Заключение
Итак, у тимлида есть родные его должности обязанности, все они касаются того, чтобы обеспечить работоспособность команды, то есть способность выполнять поставленные перед командой задачи. Все остальное — это то, что тимлид взваливает на себя добровольно (или принудительно) дополнительно, но не всегда это плохо. Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет. Думаю многие из разработчиков знакомы с такой ситуацией, когда оставив интенсивно разрабатываемый проект на несколько месяцев, по возвращению обнаруживаешь лишь редкие знакомые элементы в новой архитектуре системы. Однако, согласно рассуждениям выше, непосредственная разработка не входит в число родных обязанностей тимлида, в некоторых проектах она может быть необоснованна.
В реальном мире тимлид не брошен один для решения всех этих задач, ему помогают руководители, коллеги соседних департаментов. На практике часто эта помощь перерастает в принятие решений за тимлида, такие моменты должны настораживать, так как фактически его обязанности переходят к другим сотрудникам. Бороться с этим или смириться — решать вам, но обращать внимание на реальное положение дел уж точно стоит.
Интересует мнение разработчиков (в широком смысле — всех, кто работает в составе команд-разработчиков), тимлидов, линейных и проектных руководителей, согласны ли вы с такой декомпозицией роли тимлида? Есть ли у вас какие-либо замечания, дополнения?
Кто такой тимлид и чем он занимается
Тимлид – это ведущий человек команде. Произошло название должности от английского team leader – лидер команды. В IT-сфере этот специалист управляет штатом разработчиков, выдает каждому свою поле ответственности, отвечает не только за прием на работу, но и за последующее обучение всех сотрудников своей команды.
По факту это связующее звено между заказчиком и разработчиком.
Как понять, что необходимо получить специальность тимлида
Настоящими лидерами можно стать не только в процессе работы. Есть множество нюансов, которые необходимо учитывать, чтобы стать качественным тимлидом. Профессиональные курсы для тимлидов нужны в следующих ситуациях:
Важно помнить, что тимлид это одновременно специализированный управленец и профессиональный программист.
В каких процессах участвует тимлид
Тимлид не останавливается только на управлении командой. Для него важно правильно собрать, создать команду, а значит, он участвует в процессе найма, адаптации и последующего обучения сотрудников. Тимлид должен уметь провести собеседование, понять положительные и отрицательные качества сотрудника, сидящего перед ним.
Следующий процесс – рост сотрудников и повышение их квалификации, работа над специализацией. Это касается не только новичков, но и опытных айтишников, чтобы все члены команды соответствовали уровню потребностей конкретного бизнеса.
Самое важное, что тимлид – это практикующий разработчик. Он знает код проекта, продолжает сам работать над ним, а не только осуществляет управление ит проектами.
Также тимлид помогает остальным участникам программы заканчивать поставленные перед ними цели. Здесь можно использовать разные способы – от обсуждения кодов на совместных собраниях, до парного программирования или индивидуальных бесед по обмену опытом и идеями. Главная задача качественного тимлида – продукт должен полностью соответствовать запросам заказчика и закрыть проект следует в точно установленный срок.
Интересно, что на сегодняшний день не во всех компания ИТ-сферы есть должность тимлида. Но лидеры данной сферы всегда держат такого специалиста в компании. Зарплата в среднем профессионального тимлида составляет около 200 тысяч рублей, поэтому профессиональные курсы с помощью в трудоустройстве для таких специалистов пользуются популярностью.
Тимлид – что это за профессия, чем занимается специалист и сколько зарабатывает
Здравствуйте, уважаемые читатели!
Любому обществу, группе или компании нужен свой лидер, который организует и поведет всех за собой. Если на предприятии каждый будет заниматься только своим делом, не обращая внимания на синхронность с другими специалистами, получатся только отдельные компоненты, а не цельный продукт.
Поэтому нужен человек, который видит картину целиком и сможет для каждого выделить свою задачу. Лидер, который мотивирует и вдохновляет на продуктивную работу, умеет управлять человеческими ресурсами. И тимлид – это тот, кто сможет все это осуществить. Я детально расскажу, кто такой тимлид, что это за профессия в целом, что делает специалист и как им стать, сколько зарабатывает, плюсы и минусы работы.
Особенности профессии
Тимлид – это командующий группы веб-разработчиков. Он находится в самом центре веб-проекта: управляет командой, организует и координирует их действия, мотивирует каждого сотрудника, разбирается в технической части веб-разработки, контролирует каждый этап создания конечного продукта, является посредником между руководством, программистами и клиентом.
Team leader – это менеджер, лидер и программист в одном лице. Должность появилась совсем недавно. Да и сейчас не во всех организациях, особенно мелких, есть такой специалист. Тем не менее тимлид – важное звено в процессе разработки и реализации IT-проекта.
Как правило, тимлид – это опытный программист с огромным багажом знаний и умений. Он способен найти ошибку в работе своего подчиненного и исправить ее. Но сам специалист редко садится за написание кода, и не всегда у него есть время и возможность принять участие в технической части разработки IT-продукта.
В большей степени тимлид занимается планированием, прогнозированием, организацией и оптимизацией процесса, распределением нагрузки и времени, учитывая навыки и умения членов команды.
Но в то же время на нем лежит ответственность за весь проект. Поэтому для него так важно внимательно следить за каждым из программистов, быть в курсе всего происходящего, знать, какой этап проходит проект, и четко представлять себе, каким должен получиться конечный результат.
Чтобы команда выполняла его указания, ему нужно быть гибким и немного жестким. Тимлид должен найти к каждому члену группы свой подход, чтобы добиться уважения коллег.
В задачи тимлида может входить и подбор сотрудников в команду. В этом ему может помочь HR-менеджер. Надо с внимательностью и осторожностью подходить к формированию группы, хотя разницы в уровне, опыте и квалификации среди команды не избежать. В этом случае тимлид должен давать каждому наиболее подходящую ему задачу, которую специалист сможет выполнить.
Кроме работы с веб-разработчиками, team leader ведет переговоры с клиентами. Специалист учитывает интересы и требования заказчика, которые передает команде, следит, чтобы команда работала слаженно, эффективно и в заданном направлении.
Обязанности тимлида
В некоторой мере обязанности тимлида пересекаются с областью деятельности менеджера проектов. Но у team leader есть и свои особые задачи, характерные для веб-разработки.
В перечень основных обязанностей тимлида входит:
Требования работодателя
Для работодателя важна эффективность и качество выполняемой работы. Ему нужен надежный человек, который может самостоятельно решать мелкие проблемы, которому можно было бы доверить проект.
Для этого специалист должен обладать такими личностными качествами, как:
До того как специалиста назначат на должность тимлида, он должен проработать в IT-сфере не менее 5 лет, а также иметь следующие навыки и умения:
В этом состоят только основные требования. Остальные могут быть связаны со сферой деятельности заказчика.
Зарплата, карьера и перспективы
Тимлиды могут работать как на крупные компании, находящиеся на слуху, так и на небольшие организации.
Особенностью крупных предприятий можно назвать объединение веб-разработчиков в несколько команд, в каждой из которых во главе стоит свой официальный тимлид. И чтобы руководить всеми группами, нужен лидер лидеров, т. е. самый главный тимлид, который контролирует всех руководителей команд.
Так как эта должность является пересечением двух направлений, технического и управленческого, то и карьера может двигаться по одному из них. Это означает, что тимлид может стать менеджером проектов или системным архитектором.
Амбициозные и грамотные тимлиды могут войти в состав руководителей. Есть примеры, когда такие специалисты получали определенную долю бизнеса. Еще можно переквалифицироваться и управлять продажами, стать аналитиком.
В среднем заработная плата тимлидов находится на высоком уровне. Если смотреть в целом по России, то заработок может быть от 80 000 до 250 000 руб.
Уровень дохода во многом зависит от успешности и масштабов предприятия, а также от региона, где тимлид трудится.
Самая большая зарплата в столице. Москва предлагает специалистам зарплату 100–400 тыс. руб.
В Санкт-Петербурге заработок чуть меньше: от 90 000 до 300 000 руб.
В регионах ситуация примерно одинаковая. Например, в республиках Марий Эл, Татарстан и Якутия, Краснодарском крае, Свердловской и Тюменской областях платят от 70 000 до 230 000 руб. А в Камчатском крае можно найти вакансии с зарплатой выше 300 000 руб.
Достоинства и недостатки
Плюсами должности являются:
Как стать тимлидом
С нуля стать тимлидом не просто сложно, а невозможно. Эта должность требует наличия множества навыков и знаний, а также опыта работы. Надо понимать, что такое программирование и менеджмент, знать, как работать и управлять человеческими ресурсами.
Для старта можно выбрать такие направления в вузах, как информатика и вычислительная техника, информационные системы и базы данных, а также другие направления, связанные с информатикой и программированием.
После работы веб-разработчиком можно уже думать о том, как дорасти до руководящих постов. Для этого надо постоянно учиться, быть инициативным и проявлять лидерские качества.
В большинстве случаев тимлидом становятся после приобретения профессионального статуса senior, т. е. став экспертом в своем деле, способным оценить весь проект в целом.
Но не все senior могут стать лидерами. Его, возможно, будут воспринимать всерьез и выполнять поручения, но эти задания могут быть неэффективны, так как новоиспеченному тимлиду не хватает управленческих навыков. Даже если поступит предложение стать тимлидом, для начала надо обдумать свои возможности, чтобы никого не подвести и не стать обузой для своих же подчиненных.
Чтобы эффективно управлять командой веб-разработчиков, надо изучать психологию, менеджмент, планирование, все время обновлять знания по программированию.
Сейчас доступна различная литература, лекции и семинары для желающих стать тимлидом, а также различные онлайн-курсы от проверенных обучающих платформ.
Самостоятельное обучение
Тем, кто уже имеет опыт в программировании, необходимо подтянуть навыки лидера и управленца. В этом может помочь самообразование с помощью специальной литературы:
Онлайн-курсы
Курсы станут отличным вариантом для тех, у кого не хватает времени на самообразование. Онлайн-обучение имеет несомненные достоинства:
Популярные платформы Skillbox, Нетология, SkillFactory, Otus, City Business School и Академия АйТи предлагают свои курсы для будущих тимлидов:
Заключение
Вы уже знаете, кто такой тимлид и чем он занимается, какие у него обязанности и как им стать.
Этот человек понимает, что такое ответственность и работа в команде. Он опытный программист и лидер, способный управлять человеческими ресурсами внутри собранной им команды. Тимлид занимается конкретным проектом, может собрать всех участников вместе и подтолкнуть их идти к единой цели.
Обзоры других должностей IT-сферы и не только читайте на блоге iklife.ru. Подписывайтесь и следите за обновлениями, чтобы каждый день узнавать о новых удаленных профессиях.
Во время получения первого диплома задумалась об удаленной работе, а когда получала второй – уволилась с университета и посвятила себя фрилансу.
Из всего разнообразия онлайн-профессий выбрала копирайтинг, но изучать способы заработка в интернете не перестала. Делюсь своими знаниями о том, как зарабатывать в сети, не выходя из дома.