редакции
Funtome Messenger: развитие мобильного продукта

Базис для будущего развития закладывается еще до выхода на рынок. Инструменты и принципы в команде следующие:
· Кастдев до запуска;
· А/В и юзабилити тесты до подачи продукта юзерам;
· Заложенные в приложение аналитика и трекинг;
· Выпуск на стадии SRP (sales-ready product).
Основная идея заключается в том, что улучшать и развивать имеет смысл только то приложение, у которого есть потенциал для развития. Следуя этой мысли, мы стремились выпустить не столько качественный, сколько интересный и перспективный продукт, которым пользователь захочет продолжать пользоваться и завтра, и в отдаленном будущем.
Пройдемся подробнее по инструментарию:
Кастдев до запуска
Кастдев (customer development) — тщательное, профессиональное исследование потребностей, «болей» потенциальных клиентов и проверка гипотез разработчика — мастхэв любого проекта перед стартом. Еще на стадии оформления идеи, до того как будет введен первый символ кода, стоит определить свою ЦА, найти ее потребности и понять, как выпускаемый продукт может их удовлетворить, провести анализ предложений конкурентов и рынка субститутов, найти и сформулировать УТП — уникальное торговое предложение («очередной мессенджер, только прикольный» не является УТП «мы не висим» — тоже не оно, хотя сам по себе слоган забавный).
Важно определить, кого заинтересует продукт: взрослых или подростков, руководителей или подчиненных, профи или любителей и т.д., — и изначально «бить» в эту аудиторию, а не тратить бюджеты после выхода на рынок, «переупаковывая продукт», когда выяснится, что реальная аудитория — не та, что предполагалась. Иногда бывает, что приложение, написанное для профессионалов, больше интересует любителей, а приложение для детей — их родителей. Мы постарались это учесть.
А/В и UX/UI тесты до подачи продукта юзерам
На удивление, некоторые выкладываются в стор без внутреннего тестирования продукта и даже не пользуются предоставляемыми магазинами приложений возможностями, например, Google Play Developer Console позволяет не только провести A/B-тесты и получить отчеты по ним, но и поэкспериментировать с рекламными материалами для маркетинговой кампании (инструмент «Эксперименты»), загрузив несколько визуальных вариантов решений и выбрав из них оптимальный.
Юзабилити — это степень удобства и простоты использования. И она просто должна быть. Вспомните ощущение радости и волнения при установке нового продукта и досаду, вызванную непониманием того, как воспользоваться той или иной функцией («Как вернуться в чат?», «Где кнопка „Коллаж“?») Проверять юзабилити желательно на сторонних, но лояльных пользователях (друзьях/золотое ядро и т.д.) — желательно, тех, кто скажет правду, но не разгромит вас публично на страничке своего блога или в отзывах.
Заложенные в приложение аналитика и трекинг
Анализ данных и поведения помогает отследить, где, почему и на каком этапе пользователь теряется и что его, наоборот, привлекает и удерживает. Все эти данные позволяют оперативно подстраиваться под интересы клиента. Мы используем Amplitude, Facebook Analytics и Firebase, поскольку для нас они наиболее понятны и доступны, но есть и другие неплохие сервисы: например, Adjust, AppMetrica и Mixpanel.
Трекеры показывают, откуда приходят самые лакомые, самые «наши» пользователи. В свою очередь, сервисы аналитики подсказывают, какими устройствами они пользуются, считают поведенческие факторы и напоминают о внутренних ошибках приложения. Мы, таким образом, ориентируемся на интересы целевой аудитории и подстраиваемся под них, а также пытаемся предугадать желания топовых пользователей и предотвратить возникновение ошибок. С недавних пор мы пользуемся трекером Branch. Не нравится Branch — есть Adjust, AclX и множество аналогичных программ.
Неплохо заложить в приложение возможность обратной связи: обычно пользователь не любит совершать лишние действия и вряд ли добровольно посетит стор, чтобы поставить оценку приложению, функционал и работа которого, в целом устраивают, но есть небольшие недочеты, которые можно устранить. Вместе с фидбэком вы получаете возможность общения с пользователем для выяснения деталей проблемной ситуации и можете отследить проблему работы приложения на конкретном устройстве. Есть и приятный психологический эффект: чувствуется небезразличие разработчика к тому, что происходит с его «детищем» и готовность это разбушевавшееся «детище» в случае необходимости усмирить.
Подача продукта на стадии готовности SRP (sales-ready product).
Идея выпуска MVP (minimum viable product — минимально жизнеспособный продукт) очень заманчива, экономически обоснована и у некоторых компаний отлично работает.
К сожалению, чаще идея понимается неправильно и, когда
речь заходит об MVP, разработчики, маркетологи и авторы статей, пытаясь оправдать
существование ультрабюджетного, едва подающего признаки жизни продукта,
апеллируют к подобным иллюстрациям: Мы считаем, это в корне
неверный подход и понимание процесса выпуска MVP. Если пользователь хочет
приобрести автомобиль — задача производителя предложить ему именно автомобиль,
а не скутер и, тем более, не колесо. Пусть на первых порах авто нужно будет
подталкивать и часто загонять на СТО — это все равно должен быть полноценный
автомобиль. Т.е. мы готовим полноценную, но все еще «пробную
версию», на которой проверяется сама идея приложения, проводим анализ реакции
рынка, в соответствии с которой дорабатываем и переделываем приложение, после
чего снова «отдаем» его на тест реальным пользователям, а затем снова
переделываем и т.д. Это и есть процесс MVP. Мы не могли себе такого позволить, поскольку
мессенджер для переписки картинками без широкой базы картинок и настроенных
вербально-визуальных связей никогда не будет хорошо принят широкой публикой,
даже если наши пользователи по результатам предварительных данных были
заинтересованы в подобном мессенджере, а формировать мнение о Funtome,
как «еще об одном приложении, от которых уже трещит телефон, — только хуже и
непонятнее» мы не хотели. Поэтому тестирование проводили своими силами в
небольшой группе друзей и знакомых, а на рынок вышли с полностью готовым
нетиповым продуктом и запаслись бюджетом для продвижения и «доформирования»
рынка. Такая стратегия довольно рискованна и не всем подходит: мы не
рекомендуем ее разработчикам софта и приложений для реального бизнеса. Это то, что нужно сделать до релиза. Дальше, когда базис заложен и продукт выпущен, начинается самое интересное:
взаимодействие с пользователем. После публикации продукта его улучшение
происходит примерно по следующей схеме (порядок пунктов не важен): Внутренние процессы: а) QA, внутренний контроль качества; б) Работа со статистикой и анализ данных. 2. Работа с пользователями: а) Опросы и интервью; б) Работа с отзывами. Внутренний контроль качества, работа со статистикой
и анализ данных QA (Quality Assurance — обеспечение качества),
или тестировщики, нужны для того, чтобы искать и устранять ошибки до того, как
их найдут пользователи, и решать, готов ли продукт/его новая сборка к выкладке
в стор. Тестировщики пишут кейсы, составляют чек-листы,
тестируют продукт и фиксируют все найденные ошибки. Затем эти сведения
поступают разработчикам. В процессе контроля за устранением дефектов
тестировщики следят за своевременным исправлением ошибок и вносят
соответствующие отметки в систему. Также тестировщики осуществляют сбор и
анализ данных об ошибках, в том числе, полученных от службы поддержки. Сбор и анализ статистических данных осуществляют как
тестировщики, так и маркетологи, которые которые вносят коррективы в стратегию
развития, исходя из полученной информации. Но самое интересное, конечно, — взаимодействие с
реальным пользователем. С пользователем общаются аналитики и служба
поддержки. Чаще всего общение происходит в следующих форматах: а) Опросы и интервью Опросы и интервью могут быть как живыми, так и
проводиться в электронном виде. Нам удобны Google Forms: достаточно создать
опрос и отправить его подписчикам или разместить на своем веб-сайте, в
соцсетях. Как показала практика, Google Forms хорошо работают и
не вызывают у пользователей негатива, который может быть перенесен на компанию
в отличие от некоторых других «подвисающих» платформ и сервисов для
опросов. Полученные данные обрабатываются, и команда
делает определенные выводы о проделанной работе. В результате опросов мы видим
основные боли нашего пользователя и выстраиваем гипотезы о том, куда дальше
масштабировать функционал продукта. Благодаря подобным исследованиям в
интерфейсе появились некоторые изменения, например была добавлена возможность
редактирования отправленных сообщений и доработана система обучения. б) Работа с отзывами Важность отзывов и скорость реагирования на них
почему-то до сих пор сильно недооценивается. Отзыв — это не только мнение
пользователей о работе приложения и сообщение об ошибках, но и то, из чего
складывается оценка в магазине приложений. Грамотная работа с отзывами
помогает улучшать как продукт, так и репутацию на рынке. Нам приходят разные, в
том числе и негативные комментарии: от «отстой» до «здесь можно было бы улучшить
то-то и то-то», и мы реагируем на все. Главные принципы работы с отзывами: 1. Скорость реакции Мы стараемся отвечать как можно быстрее, но
иногда из-за разницы во времени реагируем не сразу — в любом случае, в течение
24 часов пользователь получает ответ на оставленное сообщение. Отзывы,
пришедшие через форму обратной связи на сайте и в приложении, обычно получается
обрабатывать быстрее. 2. Ответ обязателен Даже если пользователь пишет лаконичное «фу». В
таком случае мы благодарим за мнение и спрашиваем, что именно «фу». Как ни
странно, иногда пользователь не отвечает, но оценку повышает. Для нас обратная связь и мнения пользователей очень важны:
они дают возможность отследить реальные реакции на нововведения, понять, где
возникли или могут возникнуть какие-то сложности и проблемы, помогают понять
желания нашей аудитории и дают представление о том, как работает приложение на
разных устройствах. Увидеть наш мессенджер и познакомиться с ним поближе можно здесь или в Google
Play и App Store. Получите
фанум за регистрацию и проверьте сами, как работает наша обратная связь, —
будем благодарны за ваше мнение.


