#финтех#системный анализ#bi

Сервис синтетических тестовых данных для крупного банка

[ клиент ] о заказчике

Крупный банк с большим числом команд, которые разрабатывают и тестируют витрины данных. Использовать реальные персональные данные клиентов на тестовых стендах банк не может.

[ 01 ] контекст

О проекте

Заказчик развивает внутренний сервис, через который команды получают синтетические данные для тестирования витрин. Наша зона ответственности — системный анализ сервиса: требования к новым источникам и стендам, постановка задач разработке, критерии приёмки и работа с пользователями.

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

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

[ 02 ] задачи

Задачи проекта

  1. Подключать новые базы данных и тестовые стенды, на которые сервис заливает синтетические данные

  2. Превращать крупные фичи в задачи для фронтенда и бэкенда с критериями приёмки для тестирования

  3. Планировать релизы так, чтобы зависимости от смежных команд не срывали сроки

  4. Упрощать пользовательские сценарии, на которых новые пользователи бросают сервис

[ 03 ] этапы

Как мы это сделали

  1. 01

    Требования к новым стендам

    Для каждой новой базы данных собираем требования к заливке: какие типы данных она поддерживает и какие у неё ограничения

  2. 02

    Постановка задач

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

  3. 03

    Груминг на два-три релиза вперёд

    Вместе с техлидами и руководителем проекта заранее раскладываем фичи по релизам и разбираем риски, в том числе зависимости от смежных команд

  4. 04

    Поддержка Iceberg

    Добавили работу с таблицами Apache Iceberg в озере данных. Пользователи ждали её к концу года, а вывели в сентябре

  5. 05

    Работа с пользователями

    По данным кликстрима находим тех, кто зашёл в сервис, но не создал ни одной задачи. Каждую неделю встречаемся с ними, проводим демо и по их отзывам упрощаем сценарии

[ 04 ] команда и стек

Кто и на чём

экспертиза

Команда продукта

Руководитель продуктаТимлид и руководитель проектаСистемный аналитикБэкенд-разработчикиФронтенд-разработчикТестировщики
технологии

Стек

StarRocksOzoneApache IcebergSwaggerConfluence
процессы

Как работаем

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

[ 05 ] результаты

Что получил клиент

3 мес.На столько раньше плана вышла поддержка таблиц Iceberg: в сентябре вместо конца года
2–3 релизаВперёд прорабатывается бэклог на груминге с техлидами
еженедельноВстречи с новыми пользователями, которые зашли в сервис, но не начали работу
2 годаНа столько вперёд расписан план развития сервиса
Персональные данные остаются в защищённом контуреТестовые стенды получают синтетику вместо реальных данных клиентов

Дальше сервис свяжут с командой, которая генерирует тест-кейсы для витрин: одна команда готовит данные, другая — проверки. План работ расписан до 2028 года.

[ заявка ] свяжемся в рабочее время

Похожаязадача?

Расскажите о ней — подберём команду и предложим решение.

Этот сайт использует сервисы сбора технических данных посетителей (данные об IP-адресе, местоположении и др.) для обеспечения работоспособности и улучшения качества обслуживания. Продолжая использовать наш сайт, вы автоматически соглашаетесь с использованием данных технологий.