: Эволюция IT в финтехе: опыт Газпромбанка

Эволюция IT в финтехе: опыт Газпромбанка

Газпромбанк -

Всего десятилетие назад бизнес-подразделения всерьез не рассматривали программный код как инструмент, благодаря которому банки будут получать основной доход.

ИТ-специалисты преимущественно выполняли роль посредников между вендорами и заказчиками от бизнеса. О том, как все было устроено в банковском IT раньше и как меняется его роль сегодня, рассказываем в этой статье.

Хотите знать все подробности о том, как развивалось IT в Газпромбанке и как устроен процесс разработки сейчас? Слушайте и смотрите наш подкаст «Техно.Логично» — в нем регулярно обсуждаем самое актуальное в IT-сфере.

Код писали «за забором» и перекидывали в банк

Еще 10–15 лет назад в традиционных банках направление IT не играло такой заметной роли, как сейчас, когда каждый финансовый продукт дублируется в цифре, а основная деятельность ведется онлайн. Основными действующими лицами были архитекторы, специалисты по информационной безопасности, менеджеры проектов, сотрудники техподдержки и QA-инженеры — то есть те, кто формируют технические требования и отвечает за приемку решений.

Но уже через несколько лет банки столкнулись с дилеммой: начинать работать с вендором (писать код «за забором»), конечно, удобно, но вот дальше нужно как-то развивать и поддерживать IТ-системы. При этом объемы и стоимость разработки растут, аппетиты подрядчиков — тоже.

В какой-то момент схема взаимодействия стала гибридной: с коробочной вендорской модели банки стали переходить на работу с аутстаф-командами, а затем — приобретать и интегрировать их у себя. Но даже при появлении блоков инхаус-разработки IТ и бизнес в банках продолжали жить отдельно друг от друга. Все контакты велись по модели внутреннего вендора, когда тот самый «забор» находится уже внутри компании.

Затем пришла эра Agile, и IТ-сфера заметно преобразилась. Однако банкам эти перемены дались нелегко: в какой-то момент IТ-подразделения стали тем самым bottleneck — узким местом, тормозящим развитие бизнеса. По сути, для банков они оставались такими же внутренними вендорами, затраты на работу с которыми росли вместе с объемами задач, а результаты при этом были далеко не всегда впечатляющими.

Именно тогда бизнес осознал, что технологии — это его неотъемлемая часть, и Agile пришел в банковское IT. Все закрутилось вокруг команд, продуктов и бэклогов.

От экспериментов — к системной трансформации

С отказом от вендорских решений в пользу open source во многих банках решили избавиться от узких мест и полностью уйти от модели аутсорсинга — не важно, внешний он или внутренний.

В розничном блоке Газпромбанка этот переход затронул все направления работы с программным кодом, будь то разработка, тестирование или автоматизация. Процессы перестроили так, чтобы они позволяли четко понимать, как банк будет эксплуатировать создаваемый стек, развивать и дорабатывать его дальше. Так появился этап интеграционных релизов.

Однако дальше — с ростом масштабов производства — этот подход тоже стал узким местом. Назрела необходимость автоматизации процессов за счет внедрения DevOps-практик и инструментов. Но через какое-то время масштаб разработки стал настолько большим, что стандартные коробочные решения перестали справляться с автоматизацией.

В банк пришли новые сторонние команды, чтобы быстро «допиливать» и патчить эти инструменты. Запустился новый виток эволюции. Стало очевидно, что банк сосредоточен не только на создании продуктов и решений для клиентов, но и занимается разработкой и развитием целой экосистемы внутренних инструментов на базе open source.

Дальше было еще много экспериментов с организацией процессов разработки. Внедрение DevOps должно было объединить разработку (Dev) и эксплуатацию (Ops), но на практике DevOps превратился в отдельную функцию, которая занимается автоматизацией доставки изменений и настройкой CI/CD-процессов. Эксплуатация при этом осталась централизованной службой.

Потом появилась роль Site Reliability Engineer (SRE) — подход от Google, который позволил встроить функции эксплуатации прямо в продуктовые команды, обеспечивая надежность сервисов еще на этапе проектирования.

Все это напоминает конвейерное производство автомобилей: от ручной сборки — к конвейеру Генри Форда, а затем — к полностью автоматизированным современным заводам. Так и в IT-системах банков: от разрозненных решений — к централизованной инфраструктуре, а затем далее к полностью автоматизированным DevOps- и SRE-практикам.

Инженерно-ориентированный подход

Раньше IT Газпромбанка строилось преимущественно на работе с вендорами и аутстаф-командами. При этом внутри команды наблюдался разбалансированный ролевой состав: много аналитиков, проджект-менеджеров и тестировщиков, но при этом критически мало разработчиков.

У CTO продуктов не было достаточных полномочий для принятия нужных решений, а релизы были исключительно масштабными. Все, что касалось DevOps, делали IТ-специалисты, вышедшие из тестирования, а вся автоматизация была направлена только на выполнение большого количества тяжелых интеграционных или хрупких UI-тестов. Это заметно осложняло разработку.

Чтобы улучшить ситуацию, мы сознательно перешли к концепции «стартап-подхода», где нет места классическому разделению ролей: аналитик, тестировщик, разработчик и т. д., а есть инженеры уровня T-shaped, которые глубоко погружены в продукт, способны видеть общую картину и легко взаимодействуют с экспертами из смежных областей.

Этот путь может показаться менее эффективным с точки зрения классической конвейерной разработки, однако открывает гораздо больше возможностей на перспективу. Ведь в итоге мы получаем не просто исполнителей отдельных задач, а экспертов с широкими знаниями в смежных направлениях, которые глубоко понимают продукт. Если система «ляжет», а код не будет работать, создателю придется все чинить только своими силами.

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

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

Эффективность IT без иллюзий, или Как посчитать ROI

Вне зависимости от сценариев и скорости развития банковских технологий, одной из главных задач блока IT остается оценка эффективности подходов к разработке и доставке изменений конечным пользователям. Единственным объективным показателем здесь, пожалуй, становится прибыль, которую бизнес получил после внедрения новой фичи (то есть заработал банк больше денег или нет).

Но есть и другие метрики, которые помогают измерить реальный уровень IT.

  1. Lead time (в Газпромбанке мы используем название Cycle time, так как термин Lead time был занят другой метрикой) — это время от момента, когда разработчик впервые коснулся клавиатуры, до момента, когда все уже залито в прод. То есть Cycle time показывает, сколько времени прошло с момента поступления запроса от бизнеса до его конечной реализации.
  1. Deployment Frequency (частота установок на продакшен) демонстрирует количество успешных установок за определенный период времени, а значит — скорость доставки нового функционала или исправлений конечным пользователям.

Идеальная картина, когда у производства есть возможность максимально часто доставлять изменения в промышленное окружение. Это достигается за счет менее масштабных, но более частых  релизов. Багов становится меньше, их проще «отлавливать», а при необходимости релиз легче откатить к предыдущей версии.

Команда Газпромбанка в среднем реализует почти три тысячи изменений в месяц, и это не предел! К концу 2025 года мы планируем прийти к состоянию, когда сможем отправлять в продуктив каждый пул-реквест (пусть даже в выключенном состоянии).
  1. Mean Time to Repair — среднее время, необходимое для восстановления работоспособности системы после сбоя. Хорошее производство — это прежде всего качественный прикладной код, надежные инструменты для его быстрого отката и переконфигурации, контроль зависимостей в части интеграции API.
  1. Change Failure Rate — процент неуспешных установок изменений, приводящих к сбоям в продакшене. Проще говоря, соотношение хороших поставок к плохим.

Кроме этого в Газпромбанке есть специальные внутренние инструменты для оценки эффективности IT. Например, Модель зрелости показывает, какие практики, подходы и методологии использует каждая из команд разработки и насколько это эффективно. Метрика помогает лучше понять, где и за счет чего достигаются максимальные улучшения, и в дальнейшем строить разработку еще эффективнее.

Было — стало: эволюция IТ в Газпромбанке

Всего за два года мы совершили такой технологический рывок, который у большинства банков мог бы занять минимум пять лет. Сегодня наши бизнес-подразделения стали полноценными участниками всех процессов развития IТ. Именно от них исходят главные задачи.

Если раньше организационная структура была выстроена вокруг систем, то теперь все вращается вокруг продуктов.

Первое, что мы сделали, — сильно изменили организационную структуру:

  • Вместо пяти департаментов оставили три.
  • Разделили бизнес на два больших домена — кредитный и не кредитный. В них входят CTO продуктов.
  • Объединили инженеров в структуру, внутри которой блоки делятся на центры экспертизы.
  • IT-партнеров мы трансформировали в роль СТО. Также появилась отдельная роль Head of profession, в зоне ответственности которой — развитие той или иной инженерной экспертизы.
  • Стали еще более гибкими: при необходимости все команды можно быстро пересобирать без перевода специалистов из отдела в отдел. Этот подход неоднократно выручал нас, когда на рынке случались резкие изменения и нужно было быстро переключить фокус с одного направления на другое. Например, с кредитов на транзакционные продукты и депозиты.

Как менялась разработка

Чтобы трансформировать устаревшую модель тестирования в эффективную пирамиду, мы внедрили принцип Shift Left — стратегию, направленную на максимально быстрое выявление и устранение дефектов в жизненном цикле продукта. Для этого основную нагрузку тестирования сместили на ранние этапы разработки и стали потихоньку покрывать все юнит-тестами.

Еще мы использовали механизм централизованных quality gates (QG) и постепенно увеличивали процент покрытия кода тестами. Замеры показали, что простое внедрение обязательных проверок (pre-commit хуков в Git) на запуск юнит-тестов перед коммитом кода снизило количество дефектов вдвое.

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

Следуя лучшим практикам, мы работаем над едиными стандартами разработки продуктов в Газпромбанке и стремимся, чтобы каждый участник процесса следовал им. Постепенно мы приходим к тому, что все знания лежат на уровне кода и каждый IT-специалист банка должен уметь его читать.

Когда ИИ встречается с IT

Пока еще программные инструменты собирают люди, но впереди нас неизбежно ждет очередная революция, когда IТ-продукты будут создавать роботы. Современные нейросети уже преодолели экспериментальную стадию и готовы к полноценному производственному внедрению. Это приведет к трансформации всей отрасли и кардинально изменит требования к IТ-специалистам.

В будущем нейронная сеть станет инструментом, с помощью которого IТ-специалист будет генерировать код еще быстрее. Но без человека здесь все равно не обойтись, ведь кто-то должен взаимодействовать с бизнесом, чтобы продукт удовлетворял потребностям клиентов. И все же не исключены сценарии, когда бизнес-подразделения будут писать промпты и генерировать код только своими силами — без участия IТ-экспертов.

Если считать, что топовый программист превосходит мидла в 10 раз, то топовый программист, заряженный нейронкой, будет отличаться от него уже в 100 раз. Революция в IT идет полным ходом, и не исключено, что уже через три года профессии изменятся до неузнаваемости.

В планах IT-блока Газпромбанка на 2026 год — развивать и масштабировать ИИ-инструменты для разработчиков.

Ceep Calm and push

Не существует «серебряной пули», которая помогла бы в одночасье улучшить процесс разработки IT-продуктов в банке. Прогресс достигается не единым масштабным изменением, а последовательностью небольших, но тщательно продуманных и спланированных шагов. В нашем случае это:

  • внедрение юнит-тестов, CI/CD-практик и Qulity Gates;
  • строгий контроль версионности (обратной совместимости) API;
  • переход к функциональной структуре;
  • наделение CTO продуктов правом принятия решений;
  • фокус на инженеров и разработчиков;
  • формирование инженерного мышления среди руководителей;
  • отказ от монолитных интеграционных релизов в пользу небольших, но регулярных.

Как видите, никакой магии — только десятки продуманных и успешно реализованных решений. Как говорится, Ceep Calm and push!