Где найти и как выбрать тимлида

Кто такой Тимлид?

Описание профессии тимлид начну, пожалуй, с уточнения: это не специальность, а должность, или административная единица по другому, исключительно в сфере IT.

В дословном переводе с английского «Team Lead» означает «лидер команды». Это руководитель-управленец, который возглавляет коллектив веб-разработчиков. Он является ключевым связующим звеном между заказчиком и исполнителями. Тимлид проводит переговоры, принимает заказы на разработку, которые потом преобразовывает в технические задания для специалистов.

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

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

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

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

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

Обязанности тимлида

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

В перечень основных обязанностей тимлида входит:

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

Зоны ответственности QA лида

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

QA lead как стратег

QA лид отвечает за стратегию качества в стриме. Для этого он напрямую работает с Head of Stream Engineering и Head of QA.

Работает с Head of Stream Engineering

Вместе с Head of Stream Engineering QA лид определяет видение процесса разработки в части качества в перспективе минимум на год — что нам нужно сделать, чтобы достичь цели бизнеса. Head of Stream Engineering отвечает за техническую сторону достижения целей бизнеса: масштабируемую архитектуру, предсказуемую разработку, масштабирование команды (найм) и, конечно, качество продукта. 

В данном случае обеспечение качества — это не дополнительная работа, которая удлиняет t2m, это, наоборот, история про сокращение издержек. Мы хотим уделять время фичам, но тратим много времени на исправление ошибок — нужно сделать так, чтобы мы не порождали ошибки. Мы хотим, чтобы добавление кнопки заняло один день, а это занимает три недели из-за легаси в коде — нужно устранить сложный код, так как в него невозможно быстро и качественно вносить изменения. То есть при должных ограничениях качества, единственный способ ускорить t2m — это сразу делать качественнее. Этот вопрос и решает QA lead в связке с Head of Stream Engineering.

Работает с Head of QA

Однако есть не только бизнес цели стрима. Есть принципы качества, единые для всех стримов, потому что мы работаем над одним продуктом. Есть эффективные подходы и инструменты, которые можно использовать всеми стримами для экономии ресурсов. Это всё задает видение стратегии обеспечения качества на уровне компании. Head of QA помогает QA лидам совместно определять принципы и подходы.

QA lead как Project manager

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

Реальные примеры таких проектов:

• Обеспечить 80% покрытия тестами на разных уровнях;

• Уменьшить втрое стоимость ответа на тикеты для команды поддержки;

• Провести исследование доверия метрикам;

• Улучшить качество релизных веток на Х;

• Внедрение JS test framework для non-Canvas команд.

QA lead как People manager

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

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

Чем ещё занимается QA lead

Он проверяет на прочность всё вокруг.

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

Архитектура. Архитектура может не позволять покрывать код тестами из-за сильной связности. Это не дает гарантий надёжности изменений.

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

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

Тестовые окружения. Это часто сложная техническая область, где нужно строить удобные тестовые окружения для деплоя и проверки своей версии приложения.

CI/CD в части выполнения тестов всех уровней. Если получение результатов е2е тестов занимает более 10 минут, разработчик переключает контекст на другую задачу, а это порождает издержки.

Тестирование на проде

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

А также: 

• Нефункциональное тестирование и его автоматизация;

• Канареечные релизы и процесс анализа пропущенных до прода ошибок;

• Релизы и действия на проде;

• Мониторинг вышедших фичей и компонентов;

• Инциденты;

• Health monitoring.

Поддержка: контроль

1. На встречах с тимлидом при обсуждении любых вопросов постоянно проверять его понимание сказанного: «Расскажи мне, как ты понял», «Объясни своими словами» и т. д.
2. Постоянно «обнажать инструментарий»: «Смотри, я тебя подвёл к решению задачи наводящими вопросами, но решил её ты сам. Видишь, как мой коучинг работает на тебе — он так же сработает на ребятах». Хорошо бы добавить личный пример.
3. Выделять больше времени на встречи с лидом, чем раньше тратилось на общение с каждым разработчиком. У меня на общение с тимлидами уходит как минимум полтора часа в неделю, плюс куча небольших синхронизационных обсуждений.

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

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

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

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

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

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

Подбор: скоринг

• Бизнес-ориентированность — насколько человек прагматичен, когда целью является результат для бизнеса, а не, скажем, уровень удовлетворённости красотой и изящностью кода. Тимлид должен в первую очередь руководствоваться принципами управления, а не личного комфорта. Простой пример: если бизнесу нужно провалидировать в рамках A/B-теста какую-то концепцию, вероятно, нет смысла делать покрытие кода тестовой группы юнит-тестами, даже если принято покрывать тестами всё, и разработчику нравится писать тесты.
• Коммуникации. В культуре Badoo на коммуникациях построено очень многое, и умение эффективно общаться со всеми — серверниками, тестировщиками, топами, дизайнерами — просто необходимо.
• Уровень мотивации. На мой взгляд, тимлид должен обладать сильной внутренней мотивацией, ведь превращение из разработчика в тимлида — это не переход со ступеньки на ступеньку карьерной лестницы, а перепрыгивание на другую лестницу, стоящую особняком, — лестницу управления. Без сильной мотивации любое развитие — а развитие всегда есть выход из зоны комфорта — будет очень тяжёлым.
• История удачных/неудачных проектов. Сюда же относятся причины провалов проектов (чтобы потом проверять следующие проекты на наличие тех же паттернов провалов).
• Уровень неформального лидерства. Руководитель должен уметь вести за собой сотрудников, мотивировать их на достижение целей. Кроме того, неформального лидера команда легче примет в качестве тимлида.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интро: структура разработки и процесс обеспечения качества в Miro

Вся продуктовая разработка поделена на направления — стримы. Все стримы кросс-функциональные и кроме разработчиков в стримы входят и другие функции: аналитика, маркетинг, продакт, дизайн. Каждый стрим развивает часть продукта, объединённую общей идеей. Например, Growth стрим — это команды, которые работают над ростом продукта. Или Platform стрим — команды, которые разрабатывают публичную платформу и SDK. Есть стрим Stability and Scalability, команды в котором создают инструменты для доставки, инфраструктуры и обеспечения качества. Здесь разрабатываются системы для автотестирования. Все QA лиды и инженеры пользуются результатами работы этого стрима.

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

Например, практически с каждой Scrum командой работает выделенный QA инженер, который руководствуется ценностями Agile-тестирования:

«Testing throughout over testing at the end». Тестирование — это не дополнительный этап, а часть каждого этапа разработки.

«Preventing bugs over finding bugs». Процесс обеспечения качества в первую очередь направлен на предотвращение ошибок, а не на их эффективный поиск. Но это не значит, что процесс поиска ошибок нужно исключить.

«Testing understanding over checking functionality». Мы в первую очередь обеспечиваем качество продукта, а не только производим проверку на соответствие требованиям. 

«Building the best system over breaking the system». У нас нет цели найти все ошибки — мы фокусируемся на предотвращении и поиске важных. Ошибки, что встречаются крайне редко, можно пропустить, потому что их поиск будет очень дорогим.

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

Подробнее процесс обеспечения качества описан в статье.

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

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

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

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

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

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

Как становятся Team Leader

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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