Привет! Меня зовут Екатерина Бадалян, и я – руководитель центра компетенции разработки блока ИТ-развития корпоративного бизнеса в «РСХБ-Интех» (IT-компания АО «Россельхозбанк»). Моя команда в течение девяти месяцев работала над новым решением для мониторинга банковских сделок в РСХБ. Мы создали многие блоки с нуля и фактически полностью пересмотрели и переработали продукт, сформировав новую функциональную user-friendly систему. Ей уже успешно пользуется бизнес-подразделение Россельхозбанка. О том, как мы в столь сжатые сроки выстроили работу внутри команды и с заказчиком, с какими трудностями столкнулись,  как внедрили современные решения и доработали то, что осталось от исторического процесса автоматизации, а главное – безболезненно перенесли на новый стек свыше 37 миллионов мониторингов, я расскажу в этой статье.

Замысел

Наш клиент использовал для автоматизации процессов мониторинга условий кредитных сделок корпоративных заемщиков legacy-систему, написанную в 2012 году на толстом клиенте WinForms в сочетании с устаревшими библиотеками DevExpress (на двухзвенной архитектуре). Причем работала эта система в более чем 60 филиалах банка, которые не только отслеживали условия кредитования, но и формировали в ней отчеты разного уровня (некоторые из них были очень массивными). Из-за использования устаревшей технологической платформы и ежедневно растущего объема данных быстродействие решения постоянно снижалось и кратно возрастало количество технических сбоев. Оперативность отклика в период пиковых нагрузок замедлилась, возникали сложности с внесением данных. Мы пришли к точке, когда качественно развивать и улучшать систему стало уже невозможно, а поддерживать и сопровождать текущее решение – крайне сложно.

Тогда мы с менеджером проекта подготовили для бизнес-заказчика предложение по реализации совершенно нового и современного проекта с конкретным планом действий.

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

Когда мы подробно расписали и предварительно оценили скоуп задач, ожидаемый срок реализации проекта превысил год. Однако такой таймлайн заказчику не подошел – подготовку ежегодных отчетов было критично начать уже в новой системе: таким образом, нам потребовалось сократить срок на ¼ - до 9 месяцев. Приняли решение остановить все доработки старой системы, кроме критических, и бросить силы в новую разработку.

Чтобы весь процесс прошел успешно, мы применили следующие фишки планирования в сжатые сроки:

• Карта продукта (User Story Mapping): мы разделили предполагаемую доработку на релизы, а также расставили приоритеты между доработками внутри каждого намеченного релиза от жизненно необходимых функций до удобств и пожеланий на будущее развитие (мы рисовали «скелет» полностью, постоянно корректировали, тщательно отделяли «критичное» от просто «нужного»).

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

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

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

• Распределение ключевых исполнителей между задачами (мы понимали, кто сосредоточится на миграции, а кто на функциях для безопасности, на основных интерфейсах и какие вакансии нужно заполнить в первую очередь исходя из общего таймлайна проекта).

  Бэклоги и доски мы настраивали полностью под себя (как нам понятно и удобно):

Основная сложность проекта заключалась в ограниченных сроках для разработки без реальной возможности их переноса. У нас было 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-системами Банка.