Апгрейд системы мониторинга для банка: как мы заменили legacy-систему на современное Web-приложение за 9 месяцев
Привет! Меня зовут Екатерина Бадалян, и я — руководитель центра компетенции разработки блока ИТ-развития корпоративного бизнеса в «РСХБ-Интех» (IT-компания АО «Россельхозбанк»). Моя команда в течение девяти месяцев работала над новым решением для мониторинга банковских сделок в РСХБ. Мы создали многие блоки с нуля и фактически полностью пересмотрели и переработали продукт, сформировав новую функциональную user-friendly систему. Ей уже успешно пользуется бизнес-подразделение Россельхозбанка. О том, как мы в столь сжатые сроки выстроили работу внутри команды и с заказчиком, с какими трудностями столкнулись, как внедрили современные решения и доработали то, что осталось от исторического процесса автоматизации, а главное — безболезненно перенесли на новый стек свыше 37 миллионов мониторингов, я расскажу в этой статье.
Замысел
Наш клиент использовал для автоматизации процессов мониторинга условий кредитных сделок корпоративных заемщиков legacy-систему, написанную в 2012 году на толстом клиенте WinForms в сочетании с устаревшими библиотеками DevExpress (на двухзвенной архитектуре). Причем работала эта система в более чем 60 филиалах банка, которые не только отслеживали условия кредитования, но и формировали в ней отчеты разного уровня (некоторые из них были очень массивными). Из-за использования устаревшей технологической платформы и ежедневно растущего объема данных быстродействие решения постоянно снижалось и кратно возрастало количество технических сбоев. Оперативность отклика в период пиковых нагрузок замедлилась, возникали сложности с внесением данных. Мы пришли к точке, когда качественно развивать и улучшать систему стало уже невозможно, а поддерживать и сопровождать текущее решение — крайне сложно.
Тогда мы с менеджером проекта подготовили для бизнес-заказчика предложение по реализации совершенно нового и современного проекта с конкретным планом действий.
Был составлен список всех необходимых работ, сопоставлены каждому виду работ предполагаемые оценки, добавлен «запас» на возможные проволочки и неизвестность (к слову, мы впервые шли на такие радикальные шаги и были взволнованы предстоящими переменами) и обучение команды.
Оценка задач и планирование по месяцам в зависимости от ресурсов и емкости задачи
Когда мы подробно расписали и предварительно оценили скоуп задач, ожидаемый срок реализации проекта превысил год. Однако такой таймлайн заказчику не подошел — подготовку ежегодных отчетов было критично начать уже в новой системе: таким образом, нам потребовалось сократить срок на ¼ — до 9 месяцев. Приняли решение остановить все доработки старой системы, кроме критических, и бросить силы в новую разработку.
Чтобы весь процесс прошел успешно, мы применили следующие фишки планирования в сжатые сроки:
Карта продукта (User Story Mapping): мы разделили предполагаемую доработку на релизы, а также расставили приоритеты между доработками внутри каждого намеченного релиза от жизненно необходимых функций до удобств и пожеланий на будущее развитие (мы рисовали «скелет» полностью, постоянно корректировали, тщательно отделяли «критичное» от просто «нужного»).
Отделили минимально необходимые продуктиву части функционала, которые мы успеем реализовать, а все дополнительные функции, улучшения, а также идеи, которые приходили к нам во время разработки, отложить на второй этап.
Более активное вовлечение заказчика в работу команды: Владелец продукта должен быстро принимать решения, согласовывать и определять методологические подходы (понятная карта полномочий внутри задачи, договоренность на старте «по каким правилам мы работаем»).
Настройка режима работы в команде и продуктивность: прозрачную витрину задач (Владелец продукта понимает цену переделок и ошибок, команда каждый спринт показывает предсказуемый «выхлоп»).
Распределение ключевых исполнителей между задачами (мы понимали, кто сосредоточится на миграции, а кто на функциях для безопасности, на основных интерфейсах и какие вакансии нужно заполнить в первую очередь исходя из общего таймлайна проекта).
Бэклоги и доски мы настраивали полностью под себя (как нам понятно и удобно):
Доска задач команды на спринт
Наглядное планирование в Excel всех задач бэклога по исполнителям и трудоемкости
Основная сложность проекта заключалась в ограниченных сроках для разработки без реальной возможности их переноса. У нас было 7 месяцев на разработку, 2 — на тестирование, опытную эксплуатацию, миграцию данных, обучение пользователей и внедрение, вместо рассчитанных комфортных 14 месяцев на проект. Как и следовало ожидать, поставленные сроки и ожидания оказались слишком оптимистичными — трудностей и различных проблем в процессе реализации выявилось на порядок больше. Тем не менее, установленные Заказчиком сроки были соблюдены. Как?
Что помогло нам достичь нужного результата в установленные сроки:
Уменьшение объёма работ к первому релизу за счет планирования
Благодаря USM и планированию мы выделили самый важный функционал, без которого нельзя идти в продуктив, в первый релиз, тем самым отбросив все дополнительный функции и задачи на последующие релизы.
Грамотные владелец продукта (Сергей Бирюков) и менеджер (Елизавета Лощинина)
Product owner управлял командой и по-настоящему вовлекся в разработку, поэтому требования оперативно приоритизировались, а карта связанных задач корректировалась (Владелец защищал требования перед подразделениями банка, поэтому практически исключились все изменения во время или после реализации), а главное он «слышал» команду и помогал решать все возникающие проблемы. Несмотря на небольшой опыт на старте работ, Product Owner инвестировал личное время в то, чтобы разобраться «как все работает» и прислушивался к мнению команды и возможностям (подход «хочу», поменялся на «что мы сможем»).
Также, большую роль сыграл менеджер проекта, который жестко контролировал все сроки и этапы, вдохновлял команду в сложные периоды, настраивал все взаимодействия внутри команды и вне, и очень глубоко погружался абсолютно во все вопросы, этапы и части создания системы, а я, в свою очередь, помогала менеджеру на старте работ, а затем в организации всего процесса в целом и наставничеством. Наш путь оказался сложным, несмотря на это, Лиза всегда сохраняла боевой настрой, заряжала команду. Когда мы не понимали, как справиться с ситуацией, сидели по вечерам — мозгоштурмили, чтобы исправить положение, ограждали от сомнений и переживаний команду, по крайней мере старались решить трудности с заявками-соседними командами-сроками-созданием «железа»-препятствиями и так далее — менеджерами и тимлидом разработки.
Мотивированность команды идеей
Из-за большой вовлеченности команды в задачу (как со стороны разработчиков, так и со стороны владельца), команда была готова к сверхусилиям. И это оказалось ключевым преимуществом, команда совершила «чудо» несмотря на все прогнозы и сложности. Вместе мы шли к общей цели и горели задачей.
Кроме того, тимлид Аркадий постоянно придумывал для разработчиков «фишки»: шутки, голосовалки, смайлики, наборы мемов, обучение — все это поднимало настрой и объединяло.
Наращивание ресурсов
Возникли сложности при поиске в открытом рынке — не удавалось быстро подобрать новых разработчиков и других специалистов с опытом в используемых технологиях. Стало понятно, что проще обучить с нуля начинающих мидлов или джунов, чем затягивать подбор персонала. Также мы начали искать людей по всей России и собрали распределённую команду из разных городов страны.
Помимо усиления штатной команды мы приняли решение временно (на 4–6 месяцев) привлечь уже сработанную команду субподрядчиков (5 разработчиков, 2 аналитика и тестировщик). Конечно, подключение дополнительных людей занимало время, однако спустя месяц-два усилия окупались. Таким образом, размер команды временно увеличился с 12 до 21 человека — беспрецедентный объем для Scrum.
Отдельная ноша упала на плечи менеджера системы и руководителя разработки, так как команда существенно выросла и ей требовалось управлять, обучать новых членов команды, а также объединять коллектив, налаживать командный дух и взаимодействие.
Порядок в документации и качественные единообразные требования
С первых дней мы вели технический проект в Confluence, в том числе создали страничку для аналитиков с описанием библиотеки компонентов, доступной для использования в Системе.
Учиться можно и в процессе
Несколько человек, работавших с момента создания legacy-системы (с 2012–2013 гг.), в том числе руководитель разработки, один за другим, по разным причинам, покинули команду в активной стадии нового проекта. Так, вынужденно, мы остались не только без значимой части команды разработки, но и без накопленных знаний, касающихся принципов и особенностей исторического приложения (до создания нашего техпроекта вся техническая документация велась в разрозненных Word-документах). Значительная часть прежнего функционала вовсе не была описана в документации, так что время от времени приходилось разводить руками и создавать все заново.
При этом из внутренней команды выделился талантливый разработчик Аркадий, который возглавил программистов.
По стечению обстоятельств в начале проекта многие из разработчиков не имели достаточного опыта в разработке Web-приложений — не такая большая проблема сама по себе, а вот в сочетании с поставленными сроками — серьезная помеха. Изучать новое — интересно и вдохновляюще, но на определенных этапах различий оказывалось так много, что целые дни уходили на разбор довольно простых операций. В условиях отсутствия наставников, знакомых с предметной областью, мы рассчитывали лишь на себя. Так, например, некоторые архитектурные решения, выглядевшие подходящими в момент начала проекта, становились источником массы проблем впоследствии с трудоемким исправлением. В итоге рефакторинг отдельных элементов перенесли в бэклог последующих доработок.
Нюансы в процессе реализации
Первоначально задачу по переносу системы в Web-приложение мы видели просто адаптацией всех существующих функций, интерфейсов, логики «один в один», то есть предполагался порт со старого стека технологий на новый. Но что такое — перенос «один в один» десятков тысяч строк legacy-кода, наполненного «костылями» для закрытия технических проблем старого фреймворка, недокументированной логикой, не покрытого тестами и/или комментариями, раскиданного между клиентским кодом и хранимыми в базе данных процедурами? Так что оказалось, что в нашем случае не все новое — хорошо забытое старое.
В процессе работы владелец системы внес концептуальные изменения в логику — от блокировок возможностей пользователей до изменения архитектуры. Оптимизированная бизнес-логика значительно усложнила процесс миграции данных — их надо было не просто перенести, но и в процессе адаптировать под новые вводные организации механизма. Важно было также учесть разносторонность данных: при миграции необходимо было объединить несколько записей в одну таким образом, чтобы исключить интерпретации, возникавшие в разных бизнес-подразделениях. Да и масштаб добавлял сложности — например, объем только одной из самых крупных таблиц составлял свыше 37 миллионов записей, а таких таблиц были десятки.
Что касается стека, то мы остановились на .Net Core 6.0, Angular 13, Postgres Pro, потому что это «родной» для нас стек.
Пользователь — тоже часть команды
Для нас было важно создать не только функциональный и современный продукт, но и максимально удобный — хотелось, чтобы приложение пользователям понравилось. Legacy-система этим похвастаться не могла — она казалась квестом, в первую очередь для видящих ее впервые: много логики, сложный интерфейс, громоздкие ленты мониторингов и связей. Это и стало причиной концептуальных изменений. Владелец продукта настроил еженедельный обмен обратной связью с филиалами, а работу с пользователями выделили в отдельный блок внутри нашей разработки. На формирование удобного интерфейса был выделен дизайнер.
Дополнительно к еженедельным online-встречам мы создали постоянный канал общения с пользователями на корпоративном портале, где голосованием выбирали все — от шрифтов и цветов до необходимых функций.
Ближе к дате внедрения из-за изменения пользовательских путей в новой системе понадобился еще один этап: помимо обычной инструкции был подготовлен обучающий курс, в котором виртуальные герои познакомили пользователей с «Н2.0» и правилами работы в ней. К тиражированию дизайнер разработал удобную инструкцию.
Отличный старт
Качественное внедрение Системы невозможно без готовности пользователей в ней работать. Для этого наш Владелец продукта выстроил сложный график внедрения (с учетом технических ограничений по объему данных для миграции), при котором пользователи получали тестовый доступ к Системе на реальных данных, имея возможность некоторое время обучаться на реальных сделках, осуществлять параллельную работу в старой и новой Системах, сравнивая результаты для понимания своих ошибок.
Первый запуск новой системы прошел на группе из четырех филиалов, миграция данных проводилась только для них, точечно. Далее каждые выходные на протяжении 4-х недель (разбили миграцию на 8 выходных дня в связи с техническими ограничениями по объему данных для миграции) у нас происходила «двойная» миграция: одна часть филиалов получали возможность работать в Системе в тестовом режиме, вторая часть переходила уже на опытно-промышленную эксплуатацию.
Получилось, что в течение этого месяца команда работала в режиме »24/7», когда в выходные шла миграция за миграцией, а в будние дни в оперативном режиме решались возникающие у пользователей проблемы и дочищался функционал.
Также, помимо обучающего курса для пользователей, о котором я писала ранее, Владелец продукта проводил «мастер-классы» в формате видеоконференций, на которых рассказывал про концепцию осуществления функционала на новой Системе.
В заключении, мы можем смело заявить, что у нас получилось разработать Систему, которую по-настоящему приняли и полюбили пользователи. Первоначальный «базовый» функционал получилось реализовать точно в срок, система запустилась в апреле 2022 (от первоначальных сроков, которые мы планировали 9 месяцев назад, мы отклонились всего на 1 неделю). На текущий момент «Н2.0» — современная и удобная система для ведения мониторингов по клиентам и отчетности.
Наш результат:
В сжатые сроки бесшовно заменена историческая система (толстый клиент) на современное импортозамещенное решение: в пятницу сотрудники сопровождения заканчивали работать в старой системе, в понедельник полноценно продолжали работать с теми же данными уже в новой.
Проведена миграция накопленных данных (более 30 миллионов мониторингов) из MS SQL в PostgreSQL.
В процессе принципиально изменен подход к мониторингу (оптимизирована бизнес-логика, что значительно усложнило процесс миграции данных — данные были перенесены не просто из БД в БД, но и адаптированы «на лету» под новую логику организации механизма мониторинга).
Благодаря проекту у нас сформировалась сильная, сплочённая и мотивированная IT-команда.
Создана быстродействующая, надежная с интуитивно понятным интерфейсом современная система, готовая для последующего развития и интеграций с иными IT-системами Банка.
