Когда мне предложили заняться разработкой с нуля цифрового сервиса Альфа‑Мании, я была уверена, что понимаю задачу. Что может быть проще? Клиент открывает мобильное приложение банка, выбирает лотерейный билет, оплачивает его, ждет розыгрыш и, если цифры в лотерейном билете совпали — получает выигрыш. На первый взгляд всё выглядело как вполне стандартный цифровой продукт: несколько экранов мобильного приложения, интеграция с партнером, немного аналитики, немного CRM‑коммуникаций и привычная продуктовая работа.

Я никогда так не ошибалась.

Через несколько месяцев я уже обсуждала особенности прогрессивной шкалы НДФЛ, разбиралась в требованиях к онлайн‑кассам, участвовала в проработке процессов идентификации победителей и спорила с коллегами о трактовке отдельных пунктов законодательства о лотереях. 

При этом ТЗ всё ещё не было.

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

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

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

Именно тогда я поняла, что самые сложные продукты начинаются не тогда, когда команда не знает решения, а тогда, когда она практически ничего не знает про предметную область. Об этом я и расскажу. Эта статья про discovery и исследования, важность которых часто недооценивается.

Концепты клиентского пути для проведения гроусхаков

На старте мы знали только одну вещь: клиент должен получить возможность покупать лотерейные билеты внутри мобильного банка. Всё остальное было как в тумане. 

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

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

Фрагменты исследования клиентского опыта других лотерейных сервисов

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

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

Именно тогда в проекте появился эмоциональный CJM. Если обычный клиентский путь отвечает на вопрос «что делает клиент», то эмоциональный пытается ответить на вопрос «что он чувствует». Для лотереи эта разница оказалась принципиальной. Человек покупает не набор цифр и даже не шанс на выигрыш. Он покупает надежду, ожидание и эмоциональный опыт. 

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

Чем ближе был тираж, тем сильнее рос интерес, а вместе с ним количество вопросов: когда розыгрыш, где его посмотреть, как я узнаю результат? После тиража возникала уже другая потребность: как можно быстрее снять неопределенность и понять, выиграл я или нет?

Мы буквально наносили эти эмоциональные состояния на каждый этап CJM и смотрели, где продукт оставляет клиента один на один с ожиданием.

Эмоциональный CJM: путь клиента от знакомства с продуктом до результата тиража

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

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

Именно поэтому в какой‑то момент команда начала обсуждать трансляцию розыгрыша как полноценную продуктовую фичу, а не как дополнительный «бантик». С точки зрения разработки она выглядела второстепенной. А с точки зрения эмоций клиента являлась кульминацией всего сценария!

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

Первые концепты клиентского пути Альфа-Мании

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

Однако очень быстро стало понятно, что нормативные документы являются не ограничением, а полноценным источником требований.

Одним из основных источников требований стал Федеральный закон 138-ФЗ «О лотереях». Например, именно из законодательства и условий проведения конкретной лотереи мы выясняли, что покупатель становится участником лотереи сразу после оплаты и оформления лотерейного билета, какие обязанности возникают у распространителя: от условий участия и онлайн‑распространения билетов до правил выплаты выигрышей и работы с данными участников.

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

И тут выяснилось неожиданное: привычного нам сценария «отменить покупку» здесь просто нет.

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

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

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

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

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

• Нужно ли идентифицировать клиента? 

• Какая у него налоговая ставка? 

• Является ли он налоговым резидентом? 

• Какой доход он уже получил с начала года? 

• Кто выступает налоговым агентом? 

• Какие данные необходимо получить из внутренних систем банка? 

• Какие документы нужно сформировать? 

• Какие данные передать партнеру? 

• В какой момент считать выплату завершенной? 

В какой‑то момент мы ради интереса начали считать количество требований, появившихся вокруг одного сценария выплаты выигрыша. Оказалось, что одна строчка бизнес‑идеи может превратиться в десятки страниц требований и несколько интеграционных контуров.

Еще одной областью, которая неожиданно ворвалась в проект, стала фискализация — требования Федерального закона 54-ФЗ о применении контрольно‑кассовой техники. До работы над Альфа‑Манией я, как и многие, воспринимала онлайн‑кассы как что‑то существующее где‑то рядом с бухгалтерией и налоговой отчетностью. Однако очень быстро выяснилось, что чек является такой же частью клиентского опыта, как экран оплаты или push‑уведомление. Нужно понимать, в какой момент формируется чек, кто отвечает за его выпуск, какие реквизиты должны передаваться, как обрабатываются ошибки и что происходит в нестандартных сценариях. 

В результате обсуждение требований 54-ФЗ стало занимать в календаре не меньше места, чем обсуждение мобильных интерфейсов.

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

Мы довольно быстро отказались от идеи единственной точки входа и начали искать места, где продукт мог бы органично встретиться с клиентом. Анализировали существующие разделы приложения, программы лояльности, CRM‑механики, пользовательские сценарии и историю операций. 

Многие growth-гипотезы появились задолго до первых требований. По сути growth-механики начали появляться еще на этапе Discovery, когда самого продукта в привычном понимании не существовало. Мы еще не написали требования к покупке билета, но уже понимали, в каких клиентских сценариях человек может впервые встретиться с Альфа-Манией.

Поиск дополнительных точек входа в Альфа-Манию внутри мобильного банка

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

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

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

А лучший способ проверить, что получилось из пяти месяцев Discovery, сотен требований и десятков интеграций, — пройти этот клиентский путь самостоятельно. Так что заходите в Альфа‑Манию, покупайте билетик и, конечно, удачи в тираже:)

И, если получится, про то, как финтех сделал свою лотерею, я расскажу в следующей статье. Не переключайтесь.

Заходите в Телеграм-канал Alfa Digital, где рассказывают о работе в IT и Digital: новости, события, вакансии, полезные советы и мемы. Например, недавно рассказывали про систему навыков на базе Claude Code: она может составить полную картину состояния здоровья по вашей медкарте (и в посте есть ссылка на репозиторий); как попасть в топ-4% Kaggle и получил звание Kaggle master и как развивать доступность в приложении.

Читайте также: