company_banner

MVP силами одного разработчика

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

    image

    Давайте сначала вспомним, что такое М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 можно реализовать на бесплатных платформах;
    • комплексные решения сохранят время и минимизируют риски.
    FunCorp
    Разработка развлекательных сервисов

    Комментарии 5

      +2
      А прикручивали Sign in with Apple? Сейчас же это, вроде как, обязательное требование для публикации.

      Мне еще предстоит создавать backend для своего проекта, предварительно наметил использование Firebase, но пока не очень понятно. Например, любопытно, можно ли расширить предоставляемые Google возможности по аутентификации, например, авторизация через социальные сети, типа VK, ну собственно, Sign in with Apple. Был бы благодарен за подсказку, где об этом можно почитать.
        +2
        Мы использовали упрощенную авторизацию, поэтому обошлись без нее.

        Sign in with Apple обязательна если вы реализуете вход через другие соцсети. Apple авторизация уже есть в Firebase Authentication, чего не скажешь например про VK и другие. Для реализации этого возможно вам поможет firebase.google.com/docs/auth/ios/custom-auth.
          0

          А какой сервис аналитики для «замера интересующих продуктовых показателей» вы использовали?

            0
            Также использовали Firebase analytics.
            0
            А монетизацию подключали? Если там было что-то сложнее просто оплаты в магазине (особенно интересны подписки), то было бы интересно почитать подробнее.

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

            Самое читаемое