Если вы решили, что вашему бизнесу нужно приложение, то вслед за этим возникают вопросы: кто его сделает, как быстро и сколько это будет стоить? Совершенно логично, что выпустить продукт на рынок хочется поскорее. Разработчик приложения 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). Это технология, позволяющая вашему клиенту установить сайт на телефон как приложение. Она подходит компаниям, которым нужно проверить в минимальные сроки, насколько формат приложения может быть ценен для целевой аудитории, попробовать отправлять пуши, протестировать какие-то другие несложные гипотезы. Кроме того, PWA-приложение может использовать в устройстве пользователя геолокацию, микрофон, камеру, его не нужно публиковать в сторах, можно скачать из браузера, а также оно не требует постоянного подключения к интернету. Технология PWA может быть полезна для запоминаемости бренда: лого постоянно на экране пользователя, вдобавок опция отправки пушей экономит затраты на ремаркетинговые кампании, ведь части целевой аудитории предложение может быть доставлено с помощью уведомления. 

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

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

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

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

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

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

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

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

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