Если вы решили, что вашему бизнесу нужно приложение, то вслед за этим возникают вопросы: кто его сделает, как быстро и сколько это будет стоить? Совершенно логично, что выпустить продукт на рынок хочется поскорее. Разработчик приложения Yo, которое отправляет приветствие контактам из телефонной книги, создал его за 8 часов. И привлёк впоследствии 1 миллион долларов инвестиций. Это, конечно, исключительный случай. Но если полистать страницы органической выдачи, то можно встретить желаемые цифры в несколько недель. 

Заказчик, который не имел до этого дела со сферой разработки, в свою очередь, получая оценку от нас и видя иные сроки, удивляется –  ведь Google обещал ему другое! Давайте же разбираться, при каких условиях можно запустить продукт в сжатые сроки.

Что нужно принести команде?

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

Чтобы разработка приложения шла как можно быстрее, заказчику необходимо иметь четкое понимание того, что он хочет получить на выходе, для кого он его создает, зачем нужен этот сервис и какие цели он должен достичь. Замечательно, если у вас есть полноценно проработанное описание бизнес-логики и функционала будущего MVP.

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

Что вам может предложить команда разработки? 

Если речь идет о запуске в течение нескольких недель, то скорее всего, это будут либо варианты no-code/low-code разработки или продукт на основе webview. Шаблонное готовое решение на базе no/low-code вполне возможно использовать, когда адаптировать нужно будет минимально – и в рамках нескольких недель это реально. При разработке MVP с 0 стоит стоит рассчитывать на сроки от 1-2 месяцев, чтобы создать индивидуальное решение нативно или кроссплатформенно. В сжатые сроки возможно создание сервиса на webview – компоненте, позволяющем встраивать сайт внутрь приложения. Это делается весьма быстро, но имеет ряд своих недостатков, например, риск проблем с публикацией такого приложения в магазинах. Сами поставщики операционных систем борются с проектами, которые, по их мнению, не предоставляют функциональность пользователю. Шаблонные решения подходят проектам, которые представляют собой e-commerce, доставку, ed-tech, информационные системы, каталоги – эти сферы достаточно популярны уже не один год и для них уже разработаны варианты быстрой сборки.

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

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

Еще один доступный вариант – PWA (Progressive Web Apps). Это технология, позволяющая вашему клиенту установить сайт на телефон как приложение. Она подходит компаниям, которым нужно проверить в минимальные сроки, насколько формат приложения может быть ценен для целевой аудитории, попробовать отправлять push-уведомленя, протестировать какие-то другие несложные гипотезы. Кроме того, PWA-приложение может использовать в устройстве пользователя геолокацию, микрофон, камеру, его не нужно публиковать в магазинах, можно скачать из браузера, а также оно не требует постоянного подключения к интернету. Технология PWA может быть полезна для запоминаемости бренда: логотип постоянно на экране пользователя, вдобавок опция отправки push-уведомлений экономит затраты на ремаркетинговые кампании, ведь для части целевой аудитории предложение может быть доставлено с помощью уведомления.

Чаще всего при выпуске MVP мы отказываемся от периферийных функций, которые вообще-то хорошо бы, чтобы были. Они помогают сделать пользовательский опыт взаимодействия с приложением более позитивным. К примеру, поиск и фильтрация по каталогу: при создании каталога на начальных этапах мы можем не реализовывать поиск в нем, предполагая, что количество позиций будет ограничено и инструмент не потребуется. Конечно, там, где каталог является ключевой составляющей, и, где более 1000 позиций, пренебречь поиском и фильтрацией при разработке будет сложно. Но, тем не менее, это периферийные функции. Их переносят в бэклог, планируют к следующим релизам. Поэтому в таких сжатых по срокам запусках нужно быть готовым, что объем функций будет урезаться. Это нормально, это правильный подход для MVP, и он практически всегда оправдан. Запуск нового продукта – это всегда проверка, и, если гипотеза оказалась неверной, вы, в свою очередь, потратите меньше ресурсов, чем могли бы, реализуя много дополнительных функций к той основной фиче, которая может не сыграть для вашей аудитории.

Можно ли оптимизировать менеджмент процессов? 

В целом процессы могут вестись как угодно: и в связке, и в последовательности, и параллельно. Разные компании применяют разные подходы. Каноничная история – это сначала техническое задание, потом дизайн. А есть ряд команд, которые сначала делают дизайн, прорабатывают макеты, а ТЗ в этом процессе отсутствует либо идёт в сжатом виде. Дизайн имеет первичную форму и для заказчика, и для команды разработки. И бессмысленно спорить, что, в данном случае, лучше, что хуже – оценивать нужно результат. 

Разработка может быть начата еще до завершения написания технического задания. Этому соответствует принцип гибкого подхода, Agile, который мы применяем в своей работе. Мы разбиваем реализацию на отдельные спринты, под каждый спринт готовим свое описание. Это позволяет не прорабатывать всю логику сервиса на начальном этапе (если по задаче нет большого количества времени и ресурсов), а итерациями готовить ТЗ, дизайн и вести разработку.

Какие риски нужно учитывать? 

Нередко вместе с сокращением сроков запуска стоит задача и удешевления реализации. Надо понимать, что в большинстве случаев MVP  – это продукт относительно сырой с точки зрения детализации и наполнения дополнительными периферийными функциями. Для целей запуска MVP могут пренебрегать уникальностью и детализацией дизайна, меньше времени уделяется проектированию интерфейса, используются какие-то готовые компоненты. Задачи смещаются в сторону функциональности, а не проработки визуала. 

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

Реальные сроки запуска

Отвечаем на главный вопрос, с которого начали: за две недели можно сделать только прототип, либо адаптировать готовое решение . Когда мы говорим про реальные кейсы выпуска продукта на рынок, то речь будет идти о 2-3 месяцах и более, в зависимости от наполнения сервиса, требований к нему и конечной функциональности.

Если у вас остались вопросы или есть идея продукта, мы можем обсудить ее детально. Для этого заполните форму ниже или свяжитесь с нами любым удобным вам способом – подумаем, как реализовать ваш проект, вместе!