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

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

Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.

У меня получилось четыре категории:

1. Команда

2. Планирование

3. Продукт

4. Разработка

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

1. Команда

В этой категории такие задачи:

1. Отладка процесса работы над задачами.

2. Отладка процесса проведения код-ревью.

3. Проведение командных встреч.

4. Проведение встреч один на один.

5. Оценка и присвоение грейда разработчикам. Составление плана развития. Премирование на основе достижений поставленных целей.

6. Составление психологического профиля разработчиков.

7. Просмотр резюме и отбор кандидатов на собеседование.

8. Проведение собеседований.

9. Менторство.

1.1 Отладка процесса работы над задачами

Вот пример вопросов, которые мне приходилось решать, чтобы получить адекватный и детерминированный рабочий процесс по задачам: 

1. Какие типы задач есть в бэклоге, какой воркфлоу у этих задач? 

2. Как, когда и какие задачи поступают в разработку? 

3. Что делать, когда на регрессе начинают сыпаться баги и доработки? 

4. Что делать с незапланированными задачами?

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

1.2 Отладка процесса проведения код-ревью

Здесь я говорю именно про процесс код-ревью, само мое участие в код-ревью относится к другой категории.

Примеры вопросов:

1. Как и кому поступают задачи на ревью? 

2. Что нужно для прохождения код-ревью? 

3. Как проходит код-ревью?

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

1.3 Проведение командных встреч

Сюда относятся дейли, ретро, разборы багов и т.д. У меня есть своя командная встреча, что-то вроде митапа (я ее называю “сэшн”, от англ. session), куда каждый разработчик может принести свой список технических вопросов и проблем, чтобы обсудить всей командой и попробовать найти решение. Сэшн - это не ретро. На ретро мы обсуждаем процессы, а здесь - актуальные технические вопросы по проекту. В проведении командных встреч кроется огромный пласт работы для тимлида, потому что нужно не просто проводить встречи ради встреч, а работать с полученной информацией на этих встречах, чтобы решать поднятые проблемы и развиваться.

1.4 Проведение встреч один на один

Я считаю, что практика личных встреч с разработчиком просто необходима. Такие встречи помогают мне держать руку на пульсе и оперативно реагировать на сигналы, которые поступают от команды. 

Личные встречи - это отличное место для:

1. Обсуждений самых разных проблем, которые беспокоят разработчика. В личной беседе разработчик может рассказать очень многое. Самое главное, не забивать на проблемы разработчика, а пытаться их решать или менять точку зрения на проблему.

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

3. Обсуждения финансовых и карьерных вопросов.

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

1.5 Оценка и присвоение грейда разработчикам. Составление плана развития. Премирование на основе достижений поставленных целей.

Вообще, мне не очень нравится этот пункт, и он входит в круг моих обязанностей, только если этого требует руководство. Сейчас мне приходится составлять KPI для разработчиков, прости Господи, и я пытаюсь адекватно применять этот инструмент к разработчикам. Мне довелось поработать с китайскими коллегами, у которых в качестве показателей эффективности были вещи типа количества написанных строк кода за день. В результате задачи, которые можно было сделать за 10 строк, они делали за 100. Безумие, в общем. Я составляю список KPI и обязательно согласую его с разработчиками. Часть показателей согласуются с планом развития разработчика, а часть - это своего рода вызовы, которые принимает разработчик. В принципе, реальная польза от этого есть. Например, мы смогли повысить ответственность разработчиков за свою работу. Если раньше разработчик мог забить, мол, QA проверят, а я поправлю, что влекло за собой несколько итераций тестирования и потерю времени, то теперь фича может пройти тестирование с первого раза.

Что здесь требовалось от меня:

1. Составить шкалу грейдов (джун/мидл/сеньор/лид/принципл). Эта шкала требуется и для роста нынешних разработчиков, и для найма новых.

2. Формировать планы развития разработчиков. Это нужно делать индивидуально с каждым разработчиком. Уже на основе этого плана ставить ежемесячные цели.

3. Отслеживать прогресс, давать фидбек. Я это делаю в конфлюенс. Обычно на каждый целевой показатель влияет выполненная задача и написанный код, поэтому я указываю ссылки на соответствующие задачи в трекере и MR в репо и оставляю свои комментарии.

1.6 Составление психологического профиля разработчика

К этому я пришел недавно и тут пока мало, чем смогу поделиться. Суть в том, что через наблюдение за своими разработчиками можно увидеть их сильные и слабые стороны и использовать их для максимально эффективного решения поставленных задач. Например, у меня есть в команде архитектор, который может создавать крутые архитектуры, api и т.д., но которому тяжело мириться с легаси и посредственностью, и, будь его воля, он вместо бизнес фичей занимался бы рефакторингом. Есть разработчик, который может быстро крупными мазками сделать большую фичу, в которой будет некритичная масса мелких багов. Есть разработчик-перфекционист, который делает долго, но очень качественно. Понимая, кто работает с тобой в команде, можно распределять задачи таким образом, чтобы получать лучший результат по соотношению цена/качество. 

1.7 Просмотр резюме и отбор кандидатов на собеседование

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

1.8 Проведение собеседований

Основные задачи здесь:

1. Составление списка вопросов и задач для собеседования. Причем вопросов и задач много, и они разного формата, что позволяет проводить собеседование также в разном формате.

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

Я провел довольно много собеседований, и меня собеседовали немало. И мне не нравится, когда у собеседования нет четкой структуры, когда интервьюер смотрит на тебя и думает: “Чтобы такое у тебя спросить?..”. Поэтому я разработал для себя некую систему для проведения собеседований.

1.9 Менторство

Я бы разделил менторство на две категории: индивидуальное и командное. Обычно я сам выступаю ментором для новых сотрудников. Командное менторство не всегда нужно, необходимость в нем зависит от навыков и опыта команды. Главный инструмент здесь - это командное код-ревью. В течение 1-2 недель собираются ошибки, которые встречаются по ходу ревью, эти ошибки обезличиваются, а потом разбираются вместе с командой. Самое главное здесь - это обезличивание ошибок, чтобы никто не знал, чьи это ошибки, потому что в противном случае это будет не командный разбор, а бичевание провинившегося. 

2. Планирование

В этой категории такие задачи:

1. Согласование состава задач, которые будут взяты в разработку в ближайшее время.

2. Составление плана технического развития продукта.

3. Отладка и ведение процесса оценки и декомпозиции задач.

4. Планирование спринта, распределение задач и синхронизация с другими командами по текущим задачам.

5. Внесение изменений в уже начавшийся спринт (появление более срочных и важных задач, возникновение блокеров разработки).

6. Участие в обсуждениях будущих фичей.

2.1 Согласование состава задач, которые будут взяты в разработку в ближайшее время

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

2.2 Составление плана технического развития продукта

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

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

2.3 Отладка и ведение процесса оценки и декомпозиции

Здесь я пробовал разные подходы и комбинации. Процесс оценки задачи на разработку очень сильно зависит от команды. Где-то мне приходилось оценивать самостоятельно, а где-то я это полностью делегировал на разработчиков. Еще я пробовал разные подходы к оценке: коллективные, индивидуальные, оценки в часах, стори поинты и т.д. 

2.4 Планирование спринта, распределение задач и синхронизация с другими командами по текущим задачам

Я планирую спринты для своей команды. Здесь нужно учитывать текущую загруженность команды, приоритеты, порядок работы над задачами из нового спринта, а также пул задач, которые нужно будет взять в следующем спринте. И здесь как раз очень важно синхронизироваться с другими командами, чтобы понимать, когда они будут готовы отдать свою часть работы и т.д. Часто бывает необходимость выпустить довольно большой список фичей к определенной дате. Например, выпустить десять фичей через 3 месяца. Ресурсов обычно не хватает, поэтому приходится тесно работать с другими командами и разрабатывать фичи “по кусочкам”, собирая пазл к нужной дате. 

2.5 Внесение изменений в уже начавшийся спринт (появление более срочных и важных задач, возникновение блокеров разработки)

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

2.6 Участие в обсуждениях будущих фичей

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

3. Продукт

Здесь такие задачи:

1. Мониторинг “здоровья” продукта.

2. Разработка своих технических метрик и контроль работы внутренних систем на их основе.

3. Участие в устранении аварий

3.1 Мониторинг “здоровья” продукта

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

3.2 Разработка своих технических метрик

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

3.3 Участие в устранении аварий

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

4. Разработка

Здесь у меня такие задачи:

1. Ведение технического бэклога.

2. Принятие технических решений.

3. Ведение репозитория кодовой базы проекта.

4. Согласование технических требований к разрабатываемым фичам.

5. Написание кода.

6. Участие в код-ревью.

7. Написание технических гайдов.

4.1 Ведение технического бэклога

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

4.2 Принятие технических решений

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

4.3 Ведение репозитория кодовой базы проекта

Я поддерживаю репозиторий проекта в консистентном состоянии (дев, релизы, мастер, теги и т.д.). Здесь мне иногда приходится отлаживать процесс работы команды с репозиторием. 

4.4 Согласование технических требований к разрабатываемым фичам

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

4.5 Написание кода

В своей предыдущей статье я писал, что не беру на себя задачи, у которых есть жесткий дедлайн. На работе я пишу мало кода, но много читаю. В основном, я разрабатываю core функционал, от которого ничего не зависит и который можно ввести в эксплуатацию в любое время. Также я могу помогать с исправлением багов. А еще я иногда разрабатываю какие-то вспомогательные вещи, например, сейчас я разрабатываю плагин для IDE. У меня есть свои пэт проекты, которые удовлетворяют мою потребность в кодировании и помогают не отставать от технологий.

4.6 Участие в код-ревью

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

4.7 Написание технических гайдов

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

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

@ar2code - мой телеграмм канал, где я выкладываю свои материалы, опубликованные на разных площадках.