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

Привет, Хабр! Меня зовут Радик Нургалиев, я руководитель команды .NET-разработчиков IBS. В этой статье расскажу про свой карьерный рост от начинающего программиста до руководителя в компаниях разного масштаба. Понятно, что у каждой ИТ-компании свои представления о прекрасном и свои схемы карьерных треков сотрудников, а значит, не может быть некой единой для всех разработчиков инструкции «Как стать тимлидом за Х лет». Я поделюсь личным опытом. Надеюсь, кому-нибудь он поможет повторить мою траекторию: начинающий программист → разработчик со стажем 1–3 года → опытный разработчик → куратор команды → тимлид.

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

Путь развития — в тимлиды через наставничество

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

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

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

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

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

Навыки и качества

…которые, на мой взгляд, позволили мне стать тимлидом.

Навыки:

• Аналитическое мышление: способность анализировать информацию, выделять ключевые аспекты, отбрасывать лишнее, делать обоснованные выводы и принимать решения на основе полученных данных.

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

• Лояльность: проявление верности, преданности и честности в отношениях с коллегами и руководством компании, защита и поддержка их интересов.

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

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

Качества:

• Дотошность: тщательность и внимательность к деталям, стремление к точности и высокому качеству выполнения задач.

• Принципиальность: соблюдение принципов и норм при принятии решений и взаимодействии с другими людьми.

• Дерзость: решительность, принятие рисков и вызовов, стремление к достижению целей, несмотря на трудности или опасности; умение говорить «нет».

• Справедливость: понимание и соблюдение принципов справедливости, равноправия и уважения интересов всех сторон, независимо от обстоятельств; неприятие кумовства, панибратства и выделения «любимчиков» в команде.

• Гибкость: способность чувствовать и соблюдать баланс между необходимой адаптацией к изменениям и соблюдением устоявшихся норм; умение находить компромиссы; умение оценивать целесообразность и возможность исполнения той или иной задачи.

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

«Шокирующее» признание: за свои семь лет в ИТ-индустрии я не прошел ни один курс по управлению командой, делегированию или многозадачности. Что мне помогло? Наверно, просто желание. Я горю тем, что делаю. Мне нравится, я получаю удовольствие. Я не боюсь спросить совета или признать, что чего-то не знаю. Я могу подойти к старшему коллеге, узнать, как бы он решил задачу, и сделать определенные выводы. Только с течением лет из таких «хлебных крошек» в голове наконец складывается понимание, как подходить к тому или иному вопросу.

Роль и обязанности на проекте

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

Я руковожу непосредственно командой разработки, состоящей из 6 специалистов (2 front-end- и 2 back-end-программиста, 1 DevOps + 1 DBA), и не участвую пресейлах, тестировании, релизах или долгосрочном планировании, хотя и знаю о примерных планах клиента на полгода вперед. Я не «пипл-менеджер», который занимается только мотивацией и установкой дедлайнов, а человек, который продолжает работать руками с кодом: осуществляю технический контроль над задачами, выбираю оптимальные технологии и провожу код-ревью. С заказчиком же я коммуницирую только эпизодически — в роли технического специалиста для помощи руководителю проекта, когда он не может понять, чего именно хочет заказчик с технической точки зрения. Здесь я могу служить «переводчиком» между сторонами или предлагать альтернативы сложным, долгим и дорогим решениям.

Что входит в мои обязанности на проекте:

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

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

3. Контроль качества и сроков задач: осуществление надзора за выполнением работ в соответствии с требованиями проекта и установленными дедлайнами.

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

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

6. Мотивирование и развитие сотрудников: стимулирование и поддержка членов команды для повышения их мотивации и заинтересованности в проекте, а также развитие их профессиональных навыков.

7. Анализ результатов работы.

Наряду с прямыми обязанностями от меня как тимлида есть и определенные ожидания:

• достижение всех поставленных целей в рамках спринта;

• разрешение неизбежных конфликтов, которые бывают на любом проекте;

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

• системный подход к работе;

• умение эффективно общаться и доносить информацию до всех заинтересованных сторон;

• поиск и эффективное преодоление преград, которые могут помешать достижению целей проекта.

Какими вопросами задается тимлид

Или что не дает мне спать по ночам:

• цели и видение: общее видение проекта и вовлечение команды в процесс постановки целей;

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

• прогресс и коррекция: непрерывное отслеживание прогресса и результатов выполнения задач;

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

• управление рисками и ресурсами: корректировка разработки в соответствии с происходящими изменениями; приоритезация задач в соответствии с целями итогового спринта и эффективное распределение ресурсов.

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

Воркфлоу тимлида: планирование задач

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

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

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

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

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

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

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

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

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

Воркфлоу тимлида: организация задач

На схеме ниже показано, как у нас организованы задачи разработки, по каким статусам они проходят в таск-менеджере:

Серый кружок в верхнем левом углу — это задача, нарезанная в бэклог. Как только аналитик ее обработал, он проставляет статус «Открыта», а я назначаю ответственного. Открытые задачи хранятся в бэклоге разработчика и берутся в работу в соответствии с приоритетностью. Если задачу решили не выполнять в рамках данного спринта, то она получает статус «Пауза», а если разработчик хочет задать уточняющие вопросы аналитику, то «На уточнении». Выполненная разработчиком задача отмечается у него как сделанная и отправляется мне на код-ревью. Далее задача переходит на тестирование — в статус «Resolved». Здесь ее просматривает аналитик или тестировщик. Если были обнаружены какие-либо проблемы, то задача возвращается в статус «Открыта», а если у нас хэппи-флоу, то она переводится в препрод. Оттуда разработчик вливает код в целевую ветку, а задача переводится в статус «Готова».

План «тренировок»: что стоит прокачать будущему тимлиду команды разработки

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

Вот ключевые «мышцы», требующие прокачки:

1. Саморазвитие и самопонимание, а также самооценка и уверенность в себе (над этим пунктом я и сам еще работаю :)

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

3. Умение делегировать задачи и следить за их выполнением.

4. Техническое мастерство: непрерывное обучение и развитие в области ИТ; глубокое понимание технологий, используемых на проекте; способность принимать обоснованные управленческие решения.

5. Навык разрешения конфликтов и умение не создавать конфликтные ситуации хотя бы со своей стороны.

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

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

8. Способность гибко адаптироваться к изменениям, оперативно реагировать на возникающие проблемы и находить оптимальные решения. Умение отрабатывать новые требования и вызовы с минимальными потерями для проекта и команды.

9. Умение сохранять спокойствие, работать под давлением и принимать на себя риски и ответственность за сложные, но необходимые действия.

10. Умение эффективно коммуницировать с заказчиком, а также презентовать прогресс и результаты работы.

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

Картинка по ссылке кликабельна — при нажатии на любую из синих веток откроется детальное описание навыка в базе знаний.

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