Разработчик приложения Yo, рассылающего приветствие контактам из телефонной книги, создал его за 8 часов. И привлёк впоследствии 1 миллион долларов инвестиций. Интересная история, которую знают далеко не все заказчики, но многие из них видели в органической выдаче тоже достаточно сжатые сроки.
Когда вы решили, что ваш бизнес нуждается в приложении, логичные вопросы — сколько стоит и когда сделают? Если человек ранее не сталкивался со сферой разработки, то, получая нашу оценку, он будет удивлен: ведь гуглились-то сроки меньше! Поэтому сегодня рассказываем, какие условия должны совпасть, чтобы можно было разработать приложение за несколько недель.
Какой нужен бэкграунд?
Сразу обозначим — так быстро делают только MVP. Это минимально жизнеспособный продукт, в котором будет необходимый для пользователя функционал и представляющий для него ценность. В этом состоянии приложение можно публиковать, протестировать таким образом свою идею, понять, действительно ли ваша целевая аудитория нуждается в мобильном продукте, будет ли она туда переходить или останется на адаптированном сайте.
Для стремительного запуска нужно отчетливо представлять, какое приложение должно получиться на выходе, для кого оно и какие цели с его помощью бизнес будет достигать. Идеальный вариант — это наличие прописанной бизнес-логики и функций нужного вам продукта. Нам, разработчикам, подойдет техническое задание, тексто-графическое описание, кликабельный прототип, низкоуровневые макеты экранов, варфреймы — любые такого рода материалы улучшат взаимопонимание между бизнес-заказчиком и командой, создающей приложение.
Как будем разрабатывать?
Когда сроки горят и запуститься нужно за несколько недель, наиболее реальным вариантом будет no/low-code разработка или webview-основа. Но при этом важно, чтобы решение бизнес-задач не требовало детальной адаптации шаблонных решений. Разработка MVP с нуля же потребует 1-2 месяцев минимум — нативно или кроссплатформенно. Webview компонент — это история про встраивание сайта внутрь приложения. Это быстро, несложно, но в мобильных сторах такое не любят сами поставщики операционных систем. По их мнению, дополнительной функциональности пользователю такой вариант приложения не дает.
Готовые варианты быстрой сборки существуют для определенных популярных сфер: e-commerce, доставка, ed-tech, информационные системы, каталоги. Если бизнес относится к этой нише и не требует кастомизированных функций, то можно разрабатывать приложение с применением таких шаблонов.
Если проект достаточно сложный, то за несколько недель можно создать прототип для тестирования какой-либо функции. Скорее всего, это решение будет ограничено в своих возможностях, но будет демонстрировать, как с помощью тех или иных элементов пользователь будет взаимодействовать с вашей компанией, покажет, насколько корректно работают задействованные готовые библиотеки. Это будет все же больше похоже на исследование, чем на полноценную разработку приложения, но такая аналитика сэкономит в будущем временные и финансовые ресурсы.
PWA (Progressive Web Apps) — это еще одна технология, способная в краткие сроки решить вопрос разработки приложения для бизнеса. По сути, это установка сайта на телефон как приложения. С помощью PWA-продукта можно протестировать несложные гипотезы: нужны ли аудитории пуш-уведомления и будут ли они играть какую-то роль для маркетинга, ценен для клиента такой формат отдельного внебраузерного сервиса. PWA-приложения умеют использовать геолокацию, микрофон, камеру устройства пользователя, и не требуют постоянного подключения к интернету.
Как правило, при разработке MVP приложения мы отказываемся от ряда периферийных функций, которые увеличивают срок разработки, но могли бы улучшать пользовательский опыт взаимодействия с вашим приложением. Например, если в нем есть каталог, но количество позиций в нем ограничено какой-то разумной цифрой, то можно на начальных этапах отказаться от поиска и фильтрации. Безусловно, когда каталог — это основная составляющая сервиса с широкой товарной матрицей, сложно пренебрегать фильтрами. Но если в приоритете сжатые сроки, к этому нужно быть готовым и перенести данные задачи в бэклог, к следующим релизам. Это нормальный и практически всегда оправданный подход для выпуска MVP. Если ваша гипотеза оказалась ошибочной и продукт не будет дальше реализовываться или потребует значительной переработки, то вы потратите значительно меньше ресурсов, чем могли бы, если бы сразу запускали все задуманные вами фичи.
А можно задачи закрывать параллельно?
У разных команд разные подходы. Процессы, в целом, могут вестись как последовательно, так и параллельно. Традиционно сначала идет техническое задание, а потом отрисовывают дизайн. Но есть и те, кто сначала разрабатывает макеты, а ТЗ представлено в минимальном виде или вообще отсутствует. Бессмысленно заявлять, какой из вариантов единственно правильный — оценивать нужно итоговый продукт.
Если использовать гибкий подход, agile, то по нему разработка может быть начата еще в процессе написания ТЗ. Реализацию разбиваем на спринты, под каждый спринт свое описание работ. Таким образом, ТЗ, дизайн и разработка ведутся итерациями, без детальной проработки всей логики сервиса заранее.
Чем рискуем?
Важно помнить, что при запуске MVP как правило отдается приоритет задачам базовой функциональности, а не проработки визуала. Публикуемый впервые продукт может быть еще относительно сырым, потому что для сокращения сроков и удешевления реализации пренебрегают детализацией дизайна, меньше времени занимаются проектированием интерфейса.
Конечно, бывают и проекты, когда удается проработать дизайн полноценно. Идеальный вариант — найти баланс между минимальным работоспособным функционалом и подробным решением, проанализировав ценность тех или иных нереализованных элементов. Но в этом случае нужно проводить серьезную предпроектную работу со стороны заказчика: изучить конкурентов, исследовать целевую аудиторию, понять, каким будет пользовательский путь в вашем приложении. Лишняя неделя такого исследования может сэкономить месяц разработки.
Короткий ответ на главный вопрос
За две недели получится сделать прототип или адаптировать шаблонное решение. Реальные кейсы запуска продукта — 2-3 месяца в среднем, и более, в зависимости от индивидуального наполнения сервиса. Обсудить с нами своей проект можно по любым контактам отсюда: https://appcraft.pro/.
#бизнес #разработка приложений #разработка #приложения #диджитал #маркетинг #цифровизация