Онбординг Для Тимлида

Зачастую, при трудоустройстве (или смене команды), мы ожидаем, что нам должны провести онбординг. Нам очевидно, что принимающей стороне выгодно если сотрудник быстрее погрузиться в функционал и начнет приносить пользу. Вот только не всегда происходит так, как мы ожидаем. И далеко не всегда онбординг строится эффективно. В последнее время я все чаще обращаю внимание на то, как себя ведут новые сотрудники (как линейные сотрудники, так и тимлиды). И, к сожалению, вижу, что ребята сами не понимают, как быстрее погрузиться в команду и начать быстрее приносить пользу. А в компании считают, что руководители должны онбордиться сами и не помогают.

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

Что нужно знать новому тимлиду?

Верхнеуровнево, я базовую информацию разделяю на три блока:

1. Информация о продукте:

• какую проблему решает продукт;
• какая аудитория этого продукта;
• какой функционал в продукте.

2. Информация о команде:

• какая мотивация у людей в команде;
• какие у сотрудников слабые и сильные стороны;
• какие процессы в команде и почему они такие.

3. Кто принимает решения и задает вектор развития продукта

Последовательность может быть любая, но в некоторых случаях лучше начинать свое знакомство с продуктом, а уже после глубоко знакомится с командой и окружением - так будет проще понимать, о чем говорят вокруг.

А теперь подробно пройдемся по каждому пункту.

Информация о продукте

Мне удобно начинать со знакомства с продуктом. Пока ты этого не сделал - все вокруг говорят на птичьем. Этот пункт особенно важен для тимлида. Многие (в особенности начинающие) тимлиды - начинают сразу забуриваться в команду, процессы, бесконечные встречи. Далеко лишь не все могут этим управлять без понимания контекста :-) В итоге такие ребята превращаются в дорогих скрам-мастеров.

Для себя я выбрал наименее затратный вариант погружения в продукт - прошу QA провести мне виртуальную экскурсию по основному функционалу, и обязательно делаю запись. Либо могу попросить QA записать такую экскурсию, а потом смотрю запись на скорости x2. Обычно, такая экскурсия не занимает более 2х часов, но сразу дает понимание о продукте и его функционале. Записанное видео потом можно показывать новым членам команды. Во время экскурсии важно задавать вопросы относительно важности и ценности функционала (ожидаем, что QA понимает это)

Информация о команде

Я, как Dev Unit lead сперва знакомлюсь с тимлидами, узнаю про их стаж, опыт (как в текущей компании, так и в прошлых), расспрашиваю, как они пришли к этой роли. Особое внимание уделяю мотивации и вектору развития.

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

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

Следующим этапом, узнаю про процессы в команде: прошу рассказать мне жизненный цикл задачи. На этот вопрос может ответить не только тимлид, но и PM, либо кто-то из команды. И с пристрастием задаю вопросы про каждый этап движения задачи (от появления задачи на уровне идеи, до закрытия тикета в Jira). Это дает вам обзор относительно процессов, в том числе инженерных, таких как code review, тестирование и т.п.

Кто-то спрашивает про инженерные практики отдельно, но мне нравится говорить об этом в разрезе жизненного цикла задачи. Инженерные практики должны быть органично вписаны в процесс работы, в противном случае они могут быть саботированы и быть бесполезны.

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

Кто принимает решения и задает вектор развития продукта

В разных компаниях ответственность за вектор может находиться в разных плоскостях. Хорошо, если в вашей команде есть продакт-менеджер, который занимается именно этим. Если этот человек находится в другой иерархии - стоит найти время и познакомиться. Именно этот человек может дать вам важные инсайты о будущем продукта и команды. С этой информацией будет гораздо проще понять, в какую сторону стоит задавать вектор. Например: у продукта есть жизненная необходимость найти product market fit (подтвержденную ценность продукта), а вы заставляете команду все делать идеально: применять все инженерные практики, DDD, глубоко прорабатываете архитектуру. В итоге финансирование заканчивается, product marketi fit не найден, команда распущена.

Послесловие

При погружении в команду - выбирайте способ, который позволит как можно скорее погрузиться в работу. Все нефокусное откладывайте на потом. Чем скорее вы начнете разговаривать с командой на одном языке - тем проще и для вас и для команды.

Используйте этот же подход для онбординга новичков в свою команду: к выходу новичка сформируйте ему сетку встреч с тем, с кем ему будет полезно сразу познакомитьсян. Проведите продуктовый онбординг и отправьте решать задачи.