Что Нужно Знать, Начиная Разработку Собственного Приложения?

Содержание

#1. 1. Этапы процесса разработки
#2. 2. Бизнес-модель и монетизация
#3. 3. Состав команды разработчиков
#4. 4. Архитектура и технологический стек
#5. 5. Стоимость создания приложения

Ежедневно в Apple Store и Google Play появляются тысячи новых приложений, но лишь несколько из них становятся финансово успешными. Все остальные исчезают: 80% — в первый год, остальные — в течение следующих пяти лет. Главная причина их неудач — нежелание разбираться в нюансах мобильной разработки, что приводит к множеству необязательных ошибок. В этой статье мы расскажем о 7 ключевых вещах, которые должен знать каждый, кто хочет разработать свое приложение.

1. Этапы процесса разработки

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

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

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

• заказчик определяет, ЗАЧЕМ делаем;
• разработчик решает, ЧТО и КАК делаем.

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

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

Создание UI/UX дизайна. На этом этапе дизайнер создает концепцию UI/UX-дизайна для вашего приложения на основе каркасов, которые могут быть написаны бизнес-аналитиком или дизайнером UX. Дальше на основе каркасов создают макеты и прототипы пользовательского интерфейса приложения.

На все это может уйти до 20% от всего процесса создания приложения, в зависимости от его сложности и глубины проработки. Разумеется, чем сложнее будет дизайн, тем больше времени и денег уйдет на его реализацию. Но это не означает, что на дизайне нужно экономить. Совсем наоборот: дизайн — это один из самых важных элементов успеха любого IT-стартапа, поскольку именно он больше всего влияет на первое впечатление и пользовательский опыт.

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

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

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

Сам процесс тестирования кода обычно включает следующие вещи:

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

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

Развертывание продукта. После того как приложение готово и все тесты подтвердили качество кода созданного программного обеспечения, мобильные приложения выпускаются на Google Play и App Store. Перед добавлением нового приложения в свои листинги эти маркетплейсы проверяют его на соответствие правилам площадки и минимальному качеству. Если в коде обнаружатся ошибки, у вас будет очень мало времени на их исправление (2 дня в App Store). Поэтому мы настоятельно не рекомендуем экономить время и бюджет на тестировании.

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

2. Бизнес-модель и монетизация

Бизнес-модель — это то, как функционирует компания: что она делает, ради чего, как извлекает прибыль из своей деятельности, как взаимодействует с клиентами и партнерами, во что инвестирует и т. п. В случае мобильного приложения его бизнес-модель может быть направлена на выполнение самых разных задач. Самая очевидная — извлечение дохода непосредственно из приложения. Другой популярный вариант — служить «магнитом» для привлечения целевой аудитории, косвенно увеличивая охват бренда или помогая продавать товары в другом месте.

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

• Freemium-модель. Такие приложения можно загрузить бесплатно и использовать без какой-либо оплаты, но не на все 100 %. Некоторые функции и/или контент будут заблокированы. Получить доступ к заблокированным вещам можно будет только через покупку или оформив подписку.
• Платные (премиум) приложения. Для использования таких приложений их нужно купить в магазине, как обычный товар в супермаркете. Этот подход создает ценовой барьер для входа, поэтому при запуске такого приложения нужно разработать маркетинговую стратегию, которая продемонстрирует преимущество вашего софта в сравнении с бесплатными конкурентами.
• Покупки внутри приложения. В этой модели ваше мобильное приложение будет служить каналом для продаж цифровых или физических продуктов, например, брендированного мерча или эксклюзивного контента.
• Реклама в приложениях. Это, пожалуй, самая простая и доступная модель монетизации из всех, потому что пользователи смогут использовать ваше приложение абсолютно бесплатно, что убирает любые барьеры для входа. Но будьте осторожны с количеством рекламы, поскольку слишком большое количество баннеров и рекламных вставок может отпугнуть людей.
• Модель с подпиской. При таком подходе доступ к приложению пользователи получают после оформления месячной, полугодовой или годовой подписки.
• Спонсорство. Данный вариант подразумевает, что приложение будет бесплатным, а деньги на его поддержку вы будете получать путем добровольных пожертвований пользователей.

3. Состав команды разработчиков

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

Как найти такого партнера и на что обращать внимание при его выборе, мы описали в статье: «Как выбрать компанию-разработчика».

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

• Бизнес-аналитик. Собирает задачи и требования клиента к желаемому продукту, анализирует то, как софт должен выглядеть, и какие функции нужно включить в разработку, чтобы на основе этой информации создать техническую спецификацию и распланировать весь процесс с бюджетом.
• Менеджер проекта. Распределяет задачи между командой разработчиков, планирует ход работы, мотивирует, контролирует процесс и координирует общие действия. Также несет ответственность за управление рисками, тайм-менеджмент и действия в случае непредвиденных ситуаций.
• UI/UX дизайнеры. Используют каркасы, созданные клиентом и/или бизнес-аналитиком, чтобы на их основе «нарисовать» макеты интерфейса (UI). Также дизайнеры отвечают за создание отличного пользовательского опыта у конечных пользователей вашего мобильного приложения.
• Разработчики/программисты. Отвечают за воплощение дизайна и функционала приложения в программном коде, который понятен устройству пользователя, серверам и различным сторонним сервисам. Программисты могут специализироваться на фронтенд-, бэкенд- и мобильной разработке.
• QA-специалисты. Тестируют приложение на наличие багов в коде и прочих ошибок с последующим предоставлением отчета команде разработки, которая должна исправить их. Иногда QA-инженеры сами исправляют ошибки.

4. Архитектура и технологический стек

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

Обычно такая архитектура подразумевает разделение всех компонентов приложения на клиентскую (front-end) и серверную (back-end) части, которые связаны между собой и с различными сторонними сервисами через API (Application Programming Interface). Набор компонентов для серверной и клиентской частей, а также API зависит от типа конкретного приложения, его функционала и задач.

Front-end. Включает в себя компоненты, с которыми взаимодействует конечный пользователь, например покупатель в магазине. Это пользовательский интерфейс (то, что видит конечный пользователь на своем экране) и интерфейс системы. Для создания клиентской части нужны специальные инструменты (технический стек для фронтенда). Вот пример такого стека для разработки мобильного сервиса управления электронными медицинскими картами (EMR):

Веб-серверы: nginx, Apache.Back-end. Программно-аппаратная часть системы, которая отвечает за работу с информацией и осуществление функционирования внутренней части приложения. Вот как выглядит технологический стек для разработки EMR-приложения:

• Веб-фреймворки: Ruby On Rails, Phoenix.
• Язык программирования: Ruby, Elixir, Python, PHP, Java.
• Серверы баз данных: PostgreSQL, MySQL.
• Хостинг: AWS, Google Cloud Platform, Microsoft Azure.

API (Application Programming Interface). Набор специальных протоколов для соединения клиентской и серверной частей системы, а также интеграции различных сторонних сервисов, расширяющих функциональные возможности приложения. Вот пример набора API для разработки собственного EMR-приложения:

5. Стоимость создания приложения

Согласно Clutch, компании в среднем тратят на создание собственных мобильных продуктов от 13 до 142 тысяч долларов. Настолько большой разброс объясняется в основном двумя факторами: сложностью софта и местоположением разработчика. Под сложностью мобильного приложения обычно имеют в виду количество функций и сложность их реализации. Кроме того, на сложность разработки также влияют дизайн интерфейса и количество нужных интеграций.

Что касается местоположения, то это фактор важен, поскольку средняя зарплата мобильных разработчиков в разных регионах может отличаться в два-три раза. Так, программисты из Соединенных Штатов Америки в среднем получают 95 долл/час, Великобритании и Западной Европы — 67 долл/час, Восточной Европы — 32 долл/час, Африки и Азии — до 25 долл/час.

Вот ориентировочная стоимость разработки своего мобильного приложения в зависимости от его сложности и местоположения технического партнера: