Тендеры и лиды
Информация
Перед стартом почти у каждого продукта один и тот же сценарий: идей много, а выпустить всё сразу невозможно. К каталогу хочется добавить чат, к записи — программу лояльности, к заказам — аналитику и несколько ролей. Каждая функция кажется небольшой, но смета растёт, сроки двигаются, а до реальных пользователей приложение так и не доходит.
Выход не в том, чтобы сделать «как можно меньше». Хорошая первая версия должна быть небольшой, но законченной: человек решает свою задачу, бизнес получает результат, а команда понимает, что развивать дальше.
Фраза «нам нужно приложение» ничего не говорит о цели. Гораздо полезнее сформулировать один вопрос, на который должен ответить запуск.
Например:
смогут ли постоянные покупатели оформить повторный заказ без звонка менеджеру;
будут ли клиенты самостоятельно записываться на свободное время;
сократится ли ручной перенос заявок в учётную систему;
готовы ли пользователи возвращаться в приложение после первой покупки.
Такой вопрос быстро отсеивает лишнее. Если мы проверяем самостоятельную запись, сложная программа лояльности пока не помогает. А вот актуальное расписание, подтверждение записи и уведомление администратора безусловно нужны.
Список экранов — «главная, каталог, профиль, уведомления» — выглядит понятно, но не показывает, заработает ли продукт в жизни. Лучше описать путь человека от желания до результата.
Для сервиса записи он может звучать так:
Клиент выбирает услугу и свободное время, оставляет данные, получает подтверждение. Администратор сразу видит новую запись в расписании.
Если клиент увидел красивый экран «Готово», а запись не попала администратору, приложение не решило задачу. Поэтому для каждого шага стоит проверить четыре вещи:
что делает пользователь;
что в этот момент делает система;
как бизнес получает и обрабатывает результат;
что произойдёт при ошибке, повторном нажатии или пропавшем интернете.
Первая версия может быть компактной, но не должна быть хрупкой. Заказ не должен исчезать, платёж — списываться дважды, а два клиента — занимать одно и то же время.
Вместо спора «нужна функция или нет» мы обычно делим список на три понятные группы.
Без этого запуск не работает. Сюда попадает всё, без чего человек не завершит основной путь, сотрудники не смогут обработать результат или команда не поймёт, сработала ли идея.
Это улучшит уже работающий продукт. Например, напоминание о визите, быстрый повтор заказа или более удобный фильтр. Полезно, но основной сценарий можно проверить и без этого.
К этому вернёмся после первых данных. Программа лояльности, чат, дополнительные роли, сложные отчёты и другие самостоятельные гипотезы.
Важно записать не только группу, но и причину. Напоминание может быть улучшением для обычной записи — и обязательной функцией для продукта, который создаётся именно ради снижения количества пропусков.
На макете чат занимает один экран. В разработке нужно решить, кто кому пишет, где хранятся сообщения, нужны ли вложения, что происходит без сети, когда отправлять уведомления и кто разбирает жалобы.
То же самое происходит с промокодами, подписками, повторными заказами и отчётами. Поэтому перед оценкой полезно раскрыть каждую важную функцию:
откуда берутся данные;
какие роли участвуют;
с какими сервисами нужна интеграция;
какие есть статусы и ошибки;
что считается готовым результатом.
После такого разговора смета становится понятнее. Команда видит реальный объём, а заказчик — за что именно платит.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13752 тендера
проведено за восемь лет работы нашего сайта.
Есть работа, которую редко рисуют на презентации, но без неё нельзя выпускать продукт:
защита персональных и платёжных данных;
восстановление после ошибки в основном сценарии;
требования магазинов приложений;
диагностика сбоев;
аналитика ключевого действия;
рабочий интерфейс для сотрудников, которые принимают заказ или заявку.
Например, приложение доставки не заканчивается на корзине покупателя. Магазину нужно принять заказ, проверить состав, собрать его и передать курьеру. Если этого контура нет, новый канал продаж просто создаст сотрудникам ещё один список для ручной обработки.
Сокращать безопаснее количество сценариев, а не качество главного сценария.
Для первой встречи достаточно человека, который принимает продуктовые решения, и команды, способной задать вопросы о бизнесе и технологии.
Сформулируйте результат первого запуска для клиента и для бизнеса.
Нарисуйте один полный путь от потребности до обработанного результата.
Разложите идеи по трём корзинам: нужно сейчас, улучшить позже, проверить после первых данных.
Для обязательных функций отметьте данные, роли, интеграции и возможные ошибки.
Договоритесь, по какому показателю будете принимать решение после запуска.
Результат такой встречи — не стопка документов. Это понятная граница этапа: что именно делаем, что сознательно откладываем и какие неизвестные нужно проверить заранее.
До расчёта сроков и бюджета полезно собрать небольшой пакет:
кто пользователь и какую задачу он решает;
один законченный сценарий, включая ошибки;
список обязательных функций с объяснением, почему они нужны;
данные, роли и внешние системы;
критерии готовности;
что точно не входит в первый этап;
какой результат после запуска будет считаться успехом.
Если пока непонятно, как люди воспримут новый сценарий, начните с прототипа. Если есть сомнения в интеграции с 1С, CRM или другим сервисом, сначала проведите небольшой технический эксперимент. А для проверки реального использования понадобится работающая версия продукта.
Количество скачиваний само по себе мало о чём говорит. Показатель должен быть связан с главной задачей.
Для приложения записи это может быть доля людей, которые выбрали время и получили подтверждение без помощи администратора. Дополнительно стоит смотреть на дубли, технические ошибки и обращения в поддержку.
Даже при небольшом количестве пользователей можно увидеть главное: где люди останавливаются, что приходится исправлять вручную и ради какой функции они возвращаются. Эти наблюдения полезнее длинного списка идей, составленного до запуска.
Это самый короткий путь к реальному ответу: нужен ли людям продукт и что в нём стоит развивать. Чем яснее этот путь до начала разработки, тем меньше вероятность потратить бюджет на функции, до которых пользователи не дойдут.
13FOX помогает пройти весь путь от идеи до запуска: разобраться в задаче, определить состав первой версии, спроектировать интерфейс, разработать приложение и серверную часть, подготовить публикацию и дальнейшее развитие.
Если вы планируете мобильный продукт, пригласите 13FOX в тендер на Workspace или напишите нам в сообщениях площадки. Разберём вашу идею, покажем границы первого этапа и предложим понятный план запуска.
