Привет! Меня зовут Борис Рябов, я руководитель отдела разработки интерфейсов в ЮMoney и по совместительству — Product Owner платформенной команды. Поделюсь, чем такая команда может быть полезна бизнесу, почему этот подход нам подошёл и к каким трудностям надо подготовиться.
Чем занимается наша платформенная команда
В ЮMoney применяется распространённый стек на фронтенде — React, TS и Nest.JS. Он хорошо себя зарекомендовал с точки зрения разработки и найма людей, на нём у нас работают все продуктовые команды. Также у нас широко применяется микросервисная архитектура (прошу не путать с микрофронтендами), и таких сервисов уже более 70.
По мере роста компании, количества команд и сотрудников в отделе нам понадобились единые стандарты в разработке. Чтобы не решать изолированно в каждой конкретной команде одни и те же инфраструктурные задачи, а также задачи, связанные с безопасностью и качеством кода.
Нам было необходимо видеть общий вектор развития фронтенда во всех его аспектах, чтобы он соответствовал стратегии компании и гибко адаптировался под требования рынка. Для разработки важно понимать, куда мы двигаемся и чего хотим достичь.
В компаниях платформенные команды могут решать разные задачи, и со временем мы нашли то, на чём должна сфокусироваться такая команда в ЮMoney. У нас появился собственный продукт, за который мы отвечаем. ↓
По мере эволюции нашего стека и перехода от монолита к микросервисам команда платформы стала владельцем своего основного продукта — заготовки. Это решение, на котором строятся все наши микросервисы, оно учитывает технические требования, а также всю необходимую инфраструктурную подготовку.
Главная задача платформенной команды — создать фундамент для всей остальной разработки. Вот чем мы занимаемся:
Обеспечиваем техническое лидерство и ревью кода.
Разрабатываем ключевые компоненты платформы (дизайн-система и заготовка).
Стандартизируем процессы разработки, тестирования, деплоймента и мониторинга.
Обеспечиваем кросс-функциональные требования — безопасности, масштабируемости и производительности.
Распространяем лучшие практики и культуру качества.
Консультируем и обучаем продуктовые команды, помогаем им внедрять новые технологии.
Как управлять платформенной командой
Подход похож на управление продуктовой командой. Что это значит? Прежде всего нам надо понимать, кто наш заказчик. Это разработчики из других команд, которые делают пользовательские приложения и сервисы на базе нашей платформы. Мы прислушиваемся к болям отдела, регулярно собираем обратную связь об использовании заготовки, строим планы и дорожную карту, основываясь на запросах разработки.
Также у нас есть общий канал коммуникации, в котором все запросы обрабатываются в соответствии с утверждёнными приоритетами. В целом это можно назвать клиентоориентированной разработкой.
Платформенная команда работает в тесной коллаборации с отделами инфраструктуры, DevOps и ИТ-безопасности, следуя их требованиям и стандартам.
Теперь поговорим о самом важном — о людях, которые работают в платформенной команде. Поскольку команда взаимодействует со многими подразделениями и разрабатывает ключевые элементы системы, на ней лежит большая ответственность. Не каждый разработчик к такому готов, поэтому в платформенную команду попадают люди, которые хотят учиться.
Я выделил несколько ключевых требований к тем, кто стремится работать в такой команде. Помимо очевидных хардовых навыков фронтенд-разработчика, нужны:
Развитые софты. Каким бы классным ни был специалист, важно, чтобы он мог объяснять решения и мотивы коллегам по отделу. А эти решения могут быть сложными для восприятия. Задача команды — презентовать, для чего мы внедряем изменения, искать личные подходы к другим командам, где это требуется, например там, где есть сопротивление и непонимание.
Опыт продуктовой разработки. Работая исключительно в платформенной команде, можно сильно отдалиться от реальной разработки в отделе и несовершенства планирования, требований, меняющихся условий. Только человек, который проработал некоторое время над продуктами именно в нашей компании, понимает, как они создаются, и может говорить на одном языке с командами.
Желание. Куда же без него? Разработчику надо быть готовым к некоторому давлению со стороны отдела, ведь никогда не бывает идеального решения, которое подойдёт всем.
Что мы получаем от такого подхода:
Единую стратегию технического развития в рамках всего отдела, когда выделенная команда может сфокусироваться на долгосрочных целях, консистентности и архитектурной целостности ключевых компонентов системы.
Экономию ресурсов продуктовых команд: мы можем горизонтально масштабироваться, создавая новые продукты без накладных расходов, связанных с техническим обеспечением и программной инфраструктурой.
Лёгкий порог входа для разработчиков продуктовых команд — как следствие, меньшие требования и более быстрое трудоустройство.
Стандартизацию и контроль качества. Платформенная команда лучше обеспечивает соблюдение стандартов отдела и задаёт их, консультируясь с экспертами в отделе.
Именно платформенная команда, за счёт своей экспертизы, кругозора и влияния, может эффективно внедрять новые технологии, практики и подходы в масштабах отдела фронтенда и делать это сразу во всех продуктах.
Но, как и в любом подходе, здесь не обходится без сложностей
Я начну с проблемы, которая была у нас: то, как отдел воспринимал такую команду. Когда есть команда, которая берёт на себя большую ответственность за техническое развитие и задаёт регламенты, может возникнуть ощущение, что только её мнение правильное, а решения — непоколебимы и спорить с ними бесполезно. Поэтому очень важно сформировать единство внутри команды и выносить её мнение в отдел, будучи открытыми к диалогу. Если люди не боятся такого взаимодействия, это помогает заранее выявить проблемы, которые в противном случае замалчивались бы и нарастали внутри команд.
И решение здесь на поверхности — коммуникация, причём постоянная и во всех возможных форматах. Нужно системно рассказывать о том, куда мы движемся, зачем мы что-то делаем, почему это важно, а главное — что это помощь командам, а не попытка вставлять палки в колёса. В этом платформенная команда постоянно балансирует между требованиями бизнеса, техническим развитием и желаниями разработчиков.
Следующая проблема, которую хочу упомянуть, это объём экспертизы, который вынужден хранить каждый разработчик платформенной команды. При большой кодовой базе, мощных процессах деплоя и серьёзной инфраструктуре финтеха в команде естественным образом появляются хранители уникальных знаний. И объём этих знаний таков, что передать их кому-то не представляется возможным, поэтому каждый разработчик на вес золота. Пока идеального решения этой проблемы я не нашёл. Сейчас мы экспериментируем с форматом работы, где каждый участник платформенной команды берёт на себя задачи из разных областей, а не из тех, где у него больше всего экспертизы. На первый взгляд кажется, что это помогает, но время покажет.
Сложность формирования команды — это и проблема, и ключ к успеху. С одной стороны, вам нужны настоящие эксперты, которые отлично знают, как устроена разработка в вашей компании, которые знакомы с инфраструктурой и глубоко погружены в проектирование на отдел. С другой — это должно сочетаться с желанием помогать коллегам, общаться с ними, готовить презентации и выступать. Найти такое непросто, но можно взрастить, хотя это уже тема для новой статьи.
Заключение
Платформенные команды могут помочь, если перед вами остро стоит вопрос масштабирования технологий внутри компании. При правильном подходе такая команда может снизить расходы и время на разработку продуктов, смягчить последствия ухода разработчиков, упростить трудоустройство новых сотрудников. Можно достигать поставленных целей с точки зрения технического развития и держать этот вектор, помогая выполнять стратегию компании. Если перед вами стоят перечисленные задачи, присмотритесь к этому решению. Но такие команды подходят не всем и начинают приносить пользу только при определённой зрелости и масштабах компании.
Сейчас в отделе разработки интерфейсов ЮMoney, которым я руковожу, открыта вакансия JavaScript-разработчика. Откликайтесь или пересылайте друзьям, которые ищут работу. Буду рад пообщаться.