Тимлид

Страх №1. Ты не востребован на рынке

Буду получать меньше, чем сейчас

• 144–294 тыс. рублей, если являетесь профессионалом, который, возможно, менторит пару человек, но едва ли исполняет весь набор функций тимлида.
• 175–357 тыс. рублей, если вы тимлид небольшой команды.
• 225–491 тыс. рублей, если вы тимлид большой команды в 10-30 человек или менеджер менеджеров.

Как победить страх, что ты не востребован на рынке

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

Ходить по собеседованиям не обязательно значит хотеть сменить работу. Это не страшно, за это не наказывают.
Teamlead Roadmap

Растить замену ещё полезнее

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

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

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

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

Проблемы со списками задач

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

Чтобы навести порядок, я начал договариваться с каждым человеком в команде перейти обратно в общий трекер и не забивать на статусы. От себя я пообещал, что за 2-6 недель наведу порядок в трекере. А для того, чтобы история поехала, ввёл несколько правил. Во-первых, разработчик берёт в работу самую первую задачу из списка. Не надо смотреть на приоритеты, на северити, читать комментарии или что-то спрашивать. Если задача вверху, значит её нужно делать. Тем самым мне удалось уменьшить нагрузку на ребят, избавив их от трат времени по выяснению, что нужно делать. Во-вторых, я снял ответственность за то, что была сделана ненужная задача. Т.е. если ненужная задача оказалась вверху списка, то виноват в этом лид, т.е. я. Без каких-либо оговорок.

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

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

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

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

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

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

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

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

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

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

Team Leader

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

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

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

https://youtube.com/watch?v=zTwfLhJLDkI

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

ИТ-курсы с трудоустройством

У нас ты обучишься востребованной профессии и получишь старт IT-карьеры. Программы курсов разработаны совместно с нашими IT-партнёрами. При успешном прохождении курса ты будешь рекомендован к нашему партнёру в команду!

Записаться на пробное занятие

Спасибо, что дочитал до конца. Мы рады, что были полезны. Чтобы получить больше информации, посмотри ещё:

Не пропускай важные новости и подписывайся на наш YouTube, ВК, Instagram, и уведомления на adukar.by.

***

Если хотите разместить этот текст на своём сайте или в социальной сети, свяжись с нами по адресу info@adukar.by. Перепечатка материалов возможна только с письменного согласия редакции.

Стиль спускается каскадно от топ-руководителей

Есть один важный нюанс. Скорее всего, вы не идете на работу в маленький стартап, где вашим руководителем будет сам основатель. Это значит, что у вашего руководителя будет ещё как минимум один руководитель на уровень выше. Если ваш непосредственный руководитель — милейший человек, который всегда «за своих орлов», а его руководитель — авторитарный деспот с усами, то так или иначе вы будете ощущать авторитарную нотку управления на себе. Если кто-то из директоров вздумает установить в офисе камеры и будет лично следить за тем, кто уходит на 15 минут раньше положенного, то никто вам не поможет. Каким бы подходящим ни был ваш тимлид, он будет не в силах спасти вас от бушующего СТО. Именно поэтому при собеседовании нужно задавать вопросы по фреймворку STAR или PARLA, узнавать отзывы бывших сотрудников

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

С чего всё началось

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

Построение масштабируемой схемы. Отход от роли «кольца всевластия»

Одна из самых частых негативных историй, которые я слышу от разработчиков про lead’ов — все интересные куски лид забирает себе. От лидов же получаю другой фидбэк, что самая частая проблема — есть задача и её ВООБЩЕ НИКАК!!!111 нельзя делегировать.Отсюда вытекает ряд проблем.

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

Весь ваш ориентир или хайповое слово KPI заключается только в вашей команде. Если есть крутая команда, которая сплоченно, быстро делает продукт и соблюдает процессы — вы хороший лид. Старайтесь постепенно повышать различного рода компетенции в других людях

Крайне важно, чтобы это было осознанным выбором самого человека, а не навязанной сверху практикой

Краткая история

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

Должность тимлида появилась сравнительно недавно. «Родила» ее IT-сфера. Здесь работа над каким-либо проектом предполагает слаженную деятельность целой команды, которая состоит из менеджера, программиста, дизайнера, верстальщика, контент-менеджера, директолога, SEO-специалиста. Каждый из них отвечает за свой сектор, но не видит всей картины в целом. Team lead организовывает, координирует и оптимизирует их работу. Кроме того, ему хорошо известен поэтапный процесс создания веб-продукта, он четко представляет себе, каким должен быть финальный результат.

Авторитетный стиль

Справиться с этой проблемой помогает авторитетный стиль. Авторитетный лидер — он как самый энергичный таксист на районе, который знает все новости города, где выпить самый вкусный кофе, куда поехать в поисках приключений и какой номер телефона у Людочки из бюро находок в аэропорту; самый полезный человек, с которым вы когда-либо могли завести знакомство. Так и авторитетный лидер – обладает наиболее полным и четким видением стратегии компании, знает, зачем и что мы делаем, способен замотивировать самого Тони Робинсона и в некоторых случаях даже Шайя ЛаБафа.

 Это самый крутой стиль лидерства, если верить исследованиям в статье Гоулмана. На самом деле он частично включает в себя все другие стили. Авторитетный лидер описывает Definition of Success и говорит, что нужно сделать, чтобы добиться успеха. Может показаться, что он авторитарен, но на смену принуждению и контролю диктаторского подхода приходит мотивация и свобода в выборе средства достижения результата. Как и при образцовом стиле, авторитетный лидер требователен к себе и своим сотрудникам, но, если сотрудник не справляется с поставленной задачей, это является не поводом его «слить», а точкой роста и поводом применить обучающий стиль. 

Именно таким должен быть настоящий лидер

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

Варианты будущего роста

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

Junior

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

Шаг номер 1. Знание — сила!

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

Про тимлидство существуют сотни статей, видео, книг, курсов и т.д. Фильтровать нужно тщательно.

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

• М. Уоткинс «Первые 90 дней». Хорошая и вдумчивая книга о том, как успешно адаптироваться к переходу на новую должность. Чем заняться в первые 90 дней. И о том, что эта адаптация, как системный процесс, нужна не просто конкретному индивиду, а всей компании в целом.

• Дж. Ханк Рейнвотер «Как пасти котов». Книга для начинающих или будущих управленцев вполне хороша и толкова (пусть и немного стара). Однако для людей с опытом, наверное, будет немного кэпской.

• Ф. Брукс «Мифический человеко-месяц». Расскажет об управлении проектами: как надо, как не надо, и почему 9 женщин за 1 месяц не смогут родить ребенка. Есть мнение, что книга несколько устарела, тем не менее, если вы в этом не очень разбираетесь, то она обогатит вас полезными идеями.

• Э. Голдратт. «Цель. Процесс непрерывного совершенствования». Классический художественный роман, объясняющий на разных примерах теорию ограничения систем. Чтиво интересное и полезное. 

• Д. Ким, К. Бер, Д. Спаффорд. «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему». Очень интересная и поучительная книга, которая в художественном формате рассказывает о том, как в ИТ подразделении улучшают процессы работы, приходят к DevOps идеологии и спасают бизнес.

• Т. ДеМарко «Deadline. Роман об управлении проектами». Еще одна книга в художественном формате. Легкое и интересное чтение об управлении ИТ проектами.

• Т. ДеМарко, Т. Листер «Вальсируя с Медведями». Порекомендовал бы эту книгу для средних и крупных проектов. Излечивает от наивности, открывает глаза на происходящее. Показывает, что случиться может много чего и рассказывает, как с этим жить и работать.

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

• М. Ильяхов, Л. Сарычева «Новые правила деловой переписки». Замечательная книга. Смело её рекомендовал бы и разработчикам, и менеджерам, и вообще примерно всем. О том как в переписке быть толковым, уважительным, приятным и эффективным. Очень многим этого не хватает.

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

• М. Гоулстон «Как разговаривать с мудаками». Книга придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже:)

• Роадмап тимлида https://tlroadmap.io/ Очень полезный инструмент, который поможет разобраться, какие бывают требования к тимлидам, понять, что с ними делать и как подтягивать свои знания. Также подойдет как хороший инструмент для того, чтобы обговорить со своим руководителем на начальном этапе работы, что же конкретно от вас ожидается.

• Курсерный курс https://www.coursera.org/specializations/product-management Долгий и основательный курс, который покрывает всё про управление проектами. Выявление требований, план рисков, декомпозиция и распределение задач, аджайл техники и прочее. Вы справедливо можете заметить, что этот курс нужен менеджерам проектов, а не тимлидам. Теоритечески — да, а на практике возможно, что если у вас менеджер проекта и есть, то в каких-то деталях он может не очень разбираться. Тогда понадобится ваше участие.

• Регулярные двухнедельные тимлидские конференции от ребят из подкаста Podlodka https://podlodka.io/tlcrew Там много хороших докладов и душевное отзывчивое комьюнити, с которым можно порой пообсуждать в деталях то, за что обычно деньги берут на платных индивидуальных консультациях.

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

Реакция вашего друга на вопрос о стиле его руководителя

Альтернативным способом получить такую информацию является… собеседование. Если вы хотя бы раз проходили собеседование в любую компанию, то наверняка слышали вопросы вроде: «Кем вы видите себя через 5 лет?», «Назовите ваши слабые стороны» и т.д. Очевидно, что все эти вопросы задают не с целью потянуть интервью подольше, они нужны для определения софт-скиллов. На самом деле такими вопросами можно многое узнать о мотивации кандидата, составить его психологический портрет. Такого рода вопросы — это мощный инструмент, который можно использовать и в обратную сторону. Не упускайте свою возможность задать вопросы, когда вам дают слово, попросите о дополнительной сессии с будущим начальником, коллегами. Задавайте вопросы, пока не сформируете полное представление о стиле руководства в компании. Конечно, этими техниками нужно уметь пользоваться, и если вы не знакомы с софт-скилловой стороной проведения собеседований, почитайте про интерпретацию фраз-маркеров, фреймворки STAR и PARLA. Как и в случае с любым другим инструментом, чем больше вы будете практиковаться, тем лучше у вас будет получаться.  

Про devrel

Я слышал, что у вас есть школа спикеров? Можешь рассказать про нее подробнее?

Да, Speakers Club. В 2016 году на devconf я слушал про IT-бренд — для меня это была совершенно новая область, т.к. в компаниях, где я работал, этого не было. На докладе рассказывалось что такое IT-бренд, какие есть способы его прокачки и как это делать.

Я вернулся с доклада и поднял вопрос о том, чтобы начать прокачивать IT-бренд в Lamoda. Именно в этот момент к нам пришла Женя Голева, наш действующий devrel.

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

По результатам года работы Speakers Club мы подготовились и выступили на HighLoad и на других конференциях.

Speakers Club существует 4 года и мы собираемся каждые 2 недели. Люди приходят туда за тренировкой — тема не имеет никакого значения. Можно прийти рассказывать хоть про морских рыбок:) Главное — нужноприходить без презентации и просто начинать выступать. Дальше уже ведется работа над подачей, работой с аудиторией, структурой повествования и так далее. Главная идея клуба — возможность получить обратную связь о своих навыках, и получить её в максимально безопасной атмосфере.

Наш devrel работает с руководителями отделов, которые потом доносят до сотрудников мысль о том, что они могут выступать и тратить время на подготовку докладов. Людям, которым было бы интересно выступить, но они считают, что это не умеют, приходят за поддержкой в Speakers Club. Мы стараемся шарить опыт публичных выступлений и рассказываем про полезность выступлений на конференциях.

Например, на следующей неделе у нас будет мероприятие IT Gathering. На нем IT-руководство рассказывает о результатах работы за квартал: что мы сделали хорошо, что плохо, и какие у нас планы на следующий квартал. Также там выступает и devrel, рассказывает про состояние бренда, его стратегию и планы. Мы регулярно напоминаем сотрудникам о том, что можно выступать публично и почему это хорошо.

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

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

Это упражнение позволяет пробить стену с синдромом самозванца и ощущение, что “все, что я делаю скучно и неинтересно”. Когда ты слушаешь вопросы своих коллег и понимаешь, что если внутри компании есть люди, готовые задать интересный вопрос, то значит и снаружи, скорее всего, этот опыт можно интересно изложить. Дальше, при работе над докладом, можно рассчитывать на поддержку devrel либо других опытных спикеров.

То есть у вас нет проблем с трафиком людей желающих выступить?

Это постоянный фокус, над которым мы работаем. По щелчку пальцев кучу докладов создать не получается, но есть объем наработок, чтобы регулярно что-то писать на Хабр и делать стабильно по 20-30 докладов в год уже несколько лет. То есть проблемы нет, но работать над этим постоянно приходится — люди в основном думают о своих задачах, а не о том, чтобы выступать.

Выбрасываем все лишнее

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

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

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

У рекрутеров в ходу есть такой мем;)

Какие знания и навыки у него должны быть

Какие личностные качества должен иметь тимлид? Список довольно обширный, но ведь и ответственность у руководителя большая:

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

Teamlead должен иметь минимум 5 лет опыта в IT области. Что потребуется ему для успешной работы:

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

И это список только наиболее важных требований. Работа требует навыков работы с Linux based дистрибутивами, знания Agile, PHP, Scrum, MySQL, JavaScript. Могут еще встречаться условия, имеющие отношение к конкретной сфере работы заказчика.

Какие требования чаще всего звучат в описании вакансии тимлида:

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

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

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

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

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

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

Обязанности Team Lead-а

Следит за соблюдением стандартов качества при разработке.
Именно задачей тимлида является следить за тем, чтобы команда писала код, соответствующий стандартам компании, и выдавала качественный продукт.

Следит за соблюдением приоритетов.
Также тимлид должен следить за тем, чтобы команда соблюдала приоритеты при работе и вообще знала о том, что является наиболее важным на каждом конкретном этапе производства программного продукта.

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

Несет ответственность за все проблемы или сложности в коллективе

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

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

Понимает и может внедрять разные процессы и методологии в кодинге.
Также Team Lead должен иметь представление и уметь внедрять с пользой для проекта различные методологии в команде программистов, такие, например, как Scrum, Kanban, XP, Lean и так далее.

Распределяет ответственность.
Задачей тимлида является организация нагрузки таким образом, чтобы никто из членов команды не был единственным способным реализовать ту или иную часть проекта. Чтобы команда была эффективной и продолжала работать, даже если кого-то из специалистов нет на месте.

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

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