Всем привет! Меня зовут Александр Афенов. Я тимлид команды разработки Order Processing в компании Lamoda. В прошлом году я выступал на TeamLead Conf 2018. Запись выступления доступна по ссылке.
В своем докладе я расскажу историю того, как стал тимлидом, с какими проблемами столкнулся, и поделюсь разными стратегиями, которые, возможно, покажутся вам хорошо знакомыми по отдельности. Однако акцент я делаю на том, какой профит они дают в комплексе.
Доклад будет разбит на 3 части:
- В первой части речь пойдет немного о компании и особенностях нашего IT. Это нужно для того, чтобы был понятен контекст, в котором все происходит.
- Во второй расскажу о моём пути в компании.
- В третьей — про используемые методики, их плюсы и минусы.
Lamoda как IT-компания
Lamoda в первую очередь известна как крупный ритейлер модной одежды, обуви и аксессуаров в России и СНГ. При этом мало кто знает, что за процент или фиксированную сумму мы оказываем услуги разным бизнесам / юридическим лицам.
Приведу наглядный пример. Допустим, у вас есть подвальчик по пошиву кошельков. Вы создали сайт своей продукции и успешно раскрутили его. О вас теперь многие знают, но несмотря на это у вас есть проблемы с доставкой, хранением и коммуникациями с клиентами.
Lamoda может решить подобные проблемы следующими способами:
- Предоставить услуги своей службы доставки.
LM Express — это наша собственная служба доставки, которую мы давно развиваем и самостоятельно автоматизируем.
- Обеспечить коммуникацию с клиентом. Для этого у нас есть свой колл-центр.
- Хранить товар у себя или даже продавать его за вас (комиссия).
- Marketplace. Товары партнёров могут отображаться в нашем мобильном приложении, на сайте или его мобильной версии, а всё остальное партнёры делают сами.
Возникает вопрос: “Как успеть решить и свои задачи, и удовлетворить потребности партнёров?” У нас есть меняющийся и развивающийся бизнес со своими потребностями. Мы каким-то образом все улучшаем, развиваем и двигаем вперед. При этом еще нужно соответствовать тем хотелкам, которые приходят извне. Кажется, что для этого нужно своё IT, и не маленькое.
Именно об in-house разработке мы и говорим на всех конференциях с 2016 года. Все процессы мы автоматизируем сами. Это около сотни различных сервисов: от обработки заказов и платежей до работы с адресными объектами и гифт-сертификатами. Поддержкой всего этого занимается команда из приблизительно 300 человек.
Почему я рассказываю о нашем IT и его масштабах? Потому что 300 человек – это множество команд. Когда какие-то команды работают на едином технологическом стеке, мы стараемся переиспользовать все эти наработки. Это могут быть бандлы, библиотеки, практики в технической области. Но ещё мы стараемся шарить удачные процессные практики между тимлидами, и об этом я и расскажу дальше.
Ключевые вопросы
Я пришел в компанию в 2015 году. Через три дня после моего трудоустройства намечался новогодний корпоратив, на который я решил не ехать. У меня в приоритете было остаться и подумать о своих задачах на испытательный срок.
Корпоратив в Lamoda — это тематический праздник, к которому все любят готовиться. Поэтому в день X архитектор моего отдела пришел на работу при параде, во фраке. На тот момент наша команда занималась сервисом обработки заказов. Это был монолит на старом фрэймворке Zend1. Что я наблюдал? Ребята подготовили вынужденный релиз и что-то захотфиксили. Удостоверившись, что всё ок, собрались и поехали на праздник.
И вот я сижу. Релиз уехал в продакшн с хотфиксом, а передо мной красивый телевизор на 50 дюймов, на котором какой-то дашборд. На дашборде был график с надписью «Rabbit MQ problems». Кажется, что если на нем есть какие-то данные, значит, что-то сломалось. Но я не знаю, куда мне посмотреть чтобы проверить эту гипотезу.
Наверное, можно глянуть в какие-то логи. Однако я только третий день на работе и не знаю, где они. Наверное, я могу найти ссылку на grafana-борду. Быть может стоит посмотреть через нее источник метрик и покопаться там? Да, но это слишком тернистый путь. Я бы хотел, чтобы это было как-то задокументировано. И опять же есть вопрос: кто все эти люди, которые сидят вокруг? Два или три этажа, по которым распределено IT. Все что-то делают, и я не знаю, с кем мне коммуницировать, если что-то пошло не так. Нет сводной таблицы, понятной, к кому я мог бы обратиться, если понял, что релиз сломался. А может есть дежурный, а я просто не в курсе?
*(конечно же он был)*
Были и другие вопросы. Первый и самый смешной, к которому мы будем неоднократно возвращаться: “Где документация?”. Ответ прост: одновременно везде, нигде и в головах опытных сотрудников. Так как все уехали на корпоратив, а о том, где лежат доки я не знаю, то для меня ответ звучал как “нигде”. У меня был readme по которому я раскатывал проект у себя на ноутбуке. Но этого было недостаточно. Хотелось получить ответы и на многие другие вопросы. Например, какие основные правила “поведения” для разработчика?
Поясню: я решил запросить доступ к боевой системе, чтобы зайти в пользовательский интерфейс. Для меня это было бы очень полезно, так как моя задача на испытательный срок была про переработку системы авторизации, и хотелось потыкать кнопочки, авторизоваться на production стенде. Я кинул заявку в службу безопасности, на которую быстро получил лаконичный ответ: “Не-а, доступ не дадим”. Оказалось, что доступ в боевую систему получают только ее реальные пользователи: работники склада, колл-центра и так далее. Так как я до этого работал в телекоме, то привык, что у меня был доступ на чтение и запись в production базы разных сотовых операторов. А тут, оказывается, так нельзя. Есть протокол.
Кроме этого, я столкнулся и со многими другими условиями и ограничениями, о которых мне рассказал тимлид. В первые дни он посвящал меня во множество разных увлекательных моментов. Этой информации было настолько много, что не всё удавалось запомнить и записать.
Следующие интересующие меня вопросы касаются дальней перспективы. Например, как и куда расти?
Почему это важно? Потому что уже со старта мне нужно как-то себя вести. Я пришел на должность middle php developer. Что мне делать дальше, чтобы превосходить ожидания, и в дальнейшем получить более высокий грейд, например Senior? И еще один вопрос: “Чего от меня ждут на моем текущем грейде?” То есть насколько я должен быть вовлечен в такие процессы, как code review, релизы, дежурства?
На все перечисленные сейчас мною вопросы тогда отвечал наш тимлид. На последние два, более стратегические, ответ давался через систему performance review. Расскажу подробнее о ней.
Performance review
Каждые 6 месяцев человек проводит так называемое self review. Он рассказывает о крутых штуках, которые успел сделать за отведенное время. Однако тут есть подводный камень. Связан он с тем, что люди обычно указывают те достижения на self-review, которые они субъективно склонны таковыми считать. Думать в терминах бизнеса непривычно, и даже если рутинный проект позволил заработать компании кучу денег, то для разработчика он мог не представлять вызова или интереса. Есть опасность, что в таком review этот проект не будет указан.
Следующий этап — это оценка от коллег (peer review). Затем следует серия комиссий, на которых идет общение между тимлидами, руковолителями отделов, СТО, и, если нужно, HR-директором. Потом сообщение о результатах.
Какие возможны исходы?
Первый вариант: человек умудрился сделать за полгода хуже, чем было до начала работы. Кажется, пора прощаться. Так бывает крайне редко, но будем реалистами – так бывает.
Другой вариант – это двойка. Кажется, чего-то не хватило. Может быть скорости, предсказуемости, упорства. Что-то необходимо улучшить.
Тройка – чего ожидали, то и получили. Человек работает в адекватном темпе и во всех отношениях соответствует своему грейду.
Четверка – сделал больше, чем договаривались. Кандидат на повышение должности/оклада.
Пятерка – шерстяной волчара. Кажется, что пора повышать, давать премии и так далее.
Я прошел сам через несколько итераций такого review. Раньше оно проводилось каждый квартал, что было не очень удобно, так как за 3 месяца не всегда случается возможность проявить себя. Сейчас review происходит раз в полгода.
Таким образом, сначала я из middle developer вырос в senior. Потом мой тимлид решил, что теперь больше хочет работать с техникой и перешел на позицию техлида (архитектора), а я стал тимлидом.
И что дальше? Мне нужно что-то делать, как-то осваиваться.
Первое, с чем ты сталкиваешься – это с теми же самыми вопросами, о которых мы говорили раньше, только теперь уже немножко на другом уровне. То есть по-прежнему непонятно: где та самая документация? Теперь мне нужно как-то общаться с другими отделами, коммуницировать с другими лидами, архитекторами и кем-то еще, мыслить на более высоком уровне. Но на этом самом уровне документации, вероятно, тоже нет.
Еще один момент – это те же “основные правила”. Что я могу?
Наверное, я могу следить за выполнением задач, делать code review. Возможно, у меня теперь есть власть менять процессы, как-то по-своему коммуницировать с людьми.
Как и куда расти? Этот вопрос никуда не девается, потому что потом вы можете захотеть стать руководителем отдела (group lead).
Ну и вопрос – чего от меня ждут, тоже мне кажется вполне понятным.
А ещё нужно теперь уметь отвечать на все эти вопросы не только себе, но и всей команде. В моём случае команда была набрана почти с нуля. Получается, что для пятерых или для семерых человек я должен все проговорить, пояснить, поставить цели. Это занимает время и силы. Такие вещи нужно планировать и продумывать. Так что же входит в обязанности тимлида?
Что должен тимлид?
В первую очередь — это работа с задачами: их постановка, корректировка, описание под грейд того человека, которому задача достается. Например, для джуниора я предпочту делать очень подробное описание и буду ожидать, что он напишет корректный код и тесты. А senior я сообщу техническую или бизнес-цель, и он будет волен решать сам, как её достичь. В любом случае, все это занимает время.
Разумеется нужно тушить code review, когда в ходе него возникают конфликты. Мониторить, что происходит, двигать задачи по статусам. Также я на регулярной основе выполняю обязанности релиз-инженера. Необходимо часто думать о том, каким образом наш деплой аффектит всех остальных.Сервис, которым я занимаюсь – это order processing. Он связан примерно со всеми системами Lamoda и, соответственно, способен затронуть при своем релизе множество бизнес-процессов.
Еще один момент – это связанные с этим мониторинги, алерты и дежурства. Если появилась какая-то бизнес-фича, за ней надо следить, вводить новые метрики, вешать на это оповещалки, сообщать в службу поддержки и так далее. Это все вопросы архитектуры. У меня в отделе сейчас нет выделенного архитектора. Я выполняю его обязанности в тех кейсах, когда нужно какое-нибудь специфическое решение в рамках конкретной задачи/проекта.
Ещё нужно уделять внимание коммуникациям. Сюда относятся personal meetings, которые проходят примерно раз в две недели с каждым разработчиком; ретроспективы, планирование, коммуникации с менеджерами и другими отделами. А ведь ещё неплохо бы не протухнуть.
Многие говорят, что было бы здорово после 10 лет разработки получить соотношение “менеджмент к разработке” в районе 80 к 20. Даже это не всегда достижимо. В итоге, вы неизбежно теряете экспертизу и выпадаете из текущих трендов. Необходимо продолжать расти дальше.
Есть возможные стратегии, как вы можете вырасти, с точки зрения своей позиции. В следующем разделе поговорим о том, каким образом ротация ролей в команде помогает повышать bus-factor.
Ротация ролей
Введу в курс дела тех, кто не знает, и расскажу, что такое bus factor.
Bus factor — это число, которое говорит о том, что если определенное количество разработчиков “собьет автобус”, то работа над проектом встанет. Он может проявляться на самых разных уровнях. Например, это может быть bus factor по какому-то конкретному сложному элементу системы.
Допустим, у нас есть кейс, в котором нужно разгрести некую систему отчетов. Разработчик потратил 5 дней на то, чтобы это сделать. Баг был сложный, но его исправили, и все стало хорошо. Потом возникает еще какая-то проблема в этом же модуле, а тот самый разработчик оказывается на больничном. Это значит, что следующий человек должен потратить столько же времени на то, чтобы разобраться в проблеме. Разбираться придется с нуля, потому что документации (ха-ха) нет.
То, о чем речь пойдет дальше – это как раз стратегии повышения bus factor. И они сойдутся в одну, достаточно приятную картинку со всеми предыдущими обязанностями тимлида, о которых я говорил.
Кроме документации, необходим реальный опыт. То есть вам нужна команда, которая уже успела потрогать разные части системы, и теперь готова справляться с любыми задачами. Но если команда только собралась, то все это не возьмется ниоткуда на пустом месте. Моя основная цель – рассказать, как можно совмещать несколько разных подходов, которые позволят закрыть проблемы и с документацией, и с опытом.
Саппорт-инженер
Все слышали про виртуальных разработчиков. Но речь пойдет не о VR-комплектах и не о людях на удаленке, а о роли саппорт-инженера.
Кто такой саппорт инженер?
У нас это парень, который разбирает саппортный бэклог. Он пришел на работу, у него нет ни единой задачи. Он открыл бэклог по поддержке в таск-треккере (Jira), а там задачки отсортированные по критичности. Взял самое важное и начинает чинить. После того, как все проблемы решены, записывает, почему оно сломалось и как избежать этого в будущем. Если у него нет другого саппорта (это забавно, потому что саппорт не кончается никогда), то он смотрит в технический бэклог, который и так достаточно большой.
Небольшое отвлечение: речь идет о системе на полторы сотни тысяч строк на старом фреймворке Zend 1. Предыдущий архитектор команды в свое время сказал, что по нашей системе у нас долг такого размера — это технический долг, а скорее техническая ипотека. Отсюда название доклада.
Если делать нечего, саппорт-инженер может взять оттуда какую-то не приоритетную задачу, которую не жалко бросить и вернуться к вновь появившемуся саппорту. Так обычно и происходит. И он не занимается этим дольше недели, потому что это был бы прямой путь к фрустрации. Если вы на протяжении целой двухнедельной итерации занимаетесь только разгребанием саппорта, вас это будет сильно демотивировать. Вы чините, чините, чините, и этому нет конца. По этой причине мы каждую неделю передаем роль саппорт-инженера следующему человеку.
Релиз-инженер
Есть еще одна виртуальная должность, которая очень удобна для разгрузки тимлида – это релиз-инженер. Он готовит релизы по заранее запланированным fix-версиям, собирает ветки, готовит билды, прогоняет все тесты. Если тесты запускаются автоматически, то просто контролирует результат. В его же зоне ответственности выбрать, как все это красиво покатить без даунтайма и спецэффектов для зависящих от нас систем.
Бывает так, что нам нужна коммуникация с другими командами перед деплоем, чтобы предупредить их об изменениях. По итогу, релиз-инженер все выкатывает и смотрит, не разнесло ли чего. Мы используем для этого, Sentry, Prometheus, Icinga, смотрим в Elastic, при помощи Kibana. Релиз-инженер принимает решение, что делать, если что-то пошло не так. То есть именно в его ответственность входит решить, нужен ли какой-то hotfix, или мы все сломали, теряем деньги и нужно делать откат. Решение об откате принимаем только в крайнем случае, но и такое бывает.
Он же (релиз-инженер) записывает возникающие проблемы. Если что-то разорвало, было бы здорово учиться на своих ошибках. Для этого он указывает дату релиза и ошибки, которые привели к проблеме. Это дает возможность следующему релиз-инженеру посмотреть на типовые проблемы и избежать их. Ну и да, он не занимается этим дольше недели подряд, потому что собирать релиз – это дорого.
Если релиз большой, то полдня вылетает легко и очень трудно в перерывах успевать переключаться на свои задачи. Например, вы запустили какую-нибудь сборку, которая идет 20 минут. Пока идет сборка, можно покурить или подумать о жизни. Но если вы вернулись к задаче, а сборка закончилась успешно, нужно снова переключаться. В общем, это довольно муторный процесс, выдергивающий из нормальной разработки и не дающий войти в поток. По этой причине следующую неделю релиз-инженер — это другой человек.
Техлид
Другая более интересная виртуальная позиция – это технический лидер.
Архитектор (иногда называем и так) вступает в бой, когда находится большая важная задача или запускается новый проект. Это значит, что он берет на себя ответственность за проектирование, разработку и запуск. Ему дается право коммуницировать с тимлидом и менеджером команды, принимать технические решения и передается обязанность документировать их. Если на запуске происходит какая-то дрянь, то он записывает все произошедшие неполадки и их причины по такой же схеме, как это делает релиз-инженер или саппорт-инженер.
Выводы
Что мы получаем в итоге?
Ротация ролей в команде на протяжении долгого времени (не менее полугода) дает возможность даже неопытному джуниору получить навык работы с самыми разными частями системы и видами задач.
В начале я говорил о том, что с решением типовых задач могут помочь документация и реальный опыт. После применения описанных практик не факт, что вы решите проблему документации, но качественный и разнообразный опыт будет получен всеми участниками команды разработки.При продолжительной ротации виртуальных ролей человек успевает на роли саппорт-инженера потрогать самые разные части системы. Как релиз-инженер, он учится деплоить, коммуницировать, наблюдать, быстро принимать решения. Если ему досталась роль техлида, то он подготавливается к тому, чтобы самостоятельно драйвить более крупные и важные проекты.
С этого момента тимлиду можно и нужно делегировать свои задачи подчиненным, потому что, если вы помните, у тимлида есть задача самому не протухнуть и куда-то расти.
Благодаря таким практикам появляется возможность наконец-то отдать кому-то часть своей работы. Например, релизы. Это 4-8 часов в неделю, которые внезапно освобождаются время от времени. Теперь вы можете потратить их на разработку, чтение статей, решение других задач. Большой ошибкой будет не забукать это в календаре и потратить на не самые полезные встречи. Хотя, как правило, так и происходит :) Теперь тимлид может радоваться, так как у него появилась возможность меньше нервничать и доверять своим сотрудникам часть своей работы. Если с ним самим что-то случится, то проекты не встанут.
В итоге, мы повышаем bus factor тимлида. Команда в свою очередь может быть уверена, что если с тимлидом что-то пошло не так, то любой из них будет готов взять на себя кусочек работы и справиться с ним.
Конечно, есть ограничения. Такой подход невозможен если вы все делаете в одиночку (человек-отдел). Если в подчинении пара человек, то уже есть возможность ротировать дежурства и релизы. Три напарника и больше — еще лучше.
В моем случае есть 5 разработчиков, трое из которых делят между собой виртуальные роли. Остальные двое просто занимаются разработками, новыми фичами. Они не привлекаются к релизам, саппорту и так далее.
Еще один важный фактор – это время. Придется терпеть до того момента, когда ротация ролей возымеет должный эффект, а вы получите команду готовую к выполнению задач, которые обычно лежат в компетенции тимлида. Проблема в том, что мы используем время как очень доступный и восполняемый ресурс. Но это совсем не так. Вы можете считать, что за полгода или год разработчик как-то “сам” раскачается, получит необходимый опыт и будет готов к дежурствам и чему-то еще. Но этого может не произойти, и, как правило, не происходит, если ситуация пущена на самотёк. Поток задач может быть такой, что у него не будет внешней мотивации развиваться нужным образом. И именно чередуемые виртуальные роли дают шанс, что вы сможете помочь членам своей команды всесторонне развиваться и в дальнейшем продвигаться на следующие грейды.
В итоге, все сводится к одной весьма конкретной цитате: «Задача лидера в том, чтобы было больше лидеров, а не тех, кто слепо следуют за лидером”. Я считаю, что использование этих инструментов поможет вам вырастить для себя, на минуточку, команду тимлидов. Это позволит вам двигаться дальше в профессиональном и карьерном плане. Компании, команде и проекту это даст возможность комфортно существовать. Ещё вы наконец-то сможете спокойно сходить в отпуск.
Автор: kapolakaki
