🚀 Trustee Plus - ваш криптогаманець з вбудованою платіжною карткою тут 👉
Марія БровінськаРабота
27 июля 2022, 15:00
2022-07-27
Профессии в IT. Кто такие тимлиды, что они должны знать и как их оценивать?
Большинство молодых айтишников с первых дней работы мечтают вырасти до сеньора и стать тимлидом, менторить джунов и помогать команде решать сложные задачи. Однако какими именно компетенциями должен обладать тимлид, что уметь и где учиться — вопрос для многих открыт. Чтобы прояснить эту ситуацию, мы пообщались с Solutions Architect в компании DataArt Дмитрием Куперманом, уже много лет занимающимся асесментом тимлидов в компании: проводит интервью и оценивает подготовку и опыт коллег и кандидатов.
Большинство молодых айтишников с первых дней работы мечтают вырасти до сеньора и стать тимлидом, менторить джунов и помогать команде решать сложные задачи. Однако какими именно компетенциями должен обладать тимлид, что уметь и где учиться — вопрос для многих открыт. Чтобы прояснить эту ситуацию, мы пообщались с Solutions Architect в компании DataArt Дмитрием Куперманом, уже много лет занимающимся асесментом тимлидов в компании: проводит интервью и оценивает подготовку и опыт коллег и кандидатов.
Эта статья — попытка записать и упорядочить выводы, сделанные Дмитрием, отвечая на вопросы коллег:
Содержание
Дмитрий Куперман
Кто такой тимлид?
Тимлид — это, очевидно, руководитель команды разработки. Для клиентов — главный технарь, точка входа для обсуждения технических вопросов. Для команды — человек, который принимает технические решения и отвечает за них, а также за построение команды и атмосферу в ней.
Тимлид и техлид — одно и то же?
Не совсем. Вообще, четкого предела, «где начинается полиция и где кончается Беня», нет. Редко на каком-то проекте работают и PM, и тимлид, и техлид, и архитектор, и ВА. Там, где они все же есть, вероятнее всего, любые трое из этих пятерых могут проделать всю лидскую работу, если хватит здоровья.
PM обычно отвечает больше за процессы, бюджеты и стафинг. Он часто играет роль скрам-мастера на стендап-звонках.
Если в проекте есть отдельный техлид, то это главный сеньор, ответственный за технические решения.
Тимлид где-то посередине. Он должен быть достаточно сильным инженером, способным ответить на любой технический вопрос (неважно клиента или команды). Но ему нужны и хорошие знания методологии разработки, и развитые софт-скилы, чтобы выступать скрам-мастером и представлять команду на различных клиентских митингах. Чаще тимлид также выполняет роль техлида, хотя мне приходилось видеть конфигурации команды, где это были разные люди.
Сам я был тимлидом в такой команде только однажды. Техлидом был другой человек — один из самых крутых джавистов со всего DataArt, классический программист-интроверт по анекдотам. Ему бы задача посложнее, и чтобы никто не трогал. Я не принимал без него технических решений, он не особо общался с клиентами. Но что любопытно, если нам приходилось делать сложный выбор, он мог советовать и настаивать, но всегда оставлял последнее слово за мной. Мол, тебя спросят, ты и решай.
Требования к тимлиду
Теперь обсудим подробнее, что именно должен делать тимлид и почему у него не остается времени писать код.
Тимлидство держится на четырех ногах:
Техлидство.
Менеджмент и процессы.
Общение с клиентами и account management.
Общение с командой и люди управления.
Техлидство. Здесь все понятно: нужно быть достаточно крутым программистом, чтобы отвечать за технические решения. Даже если в проекте есть отдельный техлид, нужно хорошо разбираться в коде, чтобы помогать команде и отвечать на вопросы клиентов. Поэтому тимлид всегда задействован в код-ревью. Часто процесс вообще настраивают так, что без апрува от тимлида нельзя было вмержить пул-реквест, даже если его уже просмотрела вся команда.
И для авторитета в команде важно быть на уровне. Хорошо, когда тимлид может сесть на место любого из разработчиков и сделать его работу не хуже, а то и лучше.
Если и ты сам, и команда в этом уверены, будут прислушиваться к тебе гораздо охотнее, чем к теоретику, который сам код не пишет, но мудрствует. Сам я, уйдя из тимлидов в архитекторы, как раз и превратился в такого теоретика.
Я много писал на Java до 7 версии, поэтому в моей картине мира нет ни сдержек, ни лямбд. То есть я все это знаю, попробовал и оценил, но не набил на них руку до нужного уровня. Несколько раз был высмеян командой за предложения больших кусков кода, вместо которых сегодня можно написать три строчки. Особенно насмехался мой бывший практикант. (Правда, он недавно тоже стал архитектором, посмотрю на него через несколько лет!) С тех пор пытаюсь, предлагая решение, описывать алгоритм, а не способ его реализации.
Менеджмент и процессы. Тимлид — не всегда скрам-мастер, но в любой момент должен быть готов его подменить. Кроме того, он вовлечен во все процессы жизненного цикла спринта и скрам-церемонии (кто не вспомнил пять скрам-церемоний — быстро пошли гуглить!). Поэтому теорию по основным методологиям разработки, а сейчас это разные производные Agile, нужно знать и уметь применять. На одном PM команда не уедет.
Тимлид вместе с PM выстраивает удобный для команды и клиента процесс (даже если процесс изначально навязан клиентом, его можно подтолкнуть).
Кроме того, он не только учит команду работать в соответствии с этим процессом, но и следит, чтобы его придерживался клиент. Думаю, многим знакома ситуация, когда после определения скоупа спринта клиент начинает требовать добавить к нему еще несколько очень важных задач. Желательно ничего из спринта не выбрасывая.
Общение с клиентами и account management. Тимлид общается с клиентом постоянно — ежедневно и много раз. Участвует в технических дискуссиях и обсуждении требований. Рекламирует успехи команды, сообщает о проблемах, отвечает перед клиентом за провалы. Но обязательно несет клиенту главный месседж современной разработки: «Мы не просто усердно пишем код, а понимаем бизнес-потребности заказчика и удовлетворяем их». Может быть, совсем не так, как представлял сам заказчик.
Пока Тимлид не поймет, что нужно клиенту на выходе, он от клиента не отстает. Пока разработчик не поймет, зачем клиенту нужна эта фича, он не начинает писать код. И так, привить такую культуру команде тоже задача тимлида.
Если мы видим, что клиенту чего-то не хватает, не молчим: об этом нужно сообщить и клиенту, и нашей Account Management команде. Не потому, что мы продадим клиенту больше наших услуг и заработаем больше денег (хотя и это тоже важно), а потому, что он и сам нам потом не будет благодарен.
Мы несколько месяцев убеждали Product Owner в том, что в проекте нужна система real-time-мониторинга. Причем именно бизнес, где наряду с количеством ошибок показывались графики продаж за день. Зато потом приехали в командировку, а наш дашборд на больших экранах на стенах офиса светится, чтобы все видели, как обстоят дела.
Представляя команду перед клиентом, тимлид команду от клиента защищает, выступая «ушастой прокладкой». Если у клиента семь пятниц в неделю, страдать от этого имеют тимлиды и PM, но не команда.
К примеру, если клиент затеял многодневное обсуждение возможного scope change, команду к нему лучше не приобщать. То же касается уточнения требований уже работающей задачи или других подобных идей, нарушающих планы. Большое количество промежуточных результатов только нервничает инженеров и мешает им сосредоточиться.
Общение с командой и люди управления. В основном основная обязанность тимлида, отнимающего большую часть времени, — быть команде няней.
С технической частью понятно: если команда не сеньорная, каждый день придется заботиться о джуниорах и мидлах, которые чего-то не поняли или не могут с чем-то справиться.
Но важно и другое: хорошо перформит только дружная команда. Где по-доброму шутят на созвонах и помогают друг другу, где люди на одной волне, всегда корректны и честны. Построение такой команды и поддержание атмосферы в ней — главная задача тимлида. Непосредственно на его плечи ложатся все аспекты работы на этом направлении от подбора людей до one-on-one-звонков и пьянок-тимбилдингов. Придется проводить интервью с новыми участниками команды, исключать неподходящих людей (неприятно, но иногда необходимо), насаждать культуру клиентоориентированной и командной работы, вести душевные беседы с раздолбаями-джунами, из которых потом вырастут крутые синьоры и т. д.
Ну и конечно, выращивать себе замену. По мере «взросления» команды кто-то из сеньоров, а иногда даже из мидлов, начнет показывать склонность или способность к лидированию.
Таким нужно помогать, отдавая под полную их ответственность реализацию отдельных фич, особенно если над фичей работают несколько человек. Конечно, присматривая, помогая и подстраховывая. На выходе может получиться новый тимлид. Когда я шел из тимлидов в архитекторы, команду возглавил коллега, который пришел в нашу команду джуниором за два года до того. Сейчас мы с ним снова на одном проекте — теперь он мой PM. И еще двое из этой славной команды перешли в другие проекты сразу на позиции лидов.
Если команда достаточно велика, то с учетом всех перечисленных обязанностей, времени на написание кода обычно не остается. Тимлид по привычке еще вешает на себя девелоперские задачи, ничего не успевает, нервничает, сидит над ними в выходные или, вздыхая, перевешивает на других. Это нормально. Прекратить работать руками страшно, но опыт показывает, что при необходимости вернуться к активной разработке форму можно восстановить через несколько месяцев.
Как оценивать тимлида
Формальных, подробно расписанных критериев оценки мы в компании для тимлидов не используем. А во время асесмента я обычно задаю несколько вопросов по основным темам, перечисленным выше, охватывая теорию и типичные ситуации. По ответам обычно становится понятно, насколько коллега зрел и опытен в управлении командой.
Техлидство. Пропускаем, ведь у нас не техническое собеседование.
Менеджмент и процессы. Базовая Agile теория и вопросы опыта ее применения. Например:
Разница между Scrum и Kanban.
Scrum ceremonies. Какие существуют вообще, какие применяемые у вас? Если используются не все, почему?
Story points. Зачем они нужны? Используете ли вы их? Если нет, то почему?
Capacity и Velocity. Что это и зачем они нужны? Как соотносятся между собой? Используются ли у вас? Ах, не используются? Как вы тогда вообще планируете?
Как не промахнуться с эстимейтами?
Как реагировать на попытки клиентов вложить в спринт незапланированную работу?
Общение с клиентами (account management). Как вести себя, если:
Ресурсов нет, а клиенту очень нужно.
Мы сильно накосячили, и клиент об этом знает.
Мы сильно накосячили, но клиент еще не знает.
Клиент пытается микроменеджить наших разработчиков.
У клиента сменилось руководство.
Мы не согласны с техническими требованиями клиента.
Общение с командой (people management). Как вести себя, если:
Коллега ведет себя пассивно-агрессивно.
Коллега отказывается выполнять неинтересную задачу.
В команду пришел новичок, манера общения которого раздражает других.
Один из членов команды совсем не тянет по хард-скилам.
Я пытаюсь растопить лед, но наши звонки все равно похожи на партсборы.
Карьерный рост — куда дальше?
Возможно, отсутствие критериев и четко сформулированных гайдлайнов обусловлено тем, что сама позиция тимлида промежуточна. Тебе уже тесно в кресле разработчика, ты можешь больше, софт-скилы позволяют выйти на новый уровень взаимодействия с клиентами, но куда именно расти еще непонятно. Побыв несколько лет тимлидом, то есть еще инженером, но уже с большим объемом организационной работы, понимаешь, хочется ли тебе:
Далее углубляться в организационные активности, отходя от технических (путь PM).
Плюнуть на менеджмент и просто писать крутой код, попросив всех меньше тебя беспокоить (путь технического эксперта или SME).
Меньше организационной работы, больше — глубоко технической, но высокоуровневой, без кода или почти без кода (путь Technical Architect aka Systems Architect).
Меньше организационной работы, меньше кода — только высокоуровневая архитектура и много разговоров с клиентами для уточнения требований и согласования подходов (путь Solutions Architect).
Ничего не менять, потому что именно так тебе хорошо (путь наслаждения текущим положением вещей, которое тоже никто не отменял).
Читайте главные IT-новости страны в нашем Telegram
УЧАСТЬ В АЗАРТНИХ ІГРАХ МОЖЕ ВИКЛИКАТИ ІГРОВУ ЗАЛЕЖНІСТЬ. ДОТРИМУЙТЕСЯ ПРАВИЛ (ПРИНЦИПІВ) ВІДПОВІДАЛЬНОЇ ГРИ.
Ліцензія видана ТОВ "СЛОТС Ю.ЕЙ." на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 15.09.23 (рішення КРАІЛ №245 від 31.08.2023); ТОВ "СЛОТС Ю.ЕЙ." – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 26.04.2021 (рішення КРАІЛ №150 від 12.04.2021); ТОВ «СПЕЙСИКС» – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 08.02.2021 (рішення КРАІЛ №34 від 02.02.2021); ТОВ «ГЕЙМДЕВ» – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 16.02.2021 (рішення № 47 від 10.02.2021).
«Менеджмент не заканчивается на словах Agile или Kanban"». Кто такой Project Manager и как им стать
Желающих войти в IT с каждым днем становится больше. Однако большинство потенциальных айтишников оказываются перед сложным выбором: кем стать, чтобы работать в сфере информационных технологий. dev.ua начинает новую рубрику, в которой будет рассказывать, какие специальности в украинском IT есть, что делают конкретные специалисты и где учиться, чтобы стать айтишником.
Сегодня о профессии Project Manager рассказывает опытный PM в EPAM Яна Стильчук,
Бизнес-аналитик в IT: кто он, что делает и как им стать
Продолжаем цикл материалов про ІТ-специальности. Каждую из них описывает «типичный представитель» — опытный специалист. Мы надеемся, эти материалы помогут школьникам, студентам, переквалификантам, джуниорам и сочувствующим выбрать специальность в IТ, оценить перспективы или просто сверить часы с авторитетным коллегой. Обсуждайте и дополняйте материал в комментариях, чтобы сделать его ещё полезней.
Чем занимаются бизнес-аналитики, какими разными они бывают и какую пользу приносят бизнесу, рассказывает Юрий Гомон, BA Department Teach Lead в команде NIX.
В команде NIX вместе с другими лидами БA он отвечает за полный цикл профессионального развития бизнес-аналитиков: обучение в начале карьеры, разработку персональных планов развития, создание условий для роста и менторство. За 9 лет на его глазах более чем 50 специалистов прошли путь от Trainee до Senior и нашли свое призвание в нашей непростой, но динамичной и невероятно увлекательной профессии.
