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



Давайте сначала вспомним, что такое МVP.

MVP (minimum viable product — минимально жизнеспособный продукт) — продукт, обладающий минимальными, но достаточными функциями для удовлетворения первых потребителей.

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

Функционал приложения

Итак, мне нужно было сделать мобильное приложение со следующим набором основных функций:

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

Время и человеческие ресурсы

Минимальные ресурсы для этого проекта — один iOS-разработчик и 2 месяца на разработку и тестирование. Больше похоже на челлендж. Но без паники! Конечно же, я использовал уже готовые наработки. В MVP точно не стоит заниматься разработкой своих библиотек. Так что закладываем несколько дней на подбор готовых решений и необходимых опенсорс-проектов.

Дизайн

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

Конечно, фокус не должен смещаться в сторону сложных анимаций, но ведь первое впечатление можно произвести только один раз! Поэтому простой, но приятный интерфейс и понятный туториал — то, что нам нужно.

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

Архитектура

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

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

Поиск решения

Один из необходимых инструментов  —  облачная БД. Для этого я сравнил несколько самых популярных вариантов.



Из таблицы выше понятно, что Firebase — это отличное комплексное решение от Google, способное покрыть большинство потребностей разрабатываемого приложения. 

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

К тому же сервис бесплатный (при соблюдении лимитов), и для MVP их должно хватить с запасом. Хорошая документация, есть уже куча статей и туториалов по всем сервисам, вплоть до собственных видеоуроков на YouTube, — они просто не оставляют шансов не разобраться.

В итоге из Firebase я взял:

• авторизацию ‘Firebase/Auth';
• облачную БД ‘Firebase/Firestore’;
• бэкенд ‘Firebase/Functions’;
• хранилище ‘Firebase/Storage’;
• аналитику ‘Firebase/Analytics’;
• репорт крашей ‘Crashlytics’.

Так выглядит авторизация:



Для поставленных задач было достаточно упрощённой анонимной авторизации, когда пользователю присваивается только уникальный ID.

Так выглядит настройка пуш-уведомлений на клиенте:



Понадобится всего несколько строчек. Нужно подписаться на определённый Topic, на который, в свою очередь, отправляются пуши с бэка.

Так выглядит отправка на TypeScript(JavaScript) через Firebase SDK:



Оставалось только найти дешёвое решение для голосовых конференций, но тут всё оказалось не так очевидно. Firebase, к сожалению, не может покрыть этот функционал. 

Основные требования — это кроссплатформенность и простая интеграция. Тут небольшая подборка из подобных инструментов.

Внимание привлёк Jitsi — это опенсорс-проект с поддержкой iOS/Android, аудио и видеочатов на WebRTC. Для начала достаточно их бесплатного хостинга, а в дальнейшем можно переехать. Также сами конференции можно протестировать непосредственно в веб-версии, что очень упростило отладку звонков.



В Jitsi очень простая интеграция и запуск самой конференции. Но после начала звонка конференция управляется уже непосредственно через Webview, программно можно только закончить разговор. На этапе выбора этого инструмента и мысли не возникло, что с помощью доступных из кода методов нельзя, например, сделать mute/unmute. Поэтому пришлось доработать и добавить эти методы в библиотеку, а также настроить взаимодействие с элементами управления. Ещё пришлось подкрутить некоторые параметры под себя. Конечно, ушло чуть больше времени — понадобилась дополнительная неделя, но это всё ещё в разы меньше, чем ушло бы на написание своего решения. 

Итоги

Через полтора месяца приложение было готово, добавили необходимую аналитику для замера интересующих продуктовых показателей. Две недели понадобилось на тестирование и последующие доработки. Таким образом, на разработку ушло 2 месяца, как и планировали. Отмечу, что даже на небольших проектах кажется, что можно ещё что-то поправить, попробовать найти решение лучше. Эти желания уводят от главной задачи MVP.

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

И ещё раз напомню об основных моментах, которые нужно держать в голове при разработке MVP-приложения под iOS:

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