Ирина Титова: внедрение Agile и CI/CD начинается с культуры взаимодействия внутри команды

Поэтому в современной разработке программного обеспечения методология Agile и практика Continuous Integration/Continuous Deployment (CI/CD) становятся все более популярными.

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

- Ирина, давайте знакомиться, расскажите о себе и вашем направлении деятельности. 

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

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

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

- Мой опыт показывает, что масштабные финтех-проекты невозможно реализовать без стратегической трансформационной составляющей. Речь идёт не только о внедрении новых технологий, но и о перестройке процессов, управленческих моделей и культуры внутри компании. Именно такая комплексная работа позволила мне выстроить эффективные проектные офисы и сформировать подход, в котором Agile и CI/CD становятся не просто инструментами, а основой цифровой трансформации. В условиях жесткой регуляторной среды мне удавалось находить баланс между строгими требованиями регуляторов и задачами бизнеса, сохраняя фокус на продукте, его развитии и конкурентоспособности.

- Знаю, что у вас есть опыт работы с зарубежными странами.

- Мой опыт охватывает работу с финансовыми продуктами на международных рынках: от запуска новых решений до поддержки и развития уже действующих сервисов, в таких странах как Казахстан, Узбекистан, Испания, Вьетнам, Филиппины, Мексика. Управляя крупными распределенными командами, я адаптировала проекты под специфику разных стран и рынков, сохраняя при этом единые стандарты качества. Благодаря внедрению гибких методологий и совершенствованию процессов взаимодействия бизнеса и ИТ, нам удавалось заметно ускорять вывод нового функционала на рынок и обеспечивать его стабильную работу.

- Расскажите поподробнее про методологии Agile (APM) и CI/CD (Continuous Integration и Continuous Delivery/Deployment).

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

Решение Agile позволяет выстраивать короткие итерации, быстро проверять гипотезы и при этом синхронизировать работу продуктовых, ИТ и бизнес-подразделений. В свою очередь CI/CD обеспечивает техническую основу для Agile — благодаря автоматизации сборки, тестирования и развертывания новые версии продуктов могут доставляться клиентам чаще и безопаснее.

- Что они дают для банковской сферы?

- Вместе Agile и CI/CD дают банкам конкурентоспособность: скорость вывода продукта на рынок (Time-to-Market), устойчивое качество релизов, предсказуемость разработки и возможность развивать продукт, опираясь на реальные данные от пользователей.

Можно сказать, что Agile отвечает на вопрос «как управлять продуктом», а CI/CD — «как быстро и безопасно внедрять изменения». И только в связке они позволяют финансовым организациям конкурировать с финтех-стартапами и BigTech-игроками.

- Приведите пример внедрения решения.

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

Для решения этой задачи мы сфокусировались на создании сквозного процесса CI/CD, чтобы обеспечить регулярные и безопасные релизы: унифицировали пайплайн разработки для всех команд, настроили автоматическую сборку и тестирование, чтобы убрать зависимость от ручных шагов, ввели Quality Gates — проверку качества и готовности продукта на каждом этапе (анализ требований, код, тесты, согласование), интегрировали CI/CD в общую Agile-ритмику: каждая команда в конце итерации могла показывать инкремент продукта, готовый к поставке.

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

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

В итоге, CI/CD стало фундаментом для Agile-трансформации. Без автоматизированного и прозрачного пайплайна любые гибкие методологии оставались бы «на бумаге». Этот кейс показал: именно CI/CD даёт банкам возможность ускоряться, сохраняя надёжность и соответствие требованиям.

- Есть ли сложности их внедрения в регулируемой среде?

- На первый взгляд может показаться: если Agile и CI/CD так хорошо решают задачу скорости и качества, то банки должны внедрять их безоговорочно. Но реальность куда сложнее. Финансовая индустрия — это одна из самых жёстко регулируемых сфер, и здесь внедрение гибких практик сталкивается с рядом препятствий:

Во-первых, это регуляторные требования и стандарты.

Каждый релиз в банке должен соответствовать требованиям регулятора и внутренним политикам компании. Любая ошибка может привести не только к штрафам, но и к угрозе лицензии. Поэтому CI/CD приходится «усложнять» многоуровневыми проверками и согласованиями.

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

Все требования должны быть выполнены в полном объёме и в строго определённые сроки. Нарушение этих сроков несёт критические риски для банка. Именно поэтому финансовые организации не могут позволить себе относиться к регуляторным задачам как к серии A/B-тестов — здесь нужен абсолютный приоритет на полноту и безошибочность реализации.

Во-вторых, высокая цена ошибки. В финансовой организации ошибка — это не просто технический сбой или неудобство для пользователя. Даже один баг может привести к массовой блокировке транзакций, остановке работы сервисов или нарушению расчётов. Последствия выражаются не только в финансовых потерях, но и в репутационном ущербе: потеря доверия миллионов клиентов восстанавливается годами.

Именно поэтому банки не могут позволить себе подход «быстрее выкатим, а потом исправим». Каждое изменение должно быть проверено и подтверждено, а внедрение CI/CD выстраивается так, чтобы минимизировать даже малейший шанс критической ошибки.

- Знаю, что в банковской сфере многоуровневая система согласований.

- Несомненно,  каждый релиз должен пройти согласование не только внутри разработки, но и с юристами, службами безопасности и внутренним аудитом. Это создаёт сложную экосистему участников, где любое изменение должно быть подтверждено сразу несколькими сторонами.

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

Поэтому, главная задача при внедрении Agile и CI/CD в банках — не игнорировать согласования, а встроить их в процессы разработки так, чтобы они становились частью пайплайна, а не внешним препятствием.

- Какие еще существуют барьеры при внедрении прогрессивных решений?

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

Здесь необходимо обучать менеджеров новой роли лидера, создавать кросс-функциональные команды и показывать, что гибкие практики не противоречат контролю, а наоборот — усиливают его за счёт прозрачности и предсказуемости процессов.

- Расскажите про свой подход адаптации Agile и CI/CD под регулируемую среду.

- Главная особенность внедрения Agile и CI/CD в банках заключается в том, что нельзя просто копировать практики из IT-стартапов или BigTech. Финансовая индустрия требует особого баланса: скорость и гибкость должны сочетаться с безопасностью и строгим контролем.

Мой подход к трансформации строится на нескольких принципах:

• Agile + Compliance являются единым процессом.

Регуляторные проверки и комплаенс не должны быть внешним барьером. Я интегрирую их прямо в Agile-процессы и CI/CD-пайплайны. Это позволяет командам работать итеративно, но при этом каждая итерация уже учитывает требования регулятора.

• Quality Gates на каждом этапе.

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

• DevSecOps как обязательный стандарт.

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

• Фокус на продукт и конкурентоспособность.

Даже в условиях жёсткой регуляторики я всегда делаю акцент на бизнес-целях: продукт должен развиваться, оставаться удобным для клиентов и усиливать позиции компании на рынке. Для этого применяются продуктовые метрики (Time-to-Market, удовлетворённость клиентов, количество дефектов), а не только регуляторные показатели.

• Гибридный подход.

Вместо «чистого Agile» я использую комбинацию методологий: Agile-практики для разработки и гипотез + Waterfall-элементы для регуляторных проектов. Такой гибрид позволяет не терять гибкость, но при этом гарантирует точное выполнение обязательных требований в срок.

• Кросс-функциональные команды с вовлечением комплаенса.

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

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

- Давайте подведем итог и сделаем выводы по внедрению Agile и CI/CD.

- Отмечу несколько пунктов: Agile «по учебнику» не работает в жёстко регулируемой среде. Необходимо адаптировать методологию под реалии отрасли. CI/CD — это фундамент Agile. Без прозрачного и автоматизированного пайплайна невозможно обеспечить быстрые и безопасные релизы.

Регуляторика — не барьер, а часть процесса. Важно встроить требования комплаенса и безопасности в пайплайн, а не рассматривать их как внешнее согласование. Культура и люди важнее инструментов. Настоящее ускорение появляется только тогда, когда бизнес, ИТ и комплаенс работают как одна команда, а не как отдельные «цеха».

Мой главный совет: если компания хочет внедрять Agile и CI/CD в банке или финтехе, нужно начинать не с покупки инструментов, а с изменения культуры взаимодействия и построения кросс-функциональных продуктовых команд. Тогда даже самые строгие регуляторные требования перестанут быть препятствием и превратятся в часть экосистемы развития продукта.

Василий Черный

*Организация запрещена на территории РФ

*включен Минюстом РФ в список физлиц-иноагентов