Если вы решили, что вашему бизнесу необходимо приложение, то сразу же возникают следующие вопросы: кто будет заниматься этим, сколько времени это займет и сколько это будет стоить? Естественно желание вывести свой продукт на рынок как можно быстрее. Разработчик приложения Yo, рассылающего приветствие контактам из телефонной книги, создал его за 8 часов. И привлёк впоследствии 1 миллион долларов инвестиций. Это, конечно, исключительный случай. Но если полистать страницы органической выдачи, то можно встретить желаемые цифры в несколько недель.
Клиенты, которые раньше не имели дела с разработкой, наоборот, получают от нас коммерческое предложение, видят другое расписание и говорят: “Это не то, что обещал Google!”. Они удивлены. Давайте теперь рассмотрим, при каких условиях можно запустить продукт в короткие сроки.
С чем нужно приходить к команде?
Обратите внимание, что когда вы говорите о запуске через несколько недель, вы говорите только о MVP (минимальном жизнеспособном продукте с минимально необходимыми функциями, представляющими ценность для пользователей). Опубликовав свое приложение в таком формате, вы сможете протестировать свою идею и проверить, действительно ли вашей аудитории нужен мобильный сервис или достаточно адаптированной версии вашего сайта.
Для того чтобы разработать приложение как можно быстрее, важно четко понимать, что хочет получить от него заказчик, для кого оно создается, зачем ему нужен этот сервис и для каких целей он будет его использовать. Лучше всего, если у вас есть подробное и хорошо составленное описание бизнес-логики и функциональности вашего будущего 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, оригинальность и детали дизайна преуменьшаются, мало времени уделяется дизайну интерфейса и иногда используются готовые компоненты. Задачи смещаются в сторону функциональности, а не визуального дизайна.
Конечно, есть проекты, где есть время на подготовку и максимальную проработку дизайна. Конечным пилотом будет рассмотрение всех подводных камней (элементов, которые могут оказаться невыполнимыми) и нахождение баланса между минимальным практичным продуктом и более детальным решением. Анализ рынка и конкурентов, понимание целевой аудитории и изучение пути пользователя существующих и похожих продуктов Недельное исследование может сэкономить месяц времени на разработку. А сколько это будет стоить, можно рассчитать из гонорара подрядчика.
Реальные сроки запуска
Ответ на главный вопрос в начале этого раздела заключается в том, что за две недели можно создать только прототип или адаптировать готовое решение. Если говорить о реальном запуске продукта, то это занимает от двух до трех месяцев или даже больше, в зависимости от услуги, требований и конечной функциональности. Если у вас остались вопросы или у вас есть идея продукта, пожалуйста, свяжитесь с нами для получения дополнительной информации. Для этого свяжитесь с нами любым удобным вам способом – подумаем, как реализовать ваш проект, вместе!
