Моя предыдущая статья вызвала довольно бурное обсуждение на тему, кто такой тимлид и чем он занимается, поэтому в этой статье я хотел рассказать о том, чем занимаюсь я.
Вообще задачи тимлида могут сильно отличаться в разных компаниях. В моем опыте обычно было так: чем меньше в команде представлено ролей, тем больше задач будет у тимлида. Я как-то работал с тимлидом, которому приходилось даже тестировать, потому что в команде не было тестировщика.
Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.
У меня получилось четыре категории:
Команда
Планирование
Продукт
Разработка
Сначала я начал описывать свои задачи очень подробно, с историями из своего опыта и т.д., но статья стала получаться просто огромной, поэтому я ограничился списком задач и небольшими комментариями. Возможно, наиболее интересные задачи я опишу в отдельных статьях.
1. Команда
В этой категории такие задачи:
Отладка процесса работы над задачами.
Отладка процесса проведения код-ревью.
Проведение командных встреч.
Проведение встреч один на один.
Оценка и присвоение грейда разработчикам. Составление плана развития. Премирование на основе достижений поставленных целей.
Составление психологического профиля разработчиков.
Просмотр резюме и отбор кандидатов на собеседование.
Проведение собеседований.
Менторство.
1.1 Отладка процесса работы над задачами
Вот пример вопросов, которые мне приходилось решать, чтобы получить адекватный и детерминированный рабочий процесс по задачам:
Какие типы задач есть в бэклоге, какой воркфлоу у этих задач?
Как, когда и какие задачи поступают в разработку?
Что делать, когда на регрессе начинают сыпаться баги и доработки?
Что делать с незапланированными задачами?
Безусловно я, как тимлид, не могу настроить весь флоу задачи, потому что разработка - это лишь часть этого флоу, но наладить процесс внутри команды в моих силах. Отлаженный процесс позволяет мне заниматься, в основном, планированием, и практически не заниматься микроменеджментом.
1.2 Отладка процесса проведения код-ревью
Здесь я говорю именно про процесс код-ревью, само мое участие в код-ревью относится к другой категории.
Примеры вопросов:
Как и кому поступают задачи на ревью?
Что нужно для прохождения код-ревью?
Как проходит код-ревью?
Код-ревью - это процесс взаимодействия внутри команды, который оказывает большое влияние на взаимоотношения разработчиков, поэтому к нему нужно относиться серьезно. В одной моей команде ревью кода зачастую проходило очень эмоционально, разработчики спорили, что называется, о вкусах, и отношения в команде развивались по деструктивному пути. Эту проблему практически полностью удалось решить построением процесса.
1.3 Проведение командных встреч
Сюда относятся дейли, ретро, разборы багов и т.д. У меня есть своя командная встреча, что-то вроде митапа (я ее называю “сэшн”, от англ. session), куда каждый разработчик может принести свой список технических вопросов и проблем, чтобы обсудить всей командой и попробовать найти решение. Сэшн - это не ретро. На ретро мы обсуждаем процессы, а здесь - актуальные технические вопросы по проекту. В проведении командных встреч кроется огромный пласт работы для тимлида, потому что нужно не просто проводить встречи ради встреч, а работать с полученной информацией на этих встречах, чтобы решать поднятые проблемы и развиваться.
1.4 Проведение встреч один на один
Я считаю, что практика личных встреч с разработчиком просто необходима. Такие встречи помогают мне держать руку на пульсе и оперативно реагировать на сигналы, которые поступают от команды.
Личные встречи - это отличное место для:
Обсуждений самых разных проблем, которые беспокоят разработчика. В личной беседе разработчик может рассказать очень многое. Самое главное, не забивать на проблемы разработчика, а пытаться их решать или менять точку зрения на проблему.
Предоставления обратной связи и обсуждения косяков разработчика. Хвалить подчиненных нужно в присутствии коллег, а критиковать только лично.
Обсуждения финансовых и карьерных вопросов.
Увольнение сотрудника может принести большие финансовые потери компании. Безусловно, люди уходят, но хорошо, когда это происходит, скажем так, по естественным причинам, а не по причине накопившихся проблем и недовольства. Личные встречи очень сильно помогают мне мониторить команду. Я их провожу с периодичностью раз в две недели.
1.5 Оценка и присвоение грейда разработчикам. Составление плана развития. Премирование на основе достижений поставленных целей.
Вообще, мне не очень нравится этот пункт, и он входит в круг моих обязанностей, только если этого требует руководство. Сейчас мне приходится составлять KPI для разработчиков, прости Господи, и я пытаюсь адекватно применять этот инструмент к разработчикам. Мне довелось поработать с китайскими коллегами, у которых в качестве показателей эффективности были вещи типа количества написанных строк кода за день. В результате задачи, которые можно было сделать за 10 строк, они делали за 100. Безумие, в общем. Я составляю список KPI и обязательно согласую его с разработчиками. Часть показателей согласуются с планом развития разработчика, а часть - это своего рода вызовы, которые принимает разработчик. В принципе, реальная польза от этого есть. Например, мы смогли повысить ответственность разработчиков за свою работу. Если раньше разработчик мог забить, мол, QA проверят, а я поправлю, что влекло за собой несколько итераций тестирования и потерю времени, то теперь фича может пройти тестирование с первого раза.
Что здесь требовалось от меня:
Составить шкалу грейдов (джун/мидл/сеньор/лид/принципл). Эта шкала требуется и для роста нынешних разработчиков, и для найма новых.
Формировать планы развития разработчиков. Это нужно делать индивидуально с каждым разработчиком. Уже на основе этого плана ставить ежемесячные цели.
Отслеживать прогресс, давать фидбек. Я это делаю в конфлюенс. Обычно на каждый целевой показатель влияет выполненная задача и написанный код, поэтому я указываю ссылки на соответствующие задачи в трекере и MR в репо и оставляю свои комментарии.
1.6 Составление психологического профиля разработчика
К этому я пришел недавно и тут пока мало, чем смогу поделиться. Суть в том, что через наблюдение за своими разработчиками можно увидеть их сильные и слабые стороны и использовать их для максимально эффективного решения поставленных задач. Например, у меня есть в команде архитектор, который может создавать крутые архитектуры, api и т.д., но которому тяжело мириться с легаси и посредственностью, и, будь его воля, он вместо бизнес фичей занимался бы рефакторингом. Есть разработчик, который может быстро крупными мазками сделать большую фичу, в которой будет некритичная масса мелких багов. Есть разработчик-перфекционист, который делает долго, но очень качественно. Понимая, кто работает с тобой в команде, можно распределять задачи таким образом, чтобы получать лучший результат по соотношению цена/качество.
1.7 Просмотр резюме и отбор кандидатов на собеседование
Здесь мне нужно хорошо изучить резюме, чтобы составить мнение о кандидате, посмотреть код, если кандидат приложил ссылки на свои публичные репозитории, иногда приходится звонить кандидатам на 15 мин. и предварительно общаться.
1.8 Проведение собеседований
Основные задачи здесь:
Составление списка вопросов и задач для собеседования. Причем вопросов и задач много, и они разного формата, что позволяет проводить собеседование также в разном формате.
Определение, как будет производиться маппинг результатов прохождения собеседования в решение о выставлении оффера на определенный грейд. Я составлял специальную табличку, куда я заносил баллы кандидата, которые пересчитывались в грейд по специальным формулам.
Я провел довольно много собеседований, и меня собеседовали немало. И мне не нравится, когда у собеседования нет четкой структуры, когда интервьюер смотрит на тебя и думает: “Чтобы такое у тебя спросить?..”. Поэтому я разработал для себя некую систему для проведения собеседований.
1.9 Менторство
Я бы разделил менторство на две категории: индивидуальное и командное. Обычно я сам выступаю ментором для новых сотрудников. Командное менторство не всегда нужно, необходимость в нем зависит от навыков и опыта команды. Главный инструмент здесь - это командное код-ревью. В течение 1-2 недель собираются ошибки, которые встречаются по ходу ревью, эти ошибки обезличиваются, а потом разбираются вместе с командой. Самое главное здесь - это обезличивание ошибок, чтобы никто не знал, чьи это ошибки, потому что в противном случае это будет не командный разбор, а бичевание провинившегося.
2. Планирование
В этой категории такие задачи:
Согласование состава задач, которые будут взяты в разработку в ближайшее время.
Составление плана технического развития продукта.
Отладка и ведение процесса оценки и декомпозиции задач.
Планирование спринта, распределение задач и синхронизация с другими командами по текущим задачам.
Внесение изменений в уже начавшийся спринт (появление более срочных и важных задач, возникновение блокеров разработки).
Участие в обсуждениях будущих фичей.
2.1 Согласование состава задач, которые будут взяты в разработку в ближайшее время
Все начинается со встречи, на которой бизнес рассказывает техническим руководителям, какой функционал (на следующие 2-3 релиза) требуется реализовать и к какому сроку. Обычно таких встреч с бизнесом по каждой задаче бывает несколько. В итоге я или соглашаюсь с предложенным бизнесом планом, или предлагаю свое видение ситуации. В результате утверждается план, по которому команда будет работать.
2.2 Составление плана технического развития продукта
Здесь я составляю список крупных задач (эпики), которые целиком технические. Но иногда в этом плане появляются такие задачи, которые, на самом деле, должны больше волновать бизнес, но не волнуют. Составить такой план - это довольно трудоемкая работа. Для этого мне приходится в процессе работы собирать разного рода информацию, на основе которой и составляется этот план. О какой информации идет речь: проблемы проекта, о которых говорят разработчики на нашем сэшене, но которые оперативно решить нельзя, результаты анализа багов, которые появляются в результате разработки, отзывы пользователей, которые собирают лайки в сторе, но игнорируются бизнесом.
А потом еще этот план нужно согласовать и распланировать, чтобы вместе с бизнес-фичами выполнялись еще и технические задачи.
2.3 Отладка и ведение процесса оценки и декомпозиции
Здесь я пробовал разные подходы и комбинации. Процесс оценки задачи на разработку очень сильно зависит от команды. Где-то мне приходилось оценивать самостоятельно, а где-то я это полностью делегировал на разработчиков. Еще я пробовал разные подходы к оценке: коллективные, индивидуальные, оценки в часах, стори поинты и т.д.
2.4 Планирование спринта, распределение задач и синхронизация с другими командами по текущим задачам
Я планирую спринты для своей команды. Здесь нужно учитывать текущую загруженность команды, приоритеты, порядок работы над задачами из нового спринта, а также пул задач, которые нужно будет взять в следующем спринте. И здесь как раз очень важно синхронизироваться с другими командами, чтобы понимать, когда они будут готовы отдать свою часть работы и т.д. Часто бывает необходимость выпустить довольно большой список фичей к определенной дате. Например, выпустить десять фичей через 3 месяца. Ресурсов обычно не хватает, поэтому приходится тесно работать с другими командами и разрабатывать фичи “по кусочкам”, собирая пазл к нужной дате.
2.5 Внесение изменений в уже начавшийся спринт (появление более срочных и важных задач, возникновение блокеров разработки)
Зачастую срочные задачи приходят с непонятным описанием, в срочности которых я сильно сомневаюсь. И перед тем как перепланировать спринт, я выясняю все нюансы и убеждаюсь в том, что задача действительно срочная, и ее нужно брать с первым приоритетом. Только потом я вношу изменения в спринт и передаю в разработку.
2.6 Участие в обсуждениях будущих фичей
Я регулярно принимаю участие в так называемых грумингах. Основная цель моего участия - это сформировать понимание о фиче, которую хочет бизнес, и объеме работ реализации, а также выступать техническим экспертом, чтобы на начальном этапе увидеть возможные ограничения в реализации. Таких обсуждений довольно много, поэтому я не приглашаю на них разработчиков, за исключением редких случаев, когда нужна их экспертиза.
3. Продукт
Здесь такие задачи:
Мониторинг “здоровья” продукта.
Разработка своих технических метрик и контроль работы внутренних систем на их основе.
Участие в устранении аварий
3.1 Мониторинг “здоровья” продукта
Я составляю свои дашборды, где собирается необходимая мне статистика возникновения крэшей, ошибок и других аномалий в продукте. Также я создаю специальные триггеры, которые оповещают меня, если поведение продукта начинает отличаться от нормального.
3.2 Разработка своих технических метрик
Продуктовые метрики для анализа поведения и предпочтений пользователя составляет бизнес, а чтобы отслеживать и анализировать поведение внутренних систем в продакшене, мне приходится самостоятельно составлять свои технические события, на основе которых я разрабатываю нужные мне метрики. Это очень помогает отлаживать продукт, принимать некоторые технические решения, а также выявлять аномалии в поведении системы, но не приводящие к ошибкам.
3.3 Участие в устранении аварий
Иногда случаются масштабные отказы некоторых систем. Т.к. я тимлид фронта, то на мою долю редко выпадают аварийные ситуации по вине моей платформы, но все же меня иногда просят помочь с отладкой аварий на бэке. Кстати, многие технические метрики я добавил как раз после таких аварий.
4. Разработка
Здесь у меня такие задачи:
Ведение технического бэклога.
Принятие технических решений.
Ведение репозитория кодовой базы проекта.
Согласование технических требований к разрабатываемым фичам.
Написание кода.
Участие в код-ревью.
Написание технических гайдов.
4.1 Ведение технического бэклога
У меня есть свой бэклог, который состоит из задач двух типов: технический долг и техническое развитие. Я держу этот бэклог приоритезированным и актуальным.
4.2 Принятие технических решений
Я принимаю технические решения и несу за них ответственность. Далеко не все предложения исходят от меня. Многие классные идеи приходят от самих разработчиков, и я это поощряю, но последнее слово остается за мной, потому что, повторюсь, я несу ответственность.
4.3 Ведение репозитория кодовой базы проекта
Я поддерживаю репозиторий проекта в консистентном состоянии (дев, релизы, мастер, теги и т.д.). Здесь мне иногда приходится отлаживать процесс работы команды с репозиторием.
4.4 Согласование технических требований к разрабатываемым фичам
Все фичи перед тем, как пойти в разработку, проходят мое согласование. Для этого мне приходится погружаться в технические требования. Нередко бывает так, что я прошу внести изменения в требования. Согласование может быть довольно длительным процессом.
4.5 Написание кода
В своей предыдущей статье я писал, что не беру на себя задачи, у которых есть жесткий дедлайн. На работе я пишу мало кода, но много читаю. В основном, я разрабатываю core функционал, от которого ничего не зависит и который можно ввести в эксплуатацию в любое время. Также я могу помогать с исправлением багов. А еще я иногда разрабатываю какие-то вспомогательные вещи, например, сейчас я разрабатываю плагин для IDE. У меня есть свои пэт проекты, которые удовлетворяют мою потребность в кодировании и помогают не отставать от технологий.
4.6 Участие в код-ревью
Я уделяю довольно много времени код-ревью. На ревью я делаю акцент на архитектуру решения, соблюдение некоторых общепринятых принципов и практик, и, самое главное, на читабельность и сопровождаемость написанного кода.
4.7 Написание технических гайдов
Пишу сам или вместе с разработчиками технические гайды по проекту. Например: архитектура проекта, описание компонентов и их взаимосвязи, шаблоны для разработки новых фичей, описание используемых на проекте практик, описание процессов работы с гитом, описание процесса код-ревью и т.д.
На этом, думаю, что все. Пишите в комментариях, какие задачи есть у вас, будет интересно почитать и найти что-то новое для себя. Спасибо.
@ar2code - мой телеграмм канал, где я выкладываю свои материалы, опубликованные на разных площадках.
