Все о должности тимлида: кто такие руководители команды разработки и как ими становятся

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

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

Для этого специалист должен обладать такими личностными качествами, как:

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

До того как специалиста назначат на должность тимлида, он должен проработать в IT-сфере не менее 5 лет, а также иметь следующие навыки и умения:

1. Аналитические способности.
2. Знания серверных технологий.
3. Готовность к самообучению.
4. Умение учитывать мнение команды.
5. Знания масштабируемости веб-проектов.
6. Способность принимать быстрые и простые решения в стрессовых ситуациях.
7. Умение распределять обязанности внутри коллектива.
8. Навыки и умения в программировании на уровне senior.
9. Оценка и планирование бюджета.
10. Умение рассматривать проблему с разных ракурсов.
11. Навыки наставничества.
12. Умение нести ответственность за работу других людей.
13. Знания языков программирования.
14. Способность учитывать риски.
15. Умение заметить и исправить ошибку.
16. Знания планирования задач.
17. Умение планировать, ставить сроки и укладываться в них.
18. Способность сформировать команду, обучать и мотивировать новых сотрудников.
19. Умение переработки требований заказчика в техническое задание.
20. Знания в области психологии, социологии, менеджмента и кадровой политики.
21. Навыки решения конфликтов и поддержания рабочей мирной атмосферы.
22. Умение распределять нагрузку между членами группы.
23. Знания ведения переговоров.
24. Умение проводить тестирование готового продукта.
25. Навыки контроля всех этапов работы.
26. Умение вести документацию.

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

Сколько получают Тимлиды и как найти работу?

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

Так, по Москве уровень зарплаты может достигать 400 тысяч рублей и более, при этом минимальная планка тоже высокая – около 100 тысяч рублей. В других регионах зарплаты гораздо ниже, примерно от 50 до 300 тысяч рублей.

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

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

Что надо понять

Вам платят деньги не за то, что вы пишите код

Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше

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

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

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

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

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

Вам нужно нанимать людей. Хорошо, если у вас есть отдел кадров, который умеет нанимать IT-специалистов. Если нет — у вас появились дополнительные обязанности. Учитесь составлять вакансии, отбирать специалистов, проводить собеседования, увольнять. И если у вас не стартап с космическими инвестициями, готовьтесь находить людей в бюджете ниже рынка. Возможно даже придётся самому обзванивать кандидатов.

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

Вы не можете выбирать технологии, какие хотите. Обычный разработчик может предлагать новые технологии, а задача TL — поддерживать баланс стека технологий проекта. Помните, стабильность проекта и процесса разработки — ваша обязанность. Что делать, если из команды уходит единственный хранитель какой-то особенной технологии? Кроме того, использование каждой технологии должно быть обосновано. Я периодически наблюдал как полтора земплекопа в крохотном проекте всё пилят на микросервисах. Они не догадывались, что компания не была готова к этому. Конечно, ни к чему хорошему такие эксперименты не приводили.

Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.

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

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

Обязанности

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

• Заключение договора с клиентом, обсуждение всех деталей, поиск компромисса.
• Работа с договорами, различной документацией.
• Производить оценку обьемов и масштаба работ, бюджета, сроков выполнения работ.
• Расставление приоритетов, планирование больших и маленьких задач.
• Делегирование полномочий внутри коллектива таким образом, чтобы получить максимальную эффективность.
• Планирование релизов и своевременный их выпуск.
• Функции продюсера в управлении проектом, дизайнерские работы, грамотный маркетинг, разработка.
• Общительность, и налаживание контактов с каждым сотрудником, мотивирование персонала, обеспечение профессионального роста каждого.
• Мотивация, нужно показывать все на своем примере, быть образцом для своих сотрудников.
• Умение переделать бизнес-идею руководства в техническое задание для разработчиков.
• Ответственность за качество проекта, технологию его реализации.
• Написание ревью кода.
• Тестирование, проверка проекта, разработка его дизайна.
• Уметь понять и разобраться в поломке, при надобности – усовершенствовать проект.
• Написание технической документации.
• Участие в процессе формирования команды.
• Программирование архитектуры.
• Выбор наиболее подходящей и эффективной технологии для рабочего задания.
• Обьяснение общих идей каждому сотруднику команды.
• Выбор исполнителя из команды, подходящего для определенной задачи.
• Выгружать изменения на сервер.
• Обмен опытом между членами команды, с целью повышения эффективности, понимания и навыков.
• Оптимизация работы, проведение внутрикомандных совещаний.
• Ведение отчетов перед заказчиками в течении всего этапа проведения работа.
• Контролировать проект на предмет его соответствия заданным техническим параметрам.
• Оценка и поддержка предложений от других участников проекта.

Личностные качества:

• Аналитический состав ума
• Ответственность
• Пунктуальность
• Трудолюбие
• Дипломатичность
• Инициативность
• Нахождение простых способов решения сложных заданий
• Техническая грамотность (владение серверными технологиями и дистрибутивами)
• Нацеленность на результат
• Быстрое принятие решений в сложных ситуациях.

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

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

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

Обучающий стиль

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

Мы верим в то, что сможем достигать крутых результатов, если будем развивать индивидуальные навыки своих сотрудников. Для этого каждые полгода мы проводим performance review. Оно включает в себя отзывы от коллег, self-review и 1-1 с руководителем для рефлексии. После этого мы составляем план на полгода таким образом, чтобы сотрудник знал, что ему делать для улучшения своих навыков. Каждый пункт этого плана является целью и ставится по фреймворку SMART. Например, если одной из целей является крупный рефакторинг, то мы определяем definition of done этого рефакторинга. Так он станет конкретным и измеримым. Планируем объём работ: реально ли закончить этот рефакторинг за 3-6 месяцев? И думаем о том, какую пользу он принесет компании.

Девиз обучающего стиля

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Демократический стиль

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

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

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

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

Частый ответ на вопрос о странном legacy решении в проекте

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

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

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

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

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

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

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

Когда рекрутер «пинает» тимлида и команду разработки — это нормально

Воронка подбора — это зеркало найма, то, как он проходит у вас в компании. Поэтому воронка бывает разной: у кого-то шесть-семь этапов, а у кого-то — все двадцать. В разработке hh.ru воронка выглядит так:

заявка на подбор → скрининг резюме рекрутером → согласование кандидатов техническими специалистами → интервью с командой → тестовое задание (опционально) → повторное интервью → оффер.

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

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

В результате сели за круглый стол: я, команда, рекрутер. И нарисовали схему:

• Как идет процесс
• Кто за что отвечает
• Какие максимальные сроки у нас заложены под каждый этап

Решили, что если накапливается определенное количество нерассмотренных кандидатов, то рекрутер пишет в общий чат и не стесняется нас «пинать»

Если кандидат нереально хорош, то эйчар может отправить сразу ссылку на вакансию — «кандидат горящий, важно не потерять!»

Когда мы это сделали — все зависания исчезли. Главное принять, что рекрутер тут — «пинатель», это его работа и не стоит на него за это злиться.

А еще от зависаний нас спасает сервис из экосистемы hh.ru —

Кандидаты у нас долго не залеживаются, поэтому приложил скриншот из соседнего отдела:

Система хороша и тем, что мы забыли про эпоху резюме на почте (те, которые всегда теряются и очень всех раздражают): вместо них есть вот такие карточки на каждого кандидата, где можно быстро оставить отзыв и отметить — «подходит» или «не подходит». При желании часть переписки можно скрыть от команды, например, если вы хотите сравнить кандидата с кем-то из штата для корректировки уровня компенсации. Не нужно смотреть куда-то еще: все собрано в одном месте и ничего не нужно выискивать.

Выступления

Как ты сам начал выступать? Зачем тебе это?

Первый раз я выступил в 2017 на CodeFest.

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

Меня это раздражало и я решил с этим разобраться. Для начала вписался в чтение книг через Skype — занятие интересное. Люди собирались и по ночам друг другу читали все, что захотят. Этот опыт позволил мне частично разобраться со страхом перед аудиторией и я стал двигаться дальше.

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

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

В итоге я на это подсел:)

Есть какие-то планы на ближайшие выступления?

У меня стабильно пара докладов каждый год. На этот год у меня есть тезисы нового доклада и мы обсуждаем с devrel куда его можно было бы подать. Возможно, подам на РИТ. Также есть материал для TeamLeadConf.