При огромной конкуренции цифровых продуктов и высокой скорости запуска новых необходимо быстро и дёшево проверять жизнеспособность продуктовых идей. В этой статье я расскажу об опыте создания MVP собственными силами, т.е. фактически силами одного iOS-разработчика. О том, как я искал баланс при создании MVP, об инструментах, сложностях и их решении. Если вы планируете воплотить в жизнь первые проекты в мобильной разработке или хотите добавить новую ветку функционала в уже существующий продукт, то эта статья точно для вас.
Давайте сначала вспомним, что такое МVP.
MVP (minimum viable product — минимально жизнеспособный продукт) — продукт, обладающий минимальными, но достаточными функциями для удовлетворения первых потребителей.
Главная задача MVP — получить обратную связь, чтобы сформировать гипотезы дальнейшего развития и в целом оценить его целесообразность. Т.е. это должно быть максимально дёшево в случае неудачи и при этом жизнеспособно при положительном сценарии. Поэтому основную задачу можно свести к пресловутому поиску баланса на каждом этапе разработки.
Итак, мне нужно было сделать мобильное приложение со следующим набором основных функций:
Минимальные ресурсы для этого проекта — один iOS-разработчик и 2 месяца на разработку и тестирование. Больше похоже на челлендж. Но без паники! Конечно же, я использовал уже готовые наработки. В MVP точно не стоит заниматься разработкой своих библиотек. Так что закладываем несколько дней на подбор готовых решений и необходимых опенсорс-проектов.
Одной из не самых очевидных вещей из минимального набора для MVP является дизайн. Кажется, что для него достаточно перечислить названия экранов и за что они отвечают. Но в действительности же тщательно проработанный интерфейс значительно ускоряет процесс, позволяя разработчику избавиться от многих неопределённостей в работе. Проработка дизайна на ранних этапах даёт более чёткое понимание user flow, позволяет убрать лишнее и сконцентрироваться на минимально достаточном функционале для первой реализации проекта.
Конечно, фокус не должен смещаться в сторону сложных анимаций, но ведь первое впечатление можно произвести только один раз! Поэтому простой, но приятный интерфейс и понятный туториал — то, что нам нужно.
В моём случае финальный дизайн приложения был практически готов к старту разработки.
Наверное, несложно догадаться, что я работал над iOS-клиентом, и это та часть, которую нужно было сохранить и развивать далее в этом проекте. Поэтому закладываем добротную архитектуру и выделяем в модули те самые минимально жизнеспособные части, которые будут заменены на следующих этапах разработки.
Исходя из этих требований также ясно, что приложение нуждается не только в клиенте, но и в базовой логике на backend. Т.е. нужна авторизация, логика присоединения и выхода из них, формирование и менеджмент контента, отправка пуш-уведомлений.
Один из необходимых инструментов — облачная БД. Для этого я сравнил несколько самых популярных вариантов.
Из таблицы выше понятно, что Firebase — это отличное комплексное решение от Google, способное покрыть большинство потребностей разрабатываемого приложения.
Такие решения позволяют держать все элементы управления в одном месте: учётные записи пользователей, список комнат и их настройку, аналитику и информацию о крашах. А в этом случае ещё и можно управлять комнатами и их контентом через админку Firebase — очень удобно. В какой-то момент можно даже подумать, что это реклама, но мне действительно очень понравился и, главное, помог этот набор инструментов.
К тому же сервис бесплатный (при соблюдении лимитов), и для MVP их должно хватить с запасом. Хорошая документация, есть уже куча статей и туториалов по всем сервисам, вплоть до собственных видеоуроков на YouTube, — они просто не оставляют шансов не разобраться.
В итоге из Firebase я взял:
Так выглядит авторизация:
Для поставленных задач было достаточно упрощённой анонимной авторизации, когда пользователю присваивается только уникальный ID.
Так выглядит настройка пуш-уведомлений на клиенте:
Понадобится всего несколько строчек. Нужно подписаться на определённый Topic, на который, в свою очередь, отправляются пуши с бэка.
Так выглядит отправка на TypeScript(JavaScript) через Firebase SDK:
Оставалось только найти дешёвое решение для голосовых конференций, но тут всё оказалось не так очевидно. Firebase, к сожалению, не может покрыть этот функционал.
Основные требования — это кроссплатформенность и простая интеграция. Тут небольшая подборка из подобных инструментов.
Внимание привлёк Jitsi — это опенсорс-проект с поддержкой iOS/Android, аудио и видеочатов на WebRTC. Для начала достаточно их бесплатного хостинга, а в дальнейшем можно переехать. Также сами конференции можно протестировать непосредственно в веб-версии, что очень упростило отладку звонков.
В Jitsi очень простая интеграция и запуск самой конференции. Но после начала звонка конференция управляется уже непосредственно через Webview, программно можно только закончить разговор. На этапе выбора этого инструмента и мысли не возникло, что с помощью доступных из кода методов нельзя, например, сделать mute/unmute. Поэтому пришлось доработать и добавить эти методы в библиотеку, а также настроить взаимодействие с элементами управления. Ещё пришлось подкрутить некоторые параметры под себя. Конечно, ушло чуть больше времени — понадобилась дополнительная неделя, но это всё ещё в разы меньше, чем ушло бы на написание своего решения.
Через полтора месяца приложение было готово, добавили необходимую аналитику для замера интересующих продуктовых показателей. Две недели понадобилось на тестирование и последующие доработки. Таким образом, на разработку ушло 2 месяца, как и планировали. Отмечу, что даже на небольших проектах кажется, что можно ещё что-то поправить, попробовать найти решение лучше. Эти желания уводят от главной задачи MVP.
К сожалению, нужных метрик компания не получила, и это означало закрытие проекта. Но ведь это и есть один из результатов: мы проверили гипотезу, а самое главное — быстро и дёшево.
И ещё раз напомню об основных моментах, которые нужно держать в голове при разработке MVP-приложения под iOS:
Давайте сначала вспомним, что такое М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 можно реализовать на бесплатных платформах;
- комплексные решения сохранят время и минимизируют риски.