«Гигиенический минимум» в работе тимлида

Привет, я Илья — Frontend Team Lead в Альфа-Банк. Отвечаю не только за команду, но также веду и техчасть. Как тимлид я часто задаюсь вопросом «В чем моя роль?», «Как измерить эффективность моей работы?» и «Какой профит от лидов для проекта в целом?»

Для себя я вывел определение и задачи лида. Это всего лишь мои субъективные умозаключения, и искушенной публике Хабра могут быть хорошо знакомы, иногда слишком очевидны, но…повторение мать учения, как когда-то говорили. И даже если мы сто раз что-то слышали — не значит, что мы начали это делать. То, о чем я хочу рассказать — простые шаги, которые работают только при регулярном повторении, без пропуска какого-то пункта, это важно.

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

О чём будем говорить
— Архитектура
— Команда: подбор и правила
— Код
— Task трекеры

Главная задача тимлида – обеспечение

Итак, цель лида на проекте (как я ответил себе на вопрос «Кто я?» и «Зачем тут нужен?») сводится к созданию 2 вещей:

• Прозрачных и понятных процессов для проекта.

• Максимально комфортных условий для всех сотрудников. Важно! Условия должны быть такими для всех членов команды.

Звучит просто, но на практике — всё сильно сложнее. Так как, чтобы эти 2 пункта претворить в жизнь, нужно сделать 100500 маленьких шагов по их реализации. Я выделил 4 основных блока.  Рассмотрим каждый.

Лирическое отступление, важное для дальнейшего повествования.

---

• Вы управляете процессами ровно настолько, насколько они формализованы. И работать с процессами нужно системно. По отдельности ничего работать не будет. Это означает, что если у вас есть классный налаженный процесс code-review, но на команду времени не уделяется от слова «совсем», успехом это не кончится.

• Отношение к людям — основа построения всех процессов. Как ни крути, в процессе разработки участвуют люди и всё строится на базе отношений.

• Тимлид должен быть готов инвестировать собственные ресурсы. При введении новых процессов или изменении текущих, у лидера всегда должна быть готовность инвестировать собственные ресурсы в нововведения или изменения. Другими словами, сначала протопчи дорогу сам, а лишь потом веди за собой команду. И важный момент — лидер обязательно должен следовать правилам игры.

---

Архитектура

Первое, про что мы поговорим — это архитектура. 

Без архитектуры серьёзный проект разработать:

• не получится;

• это будет сильно дорого.

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

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

 При отсутствии архитектуры возникает много трудностей. Как пример, 2 яркие проблемы:

• Дорого и медленно. Чем больше строчек кода будет написано, тем дороже будет дальнейшая разработка, ведь чтобы добавить или поправить маленький кусок функционала, придётся поправить целый ряд зависимых модулей, а то и вовсе переписать. Здесь на первый план выходит зависимость стоимости к количеству строк кода. Увеличение количества разработчиков не решит проблему.

• Снижение мотивации. Разработка идет — результатов нет, точнее либо куча костылей, либо работа в стол. Желание делать что-то стоящее для проекта у инженера падает.

Решение — должна быть проработанная архитектура. 

---

Из опыта. Не один раз приходил на проект, где архитектура была НИКАКАЯ, а то и вовсе отсутствовала. Основная проблема была в том, что из-за отсутствия архитектуры возникала полная неразбериха на проекте: нет единого понимания как устроена система, бизнес-логика размазана по всему проекту — где-то часть в UI, где-то в утилитах, где-то в сторе. 

---

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

• большая связность кода;

• ощущение, что проект целиком состоит из легаси;

• куча скрытых багов.

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

 Хоть миграция ещё не закончена до конца, но проект начинает жить совсем иначе:

• чёткая структура приложения (некий скелет);

• минимум легаси;

• отдельно вынесена бизнес логика и покрыта тестами, можно спокойно рефакторить;

• связность модулей почти отсутствует, либо минимальна;

• правильно выстроены зависимости.

Вместо итога — если ещё не проработали архитектуру — сейчас самое время. Экономьте время, деньги и нервы.

Команда

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

Найм

Цель: сотрудник и проект/компания подходят друг другу.

Проект. Для кандидата должны быть подобраны подходящие задачи, лежащие в сфере его интересов. Важно учитывать стек/вектор развития/воркфлоу/мотивацию.

Сотрудник. Должен подходить по:

• Уровню компетенций. Если у вас довольно сложный проект и вам нужен разработчик уровня сеньора, а вы берёте джуна, то, думаю, что в большинстве случаев исход здесь понятен.

• Типу личности. Если проект активно растет, в команде идёт постоянное общение внутри и с соседними командами, а кандидат интроверт, (для усугубления эффекта скажем, что офигенный инженер), то придется выбирать: либо пойти по простому пути и отказаться от крутых скиллов в угоду скорости развития проекта, либо майнить много внимания и сил – экранировать сотрудника, забирая все его общение с другими людьми на себя. Риск есть. Выбор за вами.

• Мотивации. Важно понимать, в чём она состоит и насколько соотносится с потребностями проекта. Тут могут помочь коллеги из HR, советую с ними плотно обсудить эту тему после интервью.

• «Классу» кандидата*. Здесь опять же зависимость с потребностями проекта и этапом его развития. Как пример — есть тип людей, которых можно назвать «экспериментаторами»: это 50 новых идей в день, желание начать всё реализовывать, генерация нестандартных решений для задач. Такой человек идеально подошёл бы на этапе запуска, но он не подходит поддержания проекта.

Очевидные вещи, но иногда о них забывают.

Что будет если так не делать? Если не соблюдать эти условия, то возможен плохой исход ситуации: 

• «Полетит» код плохого качества.

• Задачи не будут решаться в указанные сроки.

• Может появится токсичность, что будет аффектить всю команду.

• Трата времени — команде и кандидату придется снова открывать поиск.

Как итог: результат ≠ ожиданию. 

Решение довольно простое:

• Расскажите о проекте максимально прозрачно и честно. Если есть какие-то проблемы, например, процессы не проработаны или нет CI/CD, то об этом стоит сказать, чтобы для кандидата это не было сюрпризом в первые рабочие дни.

• Опишите предстоящие задачи в ближайшее время. Например, у вас сейчас период стабилизации и вы делаете в основном баги/доработки, а кандидат хочет активных задач. 

• Постарайтесь оценить не только харды. Что соискателю интересно, чем он хочет заниматься и какой у него вектор развития? Некоторые вопросы можно задать прямо, например, «в какую сторону хочешь развиваться?». Вопрос мотивации можно понять из рассказа о прошлых проектах.

В моём опыте было много найма, и я совершал ошибки, которые умею признавать. Для меня проще расстаться с человеком во время ИС, чем потом разгребать массу проблем. 

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

Работа с командой

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

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

Гармония. Проще объяснить от обратного — не должно быть конфликтов, обид между ребятами в команде. Если что-то появляется, то это нужно оперативно решать.

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

Чтобы этого достичь я лично применяю:

• правильное распределение задач;

• встречи 1х1.

Правильное распределение задач. Помните про оценку интересов на интервью? Так вот для чего она была нужна. Смотрим на то, что подходит человеку и нужно бизнесу — матчим. И так каждый спринт. Задачи должны быть на рост и расширять экспертизу сотрудника, а также помогать нам в достижении бизнес целей. Плюс не забываем про шеринг знаний между сотрудниками — задачу должны уметь делать как минимум 2 сотрудников. Если ситуация позволяет, то даём задачу не тому сотруднику, кто её делал много раз и сделает быстро, а тот, кому это больше нужно для развития в настоящий момент. 

Встречи 1х1

Это встречи менеджера и его сотрудника, на которых обычно обсуждаются личные вопросы. На 1х1 встречах всегда прямо даем ОС с подтверждением фактами. Если у сотрудника есть вопросы, обсуждаем, честно и открыто. Сюда же входит постановка личных целей. Иногда можем просто немного пообщаться на отвлечённые темы, ибо мне действительно интересно как дела у человека за пределами работы.

Плюсы для сотрудника

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

• Оперативная обратная связь ( в обе стороны ).

Плюсы для лида.

• Помогает глубже понять мотивацию.

• Возможность быстрее выявить скрытые проблемы и вовремя на них среагировать.

• Постановка личных целей для развития.

• Показать членам команды, что они важны.

• Обратная связь.

Публично ругать людей нельзя! 

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

Похвала за результаты. Если что-то было сделано на «Ура» — обязательно говорите об этом. Порой небольшие слова вроде «Вася, ты красавчик», очень приятно слышать, и это ещё больше заряжает энергией. Хвалить так же можно публично.

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

Не работаете с командой — можно дальше ничего не делать, всё развалится. Люди делают бизнес, точка.

Код

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

• юнит-тесты: покрыть тестами, как минимум, бизнес-логику;

• статический анализ кода: eslint, prettier, TS;

• code-review.

Уверен, что про юнит тесты и статические анализаторы вы знаете не хуже меня, поэтому давайте детальнее рассмотрим процесс code-review.

Чек лист code-review

У меня на проекте есть набор правил проведения code-review:

• Формализация всех правил. Вы управляете данным процессом ровно настолько, насколько он формализован.

• Приоритет. У команды должно быть понимание, что code-review — это самая приоритетная задача из всех возможных. Выше неё только ASAP (срочная и важная задача), которых обычно нет.

• Политика обработки исключений — чтобы ни для кого не было сюрпризом ваше действие (как лида) в исключительной ситуации. Например, при определённых обстоятельствах вы имеете право оставить за собой решающее мнение либо закрыть Pull Request при нарушении конкретных правил.

• Моё субъективное дополнение — на code-review все равны. Не должно быть кого-то главного, который говорит как и что делать. Всё должно обсуждаться, быть объективно и конструктивно. Остальные правила должны быть зафиксированы в исключениях.

Правила code-review

Касательно правил — опять же, делюсь опытом. Что-то из этого может быть субъективным и характерным для моего проекта, но может пригодится и вам.

Связность модулей. Если изменения в двух больших разных модулях не связаны, тогда не собирать в один Pull Request, а сделать несколько небольших Pull Request’ов.

Ограничения по количеству строк (смотреть ченжи в 1000+ строк вряд ли кто захочет). У меня эта цифра равна 500 строчкам кода. Но если кейс исключительный, например, что-то нельзя сделать по технической причине, тогда идёт на жёсткое разделение по коммитам.

Правила добавления изменений в коммит — не собирать под один коммит ченжи, не связанные напрямую. Например, фикс в какой-нибудь утилите и добавление npm-пакета. 

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

На что смотреть и обращать внимание во время процесса code-review. Не придираться к точкам, запятым и пробелам — за нас это всё делают линтеры. 

Почти на всех проектах, где я работал лидом, изначально никогда не было процесса code-review.

В этом случае решение одно — резко добавлять данный процесс и никак иначе. 

На текущем проекте в Альфа-Банке все вышеупомянутые правила выполняются.

• Вся команда участвует в code-review, комментарии всегда конструктивные.

• Если что-то субъективно и не критично, то сразу говорится о том, что это вкусовщина, и это никак не влияет на оценку кода, это идёт как небольшой момент на подумать.

• Если проходит code-review новичка или джуна, то комментарии даются более подробные, чтобы быстрее погрузиться в проект.

• Pull Request’ы не зависают неделями, потому что есть приоритет, что code-review — самая приоритетная задача.

• В случае необходимости пингануть кого-то на code-review, есть интеграция Git со Slack — сообщения с Pull Request’ами. Просто в треде пингуется необходимый человек.

• Для ситуаций, если Pull Request’ов скопилось довольно много, то есть фиксированное время именно на процесс code-review — во вторник и четверг выделяется целый час.

Важный момент — я точно так же соблюдаю данные правила. Если я пишу код, то так же, как и все, выношу Pull Request на code-review, а не пушу втихаря сразу в master). 

Итого, правильно выстроив процесс code-review, мы получим:

• Контроль качества кода.

• Сплочённость команды. Если процесс code-review выстроен правильно, то никто друг-другу специально не ставит палки в колёса, а всё проходит конструктивно, и у команды есть понимание для чего весь этот процесс, то команда станет ближе. Процесс code-review — командообразующий элемент из-за совместной активности.

• Улучшение показателя bus-factor. Если у вас есть модуль с легаси кодом и только один человек в команде знает, как он работает, то у вас большие проблемы. Сегодня человек в команде есть, а завтра его нет. Во время процесса code-review будет понимание как работает тот или иной модуль у разных сотрудников команды.

Тask трекеры

Теперь давайте поговорим про постановку задач в тask трекерах. От того, насколько правильно прописаны требования к работе и критерии приёмки, зависит как качество, так и результат выполнения работы.

Когда я пришёл на один из проектов, то там была такая ситуация.

Как вам? 

Название «Анализ», и никакой информации о задаче нет. Попробуйте понять, что было сделано в рамках тикета — анализ или панелька? Чаще всего это тикеты, которые обсудили устно и создали просто для галочки. Как работать с таким тикетом — не понятно. 

В описании задач должны соблюдаться как минимум 2 из 3 следующих пунктов:

• Требования. Чёткое и понятное описание что делать.

• Критерии приёмки. Порой это важно, если нужно добиться определённых показателей. Например, достичь такого-то показателя перфоманса. Всё должно описываться в цифрах. Попробуй перевести в DONE задачу «Панелька».

• Опционально — описание бизнес-логики. Описание задачи на простом языке, не связанным с разработкой, часто называют user story — что делает данная фича и для чего она нужна. Можно оставить в описании тикета, можно ссылку на Confluence. Это важно для понимания, для чего именно делается функционал, как итог разработка решения пойдет с привязкой к бизнесовому контексту и у сотрудника будет уверенность, что он не просто так красит кнопочки.

Если игнорировать, то возникнут проблемы:

Уточнения.

• В сторону постановщика задачи могут прилетать бесконечные уточнения по поводу требований, критериев приёмки и описание БЛ, что несомненно будет только отвлекать постановщика/заказчика задачи.

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

Некорректные эстимэйты или вовсе их отсутствие. Возвращаясь к задаче «Анализ» — попробуйте дать чёткие эстимэйты.

Результат ≠ ожидание. В случае отсутствия чётких требований, не все могут пойти уточнять их, а сделать на своё усмотрение как посчитают правильно, да и по качеству так, как смоглось).

---

Из опыта. У нас «пустое описание» на проекте ушло сразу. Вместо него появилось минимальное, но этого всё равно было недостаточно для понимания что нужно сделать в рамках тикета. Поэтому было принято решение — заниматься грумингом (причёсыванием задач в бэклоге заранее). Я регулярно проверяю новые задачи в бэклоге, распределяю по стримам,  изучаю, составляю вопросы. Чаще всего это небольшие созвоны с вовлечёнными командами, где мы быстро обговариваем все моменты, условия и правим описания.

Итог всего процесса — задача должна быть готова для взятия в работу. Готовая для взятия в работу означает, что задача соответствует чек-листу и нет первичных вопросов по задаче.

---

И небольшое дополнение — обсудите с командой и зафиксируйте шаблон для заполнения задачи, некий скелет-заготовка. Если для тикета-задачи порой можно сделать небольшое отступление от правил, то для багфикс тикетов отступление неприемлимо. 

Багфикс тикет должен содержать, как минимум, следующую информацию:

• Мета информация: стенд для воспроизведения, пользователь и т.д.

• Шаги для воспроизведения.

• Ожидаемый результат.

• Фактический результат.

• Дополнительная информация для воспроизведения (скриншоты с выделением области, видео или HAR файлы с запросами). 

Итого, имея правильное наполнение задач получим: 

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

• Планирование спринта проходит по плану — нет отвлечения на посторонние процессы.

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

• Спасибо от команды ? Порой для команды нет ничего более приятного, чем взять в работу задачу с максимально понятными требованиями, чтобы можно было приступить сразу к разработке, а не заниматься выяснением требований (не все любят этим заниматься, особенно на постоянной основе).

• Минус стендапы для отчетов внутри команды (субъективно). Если правильно настроен процесс ведения задач в task трекере, есть наполненный бэклог, выстроена система приоритетов по задачам, есть налаженный процесс code-review, то отпадает необходимость в дейликах, на которых многие просто отчитываются что из функционала они сейчас делают и что будут делать дальше. Из Jira можно посмотреть кто что делает и что будет делать дальше, а конкретный прогресс по задаче можно посмотреть на code-review или при необходимости созвониться лично. Вместо стендапов по «отчитыванию», можно проводить встречи для обсуждения вопросов по внутренней кухне: у кого есть сложности в решении задач, посоветоваться, обсудить какой-то кейс, рассказать что-то новое либо обсудить апдейт либы. Так работает у меня и моей команды. 

В конце

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

И как и обещал — пара полезных ссылок:

• Хорошая статья про команду от Вастрика: про этапы и классы.

• Роадмап тимлида: расписаны почти все кейсы о которых говорил, с разборами причин и последствий. 

• Блог Саши Беспоясова

• Youtube-канал Егора Бугаенко

• Дока

• Youtube-канал «Веб-стандарты»

---

Статья подготовлена на основе выступления на Meet Up JS. Запись выступления доступна в группе Alfa Digital в ВК, там также есть записи докладов с других конференций и митапов. ​​Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, иногда шутим.

— Улучшаем качество кода React-приложения с помощью Compound Components
— Как мы создали Digital Workplace для сотрудников