Как решал кейс с недочётами с прошлого проекта?

Как решал кейс с недочётами с прошлого проекта

Это отличный вопрос на собеседовании, потому что показывает, как BA учится на ошибках и растёт профессионально. Я расскажу про конкретный кейс из своего опыта и как я его анализировал.

Описание проблемы

На одном из моих проектов мы разрабатывали платформу для продажи курсов. В спецификации было требование: "Пользователь может видеть список своих заказов в личном кабинете".

Что случилось:

• Разработчик реализовал список заказов с простой пагинацией (10 заказов на странице)
• При тестировании нашли проблему: у пользователя было 10,000 заказов
• Список открывался 50+ секунд
• Интерфейс был полностью неюзабилен

Когда разработчик спросил, почему так, он прав: "В требовании не было указано, как работать с большим объёмом данных. Я реализовал наиболее простой способ".

Анализ: почему это случилось

После retrospective я выявил цепочку ошибок:

1. Неполные требования на входе

• Я не описал performance constraints (max время загрузки, max объём данных)
• Не упомянул, что у платформы будут power users с 1000+ заказами
• Не указал критерии приёмки для UI: "страница должна открываться < 2 секунды"

2. Отсутствие граничных случаев

• Требование было написано для "нормального" сценария (10-100 заказов)
• Что если заказов будет 1000? 10000? Никто не подумал
• Не обсуждали с разработчиком, как он планирует эту функцию реализовать

3. Слабое тестирование

• Тестировщик тестировал на 5-10 заказах (тестовые данные были маленькие)
• Никто не создал load-тест с реалистичным объёмом данных
• На предпериоде проблема не выявилась

4. Недостаточная коммуникация

• Я не провёл техническое планирование (Technical Planning)
• Разработчику и архитектору не дал контекста: скольких пользователей мы планируем, какой объём данных

Как я решил эту проблему

Шаг 1: Срочно пофиксить (Short-term)

Сделали быстрый workaround:

• Добавили бесконечный скролл вместо пагинации
• Ограничили загрузку 50 заказами за раз
• Добавили фильтр "Последние 30 дней" по умолчанию

Время загрузки сократилось с 50 сек до 2 сек. Не идеально, но более-менее приемлемо для MVP.

Шаг 2: Переписать требование (Medium-term)

Переделал спецификацию:

### Требование 2.1: Список заказов пользователя

#### Описание бизнеса
Пользователь должен видеть историю своих заказов и быстро найти нужный заказ
чтобы проверить статус доставки, отзыв или вернуть товар.

#### Acceptance Criteria
- [x] Отображается список заказов текущего пользователя
- [x] По умолчанию показываются последние 30 дней (для экономии памяти)
- [x] Возможен фильтр по датам: от/до
- [x] Пагинация по 20 заказов или бесконечный скролл
- [x] Сортировка по дате (новые сверху)
- [x] Поиск по номеру заказа
- [x] На экране < 2 сек при 10,000 заказов

#### Граничные случаи
- Что если у пользователя 0 заказов? → Пустой экран с предложением сделать заказ
- Что если 1,000,000 заказов? → Фильтр по датам обязателен
- Что если пользователь ищет заказ, которого нет? → "Заказ не найден"

#### Performance requirements
- Время загрузки первых 20 заказов: < 500ms
- База может содержать до 1M заказов на пользователя
- На медленном 4G интернете должно работать нормально

#### Дополнительная информация
По данным аналитики, активные пользователи делают 5-10 заказов в месяц.
Некоторые корпоративные пользователи могут делать 100+ заказов в месяц.
Система должна корректно масштабироваться.

Шаг 3: Провести техническое планирование (Technical Planning)

Созвал встречу: я (BA) + разработчик + архитектор.

Обсудили:

• Какой способ реализации лучше: индексирование в БД, кеширование, paginate?
• Какие индексы нужны в БД для быстрого поиска?
• Нужна ли очередь данных (queue) для асинхронной загрузки?
• Как тестировать performance?

Архитектор предложил добавить индекс на (user_id, created_at) в таблице заказов. Это решило проблему.

Шаг 4: Улучшить процесс тестирования

Добавили требование для QA: обязательный load-test перед выпуском любой фичи со списком/таблицей.

Формула: если в фичу входит список/таблица → нужно тестировать с 10x от ожидаемого объёма данных.

Например:

• Ожидаем 100 пользователей? Тестируем с 1000
• Ожидаем 1000 заказов? Тестируем с 10,000

Это выявило бы проблему ещё до релиза.

Что я изменил в своём процессе

1. Всегда писать "as-is" сценарии

Не просто описываю требование, но и спрашиваю:

• Сколько данных может быть в системе через год? Через 5 лет?
• Каковы performance constraints? (время загрузки, размер файла, etc.)
• Какие технические ограничения нужно учитывать?

2. На техническом планировании обсуждаю масштабируемость

Чек-лист для каждого большого требования:

• Как это будет работать, если данных в 10x больше?
• Есть ли индексы в БД?
• Нужно ли кеширование?
• Как мы будем это тестировать?

3. Улучшил тестовые данные

Теперь в staging среде:

• Реалистичный объём данных (не 10, а 10,000 тестовых записей)
• Разные сценарии: 10 заказов, 1000, 100,000
• Load-тесты перед releasом

4. Добавил чек-лист для граничных случаев

Для каждого требования теперь проверяю:

• Что если данных 0?
• Что если данных очень много (1M)?
• Что если данные некорректные (NULL, пустые строки)?
• Как это работает на мобильном и медленном интернете?

Учёт на других проектах

Этот опыт помог мне на следующих проектах:

Проект 2: Аналитический дашборд

• Сразу написал performance requirements
• Обговорил с BI специалистом, какие SQL queries оптимальны
• Добавил кеширование результатов
• Результат: дашборд открывается за 300ms даже с 1M строк данных

Проект 3: Интеграция с внешним API

• Сразу обговорил rate limits: сколько запросов в минуту?
• Добавил retry logic и exponential backoff в требования
• Обсудил с разработчиком, нужны ли webhook или polling
• Результат: интеграция работает стабильно, нет потери данных

Вывод

Лучший BA — это не тот, кто не делает ошибок, а тот, кто:

1. Признаёт ошибку
2. Разбирает, почему она случилась
3. Меняет процесс, чтобы это не повторилось
4. Делится уроком с командой
5. На новых проектах применяет эти уроки

В этом кейсе я научился, что performance и масштабируемость — это не "nice to have", это часть нормальных требований. И если я этого не написал — виноват я, не разработчик.