Иногда ваши идеи просто не нужны пользователям: как исследование помогло не создать ИИ-Гузееву

Представим: вы директор крупного онлайн-магазина товаров для дома. И у вас есть идея, как повысить доходность магазина — запустить игру, где пользователи обставляют жильё, получают бонусы и потом тратят их в магазине. Вы собрали команду, разработали и запустили первую версию игры в духе «Весёлой фермы», а пользователей почти нет. Не помогает ни реклама у блогеров, ни таргет. Деньги потрачены, а прибыли нет.

Эта боль нам хорошо знакома. Так часто бывает, когда команда загорелась новой идеей, но возникают сомнения:

Ошибиться в выборе функциональности, планов и общей стратегии для приложения страшно: в мире проваливается 90% всех новых бизнес-проектов. Рассказываем, как не стать жертвой собственных идей, не потерять деньги и не разочароваться в своём проекте. И что сделать на старте, чтобы оказаться среди тех 10%, кто сделал всё правильно и запустил прибыльное приложение.

Когда мы прорабатывали функции нового приложения для Триколора, сначала нам нужно было определить цели и на их основе задачи проекта. Цель заказчика была создать такое приложение, которое бы приучило пользователей смотреть контент не только через ТВ. Цель поставили, идём искать идеи — собираем мозговой штурм.

Наша команда экспертов выдала огромное количество идей по будущим функциям. Самая шикарная затея по версии редакции — ИИ на основе личности ведущей «Давай поженимся» Ларисы Гузеевой. ИИ-Гузеева должна была помогать пользователям находить нужный контент и отвечать на вопросы.

Ещё предложили пультофон — режим переключения каналов, когда экран приложения работает как ТВ-пульт. Идеи были классные, и внедрить их мы могли, но очень важно проверить эти идеи перед тем как брать в работу.

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

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

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

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

Мы всегда начинаем с брифинга — проводим его за первый день нулевого спринта. Наш бизнес-аналитик (BA) вместе с заказчиком выясняет, какие у проекта цели, какие проблемы нужно решить, и максимально погружается в бизнес-контекст. Чем лучше команда будет понимать принципы работы заказчика и его бизнес-процессы, тем лучше приложение подойдёт для конкретной компании и её ситуации. А значит, тем больше прибыли принесёт.

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

Для полноценного исследования нужны эксперты разных направлений. На этапе мозгового штурма собирается целая команда: BA, PM, арт-директор и UX-исследователь, команда заказчика. По нашему опыту, привлекать эксперта-разработчика до начала проекта нужно редко. Наша команда приглашала лида разработки на нулевой спринт, например, когда прорабатывала интерактивного решение со сложными механиками авторизации и оплаты и AR-функциональностью.

Это не значит, что эксперты будут придумывать идеи только в рамках своих компетенций: например, разработчик будет думать только о том, как оптимизировать код, а дизайнер — про красивые градиенты на главной. Все включают креативность на максимум и предлагают всё, что приходит на ум.

Организовать процесс поможет менеджер проекта (PM) — его тоже зовём. PM поставит перед остальной командой цели мозгового штурма и будет придерживать направление идей — чтобы не пытались решать не те проблемы. Он же будет подводить итоги.

Всего 4–5 экспертов плюс команда заказчика. Больше людей не значит лучше.

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

Теперь берём наши свежепридуманные идеи и идём проверять спрос на них.

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

Дальше определяем целевую аудиторию — если приложение уже существует, рассматриваем текущих пользователей. Их и будем опрашивать на кастдеве.

Будьте готовы, что найти участников будет непросто. Чтобы опросить сотню, нужно позвать десять тысяч. На наш проект из 1000 случайно выбранных пользователей только 6% согласились на предварительное интервью. Из согласившихся 40% отказались от интервью после его назначения, а ещё часть просто не вышла на связь. Всего опросили 27 человек.

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

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

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

Нулевой спринт помог нам понять на практике простую истину:

После нулевого спринта 70% заказчиков переходят в проектирование. Это значит, что 7 из 10 директоров, стартаперов и менеджеров проектов сначала не знали, что делать, а теперь знают и делают приложение по готовому плану. Оставшиеся 3 из 10 тоже не ушли ни с чем: для них нулевой спринт подсветил проблемы и не дал потратить деньги впустую.

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

Мы знаем, что каждому бизнесу важно не упустить время и быть конкурентоспособным. Поэтому мы собираем команду для нулевого спринта за 3 часа и сразу включаемся в проект. В зависимости от сложности проекта, за 2–6 недель проведём исследование, на котором проработаем цели проекта, способы их достижения и план на несколько релизов.