> ## Content Index
> Fetch the complete content index at: https://admin.kod.ru/llms.txt
> Use this file to discover other available public pages before exploring further.

# Эволюция IT в финтехе: опыт Газпромбанка
- URL: https://admin.kod.ru/evolution-it-fintech/
- Published: 2025-09-23T13:00:16.000Z
- Updated: 2025-09-23T13:05:06.000Z
- Description: Как все было устроено в банковском IT раньше и как меняется его роль сегодня?
- Author: Газпромбанк
- Tags: Блоги

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

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

> Хотите знать все подробности о том, как развивалось IT в Газпромбанке и как устроен процесс разработки сейчас? [Слушайте](https://technologichno.mave.digital/?ref=admin.kod.ru) и [смотрите](https://rutube.ru/video/be0393a39e29180e43dda269f207c1d6/?ref=admin.kod.ru) наш подкаст «Техно.Логично» — в нем регулярно обсуждаем самое актуальное в IT-сфере.

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

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

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

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

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

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

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

![](https://admin.kod.ru/content/images/2025/09/--------------2025-09-23---15.56.36.png)

С отказом от вендорских решений в пользу 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

![](https://admin.kod.ru/content/images/2025/09/--------------2025-09-23---15.59.29.png)

Вне зависимости от сценариев и скорости развития банковских технологий, одной из главных задач блока 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, в зоне ответственности которой — развитие той или иной инженерной экспертизы.
- Стали еще более гибкими: при необходимости все команды можно быстро пересобирать без перевода специалистов из отдела в отдел. Этот подход неоднократно выручал нас, когда на рынке случались резкие изменения и нужно было быстро переключить фокус с одного направления на другое. Например, с кредитов на транзакционные продукты и депозиты.

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

![](https://admin.kod.ru/content/images/2025/09/--------------2025-09-23---16.01.44.png)

Чтобы трансформировать устаревшую модель тестирования в эффективную пирамиду, мы внедрили принцип **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!