Привет, Хабр! Один из «вечных» споров в IT – о том, как развиваться разработчику: прокачивать хардскиллы или навыки управленца? Если и вы задаете себе этот вопрос, давайте вспомним 5 известных мифов о работе тимлида – и конечно, сравним их с реальностью.
Меня зовут Александр, уже более года я веду наш внутренний проект по обучению – «Академию тимлидов». За год обучение прошли 80 разработчиков. Наш опыт показывает, что чаще всего специалисты правильно представляют будущие задачи и имеют перед собой конкретные цели. При этом бывает и так, что ожидания начинающего тимлида не совпадают с практикой.
Почему это происходит? Что делает тимлид на самом деле? Предлагаю вспомнить самые частые заблуждения и заодно разобрать конкретные задачи, которые тимлиду предстоит решать.
Нередко можно услышать мнение, что тимлид – ведущий разработчик, который использует свои лидерские качества для управления командой, но не ограничивается управлением. На практике к роли тимлида обычно переходят постепенно, и специалист посвящает больше времени управлению, чем разработке.
Конечно, в каждой компании есть свое представление о том, кто такой тимлид и что входит в его обязанности. При этом роль управленца в IT критически важна, как и в других сферах.
В первую очередь, тимлид необходим в масштабных проектах и распределенных командах, когда крупную IT-систему – например, банковскую – совместно создают и инхаус-разработчики, и несколько внешних подрядчиков.
Тимлид смотрит на проект комплексно и помогает специалистам действовать так, как будто они – единое целое. С самого начала работы он выстраивает комфортную и дружелюбную атмосферу в команде. Для каждого участника он подбирает подходящее задание и контролирует этапы его выполнения. Также тимлид может проводить качественное код-ревью, предлагать улучшения при наличии проблем и рисков.
При этом, несмотря на значимость роли тимлида, существует и прямо противоположный миф, о котором расскажем ниже.
Соотношение технических задач к управленческим может быть разным – например, 70/30, 80/20 или даже 50/50.
По мере развития проекта управленческие задачи могут отнимать все больше времени. Это значит, что тимлид действительно иногда развивает свои технические скиллы медленнее, чем другие разработчики в команде.
Впрочем, у таких ситуаций всегда есть решение – в зависимости от дальнейших целей специалиста, можно прокачивать технические или управленческие навыки.
Однако, этот фактор важно учитывать, поэтому при выборе тимлида основываются не только на хардскиллах. Наверное, многие слышали или даже видели, как в тимлиды выбирают просто толкового разработчика, а потом он либо “затухает”, демотивируется, либо из-за нехватки у него навыков ситуация на проекте становится напряженной.
Наша практика показывает, что как на обучение тимлида, так и на погружение в задачи нужно достаточно много времени. Возьмем давний пример из нашей практики, который и подтолкнул нас к созданию внутренней «Академии тимлидов».
Этот миф – как и предыдущий, об отсутствии развития у тимлида – основан на изначально отчасти неверной установке. Дело в том, что тимлид – это уже не только и не столько разработчик, сколько управленец. Если говорить о качествах и требованиях к тимлиду, в первую очередь, это желание развиваться, желание быть лидером. Тимлид – тот, кто выступает с идеями, предлагает и продумывает пути решения и распределяет задачи.
Тимлид также отвечает за техдолг и код-ревью, за планирование и технические процессы, за выполнение разработчиками задач в срок. Ему важно уметь делегировать, не брать на себя всю работу. Уметь корректно распределять задачи между членами команды в зависимости от их профессионализма, учитывая их предпочтения и стремления.
Как мы рассмотрели выше, отвечать за проект – не значит писать код в одиночку. Тимлид является ключевым связующим звеном в команде разработки. Он направляет проект в результативное русло. Его настрой влияет на весь проект и на каждого участника. Таким образом, если тимлид мотивирован, его мотивация распространяется на всю команду.
Рассмотрим, какие задачи решают тимлиды в распределенных командах, на примере одного из наших проектов – доработки крупной банковской IT-системы.
Пример: на старте в этом проекте принимали участие 11 наших Backend-разработчиков, проживающие в разных городах, и каждый из них состоял в отдельной продуктовой команде под управлением клиента.
В числе особенностей проекта были слабо развитые коммуникации в команде клиента, сложные процессы контроля (в отдельном чате) и настройки окружения.
Для того, чтобы улучшить взаимодействие в команде и ускорить разработку, мы подключили к проекту тимлида с нашей стороны. За первые полгода сотрудничества команде во главе с тимлидом удалось следующее:
На этом примере мы убедились, как значительно работа тимлида может повлиять на процессы в команде. За несколько лет сотрудничества наша команда на проекте расширилась до более чем 60 специалистов: backend-, frontend- и мобильных разработчиков, аналитиков, QA.
Это утверждение завершает список, потому что это самый очевидный миф из всех перечисленных. Если вы управляете командой, как крупной, так и небольшой, то успех проекта всегда зависит от множества факторов.
В свою очередь, это значит, что уровень дохода тимлида – как и разработчика – будет напрямую зависеть от индивидуального опыта и знаний.
Как продуктовые, так и аутсорсинговые IT-компании используют разные возможности для поиска управленцев. Одни назначают тимлидов из числа наиболее опытных разработчиков в команде, другие нанимают специалистов “извне”, третьи – выстраивают внутренние процессы обучения.
Для заказной разработки чаще всего оптимален третий путь. В этом случае специалисты могут прокачать нужные навыки постепенно, в среднем в срок от 3 до 12 месяцев.
Например, у нас есть «Академия тимлидов» – внутренний проект для передачи опыта. С 2019 года мы обучаем тех разработчиков, которые интересуются управлением командами. За год обучение прошли 80 специалистов, половина из них – более 40 человек – уже погрузились в новую роль и подключились к проектным командам.
По нашим наблюдениям, наиболее эффективно поэтапное погружение будущих тимлидов в работу: теория, практика, а также последующая поддержка ментора. Всё вместе это позволяет снизить риск “выгорания” специалиста и обеспечить его продуктивность.
В июне 2020 года мы уже рассказывали в Zoom, как устроены наши процессы обучения. После этого мы дополнили программу, опираясь на основе обратной связи. Теперь к занятиям могут подключиться разработчики из других компаний.
На занятиях мы делимся ключевыми аспектами управления командой разработки:
Меня зовут Александр, уже более года я веду наш внутренний проект по обучению – «Академию тимлидов». За год обучение прошли 80 разработчиков. Наш опыт показывает, что чаще всего специалисты правильно представляют будущие задачи и имеют перед собой конкретные цели. При этом бывает и так, что ожидания начинающего тимлида не совпадают с практикой.
Почему это происходит? Что делает тимлид на самом деле? Предлагаю вспомнить самые частые заблуждения и заодно разобрать конкретные задачи, которые тимлиду предстоит решать.
Миф №1. Тимлид – самый крутой технарь в команде
Нередко можно услышать мнение, что тимлид – ведущий разработчик, который использует свои лидерские качества для управления командой, но не ограничивается управлением. На практике к роли тимлида обычно переходят постепенно, и специалист посвящает больше времени управлению, чем разработке.
Конечно, в каждой компании есть свое представление о том, кто такой тимлид и что входит в его обязанности. При этом роль управленца в IT критически важна, как и в других сферах.
В первую очередь, тимлид необходим в масштабных проектах и распределенных командах, когда крупную IT-систему – например, банковскую – совместно создают и инхаус-разработчики, и несколько внешних подрядчиков.
Пример: бывает, что в проектной команде задействованы разработчики разных направлений, с разным опытом – Backend, Frontend и Mobile, QA-специалисты, SDET и DevOps. Даже если вы считаете, что разработчикам нужно стремиться к самоорганизации, обычно это недостижимый идеал. В жизни команде зачастую нужен классический лидер.
Пример: бывает, что в проектной команде задействованы разработчики разных направлений, с разным опытом – Backend, Frontend и Mobile, QA-специалисты, SDET и DevOps. Даже если вы считаете, что разработчикам нужно стремиться к самоорганизации, обычно это недостижимый идеал. В жизни команде зачастую нужен классический лидер.Тимлид смотрит на проект комплексно и помогает специалистам действовать так, как будто они – единое целое. С самого начала работы он выстраивает комфортную и дружелюбную атмосферу в команде. Для каждого участника он подбирает подходящее задание и контролирует этапы его выполнения. Также тимлид может проводить качественное код-ревью, предлагать улучшения при наличии проблем и рисков.
При этом, несмотря на значимость роли тимлида, существует и прямо противоположный миф, о котором расскажем ниже.
Миф №2. Тимлид не развивается как технарь и выгорает
Соотношение технических задач к управленческим может быть разным – например, 70/30, 80/20 или даже 50/50.
По мере развития проекта управленческие задачи могут отнимать все больше времени. Это значит, что тимлид действительно иногда развивает свои технические скиллы медленнее, чем другие разработчики в команде.
Впрочем, у таких ситуаций всегда есть решение – в зависимости от дальнейших целей специалиста, можно прокачивать технические или управленческие навыки.
Однако, этот фактор важно учитывать, поэтому при выборе тимлида основываются не только на хардскиллах. Наверное, многие слышали или даже видели, как в тимлиды выбирают просто толкового разработчика, а потом он либо “затухает”, демотивируется, либо из-за нехватки у него навыков ситуация на проекте становится напряженной.
Наша практика показывает, что как на обучение тимлида, так и на погружение в задачи нужно достаточно много времени. Возьмем давний пример из нашей практики, который и подтолкнул нас к созданию внутренней «Академии тимлидов».
Пример: опытному разработчику предложили руководить небольшой командой, и какое-то время он неплохо справлялся, но трудности нарастали с каждым днем. Проблема была простой: специалист не хотел никого обидеть или показаться слишком резким, ему не удавалось требовать чего-то от команды, даже когда это было нужно. Такая ошибка может привести к демотивации самого специалиста, ведь он будет считать, что не справился с новой должностью. К счастью, в той ситуации всё закончилось хорошо: разработчик честно и вовремя поговорил с руководителем, его задачу передали другому управленцу, а сам он вернулся к разработке и продолжил развивать свои хардскиллы.
Миф №3. Тимлид должен кодить сам и лучше всех
Этот миф – как и предыдущий, об отсутствии развития у тимлида – основан на изначально отчасти неверной установке. Дело в том, что тимлид – это уже не только и не столько разработчик, сколько управленец. Если говорить о качествах и требованиях к тимлиду, в первую очередь, это желание развиваться, желание быть лидером. Тимлид – тот, кто выступает с идеями, предлагает и продумывает пути решения и распределяет задачи.
Тимлид также отвечает за техдолг и код-ревью, за планирование и технические процессы, за выполнение разработчиками задач в срок. Ему важно уметь делегировать, не брать на себя всю работу. Уметь корректно распределять задачи между членами команды в зависимости от их профессионализма, учитывая их предпочтения и стремления.
Пример: в одном из наших проектов мы увидели, как тимлид стал «узким горлышком» в процессе, так как замкнул выполнение сложных задач на себя. Решением было – назначить техлида и делегировать ему часть ответственности, что позволило каждому специалисту быстрее расти в профессиональном плане.
Миф №4. Тимлид в одиночку отвечает за весь проект
Как мы рассмотрели выше, отвечать за проект – не значит писать код в одиночку. Тимлид является ключевым связующим звеном в команде разработки. Он направляет проект в результативное русло. Его настрой влияет на весь проект и на каждого участника. Таким образом, если тимлид мотивирован, его мотивация распространяется на всю команду.
Рассмотрим, какие задачи решают тимлиды в распределенных командах, на примере одного из наших проектов – доработки крупной банковской IT-системы.
Пример: на старте в этом проекте принимали участие 11 наших Backend-разработчиков, проживающие в разных городах, и каждый из них состоял в отдельной продуктовой команде под управлением клиента.
В числе особенностей проекта были слабо развитые коммуникации в команде клиента, сложные процессы контроля (в отдельном чате) и настройки окружения.
Для того, чтобы улучшить взаимодействие в команде и ускорить разработку, мы подключили к проекту тимлида с нашей стороны. За первые полгода сотрудничества команде во главе с тимлидом удалось следующее:
- провели 5 тимбилдингов распределенных команд и обеспечили благоприятный климат в команде;
- команда увеличила скорость выполнения задач на 10% за счет налаженных коммуникаций;
- сократили процесс настройки окружения с 3 дней до 4 часов.
На этом примере мы убедились, как значительно работа тимлида может повлиять на процессы в команде. За несколько лет сотрудничества наша команда на проекте расширилась до более чем 60 специалистов: backend-, frontend- и мобильных разработчиков, аналитиков, QA.
Миф №5. Разработчики переходят в тимлиды, чтобы повысить свою зарплату
Это утверждение завершает список, потому что это самый очевидный миф из всех перечисленных. Если вы управляете командой, как крупной, так и небольшой, то успех проекта всегда зависит от множества факторов.
В свою очередь, это значит, что уровень дохода тимлида – как и разработчика – будет напрямую зависеть от индивидуального опыта и знаний.
Академия тимлидов: наш опыт
Как продуктовые, так и аутсорсинговые IT-компании используют разные возможности для поиска управленцев. Одни назначают тимлидов из числа наиболее опытных разработчиков в команде, другие нанимают специалистов “извне”, третьи – выстраивают внутренние процессы обучения.
Для заказной разработки чаще всего оптимален третий путь. В этом случае специалисты могут прокачать нужные навыки постепенно, в среднем в срок от 3 до 12 месяцев.
Например, у нас есть «Академия тимлидов» – внутренний проект для передачи опыта. С 2019 года мы обучаем тех разработчиков, которые интересуются управлением командами. За год обучение прошли 80 специалистов, половина из них – более 40 человек – уже погрузились в новую роль и подключились к проектным командам.
По нашим наблюдениям, наиболее эффективно поэтапное погружение будущих тимлидов в работу: теория, практика, а также последующая поддержка ментора. Всё вместе это позволяет снизить риск “выгорания” специалиста и обеспечить его продуктивность.
В июне 2020 года мы уже рассказывали в Zoom, как устроены наши процессы обучения. После этого мы дополнили программу, опираясь на основе обратной связи. Теперь к занятиям могут подключиться разработчики из других компаний.
Что такое Академия тимлидов
Наш практикум – это 21 онлайн-консультация (более 50 часов) и 5 месяцев погружения в профессию. Онлайн-консультации проходят один раз в неделю.
26 ноября 2020 года – ближайший практикум, а также открытый вебинар (регистрация здесь).
Для кого:
- Для тех, кто хочет стать тимлидом.
- Для тех, кто уже руководит командами разработчиков.
- Для разработчиков Middle/Senior, которые хотят прокачать в себе управленческие навыки.
На занятиях мы делимся ключевыми аспектами управления командой разработки:
- персональные навыки менеджера и создание продуктивной команды;
- границы ответственности тимлида;
- основы и техники тайм-менеджмента;
- инструменты управления и основы коммуникации;
- организация, проведение и улучшение производственных процессов;
- основы управления проектами.
Приглашаю зарегистрироваться на практикум или открытый стартовый вебинар!
