# SMS Aggregate — кейс: Business Architect / Domain Architect

> Первый содержательный отклик на наши заявки (07.09.2026). Кейс-обзор: кто, что за работа, карта брифа, наши наблюдения, следующий шаг.

## Статус

| Поле | Значение |
|------|----------|
| Компания | SMS Aggregate (название по email; в брифе индустрия намеренно скрыта) |
| Контакт | Антон — сооснователь, отвечает за продукт (нетехнический). Есть партнёр: всё техническое, код, DDD |
| Вакансия | Business Architect / Domain Architect (письмо) = «бизнес-аналитик» (шапка брифа) = «Солюшен Архитектор» (как назвал Сергей) |
| Формат | Проект с понятным концом, не постоянная позиция. Удалёнка/деньги/юрисдикция — пока не обсуждались |
| Дата контакта | 07.09.2026 (email) → 10.09.2026 (ответы + описание) → 10.09.2026 (созвон) |
| Текущий шаг | ⏳ Ждём обратную связь от Антона (созвон прошёл хорошо, их ответ — «придут с обратной связью»)
| Отрасль | ✅ Подтверждено: рынок SMS-активаций (виртуальные номера для верификации) — gateway/шлюз между биржами |
| Файлы | [email.md](email.md), [brief.md](brief.md), [questions-draft.md](questions-draft.md), [call-prep.md](call-prep.md) |

## Что за работа (по брифу)

Внешний специалист приходит к двум основателям, вытаскивает из них всё знание о бизнесе и складывает в **единое описание**: понятия, правила, решения. Самому лезть в код не нужно.

Ключевые цитаты-ограничения из брифа:
- «Нужен человек со стороны, который придёт, вытащит из нас двоих всё, что мы знаем, и сложит это в одно описание».
- «Это проект с понятным концом, а не постоянная позиция».
- Чего не нужно: код, проектирование БД, предложения по архитектуре/стеку («за это отвечает партнёр, менять не собираемся»).
- Плюс-методологии (не навязывают): опыт с DDD-командами со стороны бизнеса, Event Storming, Domain Storytelling, таблицы решений, жизненные циклы. «Хотим, чтобы у вас была своя [методология]».

**Артефакты на выходе (два документа):**
- *Для владельцев:* карта процесса «запрос → деньги → статистика»; список решений (система vs человек) с входами и последствиями; противоречия и открытые вопросы; границы ответственности (ситуации, что выглядят одинаково, но разные).
- *Для разработки:* словарь понятий; сущности/связи/жизненные циклы; события и показатели + какое решение от какого зависит; таблицы решений и формулы на уровне «входы, условия, результат» (математику посчитают отдельно); бизнес-инварианты; сценарии и критерии приёмки.

**Старт работы:** отдадут оба «сырых» списка — наблюдения (Антон) и цели (партнёр).

## Карта брифа (что у них за бизнес)

Обезличенно: **реальный-time арбитраж-посредник**. Клиент по API шлёт запрос с ценовым потолком; система за доли секунды выбирает одного из многих поставщиков, покупает, отдаёт клиенту, зарабатывает на разнице. Главная особенность: почти всё для решения узнаётся **после** решения (сколько придёт запросов, есть ли товар, реальная цена, сработает ли — неизвестно заранее).

8 блоков, к которым они просят привязывать вопросы:

1. **Клиенты** — группы с разным поведением; часть цен назначаем мы, часть фиксирована; есть чужие рейтинги/блокировки на нашей статистике; жёсткие лимиты времени ответа. Сами не понимают: одинаковые клиенты получают разный объём запросов; нет модели спроса (время суток/день/месяц).
2. **Каталоги и соответствия** — у каждого клиента/поставщика свой каталог и свои названия; таблица соответствий «наше = их» ведётся руками; ошибка = покупаем не то или не находим нужное.
3. **Поставщики** — показанная цена ≠ цена продажи; несколько цен на позицию; условия «в переписке» (скидки, договорённости); всё быстро меняется; дорого ≠ надёжно. **5 разных состояний поставщика** (недоступен технически / нет товара / дорог / отключён вручную / новый и неизвестный) сегодня в системе часто выглядят одинаково.
4. **Исполнение запроса** — решение за доли секунды: у кого купить, по какой цене, сколько попыток, до какого предела расходов. Время поставщика и время ожидания клиента не согласованы. «Здесь вся экономика»: каждый выбор = ожидаемая прибыль или убыток. Правила частично в коде, частично в голове — не уверены, что совпадают.
5. **После сделки** — клиент подтверждает / отказывается / молчит; подтверждение отменяемо задним числом. Кейсы: результат после фиксации неудачи; клиент отказался, а поставщик взял деньги; результат есть, а клиент не заплатил. «Что считать успехом, для кого и в какой момент — определено неформально».
6. **Деньги** — доход и расход не совпадают по времени, иногда происходит только одно. Валюты разные, маржа зависит от курса на момент каждой операции. Спорят: маржа по сделке или в среднем; сколько тратить на заведомо убыточные пробы; с какого момента сделка убыточна. «У меня один ответ, у партнёра другой, общего нет».
7. **Статистика** — след каждой сделки; по следам решают, кто хороший, что отключать. Что записывать, какие показатели, что нельзя смешивать — описано только в коде.
8. **Цены и ручное управление** — часть решений система, часть руками «по опыту и ощущению»; исключения (отключить поставщика, поднять цену, разрешить убыточную закупку для проверки). **Ручные правила нигде не записаны — их и хотят формализовать.**

**Куда хотят прийти (цели партнёра):** максимизировать прибыль за период, а не за сделку; система сама выбирает поставщика и последовательность попыток; растит объём запросов с ожидаемой ценностью; сама управляет ценами (где можно); быстро подстраивается под спрос/предложение/курсы; находит невыгодные направления и отключает; периодически перепроверяет отключённое/неизвестное; исследует рынок с контролируемым риском; масштабируется без ручной настройки. Не договорились между собой, что такое «контролируемый риск» — «подозреваю, таких мест больше».

**Где болит (их слова):** решения принимаются каждый раз заново; система делает вещи, которые никто не может объяснить, и её боятся трогать; новые идеи ложатся поверх старых непонятно что ломая; говорят на разных языках (партнёр — кодом и агрегатами, Антон — людьми и результатом, одни слова = разное); есть наблюдения и цели, но нет середины — понятий, правил и решений.

## Гипотеза об отрасли (рабочая)

~~Крипто-арбитраж.~~ **Опровергнуто 10.09.2026.**

Отрасль: **рынок SMS-активаций** — виртуальные номера для получения SMS-кодов верификации. SMS Aggregate — шлюз (gateway) между биржами активаций: на одних подключены как поставщик номеров, на других — как покупатель. Своих SIM-карт нет. Арбитраж в реальном времени: за 3–8 секунд решают, у какого поставщика купить номер, чтобы перепродать с маржой.

Ключевые термины домена: «активация» (цикл аренды номера), «клиенты» = биржи-покупатели, «поставщики» = биржи-продавцы, «связка» = страна + сервис, «направление» = связка на конкретной бирже.

## Наши наблюдения и зоны для квалификационных вопросов

Кандидатные темы, по которым видно «с какой стороны заходим» (это **не** готовые вопросы — финальный список в questions-draft.md):

- **Определение успеха** (блок 5) — самое неформальное место: для кого, в какой момент, что с отменами задним числом.
- **Экономика сделки vs периода** (блок 6 + цели) — маржа, курсы, «потолок расходов на пробы»; как связать целевую функцию с реальными деньгами.
- **«Контролируемый риск»** — они сами признали, что не договорились; хорошая проверка, как кандидат распутывает несогласованность.
- **Язык и процесс извлечения** — как именно планируетcя вытаскивать знание: интервью? реальные кейсы? где грань «их слова ≠ что делает система» и как сверяться с партнёром.
- **Что уже было** — пробовали ли описать сами, есть ли прецеденты/наброски/старые документы; что не сработало.
- **5 состояний поставщика и границы** (блок 3) — их пример «разное выглядит одинаково»; насколько глубоко надо развести ситуации.
- **Ручные правила и исключения** (блок 8) — как собирать то, что «нигде не записано», включая правила в переписке с поставщиками.
- **Соответствия каталогов** (блок 2) — где живёт риск «купить не то»; кто ответственный за качество таблицы.
- **Статистика и показатели** (блок 7) — какие данные нельзя смешивать; как показатели связаны с решениями.
- **Объём/границы проекта** — где кончается «описание» и начинается «оптимизация» (они хотят описание, но цели звучат как задачи на оптимизацию — важно прояснить границу артефакта).

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

## Место кейса в стратегии поиска

Отклик пришёл на **архитектурно-доменную роль** (Business/Domain/Solution Architect), тогда как основная цель в AGENTS.md — позиция IC-разработчика Ruby. Кейс ведём как **отдельный трек**: проектная консалтинговая работа по доменному моделированию, без кода. За Сергеем решение, как кейс соотносится со стратегией; факты и переписка — здесь.

Заметка: название роли плавает (Business Architect / Domain Architect / бизнес-аналитик) — в переписке уточнить, кого именно ищут и что для них главное: бизнес-процессы, доменная модель или аналитика требований.

## Ответ Антона на наши вопросы

Вопросы отправлены (07.09). Ответ Антона (получен в тот же день):

> Спасибо за ваш ответ, прочитали вдвоём с партнёром. Хотим поговорить.

## Созвон (10.09.2026) — итог

Созвон состоялся. Продолжительность ~45 мин, оба основателя.

**Что делал Сергей:**
- Говорил не только про термины, но и про то, как терминами эффективно описывать требования к приложению и сам бизнес для единого языка общения
- Поднял тему: нужны термины, которые позволят формулировать стратегии проведения экспериментов и вывести их на системный уровень
- Озвучил несколько технических и бизнес-идей (вероятно, из call-prep: замкнутая петля «решение → исход», байесовская оценка вероятности успеха, эксперименты как архитектура)

**Реакция основателей:**
- Положительная: «хорошо, что вы ориентированы на бизнес»
- У них была идея «поставить искусственный интеллект, и всё он порекомендует» (ожидание magic bullet — стоит иметь в виду)
- Сказали, что придут с обратной связью

**Текущий статус:** ⏳ ждём. Ребята ушли думать.

**Ключевое наблюдение:** интерес совпал по направлению (бизнес-мышление, эксперименты как система), но неясно, совпадут ли по формату/условиям/срокам. Ожидание «ИИ решит всё» — сигнал: они ищут быстрое решение, а не системную работу.

## Next steps

1. ✅ Контекст сохранён, бриф — в [`brief.md`](brief.md).
2. ✅ Сформулированы и отправлены 7 вопросов (→ [`email.md`](email.md)).
3. ✅ Получено приглашение на созвон.
4. ✅ 10.09.2026 получены: ответы на вопросы + полное описание отрасли/бизнеса (SMS-активации, gateway между биржами).
5. ✅ Подготовка к созвону → [`call-prep.md`](call-prep.md).
6. ✅ **Созвон прошёл (10.09.2026).** Основатели отозвались положительно, обещали прийти с обратной связью.
7. ⏳ Ждём обратную связь от Антона.
8. ⏳ Если решение положительное — согласование формата/условий/ставки.