В финтехе легко начать не с той задачи. Команда может несколько месяцев разрабатывать удобный экран перевода, а потом выяснить, что пользователи не доверяют сервису свои данные, банку-партнёру не подходит сценарий проверки клиента, а комиссия делает продукт невыгодным. Этап Discovery нужен, чтобы обнаружить такие ограничения до того, как они превратятся в дорогую разработку.
Discovery — это исследование проблемы, пользователей и условий, в которых будет работать продукт. Его задача не в том, чтобы придумать идеальную концепцию или составить подробный план на год. Нужно собрать достаточно фактов, чтобы ответить на практические вопросы: кому нужен сервис, какую конкретную задачу он решает, можно ли безопасно и законно запустить выбранный сценарий и есть ли смысл вкладываться в его разработку.
Что именно проверяют
Есть ли реальная проблема. Формулировки вроде «людям неудобно управлять деньгами» слишком широки, чтобы по ним строить продукт. Команда выясняет, кто сталкивается с затруднением, в какой ситуации и как решает его сейчас. Например, владельцы небольших компаний могут тратить время на сверку поступлений из нескольких источников. Это уже проверяемая задача: можно поговорить с такими предпринимателями, посмотреть на их рабочий процесс и понять, насколько часто возникает проблема и чем она обходится.
Интервью полезны, но одних слов недостаточно. Люди могут описывать не то, как поступают на самом деле, а то, как им хотелось бы поступать. Поэтому исследователи спрашивают о недавних конкретных случаях, текущих инструментах и последствиях ошибки. Для финансового сервиса особенно важно понять, на каком шаге пользователь готов передать данные или подтвердить операцию — и что может его остановить.
Как устроен путь клиента. В финтехе интерфейс — только видимая часть услуги. За регистрацией могут стоять проверка личности, согласие на обработку данных, связь с банком, перевод средств и обращение в поддержку. Если хотя бы один шаг неясен или не работает, пользователь может не дойти до первой ценности продукта. Discovery помогает увидеть весь сценарий, а не только главный экран.
Какие ограничения задают партнёры и правила. Команде нужно заранее разобраться, какие операции она хочет проводить, какие данные для этого потребуются и кто будет выполнять отдельные проверки. В зависимости от модели могут понадобиться банк, платёжный провайдер или другие партнёры. У каждого — свои технические условия и требования к процессу. Конкретные юридические обязанности зависят от страны и устройства бизнеса, поэтому их проверяют со специалистами, а не выводят из макетов интерфейса.
Сойдётся ли экономика. Удобный сервис не обязательно устойчивый бизнес. Стоит прикинуть, сколько стоит привлечение клиента, обслуживание операций, поддержка, проверки и работа с мошенничеством, а затем сравнить эти расходы с возможной выручкой. На раннем этапе расчёты будут приблизительными. Их смысл — не в точном прогнозе, а в том, чтобы заметить заведомо слабые предположения.
Как Discovery выглядит на практике
Сначала команда формулирует гипотезы: кто пользователь, в чём его трудность, почему существующие способы не помогают и за счёт чего новый сервис может быть полезен. Затем ищет данные, которые способны подтвердить или опровергнуть эти предположения: проводит интервью, изучает реальные сценарии, обсуждает требования с потенциальными партнёрами и оценивает экономику.
Когда картина становится яснее, можно проверять решения без полноценной разработки. Прототип помогает пройти сценарий глазами пользователя; тестирование — заметить непонятные места; ручной пилот — проверить, действительно ли услуга нужна, прежде чем автоматизировать все процессы. Для некоторых вопросов достаточно схемы или расчёта, для других потребуется эксперимент с реальными участниками и заранее продуманной защитой данных.
Предположим, стартап хочет создать сервис, который объединяет финансовую информацию предпринимателя. На старте стоит проверить не только желание видеть всё в одном месте, но и то, готовы ли люди подключать счета, какие данные им действительно нужны, как часто они будут пользоваться сервисом и можно ли получить необходимую информацию через доступные интеграции. Если клиентам важнее ежемесячная сверка, чем ежедневная аналитика, первая версия продукта может оказаться гораздо проще первоначальной идеи.
Что должно получиться до начала разработки
Discovery не обязан завершаться толстым документом. Полезный результат — ясное описание выбранной аудитории и её задачи, проверенные ключевые предположения, схема основного пользовательского пути, список ограничений и понимание того, что именно войдёт в первую версию. Не менее ценно зафиксировать, что пока неизвестно: например, доступен ли нужный способ интеграции или подтвердится ли спрос на платный тариф.
Такой результат помогает команде решить, что делать дальше: запускать ограниченный пилот, менять сценарий, искать партнёра или отказаться от идеи. Отказ от неподтверждённой функции — не провал Discovery. Это способ не оплачивать её разработку, поддержку и исправление ошибок, пока не появились основания считать её нужной.
Исследование не убирает неопределённость и не гарантирует успех. Оно делает её видимой и помогает выбрать, какие риски проверять первыми. Код стоит писать тогда, когда команда понимает, какую гипотезу он проверит и какую часть пользовательской задачи решит. В финтехе такая пауза перед разработкой часто экономит время не потому, что Discovery ускоряет программирование, а потому, что помогает не строить продукт вокруг неверного предположения.
