Несколько лет мы делились своими знаниями и экспертизой на разных профильных мероприятиях и конференциях, участвовали в дискуссиях... А в этом году поняли, что у нас в банке за это время произошло столько всего, что пора делать собственную конференцию. Так появилась GPB Conf.
Более 400 профессионалов приняли участие — разработчики, инженеры и тимлиды из ведущих компаний, таких как Сбер, Т-Банк, Яндекс, VK, Авито и другие. Посетители могли погрузиться в атмосферу работы в банке, послушав доклады на Hard- и Soft-треках, а также приняв участие в активностях в экспозоне с 16 ИТ-направлениями.
Особенно приятно нам было получить много позитивных отзывов. Рассказываем, что интересного было на технологической конференции Газпромбанка.
Как мы перестроили разработку Первый Вице-Президент Газпромбанка Алексей Ульенков открыл конференцию и рассказал про инженерную трансформацию банка за последние несколько лет.
В 2021 году в банк пришла новая управленческая команда. Ее целью стала трансформация разработки для розничного бизнеса до уровня лучших российских банков и финтех организаций. За три года трансформации удалось достигнуть среднего срока вывода новых продуктов в 2 месяца, доля собственной разработки по ключевым системам близка к 100%, а доля клиентских жалоб на цифровые сервисы находится на историческом минимуме.
Это стало возможным благодаря нескольким ключевым принципам:
Все производство покрыто метриками эффективности (DORA-метрик); Переход на собственную разработку; Участие всех инженеров в написании кода; Переход к парадигме тестирования в разработке (shift left) для раннего получения обратной связи о качестве; Ориентация на бизнес-результат. Алексей Ульенков, Первый Вице-Президент Газпромбанка:
«Время вывода нового продукта в Газпромбанке сейчас занимает 2 месяца, для сравнения — в других банках это 3-4 месяца. Доля инхаус-разработки для ключевых систем — 95%». Цели команды на 2025 год:
Внедрение помощников на баз LLM для разработчиков, автоматизаторов тестирования; Замена OpenShift на k8s; Полная миграция в новое рабочее окружение; Основные работы по выносу бизнес-логики из АБС и импортозамещению; Масштабирование практик SRE; Тиражирование стандарта разработки. API-First: когда контракт важнее кода На нашем мероприятии мы уделили отдельное внимание одному из самых актуальных подходов в разработке. Об особенностях перехода на API-First рассказал Максим Морозов.
Суть подхода в том, что сначала создается четкий контракт (API), который становится основой для параллельной работы команд, и только потом пишется код. Это противоположность традиционному Code-First, где сначала создаются программные компоненты, а затем решаются проблемы их интеграции.
В масштабе крупной организации, где работают сотни команд, API-First становится не просто полезной практикой, а необходимым условием эффективной работы. Когда 200 команд и 2000 инженеров должны взаимодействовать без задержек, четкие контракты между системами критически важны для сокращения Time-to-Market.
Виктор Цветков и Юлия Григорьева поделились опытом внедрения API-First . Их доклад был не столько о технических аспектах, сколько о том, как преодолевать организационное сопротивление.
Кто-то из разработчиков видел в API-First лишнюю работу, кто-то боялся, что это замедлит разработку, а бизнес опасался дополнительных затрат и задержек в выпуске продуктов. В итоге команде удалось найти золотую середину: с одной стороны, четкий мандат руководства (без этого никуда), с другой — активное вовлечение команд через API-сообщества и рабочие группы, где разработчики сами участвовали в создании стандартов.
Результат: в розничном блоке и МСБ уже более 50 команд перешли на API-First, 127 сервисов подключены к генератору кода, а из общего количества 1033 сервисов уже 450 имеют спецификацию.
Trunk-Based Development: как выжить, когда все коммитят в одну ветку Вадим Ваганов рассказал о Trunk-Based Development (TBD) — подходе, который многим сначала кажется безумием: одна интеграционная ветка (trunk/main), куда все разработчики напрямую вносят изменения. Вадим поделился проблемами, с которыми столкнулись при внедрении, и тем, как их решали.
Для успешного внедрения TBD нужно полностью переосмыслить процесс ревью кода. Фишка в инверсии ответственности: теперь не ревьювер обязан найти время проверить ваш код, а вы, как автор MR, отвечаете за то, чтобы ваш код был проверен быстро и качественно.
Еще одно важное правило — «Общий только trunk!». Ветки создаются только для конкретных задач, ветвятся только от trunk и живут максимум несколько дней. Следующая важная мысль: «Деплой не равен релизу». Благодаря Feature Toggles можно часто деплоить в продакшн, но включать новую функциональность лишь тогда, когда это нужно бизнесу.
В результате команда получает быстрое прохождение MR через ревью, уверенность в стабильности основной ветки и возможность безопасно деплоить в любой момент.
Инженерный рост, ускорение тестирования и мониторинг Роман Олеск затронул тему, близкую каждому технарю — «Как быть инженером ». По его мнению, настоящий инженер — это тот, кто не просто пишет код по ТЗ, а понимает весь путь задачи и может влиять на процесс в любой момент.
Никакой воды и абстрактных рассуждений. Роман дал конкретные советы: как готовиться к собеседованиям (спойлер: это просто навык, который можно прокачать), как строить индивидуальный план развития и почему регулярные 1-на-1 встречи с руководителем — это не просто галочка в HR-процессах. Кстати, у него даже есть рецепт идеальной 1-на-1 встречи: 10% времени — про жизнь, 45% — про проект, остальное — про развитие. А еще мы как бы между делом рассказали про наш внутренний профиль инженера. Прокачал нужные навыки — получил «ачивку». Геймификация в действии
На другой стороне спектра — практический доклад Кристины Клигер о том, как перестать работать ночами и начать выкатывать фичи в прод по нескольку раз в день. Ее рецепт — правильно выстроенное тестирование, особенно компонентное и API.
Кристина поделилась реальным опытом: как изолированное тестирование не только повышает качество кода, но и прокачивает скиллы самих инженеров. В общем, win-win для всех — и для команды, и для пользователей, которые быстрее получают новые фишки.
Валентин Лебедев рассказал, как в банке применяют MaaS (мониторинг как сервис) — подход, когда мониторинг превращается из головной боли в удобный инструмент самообслуживания. Суть простая: видеть проблемы раньше, чем клиенты успеют пожаловаться.
Классическая проблема — мониторинг нужен всем, но настраивать его сложно, а разбираться в PromQL хочется далеко не каждому. Поэтому команда создала набор инструментов, где можно просто включить нужные функции анализа. Например, написали собственный плагин для VictoriaMetrics, чтобы инженерам не пришлось становиться экспертами по всему стеку мониторинговых решений.
Что было в экспозоне Конференция — это не только про «умные люди что-то говорят со сцены». Чтобы продемонстрировать свою экспертизу, мы подготовили экспозону с множеством активностей.
На стенде тестирования мы запустили Mission: QApossible — квест, где участникам предстояло стать QA-спецагентами, собрать идеальный набор инструментов и спасти мир от багов. Ну, или хотя бы спасти релиз от откатов.
У мобильных разработчиков играли в Mobile Jenga: нужно было собрать приложение для iOS и Android, убрав лишние блоки, но так, чтобы вся конструкция не рухнула. Метафора понятна, да?
А на стенде продуктового дизайна участники искали ошибки в UX-квесте, рисовали в инверсивных очках (это не так просто, как кажется) и верстали главный экран мобильного приложения.
Интересно было и у бэкендеров. Они подготовили несколько хитрых задач на логику, которые заставляли участников как следует поразмыслить. А фронтендеры организовали две активности: «КОДетектив», где нужно было угадать язык программирования по фрагменту кода, и Bug Hunting с заданием найти в коде уязвимость. К стендам выстроились очереди из желающих проверить свои навыки.
Квартирник: как быть с токсиками в команде Одним из самых увлекательных событий конференции стал квартирник на тему «Что делать с профессионалом, который демотивирует и ведет себя как токсик в команде» или, если совсем просто — «гений, но токсик: уволить или терпеть?». Формат квартирника был выбран не случайно: хотелось создать атмосферу, где можно говорить максимально открыто, без клише и обтекаемых формулировок.
Дискуссия получилась живой и продуктивной. Участники обсудили разные стратегии работы с токсичными сотрудниками — от личных бесед до более решительных мер.
Ответственность за решение проблемы лежит на руководителе команды. Именно он должен либо наладить диалог, либо принять сложное решение. Проблемы часто затягиваются именно потому, что лидеры избегают таких непростых ситуаций.
Важная часть — выявление причин токсичного поведения. Иногда оно может быть следствием конфликта ценностей, и в этом случае помогает прямой разговор о том, что человек разделяет, а что нет. В других ситуациях корень проблемы может быть в недостатке признания или других личных факторах.
Обсуждали и практические инструменты. Например, как объективно измерить токсичность (один из вариантов — оценка 360 градусов)? А также способы снижения уровня токсичности: регулярная похвала за успехи, материальное стимулирование и «радикальная прямота» — умение честно говорить о проблемах, не переходя на личности.
Главный вывод: универсального решения не существует — каждый случай требует индивидуального подхода. Но есть общие принципы: проблему игнорировать нельзя, действовать нужно как можно раньше, и иногда единственное правильное решение — расставание.
Было круто, будет еще круче За один день конференции мы провели десятки активностей: от технических воркшопов до игр в Mobile Jenga и UX-квестов. Мы получили множество позитивных отзывов, что особенно ценно для нашего опыта проведения конференции.
«Мы хотели показать, что Газпромбанк — это не просто финансовая организация, а технологичная и инновационная ИТ-компания, которая создает действительно удобные и надежные продукты. Первая GPB Conf точно не последняя. В будущем мы расширим программу, добавим еще больше активностей и устроим полноценный хакатон для участников. Так что ждем всех в следующем году».Юлия Иванова, начальник управления цифровых коммуникаций и продвижения технологического бренда Газпромбанк.Тех А пока собираем отзывы, анализируем опыт и готовим новые идеи, чтобы следующая конференция стала еще интереснее. Если у вас есть предложения или вы хотите выступить на следующей GPB Conf — пишите нам. Лучшие идеи обязательно воплотим в жизнь!
Комментарии