team lead что такое
Кто такой тимлид (он же Lead)
Как устроена работа человека, которого слушают даже сеньоры.
Послушать аудиоверсию этой статьи (7 минут):
Слушайте Кто такой тимлид на Яндекс.Музыке
Когда мы говорили про сеньоров, то сказали, что один из вариантов их профессионального развития — стать тимлидом. Это самый важный человек в команде.
Чем тимлид отличается от сеньора и других программистов
Вы уже знаете, что джуниоры занимаются простыми вещами, мидлы пишут код, а сеньоры, кроме этого, думают над архитектурой и проектом в целом. Но чтобы все эти люди шли к общей цели, ими нужно руководить.
Тимлид (teamlead) — руководитель команды разработчиков. Он уже не пишет код своими руками и не думает над тем, как реализовать ту или иную функцию. Вместо этого он занимается распределением нагрузки на команду, следит за ходом проекта и берёт на себя ответственность за проект в целом.
Тимлид — это высококвалифицированный программист, который знает, как управлять другими программистами.
Зачем нужны тимлиды
Представьте такую ситуацию: в компанию программистов приходит заказчик и просит разработать мобильное приложение. Сеньор начинает планировать архитектуру, мидлы пишут код, а джуниоры прикручивают кнопки в интерфейсах.
Некоторое время спустя заказчик видит, что каждый занимается своим делом, но целого продукта нет — есть отдельные части, которые работают, но половины функций нет, а те, что есть, работают не так, как нужно.
Тимлиды нужны как раз для того, чтобы таких ситуаций не возникало. Для этого тимлид делает свою руководительскую работу:
Как им стать
Как правило, тимлиды — это бывшие сеньоры.
Джуниор или мидл не смогут стать настоящими тимлидами, потому что у них не хватит квалификации оценить проект в целом и сеньоры не будут воспринимать их всерьёз. Иногда тимлидами назначают простых менеджеров, чтобы они работали с клиентом, но это тоже ошибка — такой менеджер не сможет правильно оценить объём работ и грамотно распределить задачи в команде. Чтобы стать тимлидом, нужен большой опыт в разработке и решении архитектурных задач — а этим как раз и занимаются сеньоры.
Но не из каждого сеньора получится отличный тимлид. Всё дело в управленческих навыках, которые есть не у каждого программиста. Даже если взять первоклассного сеньора, далеко не факт, что он будет так же эффективно управлять всей командой, как пишет свой код.
Кроме своей области программирования тимлид должен знать и уметь:
Короче, тимлид — это менеджер, который в совершенстве знает стек программирования своей команды.
Сколько зарабатывает тимлид
Мы посмотрели зарплаты тимлидов в разных направлениях на начало 2020 года и вот что выяснили:
Разработка мобильных приложений — 228 тысяч.
Что дальше
А дальше всё зависит от того, насколько тимлиду нравятся функции менеджера. Если ему больше нравится управлять, чем программировать, то из него может получиться хороший продакт-менеджер. О том, кто это такой — в следующий раз.
«Тимлид делает так, чтобы команде было комфортно работать вместе, а творческое начало не угасло»
Мы продолжаем цикл публикаций про ИТ-профессии. В этот раз мы поговорили с Ксенией, тимлидом в отделе технической экспертизы IBS. Она рассказала о том, каково быть Team leader’ом на проекте и какими качествами нужно обладать, чтобы эффективно управлять группой разработчиков.
Team leader (тимлид) — это IT-специалист, который управляет командой разработчиков, владеет технической стороной, принимает участие в работе над архитектурой проекта, занимается ревью (проверкой) кода, а также разработкой некоторых особо сложных заданий на проекте.
— Какова роль тимлида на проекте?
— Её не всегда замечают, но она очень важная. Разработчики — люди творческие, поэтому нужен тот, кто сыграет консолидирующую роль: поможет распределить задачи, решить трудности между аналитиками и разработчиками. Они не всегда понимают друг друга: аналитики занимают определенную бизнесовую позицию, а интерес разработчиков лежит в технической плоскости. Кроме того, тимлид решает и некоторые управленческие задачи.
Главная цель: сделать так, чтобы всей команде было комфортно работать вместе, а творческое начало не угасло.
— Чем этот функционал отличается от руководителя группы?
— В IBS эти две позиции близки по функционалу, но имеют разный уклон. Руководитель группы решает и стратегические задачи подразделения — его внутренние квалификации, развитие конкретного сотрудника в профессии. Тимлид же занимается конкретным проектом и отвечает за то, чтобы он был сделан с максимально высокими показателями и в оптимальные сроки.
— Тебе бы хотелось объединить эти две роли? Или тебе комфортно именно в том функционале, который у тебя есть?
— Сейчас мне в данном функционале комфортно. С масштабной группой я давно не работала, а сейчас у нас очень большая проектная группа из трех модулей. Я тимлид на всех трех. Поэтому пока я не задумывалась об объединении ролей.
— Сколько у тебя человек выходит?
— С учетом группы разработки на всех этих модулях с нами работают приблизительно 14 человек. Если считать всю группу целиком, с тестировщиками и аналитиками, выйдет около 30.
— Можешь назвать три качества, которыми должен обладать хороший team leader?
— Гибкость. Работы много, и не всегда тимлид видит оптимальное решение. Ему нужно уметь объективно обсуждать с коллегами реализацию задачи, то, как ее лучше сделать. Если он с чем-то не согласен, не должен давить. Объяснить всем, что это за собой повлечет, какие могут быть минусы, какие плюсы у возможных решений.
Еще нужно обладать твердостью в определенном смысле. Потому что, как я говорю, разработчики — люди творческие. Бывает, делают что-то долго, на что-то не соглашаются, могут по-разному вести себя в рамках реализации задачи. Если это влияет на работу команды, на остальных участников, на сроки, то team leader должен жестко выстроить свою позицию, чтобы проект не пострадал.
Ну и, конечно, обязательно нужно иметь разноплановый бэкграунд, чтобы оценивать результат работы команды. То есть team leader в идеале вырастает либо из аналитика, либо из разработчика и, соответственно, свои ошибки и успехи в предыдущих проектах он должен помнить и применять на практике.
— Какие решения тебе обычно приходится принимать?
— Решения по распределению задач, по распределению команды по модулям, по срокам реализации задач, которые стоят перед внедрением. Для меня самые тяжелые решения — именно по срокам и планам срочных задач, по выходу команды в нерабочее время и по планированию сверхнагрузок.
— А самое приятное решение?
— Самое приятное решение — это когда мы всё успели и можно немного пораньше кого-то отпустить.
— Что тебе нравится в работе больше всего?
— Мне очень нравится, что у нас команда с разным бэкграундом и квалификациями. Люблю, когда коллеги делятся своими компетенциями внутри команды, чему-то друг друга учат. Это здорово, когда люди заинтересованы в результате своей работы, готовы ее обсуждать, внести какие-то предложения, которые улучшат конечный результат.
— Чем сейчас занимаешься в IBS?
— Я team leader на довольно сложном проекте, по нему идет основная разработка. Там значительный фронт работ, мы заняты и разработкой, и устранением замечаний. На нем занята самая большая проектная группа.
— Ты в IBS пришла сразу на должность тимлида или уже выросла внутри компании?
— В IBS я пришла в 2013 году с должности тимлида на позицию разработчика. То есть я на предыдущем месте работала с группой. Но она была достаточно маленькая, около 5 человек. И тимлидом группы я здесь стала, наверное, только в конце 2018-го. Мы принимали проекты, которые готовятся к внедрению, и один из модулей, самый крупный, достался мне.
— Как ты вообще пришла в IT?
— У меня образование смежное с IT. В принципе, я с института работаю в этой области на разных должностях. Если бы не стала разработчиком, думаю, могла бы стать аналитиком в какой-то смежной области IT.
— Из чего состоит твой обычный рабочий день?
— Львиная доля моей работы — это общение с командой, разбор новых задач, ревью выполненных задач, обсуждение. Начинается день с просмотра Jira, тасков, новых техзаданий, встреч. И какое-то время, примерно 10%, — потому что у нас большая группа — уходит непосредственно на кодинг.
— После того как ты стала тимлидом, ощутила нехватку свободного времени?
— Его стало гораздо меньше. Не катастрофически, но сама работа отличается от рутины разработчика. Когда ты кодишь, ты работаешь все же в другой плоскости, ты взаимодействуешь с конкретными задачами. А у тимлида большая часть времени уходит на коммуникацию и решение общих вопросов между разработкой, тестированием и аналитиками.
— Ты довольно активно ведешь себя на собеседованиях. Что ты чувствуешь, когда приходится оценивать других?
— Стараюсь лояльно подходить к оценке, потому что собеседование для кандидата — всегда волнительная ситуация.
По тем вопросам, которые я обычно задаю, видно, есть ли у человека бэкграунд и хорошо ли он ориентируется в определенной области. Но по собеседованию можно сделать вывод процентов на 20. К тому же человек всегда раскрывается во время испытательного срока, часто непредсказуемо и с неожиданной стороны.
— Может быть, у тебя есть какие-то истории об этом?
— У меня есть интересный пример с прошлой работы. На собеседовании человек отвечал корректно, стройно выстраивал цепочку рассуждений. Но за испытательный срок он не выполнил ни одну задачу. И наоборот, кандидат односложно отвечал на собеседовании, но при этом все задачи, поставленные на испытательный срок, были сделаны быстро и корректно.
— У тебя есть нелюбимые вопросы на собеседовании?
— Нелюбимые — из серии психологических, как любят задавать: «Какие ваши три самые лучшие качества, какие три ваших самых больших недостатка?». Потому что большинство айтишных специалистов — интроверты, не любят о себе рассуждать и часто теряются на этих вопросах.
— Технологические. В основном я сейчас веду собеседования, которые относятся к Java. Я спрашиваю по Java Core, по Spring, по Hibernate. И по ключевым знаниям, которые нам нужны для конкретных вакансий.
— А можешь вспомнить самое необычное собеседование?
— Необычное собеседование было со специалистом с хорошим бэкграундом и резюме: работа с математическими методами, работа на кафедре одного из очень успешных ВУЗов. И все собеседование он не давал поговорить собеседующим. Рассказывал о себе, о матметодах и о кафедре, о студентах. Мы не успели за час ему задать ключевые вопросы. В итоге его не взяли, но он в конце сказал, что мы ему понравились и он готов у нас работать
— Что ты читаешь, чтобы быть в курсе последних трендов?
— Блоги, Habr, смотрю разные семинары.
— Как считаешь, есть ли необходимость в профессиональных сертификатах?
— На мой взгляд, программа по сертификации, например по Java и Oracle, как минимум очень грамотно выстроена. Она дает представление обо всех возможностях языка, которые люди при самостоятельном изучении Java не всегда знают.
И это важные нюансы, которые при незнании сказываются на производительности кода, на каких-то малозаметных деталях. Поэтому это полезно.
Даже если разработчик просто прочитает полностью программу сертификации, обратит внимание на тонкости, которые он раньше не замечал при изучении, это уже не пройдет бесследно. Но если это выльется в сертификат, то это очень хорошо.
— Ты упомянула, что твое образование смежное с IT-сферой. Можешь рассказать подробнее?
— Я училась на одной из интересных кафедр Российского государственного гуманитарного университета. Это смежная с IT область — переводчики, анализаторы данных. Они всегда востребованы и сейчас широко развиваются. Наши выпускники работают в «Яндексе», в исследовательских программах. Одна из коллег работает в Samsung.
Когда я сама ходила по собеседованиям, у меня всегда спрашивали: «Почему у вас гуманитарное образование, а вы пришли к нам на должность программиста?». На самом деле мое образование, условно говоря, на 50% гуманитарное и на 50% техническое. Оно связано с автоматическим переводом, с гуманитарными науками в области IT.
— А что ты можешь порекомендовать тем, кто хочет стать тимлидером?
— Терпения. Потому что это не только работа с кодом, но и работа с людьми, работа на результат с командой. Поэтому нужно запастись терпением и желанием что-то построить.
Что должен делать тимлид: роли, обязанности и навыки
Тимлид (Team Lead) – специалист, который руководит командой разработчиков. Это должность, а не профессия. Нельзя пройти курсы и стать лидером команды. Единственный путь – это получение опыта и наращивание профессиональных компетенций.
Чем занимается тимлид
Тимлид руководит командой разработчиков. Обычно он не пишет код (хотя может). Обычно он не думает об архитектуре (хотя может).
Общается с клиентами или бизнес-подразделениями компании.
Оценивает задачи, сроки каждого этапа, разбивает их на спринты.
Распределяет нагрузку между разработчиками.
Следит за тем, чтобы таски закрывались в срок.
Оценивает решения разработчиков, дает рекомендации.
Согласует с заказчиком готовую работу.
Тимлид несет ответственность за проект. Сроки сорваны – виноват тимлид. Хотите добавить еще фичи – разговаривайте с тимлидом (он скажет, что этот спринт уже заблокирован, но, возможно, в следующем возьмутся за вашу фичу – если сможете ее «продать»).
На тимлиде также лежат обязанности по формированию команды, онбордингу, поддержанию рабочей атмосферы. Нагрузка может быть разной. В одних компаниях тимлиды закрывают весь цикл найма разработчиков – от поиска и собеседования до онбординга и менторинга. В других компаниях тимлиды подключаются только на этапе финального собеседования с кандидатом и принимают решение о том, выдавать ли оффер.
От тимлида во многом зависит, будут ли разработчики расти профессионально. Решать эту задачу можно разными способами: проводить код-ревью, обсуждать код на индивидуальных или общих встречах, заниматься парным программированием.
У хорошего тимлида джуниоры быстро растут до мидлов. У плохого – занимаются формошлепством месяцами и не понимают, как их работа помогает бизнесу.
Какие навыки нужны тимлиду
Должность тимлида находится на стыке разработки и менеджмента. Поэтому бизнес ждет от него мощных хард- и софт-скиллов.
Опыт работы от 3-5 лет – и желательно, чтобы он включал опыт руководства хотя бы небольшой командой.
Опыт проведения код-ревью, менторинга – потому что придется помогать другим разработчикам, подтягивать джуниоров.
Умение принимать решения и брать на себя ответственность – все, что происходит с проектом, становится головной болью тимлида.
Аналитические способности и критическое мышление – для правильной оценки сложности задачи, расстановки приоритетов.
Навыки делегирования – чтобы грамотно распределять задачи между членами команды.
Знание HR – нужно разбираться в кадровой политике, потому что точно придется участвовать в формировании команды и наборе сотрудников.
Умение мотивировать сотрудников – и вообще общаться с людьми, в том числе предотвращать конфликты.
Тайм-менеджмент – для выставления реальных сроков решения задач.
Тимлид должен быть экспертом в том стеке, который использует команда. Необязательно быть лучшим во всем – это просто невозможно. Но в случае форс-мажора лидер должен быть способен заменить любого члена команды хотя бы на уровне поддержания жизнеспособности проекта.
Как стать тимлидом
В идеальном представлении путь до тимлида выглядит так:
В неидеальной жизни дорога может быть куда более сложной. Но многое зависит от размера компании и сложности проекта. А еще – от навыков человека. Не каждый сеньор может и хочет становиться тимлидом. Не всем нравится управлять людьми, общаться с бизнес-подразделениями и клиентами.
Тимлидом могут назначить и менеджера, который отлично умеет работать с клиентами. Но это ошибка, из-за которой пострадает процесс разработки. Если среди разработчиков не найдется неформальный лидер, то работа встанет. Менеджеру, который не имеет опыта в разработке, не удастся правильно оценить объем работы и распределить задачи.
Чему нужно научиться, чтобы стать тимлидом
Чтобы стать тимлидом, разработчику нужно развивать в себе менеджерские компетенции. Придется научиться:
переключаться между разными задачами,
распределять нагрузку между членами команды,
общаться с бизнесом.
Единственный способ понять, сможете ли вы быть тимлидом, – попробовать. Брать на себя больше ответственности, выполнять задачи «под ключ», чаще общаться с продакт-менеджерами, клиентами и бизнес-подразделениями компании, чтобы развить в себе продуктовое мышление.
«Быть» – новый подкаст от команды Timeweb, в котором участвуют представители различных айтишных профессий. Вы узнаете, чем они занимаются, какие навыки для этого нужны и что им доставляет наибольшее удовольствие в работе. Первый выпуск подкаста посвящен вопросам тимлидинга.
Гайд начинающего тимлида
В данной статье хотелось бы помочь разобраться в профессии начинающим тимлидам, или тем, кто об этом только думает.
Однако я уверен, что есть такие люди, которым не хочется 2 часа смотреть вебинар, а хочется за 15 минут прочитать структурированный текст. Поэтому я размещу его тут, в надежде, что он найдет своего заинтересованного читателя.
Шаг номер 0. Зачем?
Итак, вам предложили стать тимлидом или вы сами захотели им стать. Что надо сделать в первую очередь? Хорошенько подумать, а надо ли оно вам.
Я искренне убежден, что в тимлиды стоит идти, если только вы хорошенько порефлексировали и поняли, что сердечко вам подсказывает: это ваш путь.
Я общался с многими состоявшимися специалистами в этой профессии и все они говорят примерно одно и то же:
Кто-то туда идет, потому что ему нравится работать с людьми, помогать им, развивать их. Тут безусловно найдется поле для деятельности. Море работы с людьми, развитие команды, помощь соседним отделам и т.д.
Ложные цели, на которые не надо вестись:
Больше денег. В большинстве тимлидских вакансий зарплата выше сениорской не намного, а порой может быть даже и ниже. При этом всём тимлид разрывается между командой, сроками, заказчиками, кодом, процессами, бизнесом и так далее. В то время, как сениоры спокойно пилят код и иногда ревьювят код коллег.
Больше власти. Да, повлиять вы можете на что-то больше, чем рядовой разработчик, но спрос с вас будет тоже ощутимо выше. При этом зачастую реальной власти у тимлидов особо и нет. Очень часто бюджеты, найм, увольнения и прочие реальные административные рычаги в других руках. В итоге какую команду вам дали, такую и тащите, да при этом чтобы результаты были феерические.
Повышение уровня ЧСВ. Ничего особо крутого в этой должности нет. Это просто очередная должность чуть выше рядовой. Как ефрейтор или сержант в армии. Вроде лычка есть, но хвалиться особо нечем, и вокруг куча таких же.
Второе, на что надо обратить внимание при рассмотрении данной должности: тимлиды бывают разные.
Каждая компания вкладывает в эту позицию свой уникальный смысл. Где-то нужен полуменеджер-полуразработчик, где-то техлид/архитектор, где-то пипл менеджер и т.д.
Советую заранее узнать, что же именно от вас требуется.
Однако при недобросовестном или просто непонимающем работодателе, от вас будут ожидать примерно 100% менеджмента и 100% написания кода. Постарайтесь узнать об этом как можно раньше, чтобы СБЕЖАТЬ.
Про тимлидство существуют сотни статей, видео, книг, курсов и т.д. Фильтровать нужно тщательно.
Прилагаю список того, что мог бы порекомендовать я из более-менее основательного. Статьи и какие-то выступления с конференций вы можете найти и отобрать самостоятельно.
М. Уоткинс «Первые 90 дней». Хорошая и вдумчивая книга о том, как успешно адаптироваться к переходу на новую должность. Чем заняться в первые 90 дней. И о том, что эта адаптация, как системный процесс, нужна не просто конкретному индивиду, а всей компании в целом.
Дж. Ханк Рейнвотер «Как пасти котов». Книга для начинающих или будущих управленцев вполне хороша и толкова (пусть и немного стара). Однако для людей с опытом, наверное, будет немного кэпской.
Ф. Брукс «Мифический человеко-месяц». Расскажет об управлении проектами: как надо, как не надо, и почему 9 женщин за 1 месяц не смогут родить ребенка. Есть мнение, что книга несколько устарела, тем не менее, если вы в этом не очень разбираетесь, то она обогатит вас полезными идеями.
Э. Голдратт. «Цель. Процесс непрерывного совершенствования». Классический художественный роман, объясняющий на разных примерах теорию ограничения систем. Чтиво интересное и полезное.
Д. Ким, К. Бер, Д. Спаффорд. «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему». Очень интересная и поучительная книга, которая в художественном формате рассказывает о том, как в ИТ подразделении улучшают процессы работы, приходят к DevOps идеологии и спасают бизнес.
Т. ДеМарко «Deadline. Роман об управлении проектами». Еще одна книга в художественном формате. Легкое и интересное чтение об управлении ИТ проектами.
Т. ДеМарко, Т. Листер «Вальсируя с Медведями». Порекомендовал бы эту книгу для средних и крупных проектов. Излечивает от наивности, открывает глаза на происходящее. Показывает, что случиться может много чего и рассказывает, как с этим жить и работать.
М. Дорофеев «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо». Книга не про программирование, но программистам, тимлидам, менеджерам точно пойдёт на пользу. Очень толковая книга по личной эффективности, организации задач и т.п. Всем настойчиво рекомендую.
М. Ильяхов, Л. Сарычева «Новые правила деловой переписки». Замечательная книга. Смело её рекомендовал бы и разработчикам, и менеджерам, и вообще примерно всем. О том как в переписке быть толковым, уважительным, приятным и эффективным. Очень многим этого не хватает.
А. Орлов «Джедайские техники конструктивного общения». Коротко, по делу, с примерами. Однозначно рекомендую. И в работе пригодится, и в быту.
М. Гоулстон «Как разговаривать с мудаками». Книга придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже:)
Роадмап тимлида https://tlroadmap.io/ Очень полезный инструмент, который поможет разобраться, какие бывают требования к тимлидам, понять, что с ними делать и как подтягивать свои знания. Также подойдет как хороший инструмент для того, чтобы обговорить со своим руководителем на начальном этапе работы, что же конкретно от вас ожидается.
Регулярные двухнедельные тимлидские конференции от ребят из подкаста Podlodka https://podlodka.io/tlcrew Там много хороших докладов и душевное отзывчивое комьюнити, с которым можно порой пообсуждать в деталях то, за что обычно деньги берут на платных индивидуальных консультациях.
Шаг номер 2. Общий план первоначальных действий
От теории переносимся к практике.
Первым делом необходимо разобраться: кто руководитель, кто заказчики, кто кому подчиняется, а кто нет. Желательно всё записать, а еще лучше составить визуальную схему а-ля mindmap, глядя на которую будет видна общая картина всех отделов и действующих лиц.
Далее, когда вы поняли официальную часть, надо погрузиться в неофициальную.
В каждой компании и команде существуют свои неформальные лидеры, нерегламентированные связи, знакомства, опасные проекты, люди и т.д. Очень важно это всё понимать и учитывать. Иными словами, тимлиду приходится быть не просто хорошим трудягой, но еще и опытным политиком. Лично мне эти подковерные истории не очень нравятся, я стараюсь держаться от них подальше, но целиком избежать не получается, как бы я ни старался.
Какие назначить первые встречи, чтобы во всё это погрузиться?
Когда с начальником все разговоры проговорены, придет время встречаться с командой, заказчиками и смежными отделами. Очевидно, что будут общие встречи, которые вы проведете с ними, представитесь, расскажете о себе, что-то обсудите, примете какие-то решения. Но не пренебрегайте и встречами индивидуальными. Постарайтесь уделить каждому действующему лицу немного личного времени. Обсудите с ними, как они видят сейчас дела в команде и компании, какие испытывают затруднения, что считают сильными моментами, какие у них взгляды на дальнейшие перспективы. Отнеситесь к этим разговорам внимательно. Они позволят:
взглянуть на текущую ситуацию с разных сторон;
узнать какую-то историю, которая творилась еще до вас;
проанализировать самих людей;
понять ожидания этих людей от вас.
Здесь я коротко рассмотрю типичные проблемы и как с ними бороться.
Проблема с внешними коммуникациями
Авторитет и субординация в команде.
Отношения с руководством.
Есть такая штука, как матрица доверие-прозрачность.
Если кратко, то изначально к вам мало доверия и это доверие можно заслужить, не просто добросовестно выполняя свою работу, а повышая прозрачность того, как вы это делаете. Для руководства не должно быть черных ящиков, будьте открыты, умейте всегда объяснить что, зачем и почему вы делаете. Стройте такую систему работы, в которую без вашего участия можно заглянуть и более-менее понять, что у вас происходит.
Общение с заказчиками.
Тут поможет применение той же идеи, что и с руководством, плюс какая-то понятная формализация процессов общения. Придумайте регламент, как и по каким каналам связи заказчик может с вами связаться, как и когда он ставит задачу, как принимает, как обсуждает с вами и т.д. Не допускайте того, что один заказчик пишет вам в телеграм, другой на почту, третий звонит напрямую разработчику в обход вас, а четвертый звонит лично вам, но только в ночь с субботы на воскресенье просто потому, что интересная идея в голову пришла перед сном.
Проблема с самим собой
Синдром самозванца.
Меньше пишешь код, теряешь позиции на рынке среди технарей.
Действительно, тимлиды меньше пишут код. И это нормально, что они замедляют рост своих технических компетенций.
Тут надо понять, что ценность этой позиции не в том, чтобы быть самым крутым технарем (хотя хороший технический бэкграунд, безусловно, важен). Ценность в том, чтобы быть на стыке разработки и бизнеса, людей и процессов, хард и софт скиллов. Хороших разработчиков, на мой субъективный взгляд, больше, чем хороших тимлидов. Поэтому, теряя позиции на рынке труда разработчиков, вы можете открыть для себя новый, менее насыщенный кандидатами, рынок тимлидов.
Проблема с объемом работы
Неумение и страх делегировать.
Частая проблема начинающего тимлида. Кажется, что вы можете всё сделать лучше всех, поэтому всё делаете сами. И в результате может оказаться, что вы делаете кучу работы за других людей, а потом свою доделываете по вечерам, и от этого страдаете.
Микроменеджмент и чайка менеджмент.
Тоже большие проблемы не только начинающих, но и продолжающих. Если микроменеджмент растет из страха делегирования, то чайка менеджмент растет скорее из лени и безалаберности. Бороться нужно усердной работой над собой и самоанализом на тему «а не фигню ли я делаю, как менеджер?».
Остается мало времени на повышение квалификации.
А чему учиться-то, хардам, или софтам?
Замечательный вопрос. Конечно, как начинающему тимлиду, я бы рекомендовал окунуться в бескрайний океан софт скиллов и менеджмента, потому что это именно то, чего у вас было мало, как у разработчика, и то, чего от вас ждёт работодатель.
Стоит ли совсем бросать хард скиллы? В кругах тимлидов ходит много споров об этом. Лично я не бросаю. Качаю и харды, но времени на это у меня остается довольно мало. Раньше меня это расстраивало, а сейчас нет, потому что я понял и прочувствовал, что как менеджер я могу принести проекту и команде больше пользы, чем как разработчик.
Проблемы со здоровьем ментальным и физическим
Гигиена труда и образ жизни.
Чтобы вы не заболевали, не выгорали, не чувствовали, что жизнь проходит мимо, я хочу дать несколько советов:
— Постарайтесь поменьше овертаймить. Всю работу не переделаешь. Делайте сначала важную, а что-то менее важное уже можно будет перенести, отложить, или даже отменить. Не повторяйте моих ошибок. Однажды я так овертаймил, что на пару месяцев от нервного напряжения перестал ощущать вкус (это было задолго до коронавируса). Или 3 месяца работал по 260 часов в месяц, а потом целый год не хотелось не то что работать, а вообще ничего в жизни не хотелось.
— Следите за своим физическим здоровьем. Правильно питайтесь, хорошо спите, занимайтесь физкультурой, и вот это вот всё. Это важно особенно в формате удаленки, когда некоторые люди просто целый день или лежат, или сидят, согнувшись над клавиатурой. Поверьте, вы из будущего скажете спасибо вам из настоящего.
— Помните, что за пределами монитора и работы тоже существует жизнь. Иначе можно в какой-то момент понять, что в последние N лет кроме дедлайнов, тасок в жире, проектов и заказчиков вы ничего и не видели, хотя мечтали (возможно) о чем-то другом.
Важность рефлексии, что в работе, что в быту.
Очень важно думать о том, что и как вы делаете, что в рабочих моментах, что в бытовых. И неплохо бы делать это не стихийно, а систематически. Порой нас так затягивает рабочая и бытовая рутина, что мы барахтаемся в этом болоте, даже не замечая его. А регулярность подходов к рефлексии заставят систематически вытаскивать голову из болота, глядеть по сторонам, понимать, что мы делаем, зачем и как, а также насколько мы этим всем удовлетворены.
Шаг номер 4. Полезные качества для тимлида
Полезные качества, которые надо в себе взращивать:
Умение не сойти с ума при многозадачности.
Тут поможет умение выделять приоритетные задачи, а менее приоритетные делегировать и правильно контролировать.
Умение разговаривать на языке собеседника.
Умение говорить «нет».
Прям обязательное умение. Без него вы быстро будете погребены под тоннами задач со всех фронтов. И ладно бы просто вы, а еще и ваша команда, потому что заказчикам вы тоже отказывать не умеете. Иной раз умение сказать «нет», а заодно и предложить какой-то более простой вариант, про который заказчик не подумал, может сэкономить целые человекомесяцы труда и соответствующее количество денег.
Дисциплина.
Чтобы успешно управлять не только своим трудом, но и работой всей команды, нужна система. А чтобы система работала, нужна дисциплина. Стоит только чуть ослабить дисциплину, как появляются и начинают множиться разбитые окна. Чтобы дисциплина в команде появилась и закрепилась, безусловно, нужно заниматься просвещением и контролем, но лучше всего начинать с личного примера. Покажите людям, как приносит пользу ваша самодисциплина, и это будет убедительнее многочасовых теоретических рассказов.
Эмпатия.
Шаг номер 5. Что делать дальше?
Продолжайте учиться.
Самообразование в этой сфере не заканчивается никогда. Индустрия быстро бежит вперед, так что нужно не просто учиться, а делать это регулярно и довольно интенсивно.
Продолжайте (или начинайте) общаться с разными людьми в индустрии.
Я поработал и пообщался с довольно большим количеством программистов и тимлидов из разных (десятки) компаний, и оказалось, что многие из них не высовывают нос за пределы своей работы, своего отдела. Люди не знают, как обстоит с технологиями, процессами, общением, условиями труда в других компаниях. Это незнание толкает их на переизобретение одних и тех же велосипедов, а также не позволяет хоть сколь объективно оценить положение дел в своей компании.
Искренне рекомендую общаться со специалистами из разных компаний, делиться своим опытом и узнавать чужой. Это сильно расширит ваш кругозор. А где расширяется ваш кругозор, как специалиста, там и увеличивается польза для компании от вас. Так что не думайте, что это просто праздная болтовня, это вклад в вашу ценность.
Всегда критически мыслите.
Как только вы начинаете узнавать много нового и интересного, всегда появляется желание тут же это затащить себе в проект. Тут я призываю остановиться и хорошенечко поразмыслить. Не тяните что-то к себе, просто потому что про это классно рассказали на докладе или написали в книге.
Проанализируйте свою конкретную ситуацию, предложенные инструменты со всеми их плюсами и минусами. Вдумчиво внедряйте и внимательно смотрите на результаты. Работает ли это так, как прогнозировали, или что-то пошло не так? Стоит ли оставить этот инструмент, или заменить другим? Нужен ли тут вообще какой-то инструмент, или мы занимаемся оверинжинирингом ради непонятной выгоды?
Дополнительные материалы
Какие-то темы я не стал подробно раскрывать, потому что и текст получился бы слишком длинным, да и я уже писал об этом ранее в своем телеграм-канале. А копипастить, или повторяться не хочется.
Здесь я приложу список релевантных этой статье постов из канала. Это ни в коем случае не самореклама. Статья самодостаточная и без этих материалов, так что это просто факультатив, для тех, кто хочет узнать еще немного больше.