Приведи пример задачи, решенной нестандартным способом

Нестандартное решение: система рекомендаций через бизнес-правила вместо ML

Я расскажу о проекте, где "правильное" техническое решение (ML) оказалось неправильным с точки зрения бизнеса.

Ситуация: E-commerce платформа

Контекст: Стартап с B2C маркетплейсом электроники

Задача: Реализовать систему рекомендаций товаров пользователям

История проблемы:

Теч-лид предложил классическое решение:

• Machine Learning model (Collaborative Filtering)
• Data Science команда (1-2 человека)
• 3-4 месяца разработки
• Дорогая инфраструктура (GPU сервера)
• Результат: Рекомендации станут лучше на 15-20%

Проблемы:

• Бюджет стартапа ограничен
• Нет data science команды
• 3 месяца ожидания = конкуренты могут перехватить
• Нужно срочно улучшить конверсию

Как я анализировал (BA подход)

Шаг 1: Понял реальную проблему

Не "рекомендации плохие", а "пользователи не видят релевантные товары".

Анализ данных:

• 60% пользователей смотрят только на первой странице
• Средний чек товаров A и B похож, но покупатели A редко видят B
• Категории разнообразны, но связаны логически

Шаг 2: Спросил о бизнес-метриках

• Главная метрика: конверсия (покупка после просмотра товара)
• Текущая конверсия: 2%
• Таргет через 2 месяца: 3% (+50% прирост дохода)

ML модель даст +15-20% улучшение к рекомендациям, но неясно как это повлияет на конверсию.

Мое нестандартное решение

Вместо ML я предложил: Правило-ориентированную систему (Rules Engine)

Если пользователь смотрит товар из категории A,
покажи также товары из категорий B и C (связанные),
сортируй по популярности и цене.

Примеры правил:
- Смотрит ноутбук → покажи сумки для ноутбуков, аксессуары
- Смотрит монитор → покажи кабели HDMI, подставки
- Смотрит наушники → покажи кейсы, кабели для наушников

Как это реализовалось

Шаг 1: Собрал данные о связях товаров (1 день)

• Проанализировал что продается вместе
• Спросил продавцов что рекомендовать
• Посмотрел на конкурентов

Результат:

Унифицированная матрица связей товаров:

Ноутбук → {
  "must_have": [сумки, зарядки],
  "popular": [мышь, коврик],
  "premium": [охлаждающая подставка]
}

Монитор → {
  "must_have": [кабели HDMI],
  "popular": [переходники, подставки],
  "premium": [крепление на стену]
}

Шаг 2: Реализовал с простым запросом (2 дня)

Не нужен ML, нужна простая логика:

-- Рекомендации для товара ID 123
SELECT 
  recommended_product_id,
  score * popularity * (1 / price_diff) as rank
FROM product_relationships
WHERE source_product_id = 123
ORDER BY rank DESC
LIMIT 5

Шаг 3: Интегрировал в UI (1 день)

• На странице товара: блок "Часто покупают вместе"
• На главной: "Дополнительные товары"
• На корзине: "Завершите комплект"

Результаты

Бюджет и время:

• ML solution: $50K + 3 месяца
• Мое решение: $5K + 2 недели
• Экономия: $45K и 11 недель

Метрики:

• Конверсия выросла с 2% до 3.2% (+60%)
• AOV (средний чек) вырос на 25%
• Revenue прирост: +55%

Почему это сработало:

• Просто и понятно (легко поддерживать)
• Быстро (вышли на рынок раньше конкурентов)
• Дешево (низкий бюджет)
• Работает (реальные результаты)

Что было ключевого в моем подходе (BA)

1. Спросил "почему?" вместо "как?"

• Не согласился с техническим решением
• Понял реальную проблему

2. Анализировал бизнес-метрики

• Не только техническое качество
• А реальный impact на доход

3. Рассмотрел альтернативы

• ML - дорого
• Rules - дешево
• А может быть гибридный подход?

4. Обосновал с цифрами

• Техлид: "ML даст 15-20% улучшение"
• Я: "А может 1 неделю попробуем правила и посмотрим результат?"

Позже, когда выросли

6 месяцев спустя:

• Стартап получил финансирование
• Revenue вырос
• Теперь бюджет есть на ML

Я предложил гибридный подход:

• Основу: Rules-based система (работает)
• На top: ML модель (для персонализации)
• Результат: лучшее из обоих миров

Lessons Learned (что я делал правильно)

1. Не слепо следил за трендами

• ML модно, но не всегда нужно
• Простое решение часто лучше

2. Разбирался в бизнесе

• Не просто реализовать требование
• А решить бизнес-проблему
• Это разные вещи

3. Воспринимал feedback

• Техлид: "Это не真正 рекомендации"
• Я: "Верно, но они работают и дешевые"

4. Мерил результаты

• Не по технической метрике (RMSE, точность ML модели)
• А по бизнес-метрике (конверсия, доход)

Когда МОЙ подход был бы неправильным

Если бы:

• Нужна была высокая точность (медицина, финансы)
• Нужно было масштабироваться на миллионы пользователей
• Требования менялись каждый день

Тогда ML был бы оправдан.

Но в контексте стартапа с дефицитом бюджета - нестандартное решение было идеальным.

Вывод

Хороший BA не слепо следит за requirements или трендами - он думает как владелец продукта.

Мой процесс:

1. Понимаю бизнес-контекст
2. Спрашиваю "а зачем нам это?"
3. Предлагаю несколько вариантов (дорого + качество vs дешево + быстро)
4. Выбираю вариант которой максимизирует ROI
5. Мерю реальные метрики

Эта история - про то, что лучшее техническое решение часто не является лучшим бизнес-решением. И BA - это мост между этими двумя мирами.