Тимлидер: плюсы и минусы профессии

Ошибки, негатив и минусы

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

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

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

Личностные качества. В команде есть человек, который по каким-то причинам вас не устраивает

При этом абсолютно не важно, наняли его вы, или он уже был, или дали со стороны. Все люди ошибаются и вы не исключение

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

К минусам можно также отнести то, что со временем ваши технические навыки будут падать. Это и миф, и правда одновременно. Роль лида позволяет более широко взглянуть на некоторые технические аспекты, на мета-принципы программирования. А то, что вы не будете знать как запрограммировать в iOS 10 новый фреймворк CallKit и какие интерфейсные методы в нём есть — это пережить будет тяжело, но в целом можно.

Уйти (,) нельзя (,) остаться: трудный выбор коллектива

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

Тут возможны две кардинально противоположные ситуации:

• вы приходите в незнакомый коллектив;
• остаетесь в своем любимом, но знакомом до боли коллективе, просто теперь вы начальник.

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

Я не буду заострять внимание на этом варианте — он достоин отдельной истории. Кратко дам советы

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

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

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

Где научиться специальности?

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

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

1. Курс «TeamLead» от SkillBox

SkillBox – онлайн-университет современных профессий в области маркетинга, дизайна, программирования и менеджмента. Участник проекта Skolkovo, обладатель премии Рунета за 2018 и 2019 годы.

• Чему научитесь: освоите навыки управления командой разработчиков, принципы подбора персонала; изучите методологии Agile, Scrum и Kanban; сможете эффективно решать бизнес-задачи; узнаете системы мотивации работников.
• Формат обучения: практические видеоуроки, самостоятельные домашние задания с проверкой преподавателем и исправлением ошибок, защита дипломного проекта; всего 82 урока, сгруппированные в 28 тематических модулей.
• Преимущества: доступ к материалам курса навсегда с учетом всех обновлений; преподаватели-практики; разбор реальных кейсов; диплом о прохождении подготовки; отсрочка платежа до 12 месяцев.
• Длительность курса: 6 месяцев.
• Кому подойдет: начинающим специалистам, middle и senior-программистам.
• Стоимость: около 39 000 рублей, возможна рассрочка по 6 900 рублей в месяц.

2. «Руководитель команды разработки» от GeekBrains

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

• В программе обучения: автоматизация разработки, управление командой исполнителей и сложными системами. Вы научитесь подбирать специалистов, внедрять мотивационные программы, понимать продукт, разработкой которого будет заниматься команда. Узнаете как обеспечить качество работы и автоматизировать процессы.
• Продолжительность обучения: 6 месяцев.
• Формат: лекции два раза в неделю, вебинары и занятия в группе. Разбор всех тем будет проходить на основе ваших реальных кейсов. В конце занятий – защита итогового проекта и диплом о профессиональной подготовке государственного образца.
• Подойдет: начинающим управленцам и опытным разработчикам.
• Стоимость обучения: 3 113 рублей в месяц при беспроцентной рассрочке на 36 месяцев. Полная цена курса около 115 000 рублей.

3. «Team lead 2.0» от Otus

Образовательный онлайн-портал OTUS предлагает более 80 авторских курсов в области IT для разного уровня подготовки. На рынке с 2015 года. Обладатель премии Рунета за 2018 год и резидент государственной программы Skolkovo.

• В программе курса: Вы освоите современные техники и инструменты руководства. Научитесь подбирать специалистов не как отдельную единицу для выполнения рабочих процессов, а как часть сплоченной команды, которая выполняет общую задачу.  Вы не просто изучите персональные навыки управленца, но и научитесь работать с командой.
• Длительность обучения: 5 месяцев, по 4 часа в неделю в формате вебинаров (вторник и пятница в вечернее время), плюс домашние задания с проверкой преподавателем. В программе всего 7 тематических модулей, в том числе проектный (подготовка и защита диплома). По окончании курса получите сертификат о профессиональной подготовке.
• Подойдет: практикующим специалистам в области разработки не ниже уровня Middle/Senior.
• Стоимость курса: 110 000 рублей.

Описание должности

Кто такой тимлид и чем он занимается? Само название имеет английское происхождение (team leader – «лидер команды»). Этот человек – координатор команды разработчиков. Он определяет сферы ответственности своим подчиненным и контролирует их работу, организовывает обучение и обеспечивает возможности профессионального роста для специалистов, а также ведет переговоры с заказчиком.

Тимлид – не профессия, а должность. Лидером команды, как правило, становится программист-разработчик. Соответственно, программист – это профессия, а тимлидер – занимаемая им должность.

Кроме непосредственно профессиональных, на тимлида возложены функции менеджера:

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

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

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

Технические задачи тимлида:

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

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

Плюсы и минусы профессии

Теперь немного о достоинствах и недостатках профессии:

Возможность реализовать свои лидерские качества

Высокий доход

Востребованность на рынке труда

Общение с разными заказчиками и расширение круга общения

Хорошая площадка для развития карьеры

Отсутствие большой конкуренции,так как хороших тимлидов на рынке недостаточно

Ненормированный рабочий день

Ответственность за команду, а не только за себя

Необходимость постоянно совершенствовать свои профессиональные знания

Нужно постоянно быть в курсе всех вопросов, касающихся проекта

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

Как быть хорошим Team Lead-ом? Советы

Фокусируйтесь на людях, а не только на программировании.

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

Контролируйте свое эго.

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

Каждое, даже самое простое решение, может иметь далеко идущие последствия, поэтому очень важно обсуждать его со всеми заинтересованными сторонами,” — говорит Линда Брэнаган (Linda Branagan), в прошлом опытный тимлид из компании Construct Internet Design.

Обсуждайте детали и договаривайтесь обо всем заранее.
Поскольку коммуникации — это важная часть функциональности тимлида, старайтесь по-максимуму обсуждать все аспекты работы над проектом и договариваться обо всем заранее, советует Майк Скэнлин (Mike Scanlin), СЕО американской компании Born to Sell и бывший тимлид в целом ряде ИТ-компаний, среди которых T/Maker и General Magic.
“Нет ничего хуже, чем работать в течение года над проектом, и, продемонстрировав результаты своей работе на очередной спринте, услышать от членов команды что-то вроде “А как насчет этих функций?” или “Мы забыли, что нам нужно будет реализовать вот это.” Постарайтесь убедиться в том, что все известно и четко спланировано еще до начала работы над проектом,” — рекомендует он.

Не провоцируйте конфликты, но будьте готовы к ним.
Также важно помнить о том, что будучи на позиции тимлида, очень сложно угодить всем сторонам, а поэтому конфликты в той или иной форме практически неизбежны. “Работа на позиции тимлида означает, что на каком-то этапе вам придется принимать решения, касающиеся членов команды, и эти решения неизбежно будут вызывать конфронтацию. Этот аспект работы часто оказывается неожиданным для многих тимлидов, потому что далеко не все умеют и способны решать конфликты,” — сказал Стив Морс (Steve Morse), разработчик поддержки в компании Tealeaf Technology.

Правило №2. Вопросов не должно быть много

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

Мы воспользовались правилом 5±2. Обычно нам хватало трех вопросов, иногда это число вырастало до 5-ти, редко — больше.

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

Плохо: «Узнай, работал ли он с высокими нагрузками». Может, у кандидата был написанный через пень-колоду сайт без индексов и с циклическими запросами в БД, который падал от 5-ти одновременных посетителей, и это он считал высокими нагрузками («а что, сервер же не выдерживает!»). HR из его ответа этого не поймет, а корректно уточнить не всегда сможет.

Хорошо: «Был ли опыт разработки сервиса с более, чем 500 RPS или 3 млн уникальных посетителей в сутки?» Подставляем наше виденье нужной нагрузки и получаем конкретный ответ.

Правило №4. Не все вопросы обязаны быть отсекающими

Мы обычно формулировали список вопросов, миксуя обязательные пункты (must have) и желаемые (nice to have). Такой подход давал нам возможность не просто узнать, что человек пройдет первичный фильтр, но и вместе с другими данными взвесить, насколько нам интересно общаться именно с этим кандидатом.

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

Требования работодателя

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

Для этого специалист должен обладать такими личностными качествами, как:

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

До того как специалиста назначат на должность тимлида, он должен проработать в IT-сфере не менее 5 лет, а также иметь следующие навыки и умения:

1. Аналитические способности.
2. Знания серверных технологий.
3. Готовность к самообучению.
4. Умение учитывать мнение команды.
5. Знания масштабируемости веб-проектов.
6. Способность принимать быстрые и простые решения в стрессовых ситуациях.
7. Умение распределять обязанности внутри коллектива.
8. Навыки и умения в программировании на уровне senior.
9. Оценка и планирование бюджета.
10. Умение рассматривать проблему с разных ракурсов.
11. Навыки наставничества.
12. Умение нести ответственность за работу других людей.
13. Знания языков программирования.
14. Способность учитывать риски.
15. Умение заметить и исправить ошибку.
16. Знания планирования задач.
17. Умение планировать, ставить сроки и укладываться в них.
18. Способность сформировать команду, обучать и мотивировать новых сотрудников.
19. Умение переработки требований заказчика в техническое задание.
20. Знания в области психологии, социологии, менеджмента и кадровой политики.
21. Навыки решения конфликтов и поддержания рабочей мирной атмосферы.
22. Умение распределять нагрузку между членами группы.
23. Знания ведения переговоров.
24. Умение проводить тестирование готового продукта.
25. Навыки контроля всех этапов работы.
26. Умение вести документацию.

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

Демократический стиль

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

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

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

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

Частый ответ на вопрос о странном legacy решении в проекте

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

Знания и навыки

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

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

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

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

Повторюсь еще раз – тимлид это и программист, и психолог, и менеджер в одном лице.

Шаг номер 2. Общий план первоначальных действий

От теории переносимся к практике.

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

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

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

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

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

Какие назначить первые встречи, чтобы во всё это погрузиться?

Первым делом встретьтесь 1 на 1 с руководителем и, используя роадмап тимлида https://tlroadmap.io/, обговорите конкретные ожидания от вашей позиции. Главное помнить, что в роадмапе указано не «всё, что должен знать и делать тимлид», а «всё, что могут требовать от тимлида в разных компаниях», т.е. это объединение подмножеств хотелок из разных компаний. Так что, когда вам начальник скажет: «Ну, вроде выглядит норм, давай-ка всем занимайся,» — вашей задачей будет ему объяснить, что всем заниматься невозможно физически и нужно проанализировать конкретную ситуацию, проект, команду, выделить наиболее важные области, которые вы и возьмете на себя.

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

• взглянуть на текущую ситуацию с разных сторон;

• узнать какую-то историю, которая творилась еще до вас;

• проанализировать самих людей;

• понять ожидания этих людей от вас.

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

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

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

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

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

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