Всем привет, меня зовут Ян Чикнизов.
Мой опыт в IT насчитывает уже 6 лет, и за эти годы я повидал множество тимлидов и техлидов, разного рода качества, и сам выступал как хорошим лидом, так и не очень. В статье хочу с вами поделиться опытом и навыками, которые помогли мне стать хорошим лидом (по отзывам коллег, конечно же).
В этом вопросе помогут нам разобраться два замечательных персонажа.
Первый — это тимлид. У него за плечами минимум 3-4 года разработки и год лидерства! Он побывал как и в маленьких стартапах, так и в больших компаниях, трогая самый кровавый интерпрайс.
С другой стороны у нас разработчик. Он уже уверенно чувствует себя в IT: за 2-3 года, он смог проработать как в одной компании, так и в нескольких маленьких. Но амбиции уже говорят ему, что нужно расти. Давайте же поможем нашему разработчику пройти этот тернистый путь и через навыки и опыт трансформироваться в лида.
Для этого мы возьмем пять конкретных ситуаций, на основе которых обсудим, как в этой ситуации будет вести себя разработчик, а какие обязанности будет выполнять тимлид. Обсудим, как в кратчайшие сроки создать новую фичу и как потом словить аварию после её выкатки, займемся небольшим легаси-менеджментом, а также наймем новых разработчиков. Напоследок обсудим, как в очередной раз не изобрести велосипед.
Дисклеймер. Образы собирательные, У вас в компании все может быть по другому. Скажу даже больше — у нас тоже все всё иначе — у нас нет тимлидов, а есть техлиды. Здесь я описал собирательный образ тимлида. Если у вас не так — напишите в комментариях, в чем отличия. Сама статья — мой адаптированный доклад с митапа Alfa LevelUp Day. Я провёл его в несколько ироничном ключе. Возможно, на видео этот вайб передастся лучше. Видео приложил в конце.
Создание новых фичей
Итак, первый кейс. Представим, что к героям приходит бизнес в лице любимого БОССА и просит прямо здесь и сейчас, а вернее вчера, реализовать новую функцию в приложении.
Разработчик, наблюдая за этой ситуацией, говорит что готов это сделать и написать код исходя из требований. Требований может и не быть, но он к этому готов, и сделает всё, чтобы данная фича вышла в прод в скором времени.
Ну и в конце разработчик очень надеется что всё не сломается, но в противном случае разработчик готов это быстро поправить.
Но вот на сцену выходит тимлид, что же будет делать он? Он для начала поймет и обсудит, а что собственно требуется делать и нужно ли.
В его задачу входит обсудить новую фичу с бизнесом и вообще понять нужна ли она.
После обсуждения он наверняка захочет ее реализовать! Но, конечно же, своими руками он ничего делать не будет — ОН ЖЕ ТИМЛИД ?
Он найдет того, кто будет это делать и, в целом, распределит задачи между разработчиками. Тимлид имеет КОЛОССАЛЬНЫЙ опыт, поэтому не просто распределит, а расскажет как реализовать фичу и поможет со сложными архитектурными моментами. Так же он будет следить за тем как эта фича разрабатывается и успевает ли его команда делать это в срок!
И вот фича в проде! Тимлид получает премию, а разработчик — БОЛЬШОЕ СПАСИБО (но у нас и разработчик получит).
Какие навыки помогут разработчику стать тимлидом в данном кейсе?
Это, конечно же, опыт — опыт разработки систем и работы в сжатые сроки. Когда ты написал уже много кода, найти правильное решение не составит труда.
Софт скиллы. Ходите чаще на встречи с бизнесом, общайтесь со стейкхолдерами и это поможет набраться опыта в таком нелегком деле, как общение с бизнесом.
Ну и немного менеджерских задач — тимлид постоянно распределяет нагрузку между разработчиками, он знает, как это делать, потому что, как минимум, умеет распределить свою нагрузку.
Так что первый совет — начните с себя, с распределения своих задач и потихоньку растите в этом плане.
И вот наш разработчик получил немного знаний и уже умеет реагировать и выполнять срочные задачи вчера. И тут случается НЕОЖИДАННОЕ!
Представим такую ситуацию — первый день после отпуска, разработчик замечательно отдохнул и даже вечерний перелет не заставит печалиться по поводу следующего рабочего дня. Он спокойно спит и тут, звонок — на экране телефона неизвестный номер. «Опять спам или скам?» проносится в голове, но разработчик всё же решается поднять трубку. И слышит два роковых слова: «Прод упал»
Прод упал
И как же в этом случае поступает разработчик и лид?
Первым, конечно же, в игру вступает лид. Как минимум, потому что только его телефон есть у техподдержки. Лид, пытается оценить, что же произошло и насколько это аффектит пользователей.
Далее он готовит план решения этой проблемы. Это может быть как и простая тривиальная задача откатить изменения, которые уронили прод, так и более серьезная, например, восстановление базы данных.
И вот у лида есть план на руках. Он назначит ответственных и будет ВНИМАТЕЛЬНО следить и контролировать процесс восстановления. В некоторых ситуациях он и сам может поднять прод. Да-да, своими руками!
А я напомню, разработчик всё это время всё ещё спит и видит сладкие сны про кодирование фич.
Но вот он проснулся и что же будет делать сейчас?
Разработчик подключается к решению проблемы, в основном, уже постфактум, и пытается починить проблемный релиз. Для этого он конечно же обратится к мониторингу и логам, изучит их и раскатит уже исправленный релиз.
Видите основную разницу?
Тогда как разработчик подключается ПОСТФАКТУМ, тимлид находится в первом эшелоне решения этой аварии, он ответственный за свой продукт, он понимает, что происходит внутри и знает уязвимые места. Но, кроме того, он уже прошел через множество аварий и даже сам был их инициатором! Через опыт и ошибки тимлид научился как делать поставки без недоступности.
И еще одно принципиальное отличие в этих двух ролях:
Лид постарается не допустить проблемы в будущем, когда разработчик просто починит ее в моменте.
Получается, что важно проявлять вашу инициативу и подключаться к решению проблемы на всех этапах, а не успешно её игнорить. Именно так, в данном примере, наш разработчик смог стать на шаг ближе к лиду.
Что ждёт его в следующей «серии»?
Внезапно Разработчик слышит сплетни, некоторые из участников его команды начали увольняться, некоторые уже готовятся покинуть некогда сплоченное сообщество. Сам он тоже с трудом видит дальнейшее развитие в компании, так как весь его текущий продукт построен на легаси!
Легаси-менеджмент и тех долг
И тут уже сам разработчик может сам взять и подсветить легаси! Ну и, конечно же, он может начать реализацию стратегию по выпилу этого самого легаси из продукта — legacy out.
А что тимлид? Может он уже готовится управлять командой, состоящей из него и принтера в котором даже нет чернил? Тимлид призадумался и понял, что нужно вводить систему 80/20.
80% времени — продуктовые задачи;
20% времени — технические задачи.
Это означает, что в эти 20% можно встроить legacy out! А главное, что этот процесс можно проводит постоянно, не выбивая время и ресурсы.
Ну и, конечно же, куда без делегирования. Как же без того, чтобы всеми покомандовать?
Тимлид, как я уже неоднократно говорил, знает свой продукт. Он уже довольно таки давно варится в этой индустрии и видит куда она идет, а, главное, он организует процесс избавление от легаси постоянным, а не разовым событием.
Здесь наш разработчик передумал писать заявление, помог выпилить всё легаси и даже взял на себя небольшую инициативу и ответственность за Legacy Management.
И тут все свободные разработчики в индустрии прознали, что есть такая компания, где нет легаси! И решили резко, все и в один день, откликнуться на абсолютно все вакансии! Тут ваше уютное маленькое сообщество, которое помещалось в переговорку, выросло до количества, сопоставимого с аудиторией среднего митапа.
Рост команды
Разработчик видит ситуацию и знает, что надо проявлять инициативу, чтобы стать лидом. Он вызывается быть наставником, возьмёт под свое крыло новичка, допишет или обновит документацию и проведёт, конечно же, онбординг!
А вот с тимлидом будет поинтереснее.
Первым делом, он, конечно же, создаст програму онбординга. Программа будет включать в себя знакомство с проектом, процессами, командой и руководством. Тимлид уже знает сильных сотрудников в команде и сможет на них положиться в таком нелегком деле, как менторинг новичков.
А дальше идет самый сложный процесс — масштабирование под новые реалии. Согласитесь — то, что работало для 5 человек, не будет работать для 20 или 30. Например, если вы проходили регресс втроем за три часа, будет совсем не целесообразно проходить тот же самый регресс на пятнадцать человек. Задачи явно требуется распределять по другому!
Ну и бонусом, лид иногда (может быть даже не у вас) может отвечать за бюрократию и разгребать вопросы, связанные с прочими прелестями крупных компаний.
Что же позволило нашему тимлиду стать тимлидом в этом кейсе?
Он уже успел поработать в качестве разработчика в крупных компания или там, где был налажен постоянный поток новых сотрудников.
В это же время он выступал в роли ментора или наставника и помогал новичкам в этом сложном пути в новой компании.
Также он видел недостатки текущей системы и активно пытался с ними бороться. Ну, как минимум, их подсвечивал.
Наш разработчик тоже не остался в стороне и стал активно участвовать в процессах, протекающих внутри команды и компании. Это позволило ему набраться опыта и вырасти до лида в данном кейсе.
Но вот прошел квартал (а у кого-то год) и наступает замечательная пора ставить себе цели!
Квартальные цели
Разработчик собрался с командой и они решили выбрать вот эту амбициозную цель!
Представьте, если бы у них не было тимлида? Никто бы не сказал, что это всё фигня, давай по новой нам не подходит.
Ребята бы трудились, изобретали, потратили бы сотни часов (а время это деньги). И вот они релизнули этот велосипед, иииииии… Ничего! Они сделали работу в стол.
Теперь забываем, что у них не было тимлида и возвращаемся в то время, когда они пришли показывать свой план! Ну, конечно же, лид сказал что так не пойдет, вы можете просто использовать ТЕХНОЛОГИЮ Х (вставьте сюда вашу любимую), вместо вашего велосипеда, и вообще это давно уже изобрели:)!
Дальше он пойдет сам формировать цели для команды, которые:
будут полезны бизнесу;
будут соответствовать стратегии (не важно, бизнесовой или технической)
Конечно же, наш тимлид будет контролировать выполнение целей. А бонусом — проводить всякие командные и менеджерские активности, one to one и ассесменты (это процесс повышения, но не просто потому что время пришло, а на основании достижений)
А что же будет делать наш разработчик? Он будет выполнять и ВЫПОЛНИТ поставленные перед ним цели, будь это личные или бизнесовые. Также он не забудет про свой профессиональный рост и, обязательно, захочет пройти ассессмент. В конечно счете, будет ООООЧЕНЬ стараться не изобрести велосипед!
Что же позволило нашему тимлиду стать тимлидом в этом кейса?
Тимлид, конечно же, не хотел изобретать велосипед, потому что именно он бы и отвечал за такое изобретение.
К тому же у тимлида своих велосипедов достаточно.Он подходил к вопросу постановки целей с включенным критическим мышление.
Тимлид не давал эмоциям взять вверх над собой. Мы же все знаем этих нервных руководителей?)
А софт скилы позволяют ему эффективно проводить командные встречи и one to one.
Хэппиэнд
И вот дошли мы до итогов. После прохождения этих пяти кейсов наш разработчик набрался опыта, прошел трансформацию от миддла до тимлида и готов выполнять задачи в своей новой роли.
А в заключение, обобщим, кто же такой этот ваш тимлид?
В первую очередь, это менеджер. Но не просто, а менеджер с огромным опытом в своей области. Он профессионал в своем деле и может заставить слаженно работать любую команду и, главное, выполнять поставленные перед ними цели! И все это подкрепляется отличными софт скилами
А вот книги (ТЫК), которые прочитал наш разработчик и смог немножечко приблизиться к заветной должности тимлида!
Видео доклада.
Рекомендованные статьи:
Как в 3 раза снизить затраты на отказоустойчивую инфраструктуру, переехав с Hazelcast на Redis
100 дней из жизни новичка: как устроен онбординг в мобильной разработке
Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.
