# SMS Aggregate — подготовка к созвону (45 мин, оба основателя) > Формат звонка (из письма Антона): расскажут отрасль, покажут **один реальный случай** из практики и обсудят его вместе. «Хочется увидеть, как вы с ним работаете». Формат и условия — после звонка, если поймём, что совпадаем. > > **10.09.2026:** отрасль уже раскрыта в письме — рынок SMS-активаций (виртуальные номера для верификации). SMS Aggregate — шлюз между биржами. Подробности — ниже. ## 0. Что мы теперь знаем (до звонка) — и как этим бить Антон прислал ответы на все 7 вопросов + описание бизнеса. Каждый ответ — козырь для звонка. ### Отрасль (подтверждено) **Рынок SMS-активаций**: аренда виртуального номера на 15–20 минут, чтобы получить SMS-код верификации (тестировщики, маркетологи, пользователи из недоступных стран). Три участника: поставщики номеров (SIM-фермы), биржи активаций, покупатели. **SMS Aggregate — шлюз между биржами.** Своих SIM-карт нет. На одних биржах они поставщик (получают запрос «дай номер страны X под сервис Y»), на других — покупатель. Всё, что они делают: за **3–8 секунд** решают, у кого купить номер, по какой цене, что делать при отказе — чтобы в среднем быть в плюсе. **Словарь домена (использовать на звонке, чтобы показать погружение):** - «активация» — цикл аренды номера - «связка» = страна + сервис - «направление» = связка на конкретной бирже - «клиенты» = биржи, где продаём; «поставщики» = биржи/продавцы, где покупаем (одна площадка может быть и тем, и другим) ### Их ответы → наши козыри | Их ответ (дословно смысл) | Наш ход на звонке | |---|---| | **Q1:** «Успех = активация завершилась Ок и потом не изменила статус. Отменил — теряем деньги, **стату не собираем**» | «Вы не считаете потери от отмен. Это первое, что я бы сделал — метрика цены отмены по направлению. Пока её нет, вы не можете отличить плохой бизнес от хорошего» | | **Q2:** «Алгоритм определения 5 состояний поставщика — **есть, в голове**» | «Вот это и есть ядро проекта: вытащить алгоритм из головы в формальные правила» | | **Q3:** «Есть ожидание на весь заказ + на одного поставщика» | Показать, что видим двухуровневый таймаут — и спросить, как они связаны | | **Q4:** «Маржа фиксируется на момент создания активации, не меньше X%, глобально на всех» | «Одно глобальное правило маржи на всех — вы теряете на направлениях, где маржа могла бы быть выше, и гоните поток туда, где она ниже» | | **Q5:** «Хотим, чтобы человек со стороны собрал данные и **предложил бизнес-процессы, которые можно дорабатывать без кардинального изменения системы**» | Это граница проекта: НЕ редизайн системы, а описание AS IS + точечные улучшения процессов. Держать в ответах | | **Q6:** «Проверено **множество теорий, уже запутались**, что работает, а что нет» | «Вам не хватает не ещё одной теории, а порядка: как фиксировать гипотезу, метрику и решение. Сейчас вы запутались в собственных экспериментах — я это и разбираю» | | **Q7:** «Разногласия решаем **обсуждением и экспериментами**» | «Эксперимент в проде — дорого. Доменная модель делает часть споров дешёвыми: сначала договориться о понятиях, потом спорить о решениях» | **Главная нить разговора:** вы запутались, потому что знание разм'язано по трём местам (голова Антона, код партнёра, переписка), а решения принимаются «по ощущению». Я собираю это в одно описание, и тогда споры и эксперименты становятся дешевле. --- ## 1. Цель звонка и настрой **Главная цель:** пройти «экзамен» (разбор реального кейса) → получить от них предложение формата/условий. Взять проект при хороших условиях. **Вторичная цель:** квалифицировать проект для себя — отрасль, масштаб, сроки, пространство для ставки. **Настрой:** ты не нанимаемый исполнитель, а внешний эксперт с собственной методой, которого двое основателей позвали решить реальную проблему. Встреча — взаимная проверка. Они тебя проверяют на кейсе, ты их — на адекватность, объём и деньги. --- ## 2. Структура звонка — как выстроить 45 минут ### 0–10 мин: вход, отрасль + кейс Антон и партнёр рассказывают отрасль, показывают один реальный случай. Ты: - Слушаешь, записываешь события в ленту времени. - Задаёшь только уточняющие «что было дальше?». НЕ перебиваешь анализом. - Отрасль первым НЕ называешь. После reveal можно: «Похоже на то, о чём я думал» — показать, что уже считал механику. ### 10–30 мин: разбор кейса — экзамен Это главная часть. Показываешь, КАК работаешь с материалом. 1. **Размечаешь узлы решений на ленте времени:** кто решал (система или человек), какие данные были доступны в этот момент, что было неизвестно. 2. **После каждого узла — один вопрос:** «Что бы изменилось, если бы вы знали X в этот момент?» 3. **Ищешь противоречия вслух:** «Ты сказал А, партнёр говорит Б — здесь расхождение, оно важное или тактическое?» Именно за этим позвали. 4. **Завершаешь в деньгах:** «Здесь успех = …, убыток = …» — показываешь, что мыслишь в экономике, а не в событиях. Итог: не «решить кейс», а показать **процесс извлечения знания**. Даже полусырой разбор с правильными вопросами лучше «готового ответа» за 5 минут. ### 30–40 мин: прощупать проект (soft questions) - Масштаб: «Сколько клиентов, сколько поставщиков, какой дневной объём запросов?» - Тайминг: «Сколько времени вы отводите на проект? Работаете ли вы в параллель с чем-то ещё?» - Готовность сырья: «На старте вы отдадите оба списка (наблюдения + цели) — насколько они готовы сейчас?» ### 40–45 мин: закрытие - «Мне удобно начать с ваших двух списков + одного-двух таких же кейсов — на них я размечу решения и верну вам словарь понятий + карту процесса на проверку.» - Формат/условия они обещали «после звонка». Если не поднимут к концу, мягко: «Когда вам удобно обсудить условия?» --- ## 3. Как себя вести — правила | Делать | Почему | |--------|--------| | **80/20 слушаем/говорим** | Ты вытаскиваешь знание, а не читаешь лекцию | | **Думать вслух, их языком** | Не «aggregate root» → «правило, которое в коде»; не «event sourcing» → «след, который оставляет сделка». Партнёр DDD-шник — ему можно термины, но сначала завоевать доверие Антона | | **Один открытый вопрос за раз** | Без преамбулы на 2 минуты | | **Противоречия — явно, без агрессии** | «Я слышу расхождение: ты говоришь X, партнёр — Y. Оно важное или тактическое?» | | **Отвечать фактами из опыта** | Не теорией, не книжками | | **Позиционирование: мост** | Между бизнесом и кодом. Именно их боль: «говорим на разных языках» | **Твой голос:** «Я 20 лет строил системы, но главная проблема всегда была не в коде, а в том, что бизнес и разработка говорят на разных языках. Я этот разрыв закрываю.» --- ## 4. Вопросы к ним — что спросить на звонке ### Из непосланного шорт-листа (держать при себе): - **«Что каждый из вас вкладывает в 'контролируемый риск'?»** — они сами признали, что не договорились. Прямой зонд в их главное расхождение. - **«Таблица соответствий каталогов — как сегодня добавляется новый клиент или поставщик? Кто и сколько сопоставляет позиции вручную, где предел?»** — узкое место масштабирования. - **«Скрытая система рейтингов и блокировок клиентов — вы пытались её разобрать или живёте как с чёрным ящиком?»** — блок 1, неизвестное. - **«Где граница между 'описать как есть' и 'спроектировать как должно быть'? Правильно ли я понимаю, что вы хотите описать AS IS, чтобы с этой базы двигаться в TO BE?»** — этот уже в письме (вопрос 5), но на звонке можно копнуть глубже. ### На прощупывание проекта: - «Сколько клиентов, сколько поставщиков, какой дневной объём запросов?» - «Сколько времени отводите на проект?» - «Готовы ли оба списка (наблюдения + цели) к передаче?» --- ## 5. Вопросы к тебе — и как на них отвечать Это ключевой раздел. Ниже — 10 вероятных вопросов от Антона и партнёра с готовыми ответами, построенными на твоём реальном опыте. --- ### Q1: «Почему вы, разработчик/техлид, хотите делать доменную аналитику без кода?» Самый вероятный вопрос. За ним: «Вы не сбежите через неделю писать код?», «Вам не будет скучно?» **Ответ:** > Я 20 лет строил системы, но главная проблема всегда была не в коде, а в том, что бизнес и разработка говорят на разных языках. На Samokat я ввёл DDD как архитектурный baseline для трёх команд — именно потому, что без общего языка код расходится с бизнесом. На Balance я вытаскивал домен кредитного конвейера из бизнес-экспертов и переводил в сущности, RPC-протоколы и микросервисы. На Raiffeisen сводил три команды с разной архитектурой в единую C4-модель. > > Это не работа «без кода». Это работа, без которой код появляется не про то. Мне интереснее решать, ЧТО строить и какие деньги на кону, чем писать ещё один контроллер. *Evidence:* Samokat (DDD baseline, 3 команды, 18+ инженеров), Balance (LaaS domain, monolith→microservices, RPC protocol), Raiffeisen (C4 doc closure across 3 products). --- ### Q2: «Какая у вас методология? Event Storming / Domain Storytelling?» Бриф: «Хотим, чтобы у вас была своя [методология]». Партнёр спросит про конкретные техники. **Ответ:** > Основной метод — разбор реальных сценариев до жизненных циклов и таблиц решений. Event Storming и Domain Storytelling — инструменты, которые я беру, когда они дают результат, а не догма. Я смотрю на систему через решения и деньги: кто решает, на каких данных, что на кону. Инструмент подбираю под задачу — где-то нужен Event Storming на всю стену, где-то хватит трёх таблиц решений. > > У вас в брифе сказано: «хотим, чтобы у вас была своя метода». У меня она есть — сегодня покажу на вашем кейсе. *Допущение:* формального опыта фасилитации Event Storming у тебя нет — ответ строится на DDD/C4/UML-практике. Их боль — отсутствие метода вообще, а не конкретная техника. --- ### Q3: «Как вы будете вытаскивать знание из нас двоих?» Их главный вопрос. Бриф: «интервью, разбор реальных случаев, вопросы, на которые мы не сможем ответить сразу». **Ответ:** > Интервью по одному + сверка на реальных следах сделок. Беру конкретный трейд — от запроса клиента до денег на счёте — и прохожу с вами обоими по отдельности. Сравниваю, где версии расходятся. Словарь понятий фиксирую на ходу и возвращаю вам на проверку — чтобы вы оба подписались. > > Противоречия выношу вам на решение, а не закрываю удобным допущением — это ваши слова из брифа, и я с ними согласен. Партнёр даёт мне доступ к логам/следам для сверки; в код я не лезу, но факты проверяю. *Почему круто:* цитируешь их бриф — показывает глубокое чтение. Описываешь конкретный процесс, не абстракцию. Показываешь, что уже думал, КАК работать. --- ### Q4: «Как справляться с тем, что у нас разные ответы на один вопрос?» Бриф: «У меня один ответ, у партнёра другой, общего нет». «Подозреваю, таких мест больше». **Ответ:** > Не усреднять. Фиксирую оба варианта, нахожу точку, где они реально расходятся, и формулирую это как решение с последствиями для денег. Моя работа — не мирить вас, а сделать расхождение видимым и дешёвым для принятия решения. > > Вы сами написали: «подозреваю, таких мест больше». Я ожидаю, что найду их и вынесу вам. Это нормально — в любом проекте domain discovery их десятки. *Evidence:* Raiffeisen — свёл три команды с разным пониманием архитектуры в один C4 doc. --- ### Q5: «Что вы думаете о нашей отрасли / как работает наш бизнес?» Проверка проницательности. Возможно, спросят ДО того, как сами назовут отрасль. **Ответ:** > Из брифа — это арбитраж в реальном времени, где почти всё для решения узнаётся после решения: сколько придёт запросов, есть ли товар, реальная цена, сработает ли. Экономика — разница между ценой клиента и ценой поставщика, помноженная на процент успешных сделок. > > Ваша главная сложность не в алгоритме выбора поставщика, а в том, что правила этого выбора живут в трёх местах и не совпадают. Отрасль не называю — вы сказали «на встрече», но механика знакомая. **Важно:** НЕ утверждать «это крипта». Описать механику — дать им назвать отрасль. --- ### Q6: «Какая у вас ставка? Сколько это стоит?» Могут спросить, несмотря на «формат и условия обсудим после». Не называть цифру без объёма. **Ответ:** > Давайте сначала поймём объём — после этого звонка и ваших сырых списков. Я работаю за проект или понедельно; ориентир дам, когда увижу границы. Сейчас могу сказать: это не full-time, проект с концом — ставка будет проектная, не почасовая. *За кадром:* подготовить вилку. Проектная работа domain modelling — выше почасовой разработки (это не поток, а конечный проект). Если отрасль = крипта — ставка выше. --- ### Q7: «Вам не будет скучно без кода?» Вариация Q1. Проверяют, не сбежишь ли. **Ответ:** > Я пишу код 20 лет, и код от меня никуда не денется. Но здесь моя ценность — в модели, в решениях и деньгах. Если правильно описать, ЧТО система должна делать, это сэкономит вам больше, чем ещё один микросервис. Код — не самоцель. --- ### Q8: «Какой у вас опыт с real-time системами / финтех / арбитражем?» Партнёр будет копать техническую глубину. **Ответ:** > Финтех: Lending-as-a-Service на Balance — кредитный конвейер, автоматическое принятие решений, расчёт ставок, жизненный цикл заявки. Платёжные интеграции: QIWI (SeoPult, Social Quantum), PayPal/PerfectMoney (Undev). > > Real-time: event-driven на Samokat — Go-сервис Kafka→WebSocket, ~500 одновременных коннектов. High-load HTTP-краулер на Go (SeoPult). > > Арбитраж как домен — честно, нет. Но модель «решение при неполной информации + маржа» близка к риск-ценообразованию в финтехе. *Честно:* прямого опыта арбитража нет. Компенсируем смежным. --- ### Q9: «Сколько времени нужно на проект?» Не называть цифру без объёма. **Ответ:** > Сначала объём. После этого звонка и ваших списков я дам оценку — не в часах, а в границах: что входит, что нет, сколько итераций проверки с вами. --- ### Q10: «Почему мы должны выбрать вас?» Итоговый. Бить в их боль. **Ответ:** > Потому что я пришёл с вопросами про деньги и границы, а не про процесс «как сделать». Я единственный, кто спросил про ваше расхождение по марже и контролируемому риску — вы сами сказали, что это болит. У меня есть своя метода, и я говорю на обоих языках: с Антоном про деньги и клиентов, с партнёром про агрегаты и события. --- ## 6. Чего не делать — анти-паттерны | Делать | НЕ делать | |--------|-----------| | Слушать, записывать, вскрывать противоречия | Давать готовые решения кейса | | Мыслить в деньгах и решениях | Лезть в код, БД, архитектуру, стек | | Один открытый вопрос за раз | Монополизировать, читать лекции | | Показать метод на их кейсе | Показать «план из N шагов» | | «Механика знакомая, отрасль жду от вас» | «Это же крипта, да?» | | «Формат/условия обсудим после» | Поднимать деньги/сроки в первые 30 мин | | «Я строил DDD на Samokat» | «Я не аналитик, я разработчик» | | Думать вслух | Молчать и кивать | | «Мы» (я + вы) | «Я» (эксперт, который всё починит один) | --- ## 7. Ответ Антону со слотами Письмо отправить как можно скорее (в первые 24 часа). > Антон, спасибо. Хорошо, давайте созвонимся. > > Мои слоты: [День], [Дата] в [Время] MSK; [День], [Дата] в [Время] MSK; [День], [Дата] в [Время] MSK. > Часовой пояс — Москва (UTC+3). > > Сергей Подставить реальные даты на эту/следующую неделю от 10.09.2026. Избегать утра понедельника и вечера пятницы. Лучше вт–чт, 11:00–17:00 MSK. --- ## 8. После звонка — чек-лист - [ ] Записать отрасль (подтвердилась крипто-гипотеза? Или SMS-хабинг? Или третье?) - [ ] Записать суть показанного кейса и как прошёл разбор - [ ] Зафиксировать: что сработало, где затупил, что спросить в следующий раз - [ ] Зафиксировать договорённости по формату/условиям/следующему шагу - [ ] Обновить статус в `case.md`, `applications/README.md`, `AGENTS.md`