Бизнес требования для мобильного приложения

1. Бизнес-требования к мобильному приложению CLAIRE’S

2.

Целевая аудитория и возрастная категория
ЦА: девушки от 12 до 18+ лет
Покупательница Claire’s – модная и современная, любит международные
бренды, использует ювелирные украшения и бижутерию для собственного
самовыражения, наслаждается процессом покупки в наших магазинах и
открывает новые стили для себя. Ее жизненная позиция – «COOL GIRL».

3. Стратегия и бизнес-цели

Бизнес-цели
• Привлечение новых клиентов
• Стимулирование продаж
• Развитие лояльности
Стратегия стимулирования пользования приложением
• Приложение распространяется среди постоянных клиентов c элементами геймификации (получение баллов за
определенные действия – шеринг в соцсетях, отзывы, заполнение профиля, «Приведи друга», первое
бронирование заказа и т.д.)
• Это каталог, путешествие по которому станет познавательным приключением
• Приложение является альтернативой Карты – не надо носить с собой карту, есть под рукой
• Обмен баллов на подарки (на сувениры, продукцию CLAIRE’S)

4. User story

Бизнес-требования
Карта CLAIRE’S – карта в приложении. Используются элементы геймификации – «карта достижений»,
приложение может стимулировать пользователя к заказу, если ему остается немного баллов до нового
достижения.
Клуб CLAIRE’S – получение баллов за каждые действия и обмен на подарки.
Список магазинов – магазины списком и на карте, информация о каждом магазине, товарах, акциях
Социальное взаимодействие – можно поделиться приложением с другом и получить дополнительный бонус
к сумме накопления за установку нового приложения или шеринг в соц.сетях, отзывы, комментарии, опросы
Обратная связь – можно дать оценку магазину и обслуживанию после посещения, связаться по чату/
телефону/емейл
Push-уведомления – возможность сообщать пользователю об акции или брошенной корзине, поздравить с
днем рождения и пр., GEO-PUSH – когда находятся рядом с магазином.

5. Приложения для анализа

Приложения для анализа были отобраны по совокупности факторов:
— Известность бренда;
— Аналогичная целевая аудитория;
— Современный и удобный интерфейс;
— Наличие большинства функций, планируемых к реализации
VALTERA
Азбука вкуса
Girls Dress Up

6. Информационная структура приложения

1-й этап
0. Экран загрузки
Welcome
2-й этап
3-й этап
4-й этап
1.Главный экран
Программа
лояльности
Карта
Информация
Получить баллы
Оформить карту
Акции
Показать карту
Новости
Заказ
Магазины
Ввод номера
телефона
Ввод кода
подтверждения
Потратить баллы
Профиль
пользователя
Добавить фото или
выбрать из галереи
(или коненект с
соцсетью)
Изменить
персональные
данные
Запрос на доступ к
данным
Магазин
поощрений
Изменить
персональные
данные
Push-нотификации
Карточка товара
На карте
Страницы
Избранное
Схемы
Контакты
Социальная
активность
Ассортимент
Ассортимент
Ассортимент
Корзина
Бронирование в
магазине
5-й этап

7. Общие функции

8. 0.Экран загрузки

приветствие Welcome
регистрация/авторизация в Клубе
для информирования Клиента
для публикаций акций и предложений
интересной информации
получения ежедневных бонусов
вход по промокоду
интеграция с соцсетью

9. 1. Главный экран. Основная навигация

Архитектура основного экрана требует
дальнейшей проработки с учетом
карты пользовательских путей.
Внутри – оверлей с подсказками
обязательно при первой регистрации.

10. Профиль пользователя/ Запрос на доступ к данным

ФИО
Дата рождения
Город/регион
Телефон
Емейл
Добавить фото (коннект с соцсетью)
Согласие на коммуникацию

11. Изменить персональные данные

• через звонок
• автоматическое
• полуавтоматическое обновление данных в базе клиентов из мобильного приложение

12. Социальная активность

• кнопки соцсетей, комментарии к товарам, шеринг и т.д.

13. 2. Программа лояльности

14. 2.0. Программа лояльности

Бонус от 3% до 20%
Оплата баллами до 100% покупок (1 балл = 1 руб.)
Уровни участия в программе для получения привилегий:
Название уровня
бонус, % от
суммы покупок
Пороговая сумма для
получения карты
большего номинала
(руб.)
Базовый
3%
0 – 10 000
365 дней
Серебряный
7%
10 000 – 15 000
365 дней
Золотой
10%
15 000 – 50 000
365 дней
Платиновый
15%
50 000 – 100 000
365 дней
VIP
20%
от 100 000
365 дней
Срок действия бонусов
(дней)

15. 2.1. Получить баллы

при первом заказе –
при установке приложения –
за регистрацию/заполнение профиля –
действия в соцсетях (за каждый оставленный отзыв,
подписку, опрос, шеринг и т.д.) –
в День рождения –
за каждого приглашенного друга –
за каждую покупку друга –
Участие в акциях – индивидуально по каждой акции
1 руб. = 1 балл
Начисление дополнительных баллов может
происходить 1 раз в месяц или 1 раз в день (в
зависимости от разработки)

16. 2.2. Потратить баллы

Скидка от 3% до 20% в зависимости от накопленной суммы
покупок
Оплата баллами части покупок или полный обмен баллов
на товар (1 балл = 1 руб.)
Уровни участия в программе для получения привилегий:
Скидка/бонус, % от
суммы покупок
Пороговая сумма для
получения карты
большего номинала (руб.)
Срок действия бонусов
7%
0 – 15 000
365 дней
10%
15 000 – 50 000
365 дней
15%
50 000 – 100 000
365 дней
20%
от 100 000
365 дней
(дней)

17. 2.3 Магазин поощрений

ассортимент товаров CLAIRE’S
1 балл = 1 рубль

18. 3. Карта CLAIRE’S

19. 3.0. Карта CLAIRE’S

• электронная карта в приложении
• информация на карте отображает: ФИО, номер, количество баллов,
доступную скидку
• условия или ссылка на краткие и полные условия бонусной системы
У кого есть пластиковая карта, есть возможность
перейти на электронную, сохранив при этом все
данные по накоплениям и списаниям баллов

20. 3.1. Оформить карту

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

21. 3.2. Показать карту

Изображение карты находится в
верхней части экрана – при тапе на
карту «переворачивается» другой
стороной со штрих-кодом.
Показать изображение
QR-кода при оплате

22. 4. Информация

23. Информация

— Акции и скидки
— Правила программы
— Push-нотификации (могут быть как
триггерные – например о забытой
корзине, так и информирующие)
— Обратная связь
— Телефон горячей линии/чат
— Дополнительная информация

24. Обратная связь/Помощь

Зака Зака
Здесь можно оставить как общий
отзыв, так и отзыв о конкретном
посещении ресторана или доставки.
Можно обратиться через
встроенный мессенджер
Также можно оставить отзыв о
приложении.
Вьет кафе

25. 5. Заказы

26. 5.1. Ассортимент

— Фильтр по поиску товаров
— Сканирование штрих-кода
— Ассортимент по возрастной группе

27. 5.2. Карточка товара

—
Описание товара
Количество в наличие
Цвет
Размер
Поделиться в соцсетях или отправить кому-нибудь

28. 5.3. Избранное

—
Звездочка добавления в избранное
Просмотр товаров в избранном
Переход на карточку товара
Перемещение в корзину

29. 5.4. Корзина

— Оформление заказа (резерва, как в Valtera)
— Отдельное поле для применения промокода на скидку

30. 5.5. Бронирование

Поля для заполнения
— Имя и фамилия
— Телефон
— Email
— Комментарий
— Регион доставки (присутствие магазинов Клэрс)

31. 6. Магазины

32.

Список магазинов
—
списком
на карте
геолокация
с указанием контактной информации о каждом магазине

33. КОНТАКТНАЯ ИНФОРМАЦИЯ

Название организации: ООО «Роскошный мир драгоценностей»
Контактное лицо: Елисеева Надежда
Телефон: моб. 8-926-577-74-39
E-mail: [email protected]
Internet-сайт: http://www.claires.co.uk/, http://www.claires.ru/ — в разработке

Каждый бизнес стремится к тому, чтобы стать следующим Airbnb или Uber, но получится это далеко не у всех. Если вы хотите создать продукт, который будет продавать, при его создании учитывайте потребности вашей аудитории, даже не самые очевидные. Отличным помощником в этом станет подробный документ требований к мобильному приложению.

Что такое документ требований?

Документ требований к продукту (на английском PRD — product requirements document) определяет ценность и назначение приложения для вас самих и для команды разработчиков. С помощью этого документа вы сможете объяснить разработчикам для кого предназначен продукт и какую пользу он приносит конечному пользователю. PRD направляет разработку продукта, обеспечивая понимание цели, стоящей за приложением. Документ описывает бизнес-логику продукта, содержит все технические характеристики и помогает команде разработчиков преобразовать раннюю концепцию в полнофункциональное приложение.

В статье мы расскажем, как составить идеальный PRD, который поможет продукту пройти путь от идеи до выхода на рынок.

Потребности бизнеса

Любое мобильное приложение создаётся для решения определённых задач. Потребности бизнеса в PDR описывают как приложение будет отвечать нуждам компании и пользователей.

При составлении бизнес-требований необходимо учитывать следующие моменты:

• Для каких целей вам нужно приложение? Чего хотите добиться с его помощью?
• Какую текущую проблему(-ы) оно решит? Как улучшит текущие бизнес-процессы?
• Что должно делать приложение? Какова его основная функциональность, какие функции могут понадобиться?
• Существуют ли рекомендации по брендингу и дизайну, которым должны следовать разработчики?

Цели мобильного приложения

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

Уровень доступа пользователей

В PRD необходимо включить описание уровня доступа и прав для разных групп пользователей (например, администратор, гость, зарегистрированный пользователь). Вы должно чётко понимать, как каждая группа пользователей будет взаимодействовать с приложением, что подстегнёт гостя пройти регистрацию.

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

Каким вы видите ваше мобильное приложение?

Описание вашего видения продукта позволяет определить наилучший путь к конечной цели мобильного приложения. Вы должны рассказать, какую проблему (и как) оно решает, для кого предназначено, чем отличается от приложений ближайших конкурентов. Чем подробнее вы опишите каким должно быть приложение, тем больше шансов получить именно то, что хочется.

Составьте список функций

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

• регистрация и вход в систему;
• заставка;
• навигация;
• галерея изображений;
• интеграция в социальные сети;
• каталог продукции;
• корзина для покупок, отложенные/любимые товары;
• оплата товаров/услуг;
• push-уведомления;
• аппаратный доступ к устройству;
• интеграция календаря;
• система бронирования.

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

Стратегия монетизации

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

Реклама — вы получаете доход за счёт продажи рекламного пространства и показа рекламы в приложении.

Оплата за загрузку — самая старая и самая простая модель монетизации приложений. Пользователи оплачивают приложение перед его загрузкой и после установки получают доступ ко всему функционалу продукта.

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

Фримиум — при такой модели пользователи бесплатно загружают приложение, но определённые функции становятся доступны только после оплаты.

Подписка — эта модель похожа на фримиум, только бесплатная версия приложения ограничивает доступ не к функциям, а к контенту.

Технические характеристики

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

В документе требований к мобильному приложению обязательно должны быть указаны следующие параметры:

На каких платформах будет доступно приложение (iOS, Android или Windows)?

Какие версии операционной системы должны его поддерживать?

Каковы ваши потребности в обслуживании? Необходима ли дальнейшая поддержка специалистов?

Есть ли у вас текущая документация по API/сервисам?

Есть ли у вас текущие учётные записи Apple, Google или других разработчиков?

Каковы ваши текущие сервисы, серверы, базы данных?

Выбор платформы

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

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

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

Значительную роль в выборе платформы играет и стратегия монетизации. С точки зрения дохода выгоднее заняться разработкой приложения под iOS. Несмотря на меньшее количество пользователей и число загрузок, магазин приложений приносит гораздо больше прибыли.

У каждой платформы есть свои преимущества, поэтому важно тщательно изучить вопрос, чтобы понять, какая ОС больше подходит для ваших целей.

Техническое обслуживание и модернизация

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

Допущения и ограничения

Допущения, как правило, связаны с прогнозами поведения и взаимодействия пользователей с приложением. Также в этот раздел важно включить предположения, касающиеся технических и бизнес аспектов продукта. Например, какой процент пользователей увидит в продукте достаточно ценности, чтобы регулярно его использовать; будет ли работать приложение на самой последней ОС, в какие сроки продукт будет готов к релизу.

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

Подготовка к загрузке в магазины

В документе требований обязательно должна содержаться информация, необходимая для загрузки приложения в Apple App Store и Google Play. Разработчики знают требования магазинов и смогут подсказать, что именно нужно, какие нюансы следует учитывать в процессе разработки, чтобы облегчить подачу заявки.

Если загрузкой будут заниматься разработчики, не забудьте предоставить им точное название компании/юридического лица, контактную информацию и информацию об авторских правах, определиться с категорией приложения, платное или бесплатное оно будет.

Краткое и полное описание приложения, а также правильно подобранные ключевые слова помогут в продвижении продукта.

Вместо заключения

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

Структура документа:

Глоссарий

Общие положения

2.1 Предмет разработки

2.2 Назначение документа

1. Требования к графическому дизайну сайта

3.1 Требования к дизайну сайта

3.2 Порядок утверждения дизайн-концепции

1. Функциональные требования

4.1 Классы пользователей

4.2 Требования к представлению сайта

4.3 Требования к системе управления сайтом

4.4 Требования к разделению доступа

1. Требования к видам обеспечения

5.1 Требования к информационному обеспечению

5.2 Требования к программному обеспечению

5.3 Требования к техническому обеспечению

5.4 Требования к лингвистическому обеспечению

5.5 Требования к эргономике и технической эстетике

1. Требования к приемке-сдаче проекта

6.1 Требования к наполнению информацией

6.2 Требования к персоналу

6.3 Порядок предоставления дистрибутива

6.4 Порядок переноса сайта на технические средства заказчика

1. Глоссарий

Термин	Описание
Сайт	Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц
Мобильное приложение	Мобильное приложение – это специально разработанное приложение под конкретную мобильную платформу (iOS, Android, Windows Phone).
Нативное мобильное приложение	Приложение можно назвать «родным» для операционных систем – Android, IOS, WinPhone . Такие мобильные приложения пишутся на языках программирования, утвержденных разработчиками программного обеспечения под каждую конкретную платформу, а потому органично встраиваются в сами операционные системы. Приложения загружаются через магазины приложений (App Store, Google Play и т.д.) и соответствуют требованиям этих магазинов.
Администратор	Лицо, осуществляющее от имени Заказчика информационную поддержку сайта
Дизайн веб-сайта	Уникальные для конкретного веб-сайта структура, графическое оформление и способы представления информации

1. Общие положения

2.1 Предмет разработки

Рис. Use case

Предметом разработки является

• мобильное приложение с автоматическим наполнением контента;
• Сайт;

Назначение мобильного приложения:

• Предоставление полной информации о местах курортной зоны;
• Возможность осуществлять бронирование развлечений (экскурсий, снаряжения и тд);
• Возможность осуществлять бронирование проживание (тур, отели, дома отдыха, курорты и тд);
• Возможность осуществлять бронирование транспорта (авиа билетов, жд билетов, такси, автобусов);
• Возможность осуществлять бронирование питания (столик в ресторане, вызов кейтеринг и тд);

Назначение сайта

—   Вывод рекламной информации о мобильном приложении;

—   Осуществление администрирование мобильного приложения;

—   Вывод аналитической информации (с возможностью отправить на принтер и на почтовый адрес);

Цель создания мобильного приложения:

—   Агрегирование сервисов курортной зоны России в одной месте;

—   Возможность бронирования путешествий «в один клик»;

—   Обмен сообщениями и отзывами между пользователями;

Целевая аудитория сайта:

—   Семейные пары (средний возраст которых родителей 30-35 лет) с маленькими детьми, которые планируют провести отдых на курортных зонах России (Сочи, Крым и тд);

—  Молодежь (от 18 до 30 лет), которая планирует отправиться на зимние курортные зоны (Красная поляна, Кавказ и тд.);

—   Активные люди, которые любят путешествовать по России и сами планируют свой отпуск;

2.2 Назначение документа

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

Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:

• Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание, который содержит перечень требований к выполняемым работам.
• Заказчик согласен со всеми положениями настоящего Технического Задания.
• Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
• Исполнитель обязуется выполнить работы в объёме, указанном в настоящем Техническом Задании.
• Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем Техническом Задании.
• Все неоднозначности, выявленные в настоящем Техническом задании после его подписания, подлежат двухстороннему согласованию между Сторонами.
• В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и соответствующим образом оцениваются.

1. Требования к графическому дизайну сайта

3.1 Требования к дизайну сайта

При разработке сайта должны быть использованы преимущественно светлые и контрастные цветовые решения (пример дизайнерских решений: https://habrahabr.ru/post/334722/ ).

Оформление должно быть разработано в достаточно консервативном ключе.

На страницах недолжно быть большого объема текста.

В дизайне сайта не должны присутствовать:

— мелькающие баннеры;

— много сливающегося текста;

— тёмные и агрессивные цветовые сочетания и графические решения.

Рис. Пример формы авторизации

3.2 Порядок утверждения дизайн-концепции

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

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

В этом случае Исполнитель разрабатывает второй вариант дизайн-концепции (дорабатывает, вносит изменения). Обязательства по разработке второго варианта дизайн-концепции Исполнитель принимает только после согласования и подписания дополнительного соглашения о продлении этапа разработки дизайн-концепции на срок не менее пяти рабочих дней. Дополнительные (третий и последующие) варианты разрабатываются Исполнителем за отдельную плату на основании дополнительных соглашений.

1. Функциональные требования

4.1 Классы пользователей

• Гость – неавторизованный пользователь, обладает правами:
• Регистрация в мобильном приложении;
• Авторизация: ввод аутентификационных данных;

• Авторизованный пользователь обладает правами:
• Статические разделы – просмотр;
• Разделы новостей – просмотр;
• Новости – просмотр;
• Раздел бронирование билетов – просмотр;
• Раздел бронирования развлечений – просмотр;
• Раздел бронирования путевок – просмотр;
• Раздел бронирования транспорта – просмотр;
• Видеоролики, фотографии – просмотр, добавление отзыва, редактирование собственного отзыва
• Обратная связь – создание письма
• Сообщение в техподдержку – создание заявки
• Комментарии к разделам и подразделам– просмотр, добавление собственных, редактирование собственных
• Подписка на рассылки и уведомления
• Личный кабинет:
• Информация о пользователе – просмотр, редактирование собственной информации
• Статистика писем– просмотр собственных писем
• Список рассылок и уведомлений – просмотр, редактирование, удаление

3) Администратор – пользователь, авторизованный в интерфейсе сайта

• Полный доступ ко всем функциональным возможностям администрирования мобильного приложения:
• Статические разделы — просмотр, добавление, редактирование, удаление
• Разделы новостей — просмотр, добавление, редактирование, удаление
• Новости – просмотр, добавление, редактирование, удаление
• Статьи – просмотр, добавление, редактирование, удаление
• Разделы– просмотр, добавление, редактирование, удаление
• Видеоролики, фотографии – просмотр, добавление, редактирование, удаление
• Личные данные пользователей – просмотр, редактирование
• Список рассылок и уведомлений – просмотр, добавление, редактирование, удаление
• Комментарии к фотографиям, видеороликам, текстам– просмотр, редактирование, удаление
• Группы пользователей – просмотр, добавление, редактирование, удаление
• Пользователь — просмотр, добавление, редактирование, удаление, раздача прав
• Статистика – просмотр

4.2 Требования к представлению мобильного приложения

Требования к представлению главной страницы мобильного приложения.

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

В нижней части экрана должно располагаться горизонтальное меню и включать разделы: Транспорт, Питание, Развлечение, Проживание.

Контентная часть главной странице мобильного приложения должна включать:

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

Требования к отображению раздела «проживание».

При переходе пользователя на раздел «проживание» пользователю в верхней части экрана

• должен присутствовать поиск (в котором пользователь может задать город, в который он хочет поехать);
• ниже должна быть возможность выбрать дата заезда и дату отъезда;
• рядом должна быть опция выбора количества взрослых, количества номеров и количества детей;
• Разделы с отелями, хостелами, домами, гостиницами;
• Во всей остальной части экрана слева должна отображаться фотография места, рядом с правой стороны должны быть написано название места, количество звездочек, отзывы, соотношение цены и качества, спецпредложение;
• С правой стороны должна отображаться цена, агент (который предоставил информацию, и кнопка посмотреть).

Требования к внутренним страницам раздела проживание.

• стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
• во всю ширину должен располагаться слайдер с фотографиями данного места, справой стороны должна располагаться кнопка поделиться и сохранить в закладки.
• название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте)
• Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).

Требования к отображению раздела «развлечения».

При переходе пользователя на раздел «развлечения» пользователю

• в верхней части экрана должен отображаться поиск (в котором пользователь может задать развлечение, которое он хочет выбрать)
• Должны присутствовать разделы с самыми лучшими развлечениями, раздел с индивидуальными экскурсиями, раздел с общими экскурсиями, раздел с пешими экскурсиями, раздел с экстремальными экскурсиями.
• Во всей остальной части экрана слева должна отображаться фотография места, рядом с правой стороны должны быть написано название места, количество звезд, отзывы, соотношение цены и качества, спецпредложение;

Требования к внутренним страницам раздела «развлечения».

• стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
• во всю ширину должен располагаться слайдер с фотографиями данной экскурсии;
• название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте);
• Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).

Требования к разрабатываемому разделу «транспорт»

• Должны присутствовать разделы-выборы авиа-билеты, жд билеты, вызов такси, аренда автобуса;
• В разделе авиабилеты должен быть календарь с выбором дата отчета и прилета, пунктом отправления и пунктом назначения, класс
• В разделе авто должны присутствовать выбор тип авто: эконом, «люкс», «комфорт»

Требования к разрабатываемому разделу «питание»

• Вызов питания на дом
• Заказ столика в ресторане

Требования к внутренним страницам раздела «питание».

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

Требования к внутренним страницам раздела «личный кабинет».

• После регистрации пользователя у него создается личный кабинет.
• У пользователя появляются списки меню в нижней части приложения и в боковой части, который открывается с помощью слайдера пальцем.
• Личный кабинет пользователя находится в боковой части экрана. Там должна быть возможность выбрать фотографию пользователю, выбрать перейти в раздел редактирования личного кабинете. Добавления данных кредитной карты, добавления информации, включения галочки пуш уведовлений.
• К личному кабинету прикрепляется мониторинг действий (возможно гугл метрика).
• На основании активности пользователя формируется релевантные предложения

Требования к странице «оплата».

Оплата путевки, тура, экскурсии, снаряжения и тд.

• После добавления элемента (путевки и тд) в корзину, пользователю выводится сообщения о том, хочет ли он продолжить покупку чего-нибудь еще и перейти на оплату.
• После перехода пользователю на вкладку оплаты, если у него не введены данные карты, то ему предлагается вести данные карты (Номер, код, владелец). После введения этих данных пользователь переходит на страницу подтверждения оплаты
• На странице подтверждения оплаты ему выводится список того, что он выбрал, стоимость заказы, налог на данную услугу, комиссия, если она есть, и итоговая стоимость и кнопка оплатить.
• После нажатия на кнопку оплатить. Клиенту выводится сообщение, что его заказ принят и обрабатывается. Если у клиента недостаточно денег, то ему выводится сообщение, о том, что у него недостаточно денег и предлагается ему вести другой номер карты или повторить попытку снова.
• После успешной транзакции на почту клиента приходит чек о совершенной операции.
• Оплата услуг должна производиться с помощью стороннего сервиса — Payonline.
• После оплаты пользователю должно вернуться 6% кеш бека со следующей покупки.
• Передача данных производится внутри приложения с помощь REST или JSON технологии.

Оплата авиа, жд билетов.

• Оплата билетов происходит с помощью iframe, который выводится после нажатия на кнопку оплатить.
• В iframe передаются параметры: фамилия, имя, отчество, данные кредитной карты.
• После оплаты возвращается callback в мобильное приложение.

Требования к структуре сайта

• Сайт создается с целью внесения в ручном режиме информации на сайт.
• Для выгрузки отчетности

Пользователи группы «Администратор-владелец» могут редактировать все поля. Пользователи группы «Администратор-аналитик» могут выгружать информацию, но не могут редактировать и просматривать информацию о клиентах.

Авторизация

Пользователи могут авторизоваться в мобильном приложении, в форме авторизации должны присутствовать:

• Текстовое поле для ввода логина пользователя
• Кнопка отправки формы.

Данные для доступа (авторизации):

• Логин – адрес электронной почты пользователя
• Пароль – строка содержащая от 8 символов, состоящая из A-z, 0-9.

Ниже формы располагаются ссылка:

• Забыли пароль

Форма «Забыли пароль» содержит поля:

• Email адрес пользователя, указанный при регистрации

При неудачной попытке авторизации – появляется приглашение для повторной попытки

авторизоваться с формой авторизации.

Списки рассылок и уведомления

Авторизованные пользователи могут управлять своими списками рассылок, а также

просматривать полученные уведомления.

Функциональные требования:

Администратор

• Добавить рассылку
• Удаление рассылку
• Редактирование рассылку

Авторизованный пользователь

• Просмотреть список рассылок
• Подписаться на список рассылок
• Отписать от списка рассылок
• Просмотреть уведомления

4.4 Требования к разделению доступа

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

Комментарии к статьям и разделам могут оставлять только зарегистрированные пользователи.

1. Требования к видам обеспечения

5.1 Требования к информационному обеспечению

Требования к хранению данных

Все данные сайта должны храниться в структурированном виде под управлением реляционной

СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания

(изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД

размещаются ссылки на них.

Наполнение различных сайтов, функционирование которых поддерживается одной и той же

инсталляцией системы, должно храниться под управлением единой СУБД.

Требования к языкам программирования

Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS.

Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).

Для реализации интерактивных элементов клиентской части должны использоваться языки

JavaScript и DHTML.

Для реализации динамических страниц должен использоваться язык PHP.

Для разработки мобильного приложения должен быть использован ReactJS

Требования к организации гиперссылок

Все ссылки в мобильном приложении должны быть относительными (за исключением внешних).

Требования к иллюстрациям

Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть

выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.

Требования к объему одной страницы

Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.

5.2 Требования к программному обеспечению

Серверная часть:

• Операционная система семейства Unix (Linux, FreeBSD и пр.)
• Веб-сервер Apache 1.3.18 и выше
• Nginx, модуль mod_accel для Apache
• Набор библиотек и утилит ffmpeg
• PHP 4.2.0 и выше (должен быть собран как модуль Apache)
• СУБД MySQL 4.1.14 и выше (предпочтительно: поддержка формата InnoDB).
• Модули PHP: Mcrypt, FTP, ffmpeg-php
• Библиотеки PHP: Smarty, GeoIP
• Возможность доступа к localhost по FTP протоколу
• 2 пользователя БД

Желательно, чтобы PHP не был запущен в SafeMode.

Клиентская часть:

• Любой из перечисленный ниже браузеров (указана минимальная версия) с включенным
• Internet Explorer 6
• Mozilla 1.6 (Firefox 1.0)
• Opera 9
• Adobe Flash Player версии 9 и выше. Сайт должен быть работоспособен (информация,
• расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и

5.3 Требования к техническому обеспечению

Серверная часть:

• Компьютер с процессором Xeon 4 ядерный
• 2 ГГц (рекомендуется от 3 ГГц)
• Оперативная память 4 Гб
• Место на жестком диске от 1 Гб

Точные технически характеристики сервера будут уточнены после завершения системы и

обширного тестирования всех модулей

Клиентская часть:

• Компьютер с процессором i3 ГГц (рекомендуется от 1.5ГГц)
• Оперативная память 256 Мб (рекомендуется от 512 Мб)

5.4 Требования к лингвистическому обеспечению

Сайт должен выполняться на русском языке.

5.5 Требования к эргономике и технической эстетике

Дизайн приложения должен быть адаптивный и работать корректно во всех устройствах (Android и IOS) с разрешением экрана 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

1. Требования к приемке-сдаче проекта

6.1 Требования к наполнению информацией

Общие требования к информационному наполнению

Наполнение страниц мобильного приложения должно происходить в автоматическом режиме.

6.3 Требования к персоналу

Для эксплуатации веб-интерфейса сайта от администратора не должно требоваться специальных технических навыков, знания технологий или программных продуктов, за исключением общих навыков работы с персональным компьютером и стандартным веб-браузером (например, MS IE 6.0 или выше).

Администратор, оператор: уверенный пользователь сети Интернет, знание Microsoft Word.

Прочие пользователи: уверенный пользователь сети Интернет.

6.4 Порядок предоставления дистрибутива

По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в

составе:

— архив с исходными кодами всех программных модулей и разделов сайта;

— дамп проектной базы данных с актуальной информацией.

Дистрибутив предоставляется на CD-диске в виде файлового архива.

6.5 Порядок переноса сайта на технические средства заказчика

После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем

производится однократный перенос разработанного программного обеспечения в apple store, google market .

Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и

доступ к базе данных сайта.

6.6 Дополнительные требования

Требования к производительности

Работа любого скрипта не должна превышать 60 секунд.

При условии нагрузки на сервер не более

500.000 обращений к страницам портала в сутки.

Требования к безопасности

Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php-

код скриптов. Требуется разграничение доступа.

Пароли пользователей хранятся в зашифрованном виде. Перехват данных на уровне протокола tcp возможен.

На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.

Требования к надежности

Система может быть недоступна не более чем 24 часа в год. Резервирование данных осуществляет

хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить

копию сайта

Метки: тз

Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.

О чем рассказываем

Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.

Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.

В предыдущих материалах мы рассказывали:

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

Этапы создания мобильного приложения

Мы в студии обычно строим работу так:

Этап 1. Аналитика

Каждое приложение начинается с идеи. Вы рассказываете нам, какие задачи должен решать будущий сервис, и мы приступаем к сбору аналитики. Глубокий срез рынка, анализ уже существующих решений, изучение конкурентов и моделей поведения покупателей… На каждом этапе анализа мы помним о конечном пользователе и продумываем жизненный цикл клиента. Это помогает нам вместе понять, как люди будут использовать новое приложение — и сделать его максимально удобным, понятным и полезным. Такой сервис принесет пользу и вашему бизнесу.

Что в результате: референсы по функциональности и дизайну.

Этап 2. Техническое задание

Мы составляем подробное описание функциональности и дизайна будущего приложения. Определяем персонажи пользователей, описываем пользовательские истории (User Story), составляем карту путешествия пользователей (Customer Journey Map) и формируем технические требования к сервису. То есть фиксируем, каким должно быть приложение, что оно должно уметь и как это будет работать.

Благодаря такому техническому заданию (ТЗ) наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею.

Что в результате:

Что такое пользовательские истории

Пользовательские истории (User Story) пошагово описывают, как пользователь ведет себя в приложении: проходит авторизацию, просматривает каталог, оформляет заказ, совершает покупку. Такая история описывает задачу пользователя, которую он решает с помощью и приложения, и его конечную выгоду. В результате мы получаем список требований, который позволяет определить функциональность будущего приложения и сделать его максимально удобным для пользователя.

Что такое карта путешествий пользователя

Карта путешествия пользователя (Customer Journey Map) позволяет наглядно представить, как разные персонажи будут пользоваться приложением в каждой из пользовательских историй. На такой карте виден весь путь пользователя — перемещение между экранами и клики на кнопки.

Составление карты помогает понять, как технически реализовать все функции приложения.

Чек-лист: что должно быть в ТЗ

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

1. Общие сведения:

2. Функциональные требования к приложению:

3. Нефункциональные требования к приложению:

4. Реализация функциональности приложения:

Коротко

Не отказывайтесь от этапа аналитики. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать.

Благодаря грамотно составленному ТЗ наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею. Чтобы правильно составить ТЗ, используйте наш чек-лист.

В следующем материале мы расскажем, что нужно знать заказчику про проектирование, дизайн и разработку.

Книга

Этот цикл статей основан на книге, которую мы недавно сделали для своих клиентов. В этой книге мы постарались ответить на основные вопросы, которые у них возникают:

Читайте также:

По данным исследования eMarketer, средняя активность пользователей в мобильных устройствах в 2022 году достигнет четырех и более часов в день. 88% этого времени будет уходить на действия в мобильных приложениях.

Зачем вашему бизнесу мобильное приложение

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

Особенно востребованы мобильные приложения в сферах услуг, ритейле, финтехе, страховании, horeca. В 2021 году, по оценкам App Anniе, пользователи провели в приложениях для шопинга около 100 млрд часов, что на 18% больше, чем годом ранее. В приложениях для заказа еды и напитков количество сеансов достигло 194 млрд.

В e-commerce покупки через мобильные приложения в сегменте eGrocery – один из главных драйверов роста рынка. За последние пять лет доля мелких заказов продуктов питания увеличилась с 50% до 94%. А рост годового объема онлайн-заказов eGrocery составил 390%.

Эффективность приложений в данных нишах в несколько раз превышает инвестиции, вложенные в разработку.

Что нужно сделать до начала разработки

Шаг №1. Определите бизнес-требования проекта.

Для этого ответьте на вопросы:

• зачем вашему бизнесу мобильное приложение;

• какие задачи оно будет решать;

• какие цели поможет достичь;

• зачем ваше приложение нужно пользователю;

• как часто он будет в него заходить;

• откуда будет идти трафик;

• какая функциональность поможет решить боли пользователя.

Шаг №2. Составьте техническое задание.

Обозначьте в нем функции приложения, дизайн интерфейса, пользовательское поведение. Классическое ТЗ на разработку включает:

• целевую аудиторию продукта;

• функциональные требования к продукту;

• нефункциональные требования к продукту (как именно будет реализована та или иная фича в приложении);

• пользовательские сценарии;

• критерии того, как продукт должен решать поставленную задачу;

• структуру приложения;

• описание технологического стека.

Часто у бизнеса нет четкого ТЗ, а только описание бизнес-требований. Мы в Фрифлекс помогаем составить ТЗ, если его нет или в процессе составления возникают сложности.

Шаг №3. Выберите технологию.

Есть три основных подхода к разработке мобильных приложений:

• кроссплатформенная разработка (позволяет одновременно создавать приложения сразу для нескольких ОС);

• нативная разработка (позволяет разрабатывать приложение для одной ОС – отдельно для iOS и Android);

• PWA (Progressive Web Application) – технология, трансформирующая web-сайт в мобильное приложение.

Мы в Friflex специализируемся на фреймворке Flutter, который сочетает в себе преимущества кроссплатформенного и нативного подходов.

Особенности разработки на Flutter:

• отзывчивость интерфейса;

• множество готовых библиотек UI и общего назначения, возможность создать свою библиотеку компонент;

• простой доступ к передовым функциям платформы;

• большое комьюнити разработчиков;

• короткий time-to-market;

• Flutter работает быстрее других фреймворков — на частоте 60 кадров в секунду; 

• низкие затраты на исправление ошибок и добавление новой функциональности.

Шаг №4. Сформируйте команду.

Создавая мобильное приложение, можно пойти двумя путями:

• сформировать штат разработчиков in-house; 

• отдать разработку на аутсорс.

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

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

Чтобы выделить команду специалистов для разработки приложения в соответствии с целями заказчика, нам понадобится всего 10 дней с момента получения заявки.

Плюсы разработки на аутсорсе:

• экономическая эффективность (заказчик экономит на инфраструктуре и получает почасовую оплату за удаленную работу над проектом);

• эффективность работы (команда ориентирована на качество реализации конкретного проекта);

• масштабируемость команды (заказчик определяет размер команды, который легко корректируется в зависимости от задач).

Как рассчитать сроки и стоимость работ

В среднем разработка MVP (минимально жизнеспособного продукта) занимает два месяца, а на создание полноценного приложения уходит не менее трех-шести месяцев до первого релиза.

Возможные модели оплаты услуг по разработке: Fix или Time & material.

При модели Fix описывается объем работ и фиксированная стоимость. Time & material – это подход, при котором Заказчик оплачивает не фиксированную стоимость услуг, а часы работы занятых на проекте специалистов. Это позволяет гибко построить процесс разработки, дизайна и тестирования, а также реализовать максимальную прозрачность на проекте. Заказчик оплачивает услуги по фактически затраченным часам разработчика.

Заполнить бриф

12 апреля 2022

Мобильное приложение: зачем оно нужно

Мобильное приложение служит разным целям. Оно может быть основным продуктом бизнеса или дополнительным каналом привлечения клиентов. Например, мессенджер Telegram — это самостоятельное приложение-сервис, которое закрывает потребность пользователей в общении. А у супермаркета «Перекрёсток» другая ситуация: их приложение доставки второстепенно, потому что основной продукт — это розничные офлайн магазины. Однако при любой стратегии мобильное приложение приносит пользу: помогает развивать бизнес и увеличивать продажи.

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

Для некоторых стартапов создание мобильных приложений неизбежно, потому что идею можно реализовать только на смартфоне. Например, навигатор или шагомер. Такие бизнесы могут протестировать свои гипотезы и проверить спрос только с MVP приложения, о котором расскажем позже.

Как сделать мобильное приложение

Есть два основных способа создания мобильных приложений — кастомная разработка и при помощи конструкторов. Оба варианта имеют свои плюсы и минусы и достойны изучения.

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

Сборка на конструкторе

Это сервисы для создания мобильных приложений без разработки. Конструктор представляет собой библиотеку шаблонов, откуда можно выбрать готовые блоки и частично видоизменить их. Например, есть элемент «Меню», вы добавляете его в свое приложение, меняя названия самих пунктов и цвет шрифта. Алгоритм понятен, результат видно сразу, и никакого взаимодействия с кодом. Такие конструкторы называются no code.

Но есть еще версия со звездочкой, low code, где к готовым блокам можно добавить код. Такой вариант подходит, когда нужно сделать что-то нестандартное. В примере с меню кодом можно задать необычное расположение пунктов или добавить уникальный дизайн.

Главное преимущество конструкторов — скорость. Можно сделать приложение за 3-4 часа, если у него простая функциональность. Другой плюс — простота использования: в конструкторе есть готовые блоки, остается их выбрать и поменять доступные параметры.

Стоимость no code разработки — это палка о двух концах. С одной стороны, дешево, а с другой, вовсе нет. Создать мобильное приложение на конструкторе — это верхушка айсберга. Вскоре туда нужно будет вносить дополнительные элементы, а значит, привлекать разработчика и платить ему. Поэтому видимая дешевизна в начале пути обманчива. Это как с ремонтом в новостройке: можно сразу сделать качественный и дорогой, чтобы хватило на 10 лет, а можно дешево и на скорую руку, а через 2 года переделать. И не факт, что во втором случае получится сэкономить.

Создать приложение самостоятельно через конструктор недорого. Обычно конструкторы работают по системе подписки (в среднем 1000 рублей в месяц), а также предоставляют бесплатные ограниченные функции. Чаще всего это маленький набор шаблонов, при помощи которого почти невозможно сделать даже очень простое приложение. Или это бесплатный доступ ко всем шаблонам, но нельзя разместить приложение в магазине и управлять им.

Примеры сервисов для создания мобильных приложений

Обычно стартап выбирает сервис, отталкиваясь от необходимых функций, технических требований — под iOS или Android — и бюджета. Мы подобрали 3 конструктора для разных целей.

Apps Global. Российский сервис для создания мобильных приложений для малого и среднего бизнеса.

💰: 650-2 500₽https://apps-global.ru/в месяц.

📱: iOS и Android.

Функции: удобный модуль управления приложениями и сбора аналитики, можно подключить платежные системы Сбербанк, Яндекс, QIWI.

Appy Pie. Американский универсальный конструктор no-code для приложений, сайтов и чат-ботов.

💰: 999-2 999₽https://www.appypie.com/app-builder/pricing-planв месяц.

📱: iOS и Android.

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

iBuildApp. Американский сервис для создания мобильных приложений, один из первооткрывателей рынка конструкторов.

💰: $23-$59https://russia.ibuildapp.com/pricing.php (~1 400-3 600₽) в месяц.

📱: iOS и Android.

Функции: удобная разбивка виджетов по категориям, имитация экрана телефона и встроенная опция тестирования приложения в процессе разработки.

Кастомная разработка

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

Кастомная разработка похожа на VIP тариф: особый подход к приложению и полное соблюдение требований заказчика. Можно воплотить все идеи, не заботясь, есть ли под них шаблоны или нет. Нестандартные фичи и корпоративный дизайн — это все отличительные черты кастомной разработки. К ней обращаются все те, кто планируют развивать и совершенствовать свое приложение. В отличие от конструктора, кастомная разработка позволяет масштабироваться и превращать MVP в полноценный продукт.

К минусам индивидуальной разработки относят длительность. Создать мобильное приложение с нуля — дело не одного дня и не одной недели. На MVP в среднем закладывают 4 месяца, и даже этот срок примерный. Длительность связана со сложностью процесса: приложение на каждом этапе прорабатывается до мелочей, по ходу реализации у заказчика могут меняться требования к проекту, да и про тестирование не стоит забывать.

Но кастомная разработка мобильных приложений — это тот случай, когда конечный результат оправдывает все затраченные ресурсы. Чуть ниже рассказываем детально, как мы в Purrweb подходим к этому процессу и сколько это стоит.

Какие функции можно сделать с кастомной разработкой

Кастомная разработка дает волю фантазии и позволяет создавать нестандартные фичи. Вот пример трех таких функций, которые мы в Purrweb разработали для заказчиков:

1. Омниканальный чат для Grecha.pro. Приложение для общения рестораторов с поставщиками. Мы разработали нестандартный чат и настроили интеграцию с Телеграм. В чат можно сразу подключить представителя от ресторана и поставщика, а также приемщика и управляющего. Поставщик пишет в Телеграм, а сотрудники ресторана видят сообщения и отвечают в приложении Grecha.
2. Соединение со станцией пауэрбанков для Energo. Приложение для аренды зарядных устройств. Настраивали связь между приложением и зарядной станцией с пауэрбанками, которую нам прислали для работы.
3. Иерархия ролей пользователей для iZюматор. Образовательная платформа. Разграничивали набор функций для 5 пересекающихся ролей пользователей — студент, наставник, ассистент, админ, супервайзер.

Сравнение способов создания приложений 

Все еще сложно решить, где и как делать мобильное приложение? Для удобства мы проанализировали способы создания приложений и собрали основные тезисы в таблицу.

	Кастомная разработка MVP	В конструкторе
Функциональность	Любая, можно реализовать самые новаторские идеи	Ограниченная, можно использовать только готовые блоки
Дизайн	Индивидуальный, с элементами корпоративного стиля	Собственный, но в рамках изменяемых характеристик
Команда	Разработчики, тестировщик, дизайнеры, проджект-менеджер	Только фаундер
Время	3-5 месяцев	3-5 часов
Стоимость	1 800 000₽	Бесплатно с минимальным набором функций или подписка на сервис (~1 500₽ в месяц)

Кастомная разработка или конструктор? На вкус и цвет фломастеры разные. С одной стороны, конструктор кажется идеальным вариантом, потому что он простой и относительно дешевый. Однако при масштабировании или малейшем желании добавить уникальность потребуются дополнительные затраты. Собственная функция, дополнительный элемент и многое другое выходит за рамки возможностей конструктора. Поэтому, если приложение не самое примитивное, то обратиться к разработчикам все равно придется. Так почему бы не сделать это с самого начала? Ведь строить с нуля гораздо легче, чем исправлять готовое.

Инструкция по кастомной разработке мобильного приложения

Сделать приложение на конструкторе — интуитивно понятный процесс. А кастомная разработка мобильных приложений состоит из нескольких этапов и поэтому кажется более сложной. Она задействует больше специалистов и создает больше коммуникаций, но результат того стоит.

Создание мобильных приложений делят на 9 шагов, от подготовительного этапа до техподдержки приложения после релиза. Далее рассмотрим их более детально.

Шаг 1. Структурирование идеи

В IT тоже работает правило «семь раз отмерь и один раз отрежь». Перед поиском команды разработчиков распишите идею максимально подробно. Никто не сможет реализовать то, чего не знает сам фаундер. Зачем нужно мобильное приложение? Какие задачи будут решать пользователи при помощи приложения? Основные и второстепенные функции, способы монетизации, бюджет, партнеры, каналы распространения и другие параметры должны быть четко сформулированы.

Хороший инструмент, который помогает стартаперам оценить жизнеспособность проекта на ранних стадиях, — Business Model Canvas. Это таблица, в которой собраны основные вопросы бизнеса, на которые надо дать конкретные ответы. При составлении канвы предстоит и сегментировать клиентов, и структурировать расходы, и конкретизировать имеющиеся ресурсов. Полезный инструмент, который рассеет часть неопределенности и позже будет выступать опорой при разработке.

Шаг 2. Выбор способа создания приложения

Перед поиском разработчиков определитесь, где будет работать мобильное приложение: на iOS, Android или на обеих платформах.

Можно пойти к фрилансерам, можно взять программиста в штат, а можно обратиться сразу к команде, внутри которой уже отлажены процессы. Мы в Purrweb разрабатываем кроссплатформенные приложения на фреймворке React Native. Если вы решите обратиться к нам, над вашим проектом будут работать разработчики, UI/UX-дизайнеры, тестировщик и проджект-менеджер. Менеджер будет координировать команду, следить за процессами и общаться с заказчиком.

Шаг 3. Составление плана работы

До начала работ пропишите план действий с дедлайнами. Согласуйте его со всеми участниками, чтобы сроки были адекватными и выполнимыми.

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

Договоритесь с исполнителями и зафиксируйте бюджет.

Шаг 4. Дизайн

Дизайн мобильного приложения состоит из двух этапов — UX и UI. UX (user experience) отвечает за логику действий пользователя. UI (user interface) — за внешний облик приложения: корпоративный стиль, цвета, шрифты.

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

Создавая UI, дизайнер опирается на примеры других приложений, которые понравились заказчику. Определяется основная цветовая гамма, отрисовываются кнопки, значки и иконки.

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

Шаг 5. Разработка

У разработчиков есть экраны, подготовленные дизайнерами, которые они начинают превращать в код. Идут от общего к частному, от основных функций к второстепенным. Код изначально должен быть «чистым», то есть впоследствии легко изменяемым без потерь.

Мы делим разработку на спринты — двухнедельные отрезки. После каждого спринта показываем заказчику результаты и смотрим, как приложение работает на реальных устройствах.

Шаг 6. Тестирование

Тестирование идет неотрывно от разработки. Элемент верстается, затем тестируется, вносятся правки, и только потом верстается новый элемент. В коде один элемент цепляется за другой, который связан с третьим, и так далее. Поэтому нельзя сначала создать приложение, а потом начать его тестировать; это может быть чревато долгой работой над ошибками.

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

Шаг 7. Продвижение

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

Шаг 8. Релиз

Когда разработка окончена, приложение публикуют в магазинах приложений. Самые популярные — App Store и Google Play.

За размещение мобильного приложения на маркетах нужно платить. App Store просит 99$ ежегодно, а Google Play — 25$ единоразово. Эти расходы также стоит учесть на этапе планирования бюджета. А также траты на случай, если не получится с первого раза опубликовать приложение. Везде есть свои нюансы. Мы хорошо их знаем, потому что всегда доводим проекты до релиза и размещения на маркетах.

После релиза работа не останавливается. Наконец-то можно узнать, что пользователи думают о приложении. Стартап собирает обратную связь, она становится причиной изменений. Дальше мобильное приложение постоянно совершенствуется и обновляется.

Шаг 9. Техподдержка

Баги в мобильном приложении могут появляться из-за новых функций или обновлений самих iOS и Android. Техническая поддержка отвечает за исправление возникающих ошибок.

Как оценить стоимость индивидуальной разработки

Написать нам, а мы посчитаем 🙂

Стоимость разработки приложений зависит от нескольких факторов: функции, дизайн, команда. Чем больше функций и сложнее дизайн, тем дороже. Такая же история с разработчиками и дизайнерам: чем выше их квалификация и больше опыт, тем дороже стоят их услуги.

Подробнее о стоимости мобильного приложения.

Саммари

Мобильное приложение — мастхэв в настоящее время. На них приходится половина всего интернет-трафика.

Мобильное приложение можно сделать в конструкторе или разработать индивидуально с командой.

Конструктор — это сервис с набором готовых блоков, при помощи которых можно легко делать шаблонные приложения. Быстро и недорого, но с минимальными возможностями.

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

Процесс кастомной разработки мобильного приложения:

Purrweb — это команда профессионалов, которая 8 лет занимается созданием мобильных приложений. Посмотреть наше портфолио можно здесь. Оставьте контакты в форме ниже, и наш менеджер рассчитает стоимость вашего проекта.