# Бриф для кандидата

Вы откликнулись на нашу вакансию бизнес-аналитика. Спасибо. Прежде чем звать на встречу, я хочу описать, что у нас есть, где болит и что мы хотим получить, а в конце попрошу вас об одной вещи. Так мы оба сэкономим время.

Продукт и отрасль я специально описываю обобщённо. На встрече расскажем всё.

## 1. Кто мы

Нас двое, и мы же вся команда.

Я отвечаю за продукт: что мы делаем, куда идём, что внедрять следующим. Я не технический человек, смотрю на систему глазами клиента и поставщика и думаю в терминах «как должно быть, чтобы стало лучше».

Партнёр отвечает за всё техническое, от архитектуры до инфраструктуры, и пишет код. Систему строит по DDD.

Продукт работает, у него есть платящие клиенты и прибыль. Но он вырос быстрее, чем мы успели его описать. Знания о том, как всё устроено, сейчас лежат в трёх местах: у меня в голове, у партнёра в коде и в нашей переписке. Единого описания, под которым подписались бы мы оба, нет.

## 2. Как устроен бизнес

Если совсем коротко, мы посредник. Клиент через нас получает определённый товар. Мы в этот же момент покупаем его у одного из многих поставщиков, отдаём клиенту и зарабатываем на разнице. Всё автоматически, руками никто сделки не проводит. По сути это арбитраж в реальном времени.

Главная сложность в том, что почти всё, что нужно знать для решения, мы узнаём уже после того, как решение принято. Сколько запросов придёт от клиента по данной цене, неизвестно. Есть ли у поставщика товар прямо сейчас, неизвестно. Сколько реально возьмёт поставщик, узнаём в момент покупки. Сработает ли то, что купили, узнаём после того, как отдали клиенту. И так постоянно, на потоке.

Дальше по блокам. Они нужны не для красоты, а чтобы вам было к чему привязать вопросы.

### Блок 1. Клиенты

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

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

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

И ещё. Клиент тоже оценивает нас. У него есть свои рейтинги и правила блокировки, частично скрытые от нас, и построены они на нашей же статистике доставки и отказов.

### Блок 2. Каталоги и соответствия

Клиенты и поставщики торгуют не «товаром вообще», а конкретными позициями, и у каждого свой каталог. Позиция это связка из двух параметров, причём не любая связка существует: для каждого значения первого параметра свой набор вторых. У каждой группы клиентов свой список позиций и свои сокращения для них. У каждого поставщика свои связки того же самого, и тоже свои названия.

Таблицу соответствий «то, что у клиента называется так, у поставщика называется этак» ведём мы. Ошиблись в ней, и мы либо покупаем не то, либо не находим то, что на самом деле есть.

### Блок 3. Поставщики

Поставщиков много. У каждого свои цены, своё качество, своя доступность в конкретный момент, свой способ подключения. На одну позицию у одного поставщика может быть несколько цен одновременно.

Цена, которую поставщик показывает, и цена, по которой он в итоге продаёт, это разные вещи. Запросили цену, получили ответ, а купить по ней не получилось, это нормальная ситуация. Мы указываем потолок, но это не значит, что купим по одной и той же цене, продажа пройдёт по любой цене ниже потолка. Часть условий вообще не видна ни в каких запросах. Глобальные скидки, договорённости по отдельным направлениям, всё это живёт в переписке с поставщиком.

И всё это меняется очень быстро. Направление, которое сейчас продаётся по хорошей цене и с хорошим результатом, через час выглядит точно так же, но за той же ценой уже стоит другой продавец, и результат другой. При этом дорого не значит надёжно, высокая цена покупки не повышает вероятность успеха.

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

### Блок 4. Как исполняется запрос

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

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

### Блок 5. Что происходит после

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

Неприятных случаев хватает. Результат пришёл после того, как мы уже зафиксировали неудачу. Клиент отказался, а поставщик деньги уже взял. Результат есть, а клиент за него не заплатил. Что считать успехом, для кого и в какой момент, у нас сегодня определено, скажем так, неформально.

### Блок 6. Деньги

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

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

### Блок 7. Статистика

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

Что именно записывать, какие показатели из этого считать, какие данные нельзя смешивать между собой и какое решение от какого показателя зависит, сегодня описано только в коде.

### Блок 8. Цены и ручное управление

Цены для клиентов и потолки закупки у поставщиков меняются. Часть решений принимает система, часть принимаем мы, по опыту и по ощущению. Есть исключения, которые мы обрабатываем руками: отключить поставщика, поднять цену клиенту, разрешить заведомо убыточную закупку, чтобы что-то проверить.

Эти ручные правила нигде не записаны. Их-то мы и хотим превратить в формальные.

## 3. Куда мы хотим прийти

Партнёр сформулировал цели списком, я оставляю его как есть. Мы хотим, чтобы система:

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

По одному из пунктов мы между собой так и не договорились: что вообще значит «контролируемый риск». Подозреваю, таких мест больше.

## 4. Где болит

Решения вроде «какую цену поставить», «какого поставщика выбрать», «этот плохой или ещё нормальный» принимаются каждый раз заново.

Система делает вещи, которые ни один из нас не может точно объяснить, и мы боимся их трогать.

Новые идеи ложатся поверх старых, и мы не понимаем, что они при этом ломают.

Мы говорим на разных языках. Партнёр думает кодом и агрегатами, я людьми и результатом. Одни и те же слова у нас означают разное.

И материал. У меня есть список наблюдений, у партнёра список целей. А середины, то есть понятий, правил и решений, нет ни у кого.

## 5. Кого мы ищем

Это проект с понятным концом, а не постоянная позиция. Нужен человек со стороны, который придёт, вытащит из нас двоих всё, что мы знаем, и сложит это в одно описание.

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

На старте отдадим вам оба наших списка, наблюдения и цели, как сырьё.

Если у вас есть опыт работы с DDD-командами со стороны бизнеса, Event Storming, Domain Storytelling, таблицы решений, жизненные циклы, это большой плюс. Конкретную методологию мы не навязываем, но хотим, чтобы у вас была своя.

## 6. Что должно получиться

Два документа, или один в двух частях, как вам удобнее.

Для нас, владельцев:

- карта процесса от запроса клиента до денег и статистики;
- список решений, которые принимает система, и решений, которые принимает человек, с входами и последствиями;
- список противоречий и открытых вопросов с вариантами, и что мы по ним решили;
- границы ответственности, то есть какие ситуации на самом деле разные, хотя выглядят одинаково.

Для разработки:

- словарь понятий;
- сущности, связи, жизненные циклы;
- события и показатели, и какое решение от какого показателя зависит;
- таблицы решений и формулы на уровне «входы, условия, результат», саму математику посчитаем отдельно;
- бизнес-инварианты;
- сценарии и критерии приёмки.

## 7. Чего не нужно

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

Если после всего прочитанного вам интереснее, как система устроена внутри, чем как устроен бизнес вокруг неё, то мы, скорее всего, ищем не вас. Это нормально, просто напишите.

## 8. Что нужно от вас сейчас

Пришлите 5–10 вопросов, которые вы задали бы нам первыми, до начала любой работы. Не план, не оценку сроков, не коммерческое предложение, только вопросы. По ним мы поймём, с какой стороны вы заходите в задачу.

Если для вопросов не хватает информации, спросите и об этом.