Кто такой тимлид и какие у него задачи
Начнем с теории, без которой будет сложно понять, почему ты шел управлять разработкой, а вместо этого считаешь бюджет проекта.
В классическом понимании тимлид — это руководитель команды разработчиков. Все так, но с некоторыми оговорками.
Во-первых, свои тимлиды сейчас есть не только у программистов, но и у дизайнеров, аналитиков, тестировщиков, сеошников и других околоайтишных и не очень специалистов. Поэтому точнее будет сказать, что обязанности тимлида — это руководить командой сотрудников с одинаковой ролью. Хотя я буду говорить именно о разработчиках.
Во-вторых, тимлид — не просто руководитель команды, а главное связующее звено между сотрудниками и менеджментом. Это важное дополнение, и дальше я постараюсь объяснить почему.
В-третьих, чтобы понять обязанности тимлида в команде, важно разграничить роль и должность.
Роль тимлида предполагает чисто менеджерские задачи:
- доносить позицию руководства по важным вопросам;
- проводить организационные изменения;
- распределять задачи между сотрудниками и контролировать выполнение;
- отвечать на текущие вопросы команды;
- урегулировать споры;
- создавать комфортную атмосферу в коллективе;
- учитывать особенности каждого члена команды.
В чистом виде роль почти не встречается, даже если список обязанностей на рекрутинговом сайте говорит об обратном.
Должность тимлида может объединять сразу несколько ролей: тимлида, техлида и ведущего разработчика. На этой позиции специалист нередко сам пишет код, руководит работой команды и отвечает за техническую часть:
- разрабатывает стратегию развития проекта;
- проектирует архитектуру;
- определяет стек технологий для конкретных задач и проектов;
- следит за версиями задействованных библиотек;
- отвечает за качество кода;
- контролирует уровень техдолга, чтобы тот не стал критичным для проекта.
Для бизнеса куда удобнее, когда тимлид и техлид — один человек. На практике даже в крупных компаниях должность тимлида предполагает сочетание всех трех ролей в разных пропорциях. Поэтому представления о том, чем же занимается тимлид, часто разнятся.
Если спросить разработчиков из разных компаний, что входит в обязанности тимлида, ответы, скорее всего, будут разными. Такой же разброс мнений будет и среди самих тимлидов. Чтобы в этом убедиться, достаточно зайти на HeadHunter и посмотреть список обязанностей в разных вакансиях.
Кто может стать тимлидом
Чтобы возглавить команду разработки, нужны серьезные компетенции и опыт. Поэтому самый распространенный и правильный путь в тимлиды — сначала дорасти до уровня сеньора и только потом метить на руководящую должность. Но так бывает не всегда.
Если команда состоит только из мидлов и среди них есть инициативный сотрудник, который в курсе всех дел и болеет за проект, он будет прекрасным тимлидом. Да, у него поменьше технических навыков, чем у сеньора, но если в команде нет никого выше по уровню, его компетенций будет вполне достаточно.
При этом далеко не для всех сеньоров должность тимлида будет подходящим карьерным ростом. Работать на руководящей позиции должно быть по-настоящему интересно, иначе от количества менеджерской нагрузки можно зачахнуть.
Как понять, что потянешь нагрузку
Короткий ответ: попробовать. Сказать руководителю, что хочешь бесплатно взять на себя дополнительные обязанности и посмотреть, что получится. Это схема win-win, поэтому начальство обычно охотно идет навстречу.
Тимлид в выигрыше: кто-то делает за него его работу.
Бизнес в выигрыше: работа выполняется, а денег за нее платить не нужно.
Тимлид-стажер тоже в плюсе: поработав в таком режиме от нескольких месяцев до года, он может понять для себя, получается и нравится ли ему руководить. И если по каждому пункту ответ «да», можно всерьез задумываться о росте в эту сторону.
Как стать тимлидом: стратегии роста
Варианта всего два. Первый — пересидеть всех остальных разработчиков в компании и стать тимлидом как самый «старый» сотрудник. Однако есть риск, что слово «старый» не придется брать в кавычки. Второй вариант — самому проявить инициативу.
Расскажу, как было у меня. По диплому моя профессия — менеджер, а программирование я изучал самостоятельно параллельно с учебой в вузе. Так что тимлидом разработки я решил стать еще до того, как устроился на первую работу в качестве программиста.
Сначала я работал в небольших компаниях. Мне понадобилось два года, чтобы набить руку и вырасти из джуна в крепкого мидла. Без опыта в программировании стать хорошим тимлидом не получится: нужно понимать, как устроен процесс разработки, какие бывают ошибки и подводные камни.
Спустя несколько лет я пришел работать в крупную компанию и сразу обозначил, что хочу быть тимлидом. В больших компаниях раз в полгода-год обычно проводят перформанс-ревью, когда руководитель встречается с сотрудником и вместе они строят план индивидуального развития на ближайшую перспективу. На каждой такой встрече я говорил, что хочу стать тимлидом. В первый раз мне сказали: «Все классно, но сначала наберись опыта». Мы составили такой план развития, чтобы я мог получить руководящий опыт.
Около полугода вместе со своим тимлидом я оценивал и декомпозировал задачи и пробовал раскидать их между сотрудниками. Когда качество нашей работы плюс-минус сравнялось, в компании как раз сформировалась новая команда фронтенд-разработки, которую я возглавил. В крупных компаниях долго ждать не приходится.
Говорят, в развитии тимлида есть два важных рубежа: первый — от двух до шести сотрудников, второй — 7 и более. Сначала у меня был всего один сотрудник, а сейчас я возглавляю три команды фронтенд-разработки — 12 сотрудников.
Я просто проявлял инициативу, светился перед руководством, и, как только появилась возможность, меня поставили тимлидом.
Ждать роста или уходить в другую компанию
Тимлидов часто растят внутри компании, и это важно учитывать. Если на нынешней работе есть перспективы роста, стоит проявить инициативу и попробовать себя в роли руководителя. Но если вся команда — фронтендер и бэкендер и каждый сам себе тимлид, не стоит ждать чуда. Лучше перейти в компанию покрупнее и обозначить, что в перспективе хотите занять руководящую должность. Вам понадобится время, чтобы изучить процессы, понять бизнес-логику проекта. Но когда в компании откроется подходящая позиция, с большой вероятностью выберут вас, а не человека со стороны.
Какие навыки помогут стать хорошим тимлидом
На позиции тимлида одинаково важны и хард-, и софт-скилы. Чего не хватает по хардам, разработчики обычно и сами знают. Тем более эти требования сильно привязаны к специализации и стеку технологий, поэтому универсального списка не существует. Я расскажу о софт-скилах, которые считаю критически важными для продукта и компании.
Находить проблемы в процессах
От процессов в компании зависит скорость и качество разработки, а значит, и стоимость, но они редко бывают идеальными.
Например, ты исправил баг и готов вывести сборку на стенд, бизнес ждет. Но для этого нужно пройти пять пайплайнов и собрать согласования у всех причастных. Ты пишешь ответственным — тишина. Начинаешь их дергать, но приходят отписки — всем некогда. Так может пройти до шести часов, прежде чем исправленная версия попадет на стенд. И все это время ты тратишь на попытки достучаться до коллег, а бизнес теряет деньги.
Другой пример — непомерное количество доступов к разным системам, программам, стендам, репозиториям. Обычно этим страдают банки. Человек приходит на работу, ему нужно вникать в проект, но первый месяц-полтора он вообще ничего не может сделать, потому что — правильно — нет доступов. Другая проблема с доступами в том, что их много, и их названия невозможно запомнить. Например, вместо «доступ к репозиторию» в справочнике будет A32B18KZ — попробуй найди.
Я знаю реальные случаи, когда разработчик месяц-два не мог приступить к работе. Все это время он получал зарплату, но разочаровался и уволился. То есть, в компании полгода искали сотрудника, два месяца просто так платили ему зарплату, а после пришлось запускать процесс рекрутинга заново.
Такие проблемы в процессах усложняют и замедляют работу. Задача тимлида — увидеть их и понять, что конкретно работает плохо, где происходит сбой.
Решать проблемы или правильно доносить их до бизнеса
Важно не просто увидеть проблемы в процессах, но предложить варианты решения. С некоторыми трудностями можно разобраться самостоятельно, не привлекая менеджмента. Например, команда мучится с неудобным стейт-менеджером. Если проект небольшой или только в самом начале, можно устроить созвон, найти оптимальный вариант и расписать, как поэтапно внедрить без потерь новый стейт-менеджер. Решение найдено, а бизнес даже не знал о существовании проблемы.
Но большинство проблем можно решить только с помощью вышестоящего руководства. Например, чтобы ускорить выгрузку сборок на стенд, можно выделить человека, который обладает хорошими связями во всех отделах и имеет доступ к лицам, принимающим решения, и подключать его к процессу согласования. Если от коллег из других отделов нет обратной связи, он знает, кому писать, и может в ручном режиме наладить процесс. Но такая работа требует отдельной должности, поэтому нужно получить одобрение руководства компании.
Аналогичным образом решается проблема с доступами. Большинству разработчиков нужны одни и те же системы и программы. Например, фронтендерам — репозиторий, стенд, Jira и т. д. Так почему бы не сделать для них стандартный пакет доступов и не нанять человека, который за небольшую зарплату будет их запрашивать. Но для этого тоже нужна воля высшего руководства компании.
Поэтому один из основных навыков тимлида — уметь правильно донести суть проблемы до бизнеса. Здесь есть свои секретики.
- Одного раза недостаточно. Проблемы редко решаются после первого обращения, поэтому нужно ходить к руководству с определенной периодичностью и напоминать о проблеме: «команду это деморализует», «мы теряем продуктивность».
- Если видишь, как связаны проблемы команды и интересы бизнеса, бей в это место. Например, случился критичный баг, на исправление которого ушло два дня, хотя работы там на несколько часов, и в результате бизнес потерял деньги. Идешь к руководству и говоришь о проблеме согласования сборок. В такие моменты бизнес максимально открыт к предложениям. Но надо, чтобы решение уже было наготове.
Говорить с бизнесом на одном языке
Самый верный способ — подсчитать, во сколько проблема обходится компании, прежде чем идти с ней к руководству.
Я как тимлид фронтенда регулярно собираю обратную связь от сотрудников. Например, разработчики постоянно жалуются, что задачи плохо описаны. Из-за этого приходится долго выяснять, что хотел от них автор задачи. Потом тестировщики приходят к разработчикам и пытаются понять, что было сделано и что именно им нужно тестировать, и дальше по цепочке. В итоге суть каждый все равно понимает по-своему, и появляются баги.
Я подсчитал, что в среднем на исправление багов команда тратит 40% рабочего времени. Вместе с командой мы провели ретроспективный анализ и выяснили, что половина этих багов возникла лишь потому, что они неправильно поняли суть задачи. То есть 20% рабочего времени разработчиков тратится впустую — из-за того, что задачи плохо описаны. Вот с этой цифрой стоит идти к руководству. Ее несложно конвертировать в деньги — тот самый язык, который понимает бизнес.
Создавать благоприятную атмосферу внутри команды
Когда людям приятно работать друг с другом, любое взаимодействие проходит проще. Почему Scrum так популярен? Это не про документацию, а про людей. Иногда результативнее созвониться с коллегой на две минуты, чем ждать два дня, пока он задокументирует свой ответ и все подробно опишет. Так вот, когда внутри команды царит атмосфера взаимопонимания и взаимопомощи, людям легче обращаться друг к другу. Например, нашел ты кусок кода и не понимаешь, что он делает. Если обстановка в коллективе не очень, ты просто побоишься позвонить и спросить — «еще подумает, что я тупой».
Чтобы поддерживать хорошие отношения в команде, я раз в неделю провожу часовые созвоны. Это время мы делим на три части. Первая — это «расслабон». Мы делимся мемами, шутим. Вторая часть — обсуждение проблем. Иногда мы вместе накидываем карточки в Miro, что кому не нравится. Так у меня складывается картинка, что именно тормозит ребят. Дальше мы можем накидать варианты решений, которые я потом буду лоббировать перед руководством. И завершаем снова «на расслабоне»: можем обсудить кино или еще что-то. Такие встречи создают позитивную атмосферу и дают мне, как руководителю, понять, какие боли есть в команде.
Делегировать
Частая ошибка начинающих тимлидов — замыкать рабочие процессы на себе. В таком случае, если тимлид вдруг заболеет или уйдет в отпуск, работа начнет буксовать, и его постоянно будут дергать. Чтобы этого не произошло, можно научить кого-то из команды выполнять часть тимлидовских обязанностей. Например, раз в месяц доверять другим распределять задачи. Так в команде у кого-то еще будет такой навык, а тимлид сможет спокойно ходить в отпуск, зная, что без него ничего не сломается.
Пожалуй, это хороший критерий оценки работы тимлида: если убрать тебя из команды, запаса прочности точно должно хватить на месяц.
Грамотно распределять зоны ответственности внутри команды
В разработке для управления рисками на проекте применяют такую метрику, как bus factor. Она показывает, сколько членов команды должен сбить условный автобус, чтобы вывести из строя весь проект. Если bus factor = 1, у вас серьезные проблемы.
Например, мы разрабатываем сложный проект. В нем есть мудреный модуль, и только один разработчик знает, как он работает, и умеет с ним обращаться. Если этот человек заболеет, уволится или уйдет в отпуск, изменение этого модуля превратится в очень долгую и дорогую процедуру, что негативно скажется на всем проекте. Чтобы этого не произошло, нужно постепенно учить других сотрудников работать со сложными модулями или библиотеками.
Тимлид должен уметь грамотно распределить ответственность внутри команды, не замыкая процессов на одном человеке, не делая его критически важным для проекта.
Стратегическое видение проекта
Тимлид должен понимать, куда движется проект, какие у него есть проблемы и как их лечить. Например, общая загрузка команды — 100 рабочих часов в неделю. И бизнес накидывает на все 100 часов своих хотелок. А в это время на проекте копится техдолг, с которым тоже пора разбираться. Задача тимлида — отследить момент, пока техдолг не стал критичным, и пролоббировать перед руководством, чтобы какой-то процент времени команда тратила на решение текущих проблем.
С какими проблемами можно столкнуться
Лучше еще на старте знать, от чего выгорают тимлиды, чтобы распознать тревожные звоночки.
Непонимание со стороны бизнеса
Это самая распространенная проблема, когда ты из месяца в месяц пытаешься достучаться до руководства, приходишь со своими проблемами и готовым решением, но наверху лишь заносят проблему в бэклог, и ничего не происходит. Причин может быть несколько. Первая — ты говоришь с бизнесом не на том языке, и стоит изменить подход. Вторая — твой начальник «знает все лучше всех» и продолжает сражаться с ветряными мельницами. В таком случае лучшим решением будет сменить компанию.
Нехватка ресурсов
Простой пример:— твою команду постоянно заваливают задачами, и рук уже не хватает. В малом и среднем бизнесе может просто не быть денег, чтобы нанять новых сотрудников. В таком случае можно взять на себя дополнительную роль, например роль системного аналитика, и заняться описанием задач, чтобы работа двигалась быстрее. В крупных компаниях деньги, скорее всего, есть, но цепочка принятия решения слишком длинная, и нет никакой гарантии, что между начальниками третьего и четвертого звена не пробежала кошка и процесс из-за этого не застопорится. Здесь можно лишь попытаться перетянуть кого-то из высшего руководства на свою сторону или просто ждать.
Не видно результатов работы
Бывает, приходишь в компанию, разрабатываешь стратегию, строишь планы, горишь работой, но время идет, а ничего не меняется. Здесь недолго и приуныть: «Да кому все это нужно». В таком случае можно провести ретроспективный анализ, чтобы понять, почему проект не развивается. Спросить себя: «Может, я не туда бью, не те проблемы решаю?»
Отсутствие инструментов для достижения цели
Так бывает, когда тебя поставили на руководящую должность, наградили ответственностью, а рычагов управления не дали. Например, нет возможности самостоятельно проводить собеседования и набирать разработчиков к себе в команду. Здесь варианта всего два: либо пытаться достучаться до бизнеса и обозначить свою позицию, либо менять компанию.
Доступ к бизнесу
Чтобы развивать продукт и решать текущие проблемы команды, тимлид должен быть в постоянном контакте с лицами, принимающими решения. Если доступ к «верхушке» закрыт, проблемы так и останутся нерешенными, перспективные стратегии развития — неозвученными, и мотивация работать потеряется. Чтобы не выгореть, лучше сменить компанию, если наладить отношения с руководством не выходит.
Перманентный режим аврала
Иногда задач сыплется слишком много, и команда уже не справляется со входящим потоком. В ситуации постоянного аврала регулярные созвоны отходят на второй план — кому нужны мемы и пустой треп, когда этот час можно потратить на устранение багов. В итоге вся команда превращается в загнанную лошадь, которая рано или поздно выдохнется, и люди начнут уходить. Все, что может сделать тимлид, — попытаться выбить расширение штата или поставить задачи в очередь.
Плохая атмосфера в команде
Такое может случиться, если ты пришел в уже сложившуюся команду, где все друг друга ненавидят. В коллективе уже укоренился токсичный стиль общения, и ни о какой взаимопомощи речи не идет. Тогда единственное, что можно сделать, — расформировать всю команду и набрать заново.
Какой бы ни была проблема, всегда есть шанс на благоприятный исход. Не стоит сдаваться после первой же неудачи. Возможно, стоит немного подождать или сменить подход. Но если все перепробовал, а ощущение такое, будто стучишься в глухую стену, то решение уйти будет единственно верным.
Заключение
Умение решать проблемы — важное качество тимлида. Но получается, увы, не всегда. Но если чувствуете, что уже год или два топчетесь на месте и никак не можете на это повлиять, а расти хочется, сменить компанию — неплохая идея. Не стоит бояться перемен. Менять работу — это нормально.
