Базы данных. Как выбрать идеальное решение? Полный гид по SQL, NoSQL и не только

⏳ 11 мин | 🟤🟤⚪️

Перейти | BA|SA

Ликбез по ЭДО: почему это не просто техническое подключение, а пересмотр процессов, которыми нужно заниматься заранее

⏳ 7 мин | 🟤⚪️⚪️

Перейти | BA|SA

Apache Kafka в интеграционных задачах КРУПНОГО бизнеса: какие плюсы и слабые стороны у такого подхода?

⏳ 9 мин | 🟤⚪️⚪️

Перейти | BA|SA

Разработка документации для облачных сервисов, или как приручить дракона

⏳ 9 мин | 🟤⚪️⚪️

Перейти | BA|SA

Зачем и как писать ТЗ

⏳ 13 мин | 🟤⚪️⚪️

Перейти | BA|SA

Методологии менеджмента качества в бизнес-анализе: процессный подход, LEAN, теория ограничения систем. Часть 1

⏳ 9 мин | 🟤🟤⚪️

Перейти | BA|SA

🔥 Общий сбор системных аналитиков на митапе ЮMoney

Приходите на митап Код аналитика — он пройдёт 10 июля в 19:00 (по мск) офлайн в Санкт-Петербурге и онлайн из любой точки мира. Вот о чём поговорим со спикерами из ЮMoney и приглашённым экспертом:

🟣Свой чат лучше: опыт миграции с внешнего решения. Как мы ушли от партнёрской зависимости и сами сделали чат.

🟣Проектируем сервисы с умом: DDD + Event Storming. Как Event Storming помогает найти границы, а DDD — сфокусироваться на бизнесе.

🟣Продукт в архитектуре систем. Почему один и тот же продукт в BI, бухгалтерии и проектном офисе — это три разных сущности, и как с этим жить.

✅ Участие бесплатное, но нужно зарегистрироваться на сайте.

Салют! Сегодня предлагаю вам Тестовое задание на позицию Middle System Analyst

#тестовоезадание #собеседование

📝 Условие задачи:

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

🤯 Проблема:

При отмене заказа после оплаты деньги возвращаются не мгновенно, а в течение 3–5 дней или более. Это вызывает недовольство клиентов, и поддержка получает много жалоб.

Задача:
1. Проанализируйте процесс возврата денег при отмене заказа.
2. Предложите улучшения, которые сократят время возврата или улучшат коммуникацию с клиентом.
3. Опишите возможные риски и ограничения вашего решения.

При желании делитесь своими ответами или советами в комментариях 👇

Источник: @ba_and_sa

_________________

✅ Мой ответ:

1. Анализ текущего процесса возврата денег

Текущий процесс, вероятно, выглядит так:
1. Клиент отменяет заказ → система фиксирует отмену.
2. Запрос на возврат попадает в финансовый отдел или платежный шлюз.
3. Вручную или полуавтоматически проверяются данные платежа.
4. Инициируется возврат через банк или платежную систему (3–5 дней из-за банковских регламентов и проверок).
5. Клиент не получает уведомлений о статусе возврата, пока деньги не поступят.

Проблемные точки:
- Ручные или долгие проверки.
- Отсутствие прозрачности для клиента.
- Зависимость от скорости работы банка/платежной системы.


2. Предлагаемые улучшения

a) Автоматизация возврата для ускорения процесса
- Интеграция с платежным шлюзом (например, Stripe, PayPal, Сбербанк API) для автоматического возврата при отмене (если заказ еще не передан в доставку).
- Настройка правил:
- Если оплата прошла менее N часов назад → мгновенный возврат (без проверки).
- Если прошло больше времени → автоматическая проверка и уведомление клиента о сроке.

b) Улучшение коммуникации с клиентом
- Ввести статусы возврата:
- «Возврат запрошен» → «Обрабатывается» → «Деньги отправлены» (с примерным сроком).
- Отправлять SMS/email-уведомления на каждом этапе.
- Добавить в ЛК клиента раздел с историей возвратов.

c) Альтернативные решения для лояльности
- Предлагать бонусы (скидку на следующий заказ) вместо возврата, если клиент согласен.
- Возврат на внутренний кошелек (мгновенно) с возможностью вывода или использования для новых покупок.

3. Риски и ограничения

Технические:
- Не все платежные системы поддерживают мгновенные возвраты (например, банковские переводы).
- Ошибки автоматизации (двойные возвраты, технические сбои) → нужен мониторинг и ручное вмешательство в исключительных случаях.

Бизнес-риски:
- Мошенничество: клиенты могут злоупотреблять быстрыми возвратами (например, отменять после получения товара). Решение:
- Лимиты на частые отмены.
- Задержка возврата для подозрительных операций.
- Дополнительные затраты на интеграцию с платежными системами.

Юридические:
- Нужно проверить законодательство (например, в некоторых странах возврат должен быть не позднее N дней).



‼️ Итоговое решение

1. Автоматизировать возвраты для свежих платежей через API платежного шлюза.
2. Улучшить информирование клиентов о статусах.
3. Ввести fallback-механизмы: если автоматический возврат невозможен – уведомлять клиента и ускорять ручную обработку.
4. Мониторить аномалии (частые отмены, ошибки интеграции).

Метрики успеха:
- Уменьшение времени возврата (с 5 дней до 1–2 для 80% случаев).
- Снижение количества жалоб в поддержку на 50%.
- Увеличение NPS (индекс лояльности) благодаря прозрачности процесса.

«Да мы и без проектной документации справимся!»

⏳ 4 мин | 🟤⚪️⚪️

Перейти | BA|SA

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

Ведь перед тем как предлагать решения, важно выяснить детали текущего процесса и ограничения.
Вот некоторые вопросы, которые стоит задать заказчику:

Если у вас свое мнение, или я что-то упустила, делитесь в комментариях 👇

1️⃣ Про текущий процесс возврата

- «Как именно сейчас работает процесс отмены заказа и возврата денег?»
- «Есть ли ручные этапы (например, проверка финансовым отделом)?»
- «Какие платежные системы используются (эквайринг, PayPal, СБП и т.д.)?»
- «Поддерживают ли они API для автоматических возвратов?»
- «Какие статусы заказа и возврата отображаются клиенту в ЛК/уведомлениях?»

2️⃣ Про причины задержки

- «Почему возврат занимает 3–5 дней?»
- «Может ли занять еще больше, или это максимум?»
- «Это ограничение банка/платежной системы или внутренние процессы компании?»
- «Есть ли случаи, когда возврат проходит быстрее (например, для определенных способов оплаты)?»

3️⃣ Про интеграции и данные

- «Есть ли интеграция между системой управления заказами и платежным шлюзом?»
- «Если да, какие методы API доступны (например, refund, `reverse`)?»
- Какие данные проверяются перед возвратом (номер заказа, сумма, сроки оплаты и т.д.)?

4️⃣ Про коммуникацию с клиентом

- «Какие каналы уведомлений используются (email, SMS, push)?»
- «Получает ли клиент информацию о примерных сроках возврата при отмене заказа?»

5️⃣ Про риски и ограничения

- «Были ли случаи мошенничества с возвратами?»
- «Как их обрабатывают сейчас?»
- «Есть ли юридические требования к срокам возврата (например, по закону о защите прав потребителей)?»

6️⃣ Про метрики и улучшения

- «Какие метрики по возвратам сейчас отслеживаются (среднее время, % жалоб и т.д.)?»
- «Какие улучшения уже пробовали внедрять? Почему они не сработали?»

7️⃣ Про бюджет и сроки

- «Есть ли бюджет на доработки (например, интеграция с новым платежным шлюзом)?»
- «Какие сроки ожидаются для внедрения улучшений?»


————————————

Зачем это нужно? И зачем вообще задавать вопросы?

Эти вопросы помогут:
1. Выявить корень проблемы (технические ограничения vs. процессные).
2. Оценить возможности автоматизации (например, если платежка не поддерживает мгновенные возвраты, решение будет другим).
3. Предложить реалистичное решение с учетом ресурсов компании.

Пример:
Если окажется, что платежный шлюз не поддерживает автоматические возвраты, решением может быть:
- Переход на другой шлюз (например, Stripe или СБП).
- Введение "кредитов" на счет клиента (мгновенно) с возможностью вывода.

Важно: Задавайте вопросы последовательно — от общего процесса к деталям. Это покажет ваш системный подход.

Удачи всем с решением своих ТЗ 😉

Источник: @ba_and_sa