Трансформируемся от разработчика до тимлида
Всем привет, меня зовут Ян Чикнизов.
Мой опыт в IT насчитывает уже 6 лет, и за эти годы я повидал множество тимлидов и техлидов, разного рода качества, и сам выступал как хорошим лидом, так и не очень. В статье хочу с вами поделиться опытом и навыками, которые помогли мне стать хорошим лидом (по отзывам коллег, конечно же).
В этом вопросе помогут нам разобраться два замечательных персонажа.
Первый — это тимлид. У него за плечами минимум 3–4 года разработки и год лидерства! Он побывал как и в маленьких стартапах, так и в больших компаниях, трогая самый кровавый интерпрайс.
С другой стороны у нас разработчик. Он уже уверенно чувствует себя в IT: за 2–3 года, он смог проработать как в одной компании, так и в нескольких маленьких. Но амбиции уже говорят ему, что нужно расти. Давайте же поможем нашему разработчику пройти этот тернистый путь и через навыки и опыт трансформироваться в лида.
Для этого мы возьмем пять конкретных ситуаций, на основе которых обсудим, как в этой ситуации будет вести себя разработчик, а какие обязанности будет выполнять тимлид. Обсудим, как в кратчайшие сроки создать новую фичу и как потом словить аварию после её выкатки, займемся небольшим легаси-менеджментом, а также наймем новых разработчиков. Напоследок обсудим, как в очередной раз не изобрести велосипед.
Дисклеймер. Образы собирательные, У вас в компании все может быть по другому. Скажу даже больше — у нас тоже все всё иначе — у нас нет тимлидов, а есть техлиды. Здесь я описал собирательный образ тимлида. Если у вас не так — напишите в комментариях, в чем отличия.
Создание новых фичей
Итак, первый кейс. Представим, что к героям приходит бизнес в лице любимого БОССА и просит прямо здесь и сейчас, а вернее вчера, реализовать новую функцию в приложении.
Сроки — уже вчера. Впрочем, ничего нового.
Разработчик, наблюдая за этой ситуацией, говорит что готов это сделать и написать код исходя из требований. Требований может и не быть, но он к этому готов, и сделает всё, чтобы данная фича вышла в прод в скором времени.
Ну и в конце разработчик очень надеется что всё не сломается, но в противном случае разработчик готов это быстро поправить.
Но вот на сцену выходит тимлид, что же будет делать он? Он для начала поймет и обсудит, а что собственно требуется делать и нужно ли.
В его задачу входит обсудить новую фичу с бизнесом и вообще понять нужна ли она.
После обсуждения он наверняка захочет ее реализовать! Но, конечно же, своими руками он ничего делать не будет — ОН ЖЕ ТИМЛИД
