Кто такой лид в айти

Без тимлида не обойтись, а что насчет техлида?

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

А что насчет техлида? Об этой специальности говорят не так часто, но техлиды важны и нужны не менее тимлидов. Более подробно я рассказываю об этом на курсе «Руководитель команды разработки» и делюсь реальными кейсами. Но не будем отвлекаться, приступим!

Техлид — не специальность, а роль

Главное, что нужно знать о техлиде — то, что это роль. Она может быть формальной, и может быть и номинальной, все зависит от проекта и команды. Так, техлидом может стать и чаще всего становится опытный инженер, который не только оперативно справляется с собственными задачами, но и может помочь коллегам, беря на себя дополнительные технические задачи и ответственность за них.

Что касается формальной или номинальной роли, то в классическом Scrum, например, нет роли техлида, а вот в проектах и командах, которые «живут по Scrum», техлид есть.

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

А что насчет обязанностей?

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

Пример — разработка мобильного приложения. Если проект большой, то здесь обязанности техлида и тимлида редко пересекаются. Так, техлид отвечает за архитектуру мобильных приложений под две платформы, iOS и Android, за проектирования REST API в контексте разрабатываемой мобильной архитектуры. А вот за управление проектом, разработку серверной реализации API и результаты всего проекта отвечает тимлид.

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

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

Техлиды и тимлиды – зоны ответственности

Мы сразу провели границу между тимлидами и техлидами. Техлид — это упор на Hard-скиллс, а тимлид — на Soft-скиллс. Граница — в соотношении этих навыков, причем в зависимости от контекста, заданного проектом и командой.

Для того чтобы прояснить ситуацию, приведу пример. Это кросс-платформенные проекты с сервис-ориентированной архитектурой по разработке омниканальных цифровых витрин. В рамках такого проекта разрабатываются web&mobile-приложения, сервисы управления контентом, сервисы интеграции и реализации бизнес-логики (API). В таком проекте может быть целая команда лидов:

Тимлид, управляющий процессами, коммуникациями и бюджетом.

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

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

Списком задач в бэклоге управляет руководитель проекта. Задачи по разработке уходят в работу на тимлида.

Тимлид получает задачу, проверяет точность и полноту требований в задаче, при необходимости уточняет детали или дополняет описание задачи описанием уточнением требований или описанием возможной реализации. Задача уходит в работу на техлида. При этом на проекте работает три техлида: фронт, бэк, мобилка; – и тимлид понимает из описания, на кого делегировать задачу.

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

Техлид определяет исполнителя и отдаёт задачу в работу.

Задача от разработчика возвращается на код-ревью к техлиду и техлид принимает задачу или отправляет на доработку с комментарием содержащим уточнения и рекомендации.

В таком процессе за техническое качество реализации отвечает техлид, а тимлид — за сроки и бюджет.

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

Знания, умения и скиллы – поговорим конкретнее

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

Базовый набор Soft-скиллс:

Поиск и подбор кандидата, собеседование.

Постановка личных целей.

Стратегическое видение развития.

Отношения с людьми: эмпатия и эмоциональный интеллект.

Базовый набор Hard-скиллс:

Знание языков разработки и опыт программирования. Знание сопутствующих и окружающих этот стек технологий.

Понимание архитектуры проекта: принципы проектирования архитектуры, паттерны и инструменты.

Процессы и инструменты тестирования. Оптимизация тестирования, метрики и мониторинг.

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

Текстовые редакторы и интегрированные среды разработки.

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

Системы управления задачами и проектом.

Системы управления знаниями и документаций.

Системы управления версиями кода и инструменты CI/CD.

Системы контейнеризации и инструменты DevOps.

Системы мониторинга и управления инцидентами.

Серверные операционные системы и их сервисы.

Скрипты и собственные наработки кода.

Кто может стать техлидом?

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

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

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

Источник

Team Lead vs Tech Lead: кто есть кто

Представляем статью Олега Абрамова, VP of Engineering в iDeals Solutions, вышедшую на DOU.UA. Из этой статьи вы узнаете, чем отличается тимлид от техлида и чем занимаются люди на этих позициях.

Привет, я Олег Абрамов, VP of Engineering в продуктовой компании iDeals Solutions. Хотел бы поделиться опытом и своими взглядами на особенности управления процессами в IT-компаниях. А именно рассказать подробнее о том, чем отличаются роли Team Lead и Tech Lead и какие функции и задачи могут быть с ними связаны. Прежде всего это будет интересно тем, кто работает в растущих командах или задумывается о карьерном росте на позиции разработчика. А также тем, кого волнуют вопросы эффективного управления в продуктовых компаниях.

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

Кем управляем

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

В условно «плохой» команде чаще наблюдается линейный рост: общая работа не отличается от суммы индивидуальных результатов. Может быть и хуже — когда люди вообще начинают мешать друг другу. Или же при обсуждении задач члены команды не дополняют и не критикуют (в здравом смысле) решения друг друга. Например, при сложностях у фронтенд-инженера его бэкенд-коллеги уходят в режим «это не мое дело, это „его“ задача, у меня другие проблемы и другие дела».

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

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

Например, как-то у нас возник вопрос по поводу скачивания «тяжелых» файлов в разрабатываемом дополнении к нашей системе. Более опытные коллеги предложили два варианта решения инженеру, перед которым стояла эта задача. Он решил исследовать проблему с нуля и увидел недостатки в обоих решениях. Инвестировав дополнительное время, он нашел третий, оптимальный подход. Коллеги его поддержали. В итоге в релизе решение дало существенное ускорение и улучшило пользовательский опыт. Таким образом, порой out of box thinking дает продуктивные результаты — как с точки зрения бизнеса, так и с точки зрения технологий.

Но вернемся к командам. Когда число участников переваливает за 5-7 человек, возникают вопросы: кто должен обучать и направлять (управлять экспертизой), а кто — организовывать эффективную работу (управлять командой).

Какие вызовы появляются с масштабированием

Когда в команде три человека — условно [Tech/Team] Lead и пара Middle — скорее всего, сложностей с управлением не возникнет. Здесь лид «и швец, и жнец, и на дуде игрец». На нем и собственноручная разработка решений, и ревью кода других, и управление командой.

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

Давайте посмотрим на реальный кейс. Команда Lead’a Алекса занялась сложным проектом, руководство регулярно спрашивает о сроках. Сам он раньше никогда не планировал на среднесрочную перспективу — например, на месяц-два. В итоге Алекс вместо кодинга погружается в оценку и планирование, вместо анализа локальных технических изменений — в учет рисков. Как результат, все меньше кода пишет сам.

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

Логичный следующий этап — найти в команду инженера с лидерскими качествами, который бы «остался в технологиях». Такой специалист помог бы развивать и поддерживать техническое качество решений команды — Tech Lead. Сам же Алекс, если хорошо справляется с управлением людьми и проектами, становится Team Lead.

То есть вместе с ростом команды возникает необходимость разделить лидерство на «техническое» и «управленческое». Для достижения результатов команде нужны оба «крыла». Первое — чтобы задавать направление движения в сфере технологий и экспертного развития коллег. Второе — для эффективной координации, создания здоровой и продуктивной атмосферы и ориентации на бизнес-цели и результаты.

Кто такой Tech Lead

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

В разных компаниях нагрузка и функции могут отличаться. Условно занятость Tech Lead можно описать так:

Второй и третий блоки, собственно, составляют сущность роли техлида, где она начинает сильно отличаться от Senior. Давайте разберем их подробнее. Основная задача техлида — обеспечивать качественную техническую проработку и реализацию продукта. Что именно стоит считать «техническим лидерством»?

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

Кто такой Team Lead

Эта позиция имеет смысл уже в разросшейся команде — от 5 человек. Здесь управление связано с непрерывной коммуникацией как с разработчиками, так и с коллегами из других команд, с менеджментом ожиданий, ресурсов и изменений. С ростом коллектива транзакционные издержки растут, поэтому взваливать эти функции на техлида или старшего разработчика будет непродуктивно. И в здоровых командах, где следят за эффективностью, появляется Team Lead.

Если сравнить команду разработчиков с кораблем (не «Титаником»), то техлида можно назвать главным механиком, который обеспечивает надежную работу всего судна. Тимлид же в этом случае — капитан: он прокладывает курс и следит за слаженной работой команды и механизмов.

Что может входить в его задачи в продуктовой компании?

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

Как мы управляем разработкой в iDeals

В iDeals мы уже прошли этап горизонтальной структуры, когда каждая функция (BE, FE, QA) имела своего Team Lead, и пришли к вертикальным кросс-функциональным командам. Эта тема требует отдельной статьи, поэтому здесь опишу ситуацию вкратце.

Итак, сейчас в каждой команде у нас 2-3 Back-end Engineers, 1-2 Front-end Engineers, 2-3 QA/AQA Engineers. В среднем — 7-8 человек. Как правило, команда состоит из Senior/Middle+ специалистов, которые достаточно автономны (70-90% решений принимается самостоятельно).

Глава этой команды — Engineering Manager. Это человек с опытом в разработке (как правило — Back-end/Full Stack в прошлом), хорошо понимает контекст построения решений end-to-end, но предпочитает вертикальный рост в компании, а не горизонтальный. Фактически он имеющий инженерный бэкграунд Team Lead. Но от этого термина мы решили избавиться, потому что на рынке он имеет разные значения и зачастую создает неправильные ожидания.

Engineering Manager опирается на Seniors/Tech Leads, отвечает за итоговые показатели, процессы разработки и объединение контекстов всех трех функций (FE, BE, QA) в команде для принятия оптимальных решений. Кроме того, people management задачи: у него есть все рычаги для обеспечения лучших результатов работы команды и необходимый уровень автономности.

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

С грамотным развитием специалистов и/или хорошими наймами на эту роль создается правильный профицит управленческой функции. Для быстро растущего продукта (iDeals растет на 20-30% в год) это суперважно.

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

Источник

Гений, программист, стратег, менеджер. Кто такой Tech Lead и как им стать?

Кто такой Tech Lead?

В чем состоит функция Tech Lead?

Нужны ли ИТ-компаниям Tech Lead-ы?

Каким должен быть хороший Tech Lead?

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

Это то, в чем, по мнению большинства, заключается работа Tech Lead-а: делать все необходимое для того, чтобы команда разработчиков выполняла свою работу наиболее эффективно. В этом функции Tech Lead-а пересекаются с обязанностями Team Lead-а и Lead Engineer-а, с той лишь разницей, что Tech Lead должен отвечать за общий процесс и финальные результаты. Поэтому наличие Tech Lead вообще имеет смысл только в тех случаях, когда команда разработчиков достаточно большая, а проект, над которым она работает, — достаточно сложный и масштабный.

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

Формирование мотивированной команды девелоперов и менеджмент.

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

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

Координация и балансировка усилий.

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

Ответственность за все успехи и промахи команды разработчиков.

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

Чем занимается хороший Tech Lead и как им стать?

Методология разработки.

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

Стек технологий.

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

Архитектура ПО.

Та область, в которой полномочия техлида прямо пересекаются с обязанностями архитектора ПО, но Tech Lead в данном случае стоит выше, чем обычный архитектор, и отвечает за окончательные решения и подходы к ним.

Внутреннее планирование и распределение зон ответственности.

Tech Lead, как человек, несущий ответственность за финальный результат, должен устанавливать сроки сдачи тех или иных частей проекта, и определять зоны ответственности.

Сроки выпуска новых релизов.

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

Политика Code Review.

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

Источник

Кто такой тимлид (он же Lead)

Как устроена работа человека, которого слушают даже сеньоры.

Послушать аудиоверсию этой статьи (7 минут):

Слушайте Кто такой тимлид на Яндекс.Музыке

Когда мы говорили про сеньоров, то сказали, что один из вариантов их профессионального развития — стать тимлидом. Это самый важный человек в команде.

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

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

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

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

Зачем нужны тимлиды

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

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

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

Как им стать

Как правило, тимлиды — это бывшие сеньоры.

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

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

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

Короче, тимлид — это менеджер, который в совершенстве знает стек программирования своей команды.

Сколько зарабатывает тимлид

Мы посмотрели зарплаты тимлидов в разных направлениях на начало 2020 года и вот что выяснили:

Разработка мобильных приложений — 228 тысяч.

Что дальше

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

Источник