Многие программисты рассматривают свой карьерный путь через тимлида, становятся ими случайно. Или наоборот выбивают себе эту роль в команде, могут уже являться лидерами в команде, а может просто больше всех проявляли активность. И поговорка: «Вместо хорошего программиста, получаем посредственного менеджера» тут как нельзя кстати. И эта статья про то, как из посредственного менеджера сделать хорошего.
Прежде всего хочу рассказать про себя, меня зовут Никита Сапогов, и я руковожу Backend-разработкой в компании Ситилинк в отделе веб-разработки. Под моим руководством около 50 разработчиков, 6 из которых тимлиды, каждый из которых был выращен внутри компании из разработчиков.
По-настоящему задуматься над процессом обучения и его структуризации заставил одновременный выход на удалёнку всей команды разработки и увеличение количества тимлидов вдвое с 2 до 4. То есть нужно доучить двух тимлидов и обучать всех четырёх работать на удаленке эффективно.
Кто такой тимлид в Ситилинке
Прежде чем рассказывать про само обучение, стоит сказать какую роль выполняет тимлид в нашей команде:
- участвует в жизни несколько команд (до 3-ех);
- участвует во всех скрам-митингах этих команд, но не ведёт их;
- проводит техревью разработчиков;
- участвует в оценке и декомпозиции задач;
- последний ревьювер;
- управляет техдолгом (в том числе договаривается с продукт-овнером);
- участвует во встречах с бизнесом и предлагает решения.
Чему обучаем
Календарь — главный помощник
Первое с чем встречается наш тимлид это со встречами, обещаниями, большим кол-во ревью, решением архитектурных вопросов, проработкой больших задач/проектов, решением срочных вопросов и т.д.
И на первом этапе мы встретились с повальной неуспеваемостью и стрессом, и выражениями типа: «Я целый день что-то делал, но вот что не помню», но самое худшее проявление, это когда мне пишут, что мой тимлид упустил из виду что-то и подвёл тем самым.
Я когда-то и сам был в такой ситуации и нашел для себя банальное решение — календарь и начал обучать этому своих тимлидов, тут очень простой процесс:
- все регулярное записываешь в календарь, например выделить время на просмотр ревью, обед, общение с разработчиками;
- если нужно проработать большой проект, поставь несколько встреч на себя
- если нужно сделать что-то чего не хочется, поставь встречу на себя.
Следуя этим правилам тимлид ничего не забудет, и сможет давать правильные ответы на вопрос: когда будет готово?
Защищать календарь, как кошка-мама котёнка
Почти сразу тимлиды сталкиваются с тем, что в их календарь начинают ставить пересекающиеся с текущими встречи. И тимлид начинает отказывать от своих ранее запланированный встреч. Это в корне неверно!
После обучения пользования календарем я учу защищать его, и говорить слово — “нет”. Ибо если встреча срочная и важная, тимлиду напишут, пообщаются и найдут способ как устроить встречу.
Делегирование наше все
Второе чему приходиться обучать — делегирование, это очень важный процесс и недавние разработчики понимают, что они сделают быстрее, чем объяснят, и в 100% случаях это так и есть. Но тимлидов выбирают не для того, чтобы они решали задачи быстрее всех, а для развития команды и продукта. Для решения проблемы делегирования и объяснения предпринимаем следующие меры:
- учим писать документацию и доносим важность этой деятельности (чтобы объяснить текстом один раз для всех);
- проводить митапы, воркшопы (когда тема сложная и нужен дополнительный источник, помимо текста);
- показываем как можно проработать задачи так, чтобы уменьшить шанс их “недопонимания”.
Почти все из списка выше учим на основе текущих примеров или личного примера. В особо сложных случаях, проводится индивидуальная работа и контроль, может дойти вплоть до принудительного делегирования конкретных задач и запрет на самостоятельное решение.
Делегировать страшно всегда, но делать это надо, и мы в этом помогаем тимлидам.
Отстаивание позиции
Тимлиду важно следить за тем, чтобы разработка шла в правильном русле, это его обязанность. Если что-то этому мешает, мы ожидаем от тимлида, что он встанет стеной и не позволит этому случиться. Но тимлид, который раньше был разработчиком мог таким никогда не заниматься и не возникал особо. Это надо развивать. Процесс становления примерно такой:
- обучаем сообщать обо всех проблемах как можно раньше;
- напоминаем регулярно об обязанностях и ожиданиях от тимлида;
- напоминаем о том, кто его непосредственный руководитель и что к нему всегда можно обратиться, если ему не удается отстоять свою позицию или донести свою мысль.
Как следствие тимлид начинает лучше формулировать свои мысли, правильно ставить акценты и понимать, что по-настоящему важно.
Разговаривать
Навык говорения важен, так как 90% времени проводится за этим занятием. В тимлиды обычно отбираются те, у кого этот навык хорошо развит, но когда приходится это делать много, могут возникнуть проблемы.
Навык говорения применяется для проведения 1-on-1 встреч, решения спорных моментов между другими тимлидами, командами, отделами и так далее.
Возьмем довольно знакомый пример: новый тимлид в случае проблем с разработчиком, сразу говорит, мол давайте уволим? Но, как окажется он даже не спросил у разработчика: а в чём проблема? И после разговора все проясняется, проблемы его решаются, и он снова успешно работает.
Тимлид, умеющий разговаривать и договариваться, становится более самостоятельной единицей и освобождает время руководителя.
Заключение
Важная особенность обучения тимлидов работе с людьми — понимание, что они на это никогда не учились, у них есть предпосылки к этому и их надо развить.
Облегчает процесс обучения тот факт, что разработчики привыкли постоянно учиться. Обучению работе с людьми оказывается очередным чтением серий книг, статей, просмотром видео с конференций и общение со своим наставником.
И даже тот список и способ обучения не конечен, мы также постоянно его совершенствуем, экспериментируем, отказываемся и пересматриваем.