Секреты fullstack-команды: когда любая утилита по плечу

Когда один специалист способен пилить и бекенд, и фронтенд — это называется fullstack. Именно так, в четырех системах и на пяти языках программирования в отделе автоматизации бизнес-процессов Lamoda работают 27 человек. Это четыре команды разработчиков. Они пишут сразу на PHP, Go, Typescript, Java и Kotlin.

Делать так невозможно, логика этих языков слишком разная, думают новички на собеседовании. Так считал и Евгений Сальников, тимлид одной из команд доставки в Lamoda. Но спустя некоторое время его мнение кардинально изменилось, а в самом подходе Женя нашел много преимуществ.

Любую работу в Lamoda мы стараемся стандартизировать, создавать все решения на одном языке по определенным правилам. Впрочем, бывают задачи, которые нужно решать нестандартно для нашего подхода. Благодаря разумному выбору программных продуктов, специально созданных под определенные задачи, мы значительно экономим ресурсы и время. Яркий пример — Apache Camel. Это интеграционный фреймворк на Java, который используется в сервисе для взаимодействия с внешними курьерскими службами. Фреймворк позволяет быстрее адаптировать новые службы и новые API, тратить меньше времени на преобразование запроса из Json в XML. Написать все это на PHP можно, но будет нерационально, так как эта технология уже предназначена для решения этих задач.

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

Когда я только пришел в Lamoda, я не верил, что все сотрудники могут быть разносторонне компетентными (работу же невозможно планировать, когда все пишут на пяти разных языках). Но теперь я сам успешно помогаю новым участникам команды адаптироваться к такому подходу. Чаще всего они начинают работать только с одной из наших систем, например, Express, потому что все наши процессы так или иначе связаны с доставкой. Погрузившись в одну систему, в дальнейшем специалист освоит остальные и будет легко решать задачи по их доработке. Порог вхождения становится гораздо ниже.

В Lamoda один инженер в рамках одного спринта может дорабатывать и бэкенд, и API мобильного приложения, и само приложение. Любой способен поправить скрипт деплоя и написать что-то на Ansible, чтобы развернуть новый сервер. Бывает, что нам нужно запросить миллион Data matrix у внешнего API. Писать большую программу на PHP для этого невыгодно. Для таких задач есть язык Go. Мы всегда можем обратиться с вопросами к соседним командам, у которых есть экспертиза в этом языке.

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

Как я уже упоминал выше, в нашей команде среди инженеров нет распределения по специализациям: каждый может доработать любую систему. Например, для создания новой эффективной формы возврата нужно затронуть системы Express и XDC.

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

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

Для наиболее эффективного планирования и получения точного результата, мы двигаемся двухнедельными спринтами и используем Покер-планирование (англ. Planning Poker или Scrum poker). Это техника оценки сложности или относительного объема предстоящей работы. Такая система основана на достижении договоренности: специалисты прогнозируют, сколько времени займет та или иная задача на основе своего опыта. Каждый участник команды дает предстоящей задаче оценку, из суммы которых складываются наиболее реалистичные сроки.

Fullstack-программист — очень дорогой специалист. На рынке их немного. Вот что я рекомендую сделать, чтобы снять дефицит таких кадров в своей команде.

Все мои страхи о том, что такую работу невозможно спланировать не подтвердились. Наоборот, такой подход показал мне, что fullstack-работой еще как можно управлять и тем самым развивать экспертизу. Если у вас есть опыт формирования fullstack-команды, поделитесь им в комментариях.