Мобильные приложения: как оценить основную идею

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

Выбираем идею

Востребованное мобильное приложение соответствует трем принципам: people, tech, business.

Принцип People — приложение должно вызывать желание им пользоваться.

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

Громкий проект «шлем виртуальной реальности для программистов» потерпел фиаско. На первый взгляд идея — бомба. Программист надевает шлем и погружается внутрь кода. Его ничто не отвлекает, он полностью сосредоточен. Но на практике оказалось, что картинка получается недостаточно четкой для написания кода. Текст выглядит размытым.

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

Принцип Business — приложение должно выполнять бизнес-задачи. Каждое мобильное приложение — отдельный бизнес-проект. Не проработанное до конца приложение не станет востребованным. Пользователи придут благодаря агрессивной рекламной кампании, но скоро разочаруются в приложении, которое лагает или не соответствует ожиданиям, и удалят его. Инвесторы обращают внимание не только на количество скачиваний, но и на показатель Uninstall Rate, который информирует о соотношении количества деинсталлированных приложений к количеству установленных за определенный промежуток времени.

Приложение должно решать четыре задачи:

• Преследовать цели бизнеса.
• Решать проблемы бизнеса: оптимизировать, упрощать, делать удобнее.
• Решать проблемы пользователя.
• Создавать дополнительную ценность для пользователя.

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

Отбираем функционал

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

«Ценность против рисков». Матрица используется для отбора функций для разработки и расставления приоритетов очередности. Необходимо каждую функцию оценить по типам риска:

• просрочить дедлайн;
• превысить финансирование;
• не справиться с разработкой.

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

Buy a feature. Методика основана на принципе геймификации. Проводится среди потенциальных пользователей мобильного приложения. Все функции необходимо оценить по трем критериям:

• время разработки;
• сложность реализации;
• необходимые ресурсы.

Затем для каждой функции назначаем цену. Всем участникам выдаем определенное количество денег в размере от ⅓ до ½ стоимости всех функций и предлагаем купить нужную. Поведение пользователей покажет, какой функционал важен и насколько.

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

I like it — I expect it — I am neutral — I dislike it but can accept it — I dislike it and can not accept it 

На основании ответов строится диаграмма, где:

• attractive — то, что пользователи не ожидают увидеть и чем они восхищаются и готовы поделиться;
• performance — то, что является конкурентным преимуществом;
• must-be — то, что ожидают увидеть в приложении;
• indifferent — то, что не вызывает эмоций у пользователей.

Оси координат обозначают: ось Х — функционал, ось Y — удовлетворенность.

Также каждой функции пользователи присваивают приоритет от 1 до 9 баллов, где 1 - совсем не важно, 9 - очень важно. Кроме этого, каждый вариант ответа имеет свой показатель в баллах:

• I like it — 4;
• I expect it — 2;
• I am neutral — 0;
• I dislike it but can accept it — (-1);
• I dislike it and can not accept it — (-2).

Подсчитываем ответы и получаем точки в системе координат, по которым строится модель.

Оцениваем стоимость

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

Существуют специальные интернет-проекты, которые позволяют выяснить ориентировочную стоимость разработки приложения. Они работают как калькуляторы: отвечаете на вопросы, получаете цену разработки. Популярные проекты:

• Estimate My App;
• How Much To Make An App?;
• Телеграм-бот App Estimator.

Разработка MVP (minimum viable product) занимает примерно от двух недель до четырех месяцев. По оценке портала AppTractor, стоимость разработки MVP в 2017 г. составляет 150-250 тысяч руб. на одну платформу или 350-450 тысяч руб. на обе платформы и серверную часть.

По данным компании Aspirity, стоимость разработки мобильных и веб-продуктов зависит от типа подрядчиков. Самый экономный вариант — договор напрямую с программистом и оплата в «черную».

Разработчик	Цена за час, руб.	Лендинг (50 ч)	MVP (150 ч)	Мобильное приложение на 1 платформу  (300 ч)
Программист, оплата в конверте	550	27 500	82 500	165 000
Программист, оплата через ИП	600	30 000	90 000	180 000
Фрилансер	850	42 500	127 500	255 000
Программист в штате	850	42 500	127 500	255 000
Веб-студия	1300	65 000	195 000	390 000

Тестируем гипотезу

Каждая придуманная идея — гипотеза, которая должна быть подтверждена или опровергнута. Существует ряд методик и тестов. Самый элементарный — «коридорный тест». Основатели рисуют на бумаге макет будущего приложения и выходят с опросом «в коридор», т. е. опрашивают друзей и знакомых, насколько им нравится идея и будут ли они пользоваться таким продуктом. На коридорной стадии отсеиваются самые нежизнеспособные варианты.

Другие способы тестирования предполагают наличие MVP — минимально жизнеспособного продукта. Его создание не должно занимать много времени, но реализация должна включать главные функции приложения. Две основные задачи стоят перед MVP. Первая - дать возможность потребителю оценить продукт. Вторая - собрать информацию для подтверждения или опровержения гипотезы.

MVP для предзаказа. Основная идея тестирования — найти потенциальных покупателей или инвесторов. Создатели могут сделать прототип проекта или разработать сайт, чтобы рассказать о приложении, показать, для чего оно будет создано и какие проблемы решит. После этого попытаться найти желающих купить будущий продукт. Это может быть соглашение о намерениях или предзаказы на краудфандинговых платформах Kickstarter или Planeta.ru. В любом случае создатели ждут от потенциальных покупателей денежных обязательств, а не просто контактных данных в виде имени и телефона.

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

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

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

MVP «Консьерж». Тестирование похоже на «Волшебника страны Оз», но в этом варианте пользователь знает, что с ним работают лично и индивидуально. Здесь разработчики выступают в роли высококвалифицированного консьержа, готового выполнить запросы клиента. «Консьерж» применяют, когда успех приложения зависит от каждого пользователя (например, приложение для работы внутри компании), или основные потребители находятся оффлайн, или невозможно заранее оценить операционные расходы и логистику выполнения услуги. Тестирование позволяет собрать информацию о целевой аудитории и оценить возможности монетизации.

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

Заключение

По данным AppAnnie, количество новых приложений растет в геометрической прогрессии. За октябрь 2017 г. в Google Play было добавлено 150 тысяч новых приложений, в App Store — 50 тысяч. Всего на конец октября 2017 г. суммарное количество мобильных приложений в Google Play и App Store составляет 5,5 млн. В таких условиях добиться успеха новому приложению не просто. Чтобы создать востребованный продукт:

1. Выбирайте идею, опираясь на принципы people, tech, business.  
2. Проводите исследования целевой аудитории до разработки.
3. Включайте в приложение только востребованный функционал.
4. Тестируйте гипотезу с помощью MVP.