«Победить проект во что бы то ни стало»: введение в профессию тимлида

«Тимлид не альфа-самец, каким его считают»

— Тимлид — кто он такой?

Алексей: Тимлид — человек команды. Наставник, ментор, тренер — как угодно. Он следит, чтобы сотрудникам было комфортно и они развивались, а задачи выполнялись в срок. Чаще всего на эту должность назначают тех, кому доверяют, кто возьмёт на себя ответственность за результат.

Тимлид не альфа-самец, каким его считают (самый сильный, громче всех рычит и лучше бьётся). Альфа-самец — это про собственную власть. Тимлид — не про себя, а про людей. Он принимает удары и разруливает их.

— В чём разница между тимлидом, техлидом, менеджером проектов и руководителем проектов?

Алексей: Менеджер управляет проектом, отслеживает его статус. Он не может принимать глобальные решения. Такая возможность есть у руководителя, на нём лежит ответственность за проект. Тимлид занимается командой, контролем её процессов и сроков, а техлид — техническими работами. Например, определяет стек технологий или его архитектуру.

Дмитрий: Здесь нужна предыстория, чтобы объяснить, как профессии тимлида, техлида, разработчика и аналитика сформировались из обязанностей одного человека.

— Интересно.

Дмитрий: У нас с Лёшей немного разные пути в профессию. Я практик. Моя карьера началась, когда любому бизнесу требовался «мальчик, который придёт и всё сделает».

Тогда деревья были большими, проекты маленькими, а «мальчика» и правда хватало. Он верстал (фронтендеров тогда не было), как-то программировал вёрстку (тогда не было и бэкендеров) и оформлял страницу (даже дизайнеров не было). Рынок рос, у «мальчика» копились обязанности. Он не справлялся физически. Тогда роли начали отпочковываться: появились дизайнер, программист, потом аналитик, от него — системный аналитик, бизнес-аналитик и так далее. Стали формироваться команды.

— А в кого мог вырасти этот «мальчик»?

Дмитрий: Либо в большого начальника, который рулит процессом (СТО, СIО), либо в начальника на уровень пониже, в тимлида. Основная его функция теперь — «победить проект» во что бы то ни стало.

Тимлид должен видеть «победу», знать путь к ней и добежать по этому пути с минимальными потерями. Его ресурсы — это команда. Выросший «мальчик» работает с её ожиданиями, софт-скиллами, хард-скиллами и мотивацией. Кому-то нужно заработать больше денег на ипотеку, кто-то хочет завоевать доверие команды, третий, наоборот, боится это доверие потерять.

— Многие считают, что тимлид может работать только в сфере разработки…

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

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

Задачи тимлида: на конкретных примерах

— Объясните на примерах: из каких конкретно задач состоит работа тимлида?

Дмитрий: Я воспринимаю работу тимлида по слоям. Нижний — работа с командой, чуть выше — работа с планированием, ещё выше — работа с бизнесом.

1. Работа с командой, краткосрочное планирование.

На этом уровне тимлид работает в рамках спринта. Вначале он проводит планирование и составляет бэклог. Далее организует демонстрацию проекта и подводит итоги.

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

2. Планирование в среднесрочной перспективе и контроль глобальных задач.

На следующем уровне тимлид взаимодействует с продакт-менеджерами и проджект-менеджерами, изучив перед этим результаты команды. Например, на прошлом спринте две команды провалились — и надо придумать, как этот фейл компенсировать в следующем спринте.

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

3. Работа с бизнесом.

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

Алексей: Ещё все, говоря о работе тимлида, постоянно опускают вопрос people-менеджмента.

— А что с people-менеджментом?

Алексей: Например, если в команде появился стажёр или открылась вакансия, это нужно контролировать, и на тимлида ложится дополнительная нагрузка. Кроме того, он постоянно должен думать о том, что происходит в команде, о процессах и задачах.

Приведу интересное наблюдение: на выполнение своих задач разработчик тратит 70–80% рабочего времени, а у тимлида есть на это лишь 50–70%. Но если у него большая команда и сложные заказчики, то вообще лишь 20%. Всё остальное время тимлид работает этаким «дежурным за входящим потоком», то есть оценивает поступающие задачи и распределяет их.

— Допустим, в команде действительно появляется стажёр или джуниор. Как правильно вовлекать новичков в процессы?

Алексей: Эти сотрудники почти без опыта. Они не всё знают и не всеми инструментами владеют. Поэтому таким ребятам лучше всего давать простые и понятные задания с минимальными рисками. Это не должны быть задачи «по решению проблемы», когда нужно проанализировать ситуацию и выбрать самый эффективный путь, — так делают уже сеньоры.

Джунов и стажёров нужно всё время контролировать — и задавать им побольше вопросов вроде «Как ты будешь решать эту задачу?», «Как ты думаешь, за сколько её выполнишь?» Это открытые вопросы, на них нельзя ответить «да» или «нет».

— А что плохого в закрытых вопросах?

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

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

Дмитрий: А мне нравится такая практика: подробно описываешь суть проблемы, все-все-все особенности, объясняешь алгоритм и отпускаешь. Когда джун возвращается, ты точно так же проверяешь каждый шаг. Если всё получилось, в следующий раз даёшь задание без алгоритма — справится или нет? Не справится — возвращаемся на первый шаг. Справится — усложняем дальше до тех пор, пока не сможем просто прийти и сказать: «Вася, сервер упал, подними, пожалуйста» ;)

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

— Вырасти в тимлида можно только из мидла и сеньора — или возможен другой путь?

Алексей: Конечно, джун сразу в тимлида не вырастет. Но рост всегда будет у тех, у кого есть шило в заднице ;) У тех, кто предлагает изменения в процессах, думает, как вырасти в техническом плане, ходит на конференции, читает «Хабр» и сразу хочет применять новые знания на практике.

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

— А случается так, что на роль тимлида ищут человека извне, а не повышают кого-то из команды?

Алексей: В моём управленческом опыте это довольно частая история. Например, люди хорошо выполняют свою работу, но им постоянно нужно ставить задачи. Я думаю за них, как им развиваться, — а это не совсем правильно. Мне комфортнее работать с инициативными людьми, чтобы я, как руководитель, направлял их инициативы в интересах компании.