КЛЮЧЕВОЕ РЕШЕНИЕ
Развивать технологии вместе с системой работы команд
Обновление платформ требует не только архитектурных решений. Командам нужны собственная экспертиза, понятные приоритеты и общие критерии качества — от подготовки задачи до выпуска изменений.
Масштаб задачи и моя роль
Я отвечала за цифровую трансформацию всего контура рисков банка: техническую стратегию, портфель, архитектурные решения и развитие команд. Контур включал розничные, инвестиционные и интегрированные риски, риски КИБ — крупнейших корпоративных клиентов — и риски малого и среднего бизнеса.
В мою зону ответственности также входила защита контура перед Центральным банком России.
Нужно было одновременно развивать действующие продукты, проводить технологическую трансформацию и усиливать способность команд самостоятельно выпускать и сопровождать изменения.
01 / ТЕХНОЛОГИЧЕСКАЯ СТРАТЕГИЯ
Связать отдельные проекты в программу изменений
Развитие действующих продуктов и замена наследуемых решений требовали общих приоритетов и согласованного технического курса.
Что делали
Обновляла стратегию направления, связывала её с планами команд и защищала целевые архитектурные решения. Замена легаси, развитие платформ и работа с техническим долгом рассматривались в общем портфеле.
Результат
Обновлены стратегические ориентиры и защищены решения по трансформации платформ. Команды получили согласованную основу для дальнейшей разработки.
Вывод. Стратегия полезна, когда из неё понятны приоритеты, ответственность и последовательность действий.
02 / КОМАНДЫ И ПОСТАВКА ИЗМЕНЕНИЙ
Усилить собственную экспертизу и ответственность
Для развития и сопровождения систем нужны устойчивые инженерные компетенции и понятный порядок работы между анализом, разработкой и тестированием.
Что делали
Развивала центры компетенций и управление поставкой. Распространяли Definition of Ready и Definition of Done на инженерные направления, связывали бэклог, дорожные карты и ресурсы. Организовали технические демонстрации и обмен опытом.
Результат
Сформированы центры компетенций, расширено применение общих критериев готовности и организован контроль эффективности команд.
Вывод. Поставка становится управляемой, когда участники одинаково понимают, что должно быть готово на каждом этапе.
03 / КРЕДИТНЫЕ ПЛАТФОРМЫ
Развивать продукт и обновлять его технологическую основу
В массовом и корпоративном кредитовании нужно было поддерживать текущие процессы и параллельно проводить технологические изменения.
Что делали
Вела программу развития кредитных и расчётных платформ: от обоснования целевых решений и формирования команд до планирования выпусков и проверки поставок. Архитектурные изменения связывали с конкретными бизнес-сценариями.
Результат
Защищены целевые решения, сформированы проектные команды; по направлениям выполнены поставки и проверки расчётов. Каждый проект проходил свои этапы разработки, тестирования и запуска.
Вывод. Большая трансформация складывается из проверяемых результатов отдельных проектов.
04 / ДАННЫЕ И ИНТЕГРАЦИИ
Повторно использовать общие решения
Разным продуктам нужны данные из нескольких источников. Повторяющиеся интеграционные задачи требуют общей платформенной логики.
Что делали
Прорабатывали единый подход к загрузке и подготовке данных, выделяли общие компоненты. В программу включили развитие внутренней интеграционной экспертизы и повторное использование готовых решений.
Результат
Согласовано общее интеграционное решение; в одном из направлений завершена разработка единого коннектора к источникам данных. Усилена внутренняя экспертиза сопровождения интеграций.
Вывод. Платформенный подход начинается с конкретной повторяющейся задачи, которую полезно решить один раз.
05 / КАЧЕСТВО РАЗРАБОТКИ И AI
Сделать проверку качества регулярной частью работы
Развитие платформ должно сопровождаться проверкой качества изменений. Повторяющиеся инженерные задачи создают отдельную область для автоматизации.
Что делали
Расширяли автотестирование и инструменты управления тестами. AI-помощник применялся для ревью автотестов, работы с базой знаний и рутинных задач. Автоматизацию связывали с работой инженерных команд.
Результат
Расширено покрытие автотестами, обновлены инструменты тестирования и появились практические сценарии использования AI в инженерной работе.
Вывод. Ценность AI определяется конкретной задачей и проверкой результата в рабочем процессе.
Общий эффект работы
Эти показатели относятся к работе блока в целом и не суммируются как результаты пяти отдельных направлений.
Длительность цикла поставки сократилась на 44%. Отдельно измеряемая эффективность блока разработки выросла на 49%. Архитектурный и ИБ-техдолг сократился на 80%.
Оценка со стороны внутренних заказчиков выросла с 2,8 до 4,9 из 5. Были разработаны, защищены и реализованы более семи проектов замены legacy-систем.
Какой опыт я переношу в консалтинг
Сначала связываю техническую стратегию с конкретным результатом для бизнеса. Затем разбираю портфель, зависимости, ответственность и критерии готовности. Это помогает менять систему работы целиком — от выбора задачи до поставки и эксплуатации.
ЦИФРЫ И ДЕТАЛИ
Масштаб и обобщённые результаты
- Контур. 160+ человек в delivery, 43 ИТ-системы риск-контура, три вендора. Часть систем — legacy возрастом 15–20 лет.
- Управление. Разделили Discovery и Delivery. Закупки перевели на условия с правом передачи кода; ключевые позиции подрядчиков (43) перевели в штат.
- Технологии. Кредитование по онлайн-триггерам запустила внутренняя команда, а не вендор: 5 клиентов в секунду, полное решение — за 90 секунд. Запас производительности на высокий сезон — более 20% по всем системам; длительность значимых инцидентов 139 → 58 часов.
- Качество. 90% дефектов находим до продуктива. Первичное нагрузочное тестирование — 62 → 52 дня, регулярное — 7 → 3 дня.
ВЫВОД
Скорость начинается с управляемости
Техническая стратегия становится выполнимой, когда у команд есть компетенции, понятные границы ответственности и общий способ проверять качество. Эффект нужно оценивать по нескольким показателям: скорость поставки, качество и устойчивость систем отражают разные стороны работы.