Моя предыдущая статья вызвала довольно бурное обсуждение на тему, кто такой тимлид и чем он занимается, поэтому в этой статье я хотел рассказать о том, чем занимаюсь я. Вообще задачи тимлида могут сильно отличаться в разных компаниях. В моем опыте обычно было так: чем меньше в команде представлено ролей, тем больше задач будет у тимлида. Я как-то работал с тимлидом, которому приходилось даже тестировать, потому что в команде не было тестировщика. Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам. У меня получилось четыре категории: Команда Планирование Продукт Разработка Сначала я начал описывать свои задачи очень подробно, с историями из своего опыта и т.д., но статья стала получаться просто огромной, поэтому я ограничился списком задач и небольшими комментариями. Возможно, наиболее интересные задачи я опишу в отдельных статьях. В этой категории такие задачи: Отладка процесса работы над задачами. Отладка процесса проведения код-ревью. Проведение командных встреч. Проведение встреч один на один. Оценка и присвоение грейда разработчикам. Составление плана развития. Премирование на основе достижений поставленных целей. Составление психологического профиля разработчиков. Просмотр резюме и отбор кандидатов на собеседование. Проведение собеседований. Менторство. Вот пример вопросов, которые мне приходилось решать, чтобы получить адекватный и детерминированный рабочий процесс по задачам:  Какие типы задач есть в бэклоге, какой воркфлоу у этих задач?  Как, когда и какие задачи поступают в разработку?  Что делать, когда на регрессе начинают сыпаться баги и доработки?  Что делать с незапланированными задачами? Безусловно я, как тимлид, не могу настроить весь флоу задачи, потому что разработка - это лишь часть этого флоу, но наладить процесс внутри команды в моих силах. Отлаженный процесс позволяет мне заниматься, в основном, планированием, и практически не заниматься микроменеджментом. Здесь я говорю именно про процесс код-ревью, само мое участие в код-ревью относится к другой категории. Примеры вопросов: Как и кому поступают задачи на ревью?  Что нужно для прохождения код-ревью?  Как проходит код-ревью? Код-ревью - это процесс взаимодействия внутри команды, который оказывает большое влияние на взаимоотношения разработчиков, поэтому к нему нужно относиться серьезно. В одной моей команде ревью кода зачастую проходило очень эмоционально, разработчики спорили, что называется, о вкусах, и отношения в команде развивались по деструктивному пути. Эту проблему практически полностью удалось решить построением процесса.  Сюда относятся дейли, ретро, разборы багов и т.д. У меня есть своя командная встреча, что-то вроде митапа (я ее называю “сэшн”, от англ. session), куда каждый разработчик может принести свой список технических вопросов и проблем, чтобы обсудить всей командой и попробовать найти решение. Сэшн - это не ретро. На ретро мы обсуждаем процессы, а здесь - актуальные технические вопросы по проекту. В проведении командных встреч кроется огромный пласт работы для тимлида, потому что нужно не просто проводить встречи ради встреч, а работать с полученной информацией на этих встречах, чтобы решать поднятые проблемы и развиваться. Я считаю, что практика личных встреч с разработчиком просто необходима. Такие встречи помогают мне держать руку на пульсе и оперативно реагировать на сигналы, которые поступают от команды.  Личные встречи - это отличное место для: Обсуждений самых разных проблем, которые беспокоят разработчика. В личной беседе разработчик может рассказать очень многое. Самое главное, не забивать на проблемы разработчика, а пытаться их решать или менять точку зрения на проблему. Предоставления обратной связи и обсуждения косяков разработчика. Хвалить подчиненных нужно в присутствии коллег, а критиковать только лично. Обсуждения финансовых и карьерных вопросов. Увольнение сотрудника может принести большие финансовые потери компании. Безусловно, люди уходят, но хорошо, когда это происходит, скажем так, по естественным причинам, а не по причине накопившихся проблем и недовольства. Личные встречи очень сильно помогают мне мониторить команду. Я их провожу с периодичностью раз в две недели. Вообще, мне не очень нравится этот пункт, и он входит в круг моих обязанностей, только если этого требует руководство. Сейчас мне приходится составлять KPI для разработчиков, прости Господи, и я пытаюсь адекватно применять этот инструмент к разработчикам. Мне довелось поработать с китайскими коллегами, у которых в качестве показателей эффективности были вещи типа количества написанных строк кода за день. В результате задачи, которые можно было сделать за 10 строк, они делали за 100. Безумие, в общем. Я составляю список KPI и обязательно согласую его с разработчиками. Часть показателей согласуются с планом развития разработчика, а часть - это своего рода вызовы, которые принимает разработчик. В принципе, реальная польза от этого есть. Например, мы смогли повысить ответственность разработчиков за свою работу. Если раньше разработчик мог забить, мол, QA проверят, а я поправлю, что влекло за собой несколько итераций тестирования и потерю времени, то теперь фича может пройти тестирование с первого раза. Что здесь требовалось от меня: Составить шкалу грейдов (джун/мидл/сеньор/лид/принципл). Эта шкала требуется и для роста нынешних разработчиков, и для найма новых. Формировать планы развития разработчиков. Это нужно делать индивидуально с каждым разработчиком. Уже на основе этого плана ставить ежемесячные цели. Отслеживать прогресс, давать фидбек. Я это делаю в конфлюенс. Обычно на каждый целевой показатель влияет выполненная задача и написанный код, поэтому я указываю ссылки на соответствующие задачи в трекере и MR в репо и оставляю свои комментарии. К этому я пришел недавно и тут пока мало, чем смогу поделиться. Суть в том, что через наблюдение за своими разработчиками можно увидеть их сильные и слабые стороны и использовать их для максимально эффективного решения поставленных задач. Например, у меня есть в команде архитектор, который может создавать крутые архитектуры, api и т.д., но которому тяжело мириться с легаси и посредственностью, и, будь его воля, он вместо бизнес фичей занимался бы рефакторингом. Есть разработчик, который может быстро крупными мазками сделать большую фичу, в которой будет некритичная масса мелких багов. Есть разработчик-перфекционист, который делает долго, но очень качественно. Понимая, кто работает с тобой в команде, можно распределять задачи таким образом, чтобы получать лучший результат по соотношению цена/качество.  Здесь мне нужно хорошо изучить резюме, чтобы составить мнение о кандидате, посмотреть код, если кандидат приложил ссылки на свои публичные репозитории, иногда приходится звонить кандидатам на 15 мин. и предварительно общаться.  Основные задачи здесь: Составление списка вопросов и задач для собеседования. Причем вопросов и задач много, и они разного формата, что позволяет проводить собеседование также в разном формате. Определение, как будет производиться маппинг результатов прохождения собеседования в решение о выставлении оффера на определенный грейд. Я составлял специальную табличку, куда я заносил баллы кандидата, которые пересчитывались в грейд по специальным формулам. Я провел довольно много собеседований, и меня собеседовали немало. И мне не нравится, когда у собеседования нет четкой структуры, когда интервьюер смотрит на тебя и думает: “Чтобы такое у тебя спросить?..”. Поэтому я разработал для себя некую систему для проведения собеседований. Я бы разделил менторство на две категории: индивидуальное и командное. Обычно я сам выступаю ментором для новых сотрудников. Командное менторство не всегда нужно, необходимость в нем зависит от навыков и опыта команды. Главный инструмент здесь - это командное код-ревью. В течение 1-2 недель собираются ошибки, которые встречаются по ходу ревью, эти ошибки обезличиваются, а потом разбираются вместе с командой. Самое главное здесь - это обезличивание ошибок, чтобы никто не знал, чьи это ошибки, потому что в противном случае это будет не командный разбор, а бичевание провинившегося.  В этой категории такие задачи: Согласование состава задач, которые будут взяты в разработку в ближайшее время. Составление плана технического развития продукта. Отладка и ведение процесса оценки и декомпозиции задач. Планирование спринта, распределение задач и синхронизация с другими командами по текущим задачам. Внесение изменений в уже начавшийся спринт (появление более срочных и важных задач, возникновение блокеров разработки). Участие в обсуждениях будущих фичей. Все начинается со встречи, на которой бизнес рассказывает техническим руководителям, какой функционал (на следующие 2-3 релиза) требуется реализовать и к какому сроку. Обычно таких встреч с бизнесом по каждой задаче бывает несколько. В итоге я или соглашаюсь с предложенным бизнесом планом, или предлагаю свое видение ситуации. В результате утверждается план, по которому команда будет работать. Здесь я составляю список крупных задач (эпики), которые целиком технические. Но иногда в этом плане появляются такие задачи, которые, на самом деле, должны больше волновать бизнес, но не волнуют. Составить такой план - это довольно трудоемкая работа. Для этого мне приходится в процессе работы собирать разного рода информацию, на основе которой и составляется этот план. О какой информации идет речь: проблемы проекта, о которых говорят разработчики на нашем сэшене, но которые оперативно решить нельзя, результаты анализа багов, которые появляются в результате разработки, отзывы пользователей, которые собирают лайки в сторе, но игнорируются бизнесом.  А потом еще этот план нужно согласовать и распланировать, чтобы вместе с бизнес-фичами выполнялись еще и технические задачи. Здесь я пробовал разные подходы и комбинации. Процесс оценки задачи на разработку очень сильно зависит от команды. Где-то мне приходилось оценивать самостоятельно, а где-то я это полностью делегировал на разработчиков. Еще я пробовал разные подходы к оценке: коллективные, индивидуальные, оценки в часах, стори поинты и т.д.  Я планирую спринты для своей команды. Здесь нужно учитывать текущую загруженность команды, приоритеты, порядок работы над задачами из нового спринта, а также пул задач, которые нужно будет взять в следующем спринте. И здесь как раз очень важно синхронизироваться с другими командами, чтобы понимать, когда они будут готовы отдать свою часть работы и т.д. Часто бывает необходимость выпустить довольно большой список фичей к определенной дате. Например, выпустить десять фичей через 3 месяца. Ресурсов обычно не хватает, поэтому приходится тесно работать с другими командами и разрабатывать фичи “по кусочкам”, собирая пазл к нужной дате.  Зачастую срочные задачи приходят с непонятным описанием, в срочности которых я сильно сомневаюсь. И перед тем как перепланировать спринт, я выясняю все нюансы и убеждаюсь в том, что задача действительно срочная, и ее нужно брать с первым приоритетом. Только потом я вношу изменения в спринт и передаю в разработку. Я регулярно принимаю участие в так называемых грумингах. Основная цель моего участия - это сформировать понимание о фиче, которую хочет бизнес, и объеме работ реализации, а также выступать техническим экспертом, чтобы на начальном этапе увидеть возможные ограничения в реализации. Таких обсуждений довольно много, поэтому я не приглашаю на них разработчиков, за исключением редких случаев, когда нужна их экспертиза. Здесь такие задачи: Мониторинг “здоровья” продукта. Разработка своих технических метрик и контроль работы внутренних систем на их основе. Участие в устранении аварий Я составляю свои дашборды, где собирается необходимая мне статистика возникновения крэшей, ошибок и других аномалий в продукте. Также я создаю специальные триггеры, которые оповещают меня, если поведение продукта начинает отличаться от нормального. Продуктовые метрики для анализа поведения и предпочтений пользователя составляет бизнес, а чтобы отслеживать и анализировать поведение внутренних систем в продакшене, мне приходится самостоятельно составлять свои технические события, на основе которых я разрабатываю нужные мне метрики. Это очень помогает отлаживать продукт, принимать некоторые технические решения, а также выявлять аномалии в поведении системы, но не приводящие к ошибкам.  Иногда случаются масштабные отказы некоторых систем. Т.к. я тимлид фронта, то на мою долю редко выпадают аварийные ситуации по вине моей платформы, но все же меня иногда просят помочь с отладкой аварий на бэке. Кстати, многие технические метрики я добавил как раз после таких аварий. Здесь у меня такие задачи: Ведение технического бэклога. Принятие технических решений. Ведение репозитория кодовой базы проекта. Согласование технических требований к разрабатываемым фичам. Написание кода. Участие в код-ревью. Написание технических гайдов. У меня есть свой бэклог, который состоит из задач двух типов: технический долг и техническое развитие. Я держу этот бэклог приоритезированным и актуальным. Я принимаю технические решения и несу за них ответственность. Далеко не все предложения исходят от меня. Многие классные идеи приходят от самих разработчиков, и я это поощряю, но последнее слово остается за мной, потому что, повторюсь, я несу ответственность. Я поддерживаю репозиторий проекта в консистентном состоянии (дев, релизы, мастер, теги и т.д.). Здесь мне иногда приходится отлаживать процесс работы команды с репозиторием.  Все фичи перед тем, как пойти в разработку, проходят мое согласование. Для этого мне приходится погружаться в технические требования. Нередко бывает так, что я прошу внести изменения в требования. Согласование может быть довольно длительным процессом. В своей предыдущей статье я писал, что не беру на себя задачи, у которых есть жесткий дедлайн. На работе я пишу мало кода, но много читаю. В основном, я разрабатываю core функционал, от которого ничего не зависит и который можно ввести в эксплуатацию в любое время. Также я могу помогать с исправлением багов. А еще я иногда разрабатываю какие-то вспомогательные вещи, например, сейчас я разрабатываю плагин для IDE. У меня есть свои пэт проекты, которые удовлетворяют мою потребность в кодировании и помогают не отставать от технологий. Я уделяю довольно много времени код-ревью. На ревью я делаю акцент на архитектуру решения, соблюдение некоторых общепринятых принципов и практик, и, самое главное, на читабельность и сопровождаемость написанного кода.  Пишу сам или вместе с разработчиками технические гайды по проекту. Например: архитектура проекта, описание компонентов и их взаимосвязи, шаблоны для разработки новых фичей, описание используемых на проекте практик, описание процессов работы с гитом, описание процесса код-ревью и т.д. На этом, думаю, что все. Пишите в комментариях, какие задачи есть у вас, будет интересно почитать и найти что-то новое для себя. Спасибо. @ar2code - мой телеграмм канал, где я выкладываю свои материалы, опубликованные на разных площадках. Android Teamlead