Быть тим-лидом

Эту статью я решил написать как дополнение к статьям “Кто такой Team Lead и нужно ли им становиться” и “Как тимлиду развивать себя и команду: принципы SOLID“. Для первой она является логическим продолжением рассказывая подробнее о том, что делает тим-лид, а для второй дополнением.

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

[sendpulse-form id=”278″]

Роли в проекте

В любом проекте можно встретить такие роли:

• Разработчик пишет код, причём такой, что его, если что, могут править и читать коллеги. В маленькой команде на 5-6 человек нет  индивидуального кода, есть только общая задача. Кто-то ушёл в отпуск или заболел — мы можем дописать хотфикс или внедрить новую фичу, не дожидаясь его.
• Тимлид собирает людей, ставит им задачи, делает оценки, превращает требования архитектора или аналитика в техзадание разработчикам, ведёт трекер и вообще занимается всем тем, что относится к процессу промышленного получения кода из мозга. Но при этом тимлид не разговаривает с людьми особо за пределами команды.
• Проект-менеджер занимается взаимодействием между теми, кому что-то надо от разработчиков и разработчиками. Если у него выделенная роль, то трекер уже на нём, приоритеты задач, способы решения, — всё это обсуждается с ним. Проект-менеджер получает и ищет нужные ресурсы, занимается документами и решает организационные задачи, выделяет работы, разбивает задачи. За просроченный проект отвечает ПМ, за качество реализации — тимлид (на самом деле тоже ПМ, но мы любим все проблемы с кодом валить на лидов, они же им занимаются и проверяют что пишут их разработчики).
• Архитектор или аналитик пронзают мыслью пласты времени и читают мысли заказчика по поводу того, что же надо. У нас выделенного архитектора нет, точнее, архитектор выступает одним из бизнес-заказчиков. Про эту работу лучше расскажет мой коллега архитектор, который занимается крупными вещами, у меня ничего длиннее 5 лет не было.
• Продуктолог продумывает разработку услуги от и до, а программист обеспечивает воплощение идей продуктолога и вдобавок делает всё, чтобы клиент смог удобно, безопасно, со всеми необходимыми SLA, без риска поломки или «падения» от нагрузки заказать услугу.

Ключевое отличие ПМ от тимлида не только в круге общения, но и в том, что ПМ может не разбираться в том, как конкретно делать работу, достаточно понимания общего принципа. Он говорит, что делать, тимлид —  предлагает как делать.

Как пример приведу опыт своего товарища работающего ПМ в геймдеве: надо поставить задачу композитору для музыки уровня. Нужно сказать, какую музыку ты хочешь. «Более роскошно, у тебя слишком быстрый ритм» — вроде, он понимает, но ты чувствуешь, что что-то не то. Повезёт, если найдёте общий язык. Аналогично приходится договариваться с дизайнером, и разработчиком интерфейсов.  Это утомительно, но дает хороший опыт, чтобы находить общий язык с другим мозгом. Потом, уже будучи на любом проекте проекте будет проще находить понимание с заказчиком.

Как устроена у нас работа

Заказчик говорит аналитику, что он хочет. Аналитик идёт к ПМ и они обсуждают требования и начинается подбор команды. После этого ПМ, тим-лид и аналитик садятся и обсуждают бэклог, который к моменту подбора команды уже составлен ПМ и аналитиком и согласован с заказчиком. Тим-лид должен с командой дать оценки, после чего обсуждает их с ПМ. Затем ПМ и аналитик расставляют приоритеты — что делаем вначале, что в конце. Профит от аналитика в том, что в его голове хранится актуальный бэкап логики будущего проекта целиком, и он понимает какие задачи и как в эту логику укладываются, а не так, что «сделали, как просили, посмотрели — чота ой, переделали потом 8 раз, пока не перестало ойкать».

Затем тим-лид разбирает бэклог и набивает тасктрекер. Около 50% времени тим-лида уходит на работу с командой и задачами: обсуждение задач, схемки на бумажках, управление тасктрекером, ревью кода. Ревью делает в основном тим-лид, эпизодически скидывая на других разработчиков Senior или Middle уровня. Около 40% времени тим-лид пишет код сам (его ревьюят внутри команды). Ещё около 10% времени у него уходит на «условный девопс», потому что мы сами поддерживаем свою тестовую среду.

Разработка архитектуры приложения — на команде разработки — одна из наших задач. Это в такое обсуждение — «как нам сделать вот такой набор фич, чтобы потом на поддержке не погибнуть». Вычислительно или алгоритмически-сложных задач у нас как-то немного. Зато много задач как раз насчет архитектуры, гибкости настроек и интеграции. То есть хардкор как бы в другом — в архитектуре приложения.

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

У нас в команде есть отдельные разработчики бекенда и фронта. В принципе наши бекенд-разработчики могут что-то поправить и дописать во фронте, но это сильно тормозит работу — выгрузить из головы php, загрузить js — вообще-то утомительно. Фронтендщик может из кода бекенда прочитать параметры вызовов API, и мы этим нагло пользовались, чтобы не документировать код. Потом завели автоматическую генерацию доков по API и перестали его мучить.

Собеседования

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

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

Второй – HR отбирает кандидатов и направляет их на собеседование к тим-лиду.

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

На первых собеседованиях тим-лиду сложно и непонятно, как за 1 час оценить, как человек будет работать. Через 5-6 встреч экспериментов уже появился общий шаблон, и все становится хорошо.

На собеседованиях надо интересоваться, в каком проекте человек работал, как там был выстроен процесс. Это нужно для того, чтобы понимать, освоил ли кандидат хорошие инженерные практики или плохих нахватался. Например, точно ли кандидат работал в команде или просто сидел рядом с ребятами и одиноко пилил свой пухлый модуль, и некому было сказать ему «твой код — барахло!». Заставляли ли его старшие товарищи писать тесты до или после функционала или и так сойдет? То есть, было ли в жизни разработчика достаточно очистительного страдания, полезного для души, или так как-то проскочил.

Мы все на собеседовании любим говорить, что в предыдущем проекте было широко поставлено code-review. В проектах с горящими сроками разработчики должны выделять на это время, а это не всегда выходит. Бывают такие проекты, где до ревью дело не доходит никогда по «объективным причинам». Ох, как вспомню наши первые работы, когда технический долг приходит, когда у тебя 15 минут до планируемого релиза… Повторения не хочется совсем.

Ещё спрашивайте, какая была самая сложная задача, как решал, с чем приходилось сталкиваться. Во-первых, интересно, какие задачи бывают кроме тех, что приходится решать самим. И потом интересно посмотреть — человеку самому-то это все интересно или как-то уже не очень. Мое правило такое – если человек в состоянии мне хотя бы 5 минут рассказывать с горящими глазами как он делал пусть даже самую пустяковую задачу – значит он: во-первых – знает чем занимался, во-вторых – понимает что делал, в-третьих – задачи для него не “сделать надо чтобы получить зарплату”. Если же человек судя по резюме работал с нагруженными проектами, но из него ничего не вытащить раскаленными добела клещами – тут что-то не так.

Дальше надо посмотреть на собственно код. Если есть проекты на GitHub —  клёво, можно, во-первых, водить пальцем по коду, задавать вопросы вида «почему так, а не сяк», «как это можно улучшить» и «какая тут алгоритмическая сложность». Во-вторых, если кто-то запилил сам своей проект — ну, значит, может все-таки сам себя замотивировать, а это хороший, полезный скилл. Но, естественно, не у всех он был. Тогда в дело вступала тестовая задачка — очень маленькая, строк на 20.

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

Еще проще оценивать опыт, если он схож с вашим собственным: разработку бекенда веб-приложения или веб-сервиса в портфолио считаю за «плюс» — ясно, что на человека валились шизовые задачи вида «уменьшить время работы запроса» или там «закэшировать только зеленую часть страницы» — следовательно, как минимум, у человека крепкая психика.

Процесс найма не быстрый. За это время кандидат может получить ещё офферов и тупо не ждать.

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

Иногда оказывалось, что человек любит приходить на собеседования, а потом пропадать. На такого естественно мне не хочется тратить свое время.

Попадались и такие кто имел работу, а на собеседование приходил просто чтобы проверить себя. С такими я иногда связывался и предлагал написать на Linkedin рекомендацию. Двое из таких ребят потом перекочевали все-таки к нам.

Ещё моменты

Есть интересные стереотипы. Например, «у программистов логический склад ума». Скорее всего, так и есть, но никому от этого не легче — даже внутри команды проекта у каждого кодера в голове разная картина проекта, и у каждого — очень логичная, но при этом все их картинки взаимно-противоречивы. Задаешь простой вопрос «а можно сделать иконку фиолетовой?» — у человека мука на лице. По-моему, со стороны должно выглядеть непоследовательно и странно.

Еще «чтобы круто кодить, необходимо техническое образование» или «хорошо знать математику». Пока нас всех не заменили нейронные сети, разработчиков требуется много, и не все из них должны быть хардкорными. Техническое образование и математика, конечно, прокачивают мозговую мышцу и системное мышление, но, мне кажется, не менее эффективно качать ее специфическими для разработки разделами математики (логика, множества, графы, алгоритмы) и кодить всё, что под руку попадет.

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