Сделать MVP приложения

В рамках набора учащихся на курс "Product Manager IT-проектов" Сергей Колосков подготовил статью.

Приглашаем также всех желающих на бесплатный демо-урок «Как продакт-менеджеру найти метрику роста и свести Unit-экономику?»
За вебинаре участники узнают:
- почему успех продакт-менеджера — это рост главной метрики продукта;
- как определить метрику роста;
- как построить аналитику и продукт вокруг метрики роста;
- научитесь расчету unit-экономики, как это делают продакт-менеджеры;
- что может сделать продакт-менеджер для улучшения unit-экономики.

MVP (Minimum Viable Product – «минимально жизнеспособный продукт») – необходим, чтобы понять, как товар или услуга заскакивает аудитории, при максимальных затратах на воссоздание. Ей не требуются структурные и дизайнерские излишества – всё, что там не будет, работает сурово на бизнес-задача продукта. Концепция MVP уместна, когда нужно отпустить приложение своевременно, понять, что индивидуумы будут им пользоваться, и перепроверить все гипотезы, которые вы переформулировали на этапе строительства. Выбрав её, вы не истратите деньги на скучный аудитории товар. А если интереса не будет, то вы сможете развивать приложение дальше. MVP-версия мобильного дополнения для интернет-магазина должна непременно состоять из главной страницы, справочника с поиском, корзины и функции выплаты. Добавлять мультипликацию, подключать сторонние call-центры, предлагать насколько способов выплаты и внедрять дополненную или онлайновую реальность поздно. Убедитесь, что в дополнении покупают, а дальнейший анализ продемонстрирует, что ещё нужно юзеру. Если вы магазин, продающий цветы, то в приложении вашем должен быть список цветов, корзина (возможность купить) и доставка. Не надо делать социальную сеть любителей цветов, оплату Apple Pay, дизайн от «Студии Лебедева» и подбор букетов с помощью искусственного интеллекта. Ваша цель — начать продавать цветы в мобильном приложении, а все остальное перечисленное — приятное, но очень дорогое дополнение, которое, если вы захотите, можно будет реализовать позднее. Если вы определяете минимум функций для своего приложения, то, скорее всего, они давно решены подрядчиком и стоят вменяемых денег. Вы сэкономите (сколько точно, сказать трудно — разброс между тем, что нужно, и тем, что хочет заказчик, иногда разителен) и получите работающий продукт.

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

iOS или Android: что лучше выбрать

На разработке приложения можно сэкономить в два и более раза, если делать приложение только под одну платформу – iOS или Android. За айфоны:

• юзеры приложения для iOS более платежеспособны;

• типов устройств не очень много;

• высокие показатели обновляемости софта;

• более сильная защита от хакеров;

• в сторе более качественный и модерируемый контент.

Но окончательный разбор платформы обусловлен миссии прибавления и его аудитории. Желаете приобретать и делаете ставку для реальных пользователей? Предпочитайте iOS. Создаёте продукт, ориентированный для массы сиречь регионы, обитатели каких не пристрастились сиречь не имеют возможности выплачивать после числовые продукты? Осуществляете гарантийное использование ради курьеров и трейдерских поверенных не можете допустить себе драгоценный склад устройств? Предпочитайте Android. Желаете схватить мир? Предпочитайте двух платформы.

Кроссплатформенные приложения: что это и как экономит деньги

Подход к разработке приложения может быть нативным и кроссплатформенным. Нативные приложения создаются на конкретном языке программирования для конкретной платформы: языки Java и Kotlin — для Android, а Swift не ниже третьей версии — для iOS. Достоинства: прямой доступ к аппаратной части устройства; привычный для пользователей платформы интерфейс. Недостаток: высокая стоимость разработки и поддержки из-за привлечения минимум одного разработчика для каждой платформы. Кроссплатформенные разработка мобильных приложений осуществляется с помощью веб-технологий. Чтобы написанный код заработал на мобильных устройствах, его нужно либо «перевести» на понятный им язык, либо сделать прослойку, которая работает на устройстве и переводит обращения к функциям устройства с непонятного для них языка на понятный. Делать проект можно нативными средствами, а можно на кроссплатформенном фреймворке. «Натив» позволяет решить практически любую техническую проблему, сделать приложение очень шустрым и красивым. Минус один — длительность и стоимость разработки. С «кроссплатформой» все совсем по-другому. Она делится как минимум на два типа: первый — это просто web-view с сайтиком внутри, который напоминает мобильное приложение, второй — более продвинутый вариант, когда все элементы интерфейса реализованы нативно, а вот логика как раз на ином, не нативном, языке. Во второй категории идет ReactNative, NativeScript, Xamarin. Из плюсов — опять же высокая скорость разработки, нативные интерфейсные элементы, быстрая работа приложения, возможность подключения нативных библиотек и компонентов. Достоинство: низкая стоимость разработки и поддержки из-за привлечения одного веб-разработчика.

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

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

Как сэкономить на бэк-энде

Большинство прибавлений функционирует с данными: воспринимает через пользователя, отдаёт на сервер. Расходы можно сократить:

1. Хранить данные на стороне клиента, то есть в устройстве. В таком случае для работы приложения не нужен интернет, но так оно лишается интерактивности

2. Использовать бессерверную архитектуру приложений

3. Работать с данными через интеграции с бесплатными инструментами (гугл-таблицами, чатами в телеграм)

Экономия с помощью зерокод-инструментов

Растущий рынок мобильных приложений в какой-то момент не мог не предложить малому и среднему бизнесу создавать приложения в конструкторах и генераторах.

Такой подход создания собственного мобильного приложения позиционируется как не требующий никаких знаний о программировании: пользователь конструктора работает в редакторе, где выбирает шаблон интерфейса мобильного приложения, подключает чат, монетизацию, программу лояльности, push-уведомления, аналитику, интегрирует его с соцсетями и сторонними сервисами и т. п. Зачем нужно приложение на конструкторе? Чтобы осмотреться в мобильной среде, увидеть востребованность бизнес-идеи в ней, а если она есть, то это будет зелёным светом к разработке приложения с нуля. Конструкторы для создания мобильных приложений делятся на два типа:

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

2. Такие, в которых создатели этих конструкторов работают сами, собирая приложение под определённого клиента.

Сэкономить на мобильной разработке с помощью маркетплейсов

Молодому бизнесу может интереснее подключиться к маркетплейсу. Например, ресторан могут не делать своё приложение, а завести аккаунт на Яндекс.Еде, а производитель обуви – в маркетплейсе Ozon. Став партнёром, магазин платит площадке комиссию с каждой продажи. В силу того, что процессом купли-продажи товара или услуги управляет маркетплейс, у вас не получится выстроить с пользователем близких отношений. Напомним, что решение идеально, чтобы протестировать спрос – остального вы добьётесь за счёт своего приложения.

PWA вместо приложения

Progressive Web App — это не просто сайт: открывается в мобильном браузере, посылает push-уведомления, иметь доступ к некоторым аппаратным частям устройства и открываться с рабочего стола через клик на иконку. При этом места на устройстве он занимает меньше. За эти годы появилось уже достаточно кейсов, подтверждающих, что PWA играют на руку бизнесу: пользователям нравится тот опыт, который они получили от приложения, и они продолжают им пользоваться, нести трафик и покупать товары. От скорости загрузки PWA-версий сайта выиграли Lancome, Tinder, Uber, Pinterest и другие известные продукты.

Чего делать не нужно:

• Не экономьте на начальном этапе. Продумайте ваш будущий сервис, как он должен работать, на чем вы будете зарабатывать? И миллион других вопросов. Найдите толкового аналитика еще до того, как вы приняли решение что-то делать. Проведите полноценное тестирование самой идеи. Возможно, вам и не нужно никакое мобильное приложение.

• Нельзя экономить на тестировании. Если вы не «Сбербанк», то один-два бага в приложении — и пользователя вы потеряли навсегда.

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

Узнать подробнее о курсе "Product Manager IT-проектов".

Смотреть вебинар «Как продакт-менеджеру найти метрику роста и свести Unit-экономику?»