Какие навыки помогут вам стать хорошим руководителем группы разработки?

Привет. Меня зовут Александр Гузенко, я руководитель трех команд фронтенд-разработки в крупной компании. Недавно один из сотрудников подошел ко мне и сказал: «Я хочу вырасти до тимлида. С чего начать?» Так родилась идея этой статьи, которую я обещал отправить ему позже в качестве руководства.

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

Кто такой руководитель команды и за что он отвечает?

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

В классическом понимании тимлид — это руководитель команды разработчиков. Это верно, но с некоторыми оговорками.

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

Во-вторых, тимлид – это не просто руководитель команды, а главное связующее звено между сотрудниками и руководством. Это важное дополнение, и ниже я постараюсь объяснить почему.

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

Роль руководителя группы включает в себя в основном управленческие задачи:

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

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

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

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

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

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

Кто может стать лидером команды?

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

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

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

Как понять, что вы справитесь с нагрузкой?

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

Побеждает лидер команды : кто-то делает за него работу.

Бизнес выигрывает : работа выполняется, но за нее не нужно платить деньги.

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

Как стать тимлидом: стратегии роста

Есть только два варианта. Первый — отсидеть всех остальных разработчиков в компании и стать тимлидом как самый «старший» сотрудник. Однако есть риск, что слово «старый» не придется заключать в кавычки. Второй вариант – проявить инициативу самостоятельно.

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

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

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

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

Говорят, что есть две важные вехи в развитии лидера команды: первая – от двух до шести сотрудников, вторая – 7 и более. Сначала у меня был всего один сотрудник, а сейчас я руковожу тремя командами фронтенд-разработки — 12 человек.

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

Ждать роста или уйти в другую компанию?

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

Какие навыки помогут вам стать хорошим руководителем команды?

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

Умение находить проблемы в процессах

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

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

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

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

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

Способность решать проблемы или правильно сообщать о них бизнесу

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

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

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

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

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

  
  

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

Говорите на том же языке, что и бизнес

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

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

Я подсчитал, что в среднем команда тратит 40% своего рабочего времени на исправление ошибок. Вместе с командой мы провели ретроспективный анализ и выяснили, что половина этих ошибок возникла только из-за неправильного понимания сути проблемы. То есть 20% рабочего времени разработчиков тратится впустую из-за того, что задачи плохо описаны. Это номер, с которым вам следует обратиться к руководству. Их легко конвертировать в деньги — тот же язык, который понимает бизнес.

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

Когда людям нравится работать друг с другом, любое взаимодействие становится более гладким. Почему Scrum так популярен? Речь идет не о документации, а о людях. Иногда эффективнее позвонить коллеге на две минуты, чем ждать два дня, пока он задокументирует ответ и подробно все объяснит. Итак, когда внутри коллектива царит атмосфера взаимопонимания и взаимовыручки, людям легче контактировать друг с другом. Например, вы нашли кусок кода и не понимаете, что он делает. Если ситуация в коллективе не очень хорошая, ты просто побоишься позвонить и спросить – «он подумает, что я дурак».

Для поддержания хороших отношений внутри коллектива раз в неделю провожу часовые созвоны. Разделим это время на три части. Первый – «расслабленный». Делимся мемами и шутками. Вторая часть – обсуждение проблем. Иногда мы кидаем карты в Миро, что не всем по душе. Так я понимаю, что именно тормозит ребят. Тогда мы сможем предложить варианты решения, которые я потом буду лоббировать у руководства. И заканчиваем снова «расслабленно»: можем обсудить фильмы или что-то еще. Такие встречи создают позитивную атмосферу и позволяют мне, как руководителю, понять, какие боли есть в команде.

Делегат

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

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

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

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

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

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

Стратегическое видение проекта

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

С какими проблемами вы можете столкнуться как руководитель группы?

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

Непонимание со стороны бизнеса

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

Недостаток ресурсов

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

Результатов работы не видно

Бывает, приходишь в компанию, разрабатываешь стратегию, строишь планы и увлечен работой, но время идет и ничего не меняется. Здесь не приходится долго впадать в уныние: «Кому все это нужно?» В этом случае можно провести ретроспективный анализ, чтобы понять, почему проект не продвигается. Спросите себя: «Может быть, я бью не в ту цель, решаю не те задачи?»

Отсутствие инструментов для достижения цели.

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

Прямой доступ к высшему руководству

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

Постоянный аварийный режим

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

Плохая атмосфера в коллективе

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

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

Заключение

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