-
21 мая, 2018

Эту статью я решил написать как дополнение к статьям «Кто такой 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 рекомендацию. Двое из таких ребят потом перекочевали все-таки к нам.

Ещё моменты

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

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

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

ТЕГИ
RELATED POSTS

ОСТАВИТЬ КОММЕНТАРИЙ

Николай Сарры
Харьков, Украина

Меня зовут Николай, и вот уже 5 лет я руководитель IT-проектов.Добро пожаловать в мой лофт с заметками, статьями, идеями и мыслями по управлению проектами, использованию гибких методологий разработки.Здесь собраны мои мысли, решения, заметки и статьи. В основном по управлению проектами, PHP-разработке и используемым инструментам, обзоры прочитанных статей, тезисы посещенных конференций.