Денис Гузовский, «Открытие»: Гибкая разработка кажется очень дорогой, но это плата за скорость

Денис Гузовский

К полноценному двухскоростному ИТ мы вплотную «подобрались» в прошлом году

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

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

Со всеми этими задачами мы справляемся. Установленные правлением внутренние KPI выполняем, успешно поддерживаем все проекты, связанные с развитием банка, у нас достаточно высокие показатели доступности — выше 99% по всем системам и сервисам.

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

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

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

Нам всем понравилась скорость такого движения. Безусловно, мы увидели и риски, которые несет в себе agile. Понимая эти риски и преимущества, которые дает гибкая разработка, мы разделили все наше ИТ-развитие на две компоненты. Так в «Открытии» появилось двухскоростное ИТ: часть проектов мы реализуем по agile-методикам, а часть — по классическим сценариям. У нас есть фиксированные проекты, нацеленные на определенный результат, например, по предоставлению бухгалтерских данных в Центробанк. Но есть и динамические проекты, в которых мы просто обещаем решить некое количество задач, примерно оценивая, что такое «задачи» и какое время потребуется на их реализацию.

Примерно три года назад, когда в банк «Открытие» пришла новая большая команда ИТ-специалистов. К полноценному двухскоростному ИТ мы вплотную «подобрались» в прошлом году.

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

С другой стороны, у нас в банке действительно спокойно уживаются две методологии. И когда мы решаемся на эксперимент — применяем классический agile без малейших отступлений, который мало кто в России на самом деле исповедует. Думаю даже, что мы новаторы. Я не слышал о других банках, которые объявили бы об одновременном применении двух этих методологий.

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

Проще, чем можно подумать. Но это связано с тем, что коллеги из нашего блока ИТ протестировали agile на проектах, которые были реализованы без участия бизнеса. У нас были отличные результаты, которыми мы смогли подкрепить наши идеи.

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

Мне кажется, гораздо сложнее было договориться с бизнесом о принятии рисков. В первых проектах банк двигался очень осторожными шагами, подстилали соломку везде, где можно, чтобы доказать работоспособность идеи и оправданность экспериментов. У нас получилось и потом стали рисковать больше.

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

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

Другой условный минус я вижу в том, что agile — это дорого. И это нельзя исправить, потому что это плата за скорость, высокий показатель time-to-market, большие шансы попасть в цель. Ради чего вообще существует гибкая разработка? Ради возможности подкручивать этот «летящий снаряд», пока он еще летит. При классическом подходе пока ты стреляешь, мишень уезжает. А agile еще и дает уверенность в том, что выпущенный продукт не «заглючит» ни с одной из сторон товарищей, с которыми ты интегрирован, что коллеги поймут любые форматы и спецификации. Но, пусть это и не относится к «Открытию», бизнес часто хочет, чтобы работало, как при гибком подходе, но стоило, как при классическом. А так не получается.

В первую очередь, вопрос был актуален именно для банка «Открытие», который объединил в себе семь других крупных финансово-кредитных организаций. А всего в ИТ-контуре мы в том или ином виде насчитали следы 50 банков! Вполне имевшая права на жизнь идеология предыдущего руководства заключалась в отказе от взаимной интеграции систем приобретаемых банков. Вместо этого шло их развитие как отдельного бизнеса одного холдинга. Поэтому серьезных интеграционных проектов до прихода нашей команды не существовало, и мы действительно получили разрозненную конструкцию, множество процессингов и банковских систем, которые работали сами по себе. Эти бизнес-локации приносили свою прибыль, но мы все-таки посчитали, что клиентам сложно объяснять разность продуктов и сервисов между регионами. Поэтому было принято решение переходить на единую платформу.

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

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

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

Для примера: одна из систем, кстати, украинская, включала более сотни серверов и порядка 70 баз данных. Глубина хранения — около 15 лет. С точки зрения объемов речь идет о десятках терабайт данных и 40 миллионах клиентов. Может показаться, что это совсем не много по современным меркам. Но, напомню, это действительно неструктурированные данные разных лет и даже десятилетий, управлять которыми очень сложно из-за разношерстности применяемого ПО.

Денис Гузовский

Сэкономили на архивных системах 10 человеко-лет работы

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

Конкретным решением стало Oracle Big Data Appliance, выбранное в свое время на архитектурном комитете для нашего хранилища — тоже в целях экономии. Таким образом здесь мы обеспечили синергию. Если говорить о решении для визуализации и подготовки отчетов, то тут нам не было принципиально какое-то конкретное решение. С этим BI-инструментом нам помог «Неофлекс».

Забегая вперед, отмечу, что в этом проекте мы хотели найти партнера, у которого есть опыт подобных внедрений. Идея интеграции архивных систем очень хороша, но в мире очень мало банков, которые реализовали бы такие проекты. А на российском рынке мы совершенно точно стали первопроходцами. Поэтому мы определили перечень компаний, у которых были хотя бы отдаленно похожие проекты, после чего провели открытый конкурс, на котором победил «Неофлекс».

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

Наши предварительные ожидания относительно сложности проекта по отдельным показателям не совпадали с итоговыми в полтора-два раза. Что-то оказалось дешевле, быстрее и проще, что-то — гораздо сложнее, дороже и дольше. По ходу проекта мы усилили команды менеджмента, методологию подготовки архивных данных. Очень важными в реализации оказались коммуникационные навыки партнеров, умение договариваться, понимать заказчика, перестраиваться на ходу. «Неофлекс» полностью оправдал наши ожидания.

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

Которые раньше делали операционные сотрудники, прикрепленные к определенным архивным системам. Они имели доступ к этим системам, знали, как найти нужные данные или клиентов. Это могли быть, условно, две девушки на весь банк, и если бы их не стало, у нас были бы большие неприятности.

В ноябре 2019 года.

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

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

Поэтому с технологической точки зрения здесь оказалось очень много компонентов. Например, необходимо было убедиться, что при перегрузке данных в Hadoop ничего не пропало и не утратило целостности. Кроме того, пришлось построить в витрине образы доступа к этим данным посредством BI-инструмента. Сейчас можно просто зайти в приложение, набрать фамилию, и тебе покажут, где, в каких базах данных есть клиент, какие на него зарегистрированы счета, и какое платежное поручение было связано с ним 7 лет назад. И вот эту технологическую часть проекта мы уже полностью реализовали. Сейчас проект находится в стадии наращивания и тиражирования.

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

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

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

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

Дальше: если говорить не про 168 систем, а хотя бы про 20, то на них завязаны 20 виртуальных серверов, которые теперь можно снять с эксплуатации, на которые не нужно будет накатывать обновления операционных систем. А это экономия и денег, и времени сотрудников. Думаю, речь идет об экономии примерно 10 человеко-лет работы.

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