---
title: Сервис синтетических тестовых данных для крупного банка
url: https://evapps.ru/case/servis-sinteticheskih-testovyh-dannyh/
description: Системный анализ сервиса, который заменяет персональные данные синтетикой и заливает её на тестовые стенды: новые базы данных, Iceberg, работа с пользователями.
industry:
  - Финтех
services:
  - Системный анализ
  - Аутстаффинг аналитиков
technologies:
  - BI
solutions: []
---

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

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

## О проекте

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

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

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

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

1. Подключать новые базы данных и тестовые стенды, на которые сервис заливает синтетические данные
2. Превращать крупные фичи в задачи для фронтенда и бэкенда с критериями приёмки для тестирования
3. Планировать релизы так, чтобы зависимости от смежных команд не срывали сроки
4. Упрощать пользовательские сценарии, на которых новые пользователи бросают сервис

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

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

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

**3. Груминг на два-три релиза вперёд.** Вместе с техлидами и руководителем проекта заранее раскладываем фичи по релизам и разбираем риски, в том числе зависимости от смежных команд.

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

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

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

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

## Стек

StarRocks, Ozone, Apache Iceberg, Swagger, Confluence

## Как работаем

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

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

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

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