Всем привет, меня зовут Семён и я руковожу разработкой витрины объектов недвижимости в ДомКлик. В прошлой части этой серии статей мы поговорили про самую трудоёмкую область работы тимлида — работу с людьми. Сегодня я расскажу про не менее важную тему для любого тимлида — технологии. Насколько «крут» должен быть тимлид технически? Должен ли он писать код? Отвечает ли тимлид за техническое состояние своего «хозяйства»? Кого заинтересовал, прошу под кат.
Об уровне владения технологиями
Должен ли тимлид быть самым-крутым-нинзя-рокстар разработчиком? Вопрос дискуссионный. Зависит от компании: где-то тимлид сам проектирует архитектуру, принимает все ключевые решения по реализации функциональности, проводит code review, отвечает за релизы; а где-то эта роль подразумевает управление людьми, и в команде есть техлид, закрывающий основные технические вопросы.
Для себя я отвечаю на этот вопрос следующим образом: «тимлид должен иметь опыт разработки, но не обязан быть самым лучшим разработчиком в команде». Более того, тимлид обязан сплотить вокруг себя разработчиков гораздо круче, чем он сам.
Окей, мы разобрались с тем, что у тимлида должен быть опыт разработки. Каким уровнем знаний он или она должны обладать? На мой взгляд, уровень владения техническими вопросами должен быть достаточным, чтобы:
- свободно проектировать реализацию функциональности;
- при этом определять узкие места и риски;
- оценивать размер команды, трудозатраты на проект;
- знать сценарии решения типовых проблем;
- декомпозировать сложную проблему на простые задачи;
- отвечать на запросы бизнеса;
- выступать арбитром при разрешении технических споров в команде;
- реагировать и координировать сотрудников при критических инцидентах в production.
Должен ли тимлид постоянно писать код?
На мой взгляд — ни в коем случае. Иначе — это не тимлид, а высокооплачиваемый разработчик. Но если тимлид не пишет код, то зачем все эти знания? Как говорит Егор Толстой: «тимлид — это снежинка», и наша диаграмма из предыдущей статьи тому подтверждение:
Я отнёс к блоку технологий в обязанностях тимлида четыре области:
- инженерная культура;
- Agile-процессы;
- SLA;
- постоянное улучшение качества.
Что я понимаю под инженерной культурой?
На мой взгляд, инженерная культура — это комплексное понятие, которое состоит из двух частей: осязаемой (инженерной) и неосязаемой (культурной).
К первой категории я отношу конкретные техники, методики и инструменты, использование которых тимлид регулирует, продвигает и контролирует:
- архитектурные стандарты;
- типовые решения;
- правила оформления кода (stylе guides);
- стандарты code-review;
- автомацизация рутинных операций;
- практики сообщества;
- работа с техдолгом;
- документация.
Ко второй части относятся неосязаемые понятия, которые также зависят от тимлида:
- внутренний стандарт качества команды;
- ответственность за принятие решений;
- научный подход;
- нетерпимость к плохим решениям;
- открытость к экспериментам;
- ориентация на результат.
Agile-процессы
Почему я пишу Agile? Почему не рассматриваю другие подходы к разработке? Потому что, на мой взгляд, ничего лучше, чем Extreme Programming и принципы Agile Manifesto ещё не придумали. Как еще нам действовать в условиях неопределённости, в которых работает большинство из нас?
Почему налаживание процессов — проблема тимлида? Я уверен, что невозможно выпускать стабильный продукт вовремя без налаженных процессов в разработке. Как мы передаём задачи от продукта в разработку? Как проверяем гипотезы? Как уменьшаем риски вкладывания наших усилий «не туда»? Как релизим? Как даём быструю обратную связь заказчику? Если на эти вопросы не будет чётких ответов, на каждом этапе разработки будут потери времени и усилий на их прояснение. Поэтому, процессы должны сидеть в подкорке мозга каждого члена команды, включая бизнес, дизайн, разработку. И работа тимлида как раз состоит в том, чтобы эти процессы наладить и закрепить. Для этого хорошо подойдёт cookbook — свод правил, который стоит обсудить со всеми членами команды и выложить на Confluence/вики/базу знаний команды, показывать новым членам команды при введении в работу, и постоянно совершенствовать его.
SLA
Ещё одна особенность позиции тимлида — ответственность за доступность и бесперебойную работу сервисов, которыми владеет команда. Руководство не очень любит разбираться, где конкретно проблема. Даже если, к примеру, проблема у подрядчика в дата-центре, но проявляется она у тебя на продукте, поднимут первым тебя. Нужно быть готовым, что тебе позвонят ночью с тем, что не работает поиск, или включат в чат на выходных, где генеральный директор пытается понять, почему у него не грузятся фото в приложении. Это случится обязательно, рано или поздно. И тимлид должен быть готов к этому.
Для того, чтобы быть готовым к инцидентам и уменьшить уровень стресса, когда они происходят, нужно, как минимум, иметь:
- мониторинг сервисов;
- архитектурную схему;
- настроенный доступ к критическим системам;
- налаженные отношения со смежниками.
Мониторинг сервисов
Хорошо настроенный мониторинг сервисов и оповещения по заранее согласованным пороговым значениям — это ключ к здоровому сну, потому что он позволяет диагностировать проблему на ранней стадии и проинформировать всех стейкхолдеров о её наличии. Также, важно организовать дежурство по сервисам в вашей ответственности в нерабочее время и выходные. В нашей компании дежурные по сервисам получают дополнительную оплату и дни отгула. В идеальном сценарии, дежурный получит оповещение первым, сможет проанализировать и устранить проблему, передать её ответственным лицам или инициирует создание чата по устранению проблемы со всеми заинтересованными. В таком случае тимлиду даже не придётся реагировать.
Архитектурная схема
Когда я говорю «архитектурная схема», я не имею в виду чертёж размером со стену, распечатанный на листах А1 (доводилось видеть и такое). Я, скорее, подразумеваю, что тимлид должен знать все компоненты (микросервисы) в своём владении, бизнес-логику, по которой эти компоненты обмениваются данными, типовые сценарии использования сервиса. Также тимлиду нужно знать путь запроса до приложения со всеми балансировщиками, API-гейтвеями, waf-ами, IPS-ками, ингрессами и прочими проксями — это позволит быстро диагностировать проблему и найти ответственных.
Настроенный доступ
Даже при хорошо налаженной схеме дежурства может случиться так, что дежурный недоступен (сел телефон, отключили интернет, крепко спит и т.д.). И в таком случае всё равно реагировать придётся тимлиду. Поэтому важно иметь настроенный доступ во все критические системы, которые могут пригодиться при диагностировании и решении проблемы. Для меня это реплики баз данных, поды Kubernetes/kubectl, ELK, CI/CD, UI RabbitMQ, и конечно VPN, чтобы добраться до всего этого.
Отношения со смежниками
Не секрет, что в современном мире команда разработки не делает продукт в вакууме: всегда, как минимум, есть команда DevOps/эксплуатации, подрядчики с дата-центрами, служба безопасности со своими прокси, DBA с базами, провайдеры связи, DNS, CDN и бесконечное число внешних интеграций. При сбое любого из этих узлов может возникнуть ощущение, что ваш продукт не работает. В этом случае координировать усилия по устранению проблемы придётся тимлиду. Очень важно при этом быть «на короткой ноге» со смежными командами/подрядчиками: как минимум, нужно иметь все контакты (почтового адреса недостаточно, нужен номер телефона или аккаунт мессенджера). Но лучше, когда у вас со смежниками есть общий чат, в котором в любое время можно организовать взаимодействие. Помогает также заранее провести учения по имитации недоступности систем (мы писали об этом тут), итогом которых станет протокол реагирования на инциденты.
Постоянное улучшение качества
Не секрет, что в погоне за time-to-market мы часто принимаем «быстрые решения» и встраиваем «костыли» в наш код (конечно же, с намерением вернуться и всё отрефакторить, когда будет время!).
Как только такое «быстрое решение» поселилось в вашей кодовой базе, оно становится проблемой тимлида, потому что влияет на поддерживаемость и расширяемость сервиса. Задача тимлида — сделать так, чтобы все подобные задачи «на рефакторинг» регулярно попадали в бэклог команды. Иными словами, тимлид должен организовать в команде работу с техническим долгом. В нашей компании принято выделять 20 % спринта на работу с техдолгом, причём эта квота не включает в себя баги и написание тестов — такие задачи мы относим к продуктовым.
Кроме работы с техдолгом, тимлид должен выступать амбассадором качества продуктов своей команды: следить за трендом багов, участвовать в приёмке продукта, мотивировать людей увеличивать тестовое покрытие и писать качественный код.
Заключение
В этой статье мы рассмотрели, каким должен быть технический уровень тимлида (должен быть опыт разработки). Также, я рассказал, как тимлид может организовать работу с инженерной культурой, процессами, SLA и качеством. В следующей части мы рассмотрим, пожалуй, самую противоречивую часть работы тимлида — работу с бизнесом, так что, как всегда, stay tuned!
