Сделать MVP приложения
В рамках набора учащихся на курс "Product Manager IT-проектов" Сергей Колосков подготовил статью.
Приглашаем также всех желающих на бесплатный демо-урок «Как продакт-менеджеру найти метрику роста и свести Unit-экономику?»
За вебинаре участники узнают:
- почему успех продакт-менеджера — это рост главной метрики продукта;
- как определить метрику роста;
- как построить аналитику и продукт вокруг метрики роста;
- научитесь расчету unit-экономики, как это делают продакт-менеджеры;
- что может сделать продакт-менеджер для улучшения unit-экономики.
MVP (Minimum Viable Product – «минимально жизнеспособный продукт») – необходим, чтобы понять, как товар или услуга заскакивает аудитории, при максимальных затратах на воссоздание. Ей не требуются структурные и дизайнерские излишества – всё, что там не будет, работает сурово на бизнес-задачу продукта. Концепция MVP уместна, когда нужно отпустить приложение своевременно, понять, что индивидуумы будут им пользоваться, и перепроверить все гипотезы, которые вы переформулировали на этапе строительства. Выбрав её, вы не истратите деньги на скучный аудитории товар. А если интереса не будет, то вы сможете развивать приложение дальше. MVP-версия мобильного дополнения для интернет-магазина должна непременно состоять из главной страницы, справочника с поиском, корзины и функции выплаты. Добавлять мультипликацию, подключать сторонние call-центры, предлагать насколько способов выплаты и внедрять дополненную или онлайновую реальность рано. Убедитесь, что в дополнении покупают, а дальнейший анализ продемонстрирует, что ещё нужно юзеру. Если вы магазин, продающий цветы, то в вашем приложении должен быть список цветов, корзина (возможность купить) и доставка. Не надо делать социальную сеть любителей цветов, оплату Apple Pay, дизайн от «Студии Лебедева» и подбор букетов с помощью искусственного интеллекта. Ваша цель — начать продавать цветы в мобильном приложении, а все остальное перечисленное — приятное, но очень дорогое дополнение, которое, если вы захотите, можно будет реализовать позднее. Если вы определяете минимум функций для своего приложения, то, скорее всего, они давно решены подрядчиком и стоят вменяемых денег. Вы сэкономите (сколько точно, сказать трудно — разброс между тем, что нужно, и тем, что хочет заказчик, иногда разителен) и получите работающий продукт.
Сложностей в данном варианте особых нет. Главное — не забывать предупредить пользователя, что это лишь один из релизов, функционал еще реализован не полностью, наберитесь терпения.
iOS или Android: что лучше выбрать
На разработке приложения можно сэкономить в два и более раза, если делать приложение только под одну платформу – iOS или Android. За айфоны:
юзеры приложения для iOS более платежеспособны;
типов устройств не очень много;
высокие показатели обновляемости софта;
более сильная защита от хакеров;
в сторе более качественный и модерируемый контент.
Кроссплатформенные приложения: что это и как экономит деньги
Подход к разработке приложения может быть нативным и кроссплатформенным. Нативные приложения создаются на конкретном языке программирования для конкретной платформы: языки Java и Kotlin — для Android, а Swift не ниже третьей версии — для iOS. Достоинства: прямой доступ к аппаратной части устройства; привычный для пользователей платформы интерфейс. Недостаток: высокая стоимость разработки и поддержки из-за привлечения минимум одного разработчика для каждой платформы. Кроссплатформенные разработка мобильных приложений осуществляется с помощью веб-технологий. Чтобы написанный код заработал на мобильных устройствах, его нужно либо «перевести» на понятный им язык, либо сделать прослойку, которая работает на устройстве и переводит обращения к функциям устройства с непонятного для них языка на понятный. Делать проект можно нативными средствами, а можно на кроссплатформенном фреймворке. «Натив» позволяет решить практически любую техническую проблему, сделать приложение очень шустрым и красивым. Минус один — длительность и стоимость разработки. С «кроссплатформой» все совсем по-другому. Она делится как минимум на два типа: первый — это просто web-view с сайтиком внутри, который напоминает мобильное приложение, второй — более продвинутый вариант, когда все элементы интерфейса реализованы нативно, а вот логика как раз на ином, не нативном, языке. Во второй категории идет ReactNative, NativeScript, Xamarin. Из плюсов — опять же высокая скорость разработки, нативные интерфейсные элементы, быстрая работа приложения, возможность подключения нативных библиотек и компонентов. Достоинство: низкая стоимость разработки и поддержки из-за привлечения одного веб-разработчика.
Недостатки: необходимость доработки интерфейса для каждой платформы согласно гайдлайнам; трудности в достижении правильной работы всех нужных функций; медлительность, поэтому подходит для разработки только простых приложений.
Кроссплатформенная разработка поможет вам сэкономить в том случае, если вы создаёте простое приложение, проверяете гипотезы или у вас есть свой веб-разработчик. В остальных случаях рекомендуем выбирать нативную разработку.
Как сэкономить на бэк-энде
Большинство прибавлений функционирует с данными: воспринимает через пользователя, отдаёт на сервер. Расходы можно сократить:
Хранить данные на стороне клиента, то есть в устройстве. В таком случае для работы приложения не нужен интернет, но так оно лишается интерактивности
Использовать бессерверную архитектуру приложений
Работать с данными через интеграции с бесплатными инструментами (гугл-таблицами, чатами в телеграм)
Экономия с помощью зерокод-инструментов
Растущий рынок мобильных приложений в какой-то момент не мог не предложить малому и среднему бизнесу создавать приложения в конструкторах и генераторах.
Такой подход создания собственного мобильного приложения позиционируется как не требующий никаких знаний о программировании: пользователь конструктора работает в редакторе, где выбирает шаблон интерфейса мобильного приложения, подключает чат, монетизацию, программу лояльности, push-уведомления, аналитику, интегрирует его с соцсетями и сторонними сервисами и т. п. Зачем нужно приложение на конструкторе? Чтобы осмотреться в мобильной среде, увидеть востребованность бизнес-идеи в ней, а если она есть, то это будет зелёным светом к разработке приложения с нуля. Конструкторы для создания мобильных приложений делятся на два типа:
Такие, в которых люди без знаний о дизайне и разработке смогут что-то сделать самостоятельно.
Такие, в которых создатели этих конструкторов работают сами, собирая приложение под определённого клиента.
Сэкономить на мобильной разработке с помощью маркетплейсов
Молодому бизнесу может интереснее подключиться к маркетплейсу. Например, ресторан могут не делать своё приложение, а завести аккаунт на Яндекс.Еде, а производитель обуви – в маркетплейсе Ozon. Став партнёром, магазин платит площадке комиссию с каждой продажи. В силу того, что процессом купли-продажи товара или услуги управляет маркетплейс, у вас не получится выстроить с пользователем близких отношений. Напомним, что решение идеально, чтобы протестировать спрос – остального вы добьётесь за счёт своего приложения.
PWA вместо приложения
Progressive Web App — это не просто сайт: открывается в мобильном браузере, посылает push-уведомления, иметь доступ к некоторым аппаратным частям устройства и открываться с рабочего стола через клик на иконку. При этом места на устройстве он занимает меньше. За эти годы появилось уже достаточно кейсов, подтверждающих, что PWA играют на руку бизнесу: пользователям нравится тот опыт, который они получили от приложения, и они продолжают им пользоваться, нести трафик и покупать товары. От скорости загрузки PWA-версий сайта выиграли Lancome, Tinder, Uber, Pinterest и другие известные продукты.
Чего делать не нужно:
Не экономьте на начальном этапе. Продумайте ваш будущий сервис, как он должен работать, на чем вы будете зарабатывать? И миллион других вопросов. Найдите толкового аналитика еще до того, как вы приняли решение что-то делать. Проведите полноценное тестирование самой идеи. Возможно, вам и не нужно никакое мобильное приложение.
Нельзя экономить на тестировании. Если вы не «Сбербанк», то один-два бага в приложении — и пользователя вы потеряли навсегда.
Инхаус разработка — это не про экономию. Иногда компании принимают решение делать мобильное приложение своими силами. Это кажется странным, ведь для ведения даже не самого сложного проекта в штате должны быть менеджер проектов, аналитик, дизайнер, собственно разработчик, инженер по тестированию, почти всегда нужен и бэкенд-разработчик для интеграции приложения в инфраструктуру, часто нужны и фронтенд-программисты. Такое расточительное решение имеет смысл, когда мобильное приложение становится предельно значимым каналом работы с клиентом. Например, именно так поступает «Альфа-Банк».
Узнать подробнее о курсе "Product Manager IT-проектов".
Смотреть вебинар «Как продакт-менеджеру найти метрику роста и свести Unit-экономику?»
