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

Знаете ли вы, что около 6 140 мобильных приложений выходят в Google Play ежедневно? А к 2020 году число релизов в App Store достигнет 5 миллионов? Статистика говорит об одном: пора разрабатывать своё мобильное приложение. Если вы всерьёз задумались над разработкой приложения, наш обзор вам поможет.

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

Итак, пьеса “Процесс разработки мобильного приложения” в 7 действиях.

Действующие лица

Клиент — заказчик мобильного приложения, идейный вдохновитель проекта
Azoft — разработчики приложения
Project manager — менеджер проекта
Бизнес-аналитик — исследователь и хранитель знаний о требованиях к продукту
UI/UX дизайнер — создатель интуитивного и привлекательного интерфейса приложения
Разработчик — инженер, который пишет код приложения
QA инженер — специалист по тестированию приложения

Пролог

Сначала клиент приходит с идеей мобильного приложения. Мы просим клиента предоставить нам техническое задание (ТЗ), а если его нет — высылаем бриф на разработку мобильного приложения. Бриф помогает расставить приоритеты, обозначить цели и задачи приложения.

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

На выходе:

• описание базовых функций мобильного приложения
• выбор платформы: iOS, Android или кросс-платформа
• выбор методологии: Agile или Waterfall.

Действие первое — Планирование и оценка

Первый вопрос, который интересует клиента: “Сколько это будет стоить?”. Следующий за ним: “Когда будет готово мобильное приложение?”. Чтобы ответить на оба вопроса, Azoft проводит оценку и составляет план работ. На этом этапе к проекту обычно присоединяется менеджер проекта. Он может выступать со стороны заказчика или со стороны команды разработчиков. Задачи менеджера проекта: координировать работу команды и общаться с заказчиком.

Но что же означает загадочное слово “оценка”? На этом этапе мы изучаем техническую документацию. Рассчитываем, сколько времени потребуется на разработку и тестирование. Выявляем не описанные сценарии и узкие места в ТЗ.

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

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

На выходе:

• скоуп задач
• бюджет проекта.

Действие второе — Aналитика

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

Бизнес-аналитики в Azoft выявляют требования к мобильному приложению, предлагают варианты реализации, строят схемы взаимодействия пользователя с приложением, создают основу UI — wireframes.

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

На выходе:

• спецификация функциональных требований
• спецификация нефункциональных требований
• основа графического интерфейса — wireframes
• план проекта
• детальный бюджет.

Действие третье — Дизайн приложения

Иногда клиенты приходят с готовым дизайном. Если дизайна у заказчика нет, мы создаём UI/UX с нуля. Когда аналитик передаёт дизайнеру основу графического интерфейса, вайерфреймы, мы приступаем к визуальному дизайну. Отрисовываем карту экранов, графические элементы, детализированный прототип с учётом различных сценариев использования.

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

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

На выходе:

• карта экранов
• дизайн приложения
• привлекательный UI и удобный UX.

Действие четвёртое — Разработка

Когда есть развёрнутое ТЗ и оценка, готов дизайн и утверждён прототип мобильного приложения, начинается хардкор. Команда разработчиков пишет код, чтобы реализовать запланированное поведение приложения и соединить логику приложения с серверной частью, если она предусмотрена. А также мы воплощаем готовый дизайн в коде — прописываем все стили и элементы UI, с которыми взаимодействует пользователь приложения.

В нативной разработке мы применяем языки Java и Kotlin для Android, Objective-C и Swift для iOS, и самые современные фреймворки и библиотеки. В кроссплатформенных решениях работаем с React Native и NativeScript.

Как только часть функционала разработана, мы её тестируем и продолжаем трудиться над остальными функциями.

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

На выходе:

• версия приложения, готовая к тестированию
• корректировки дизайна.

Действие пятое — Тестирование и багфиксинг

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

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

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

На выходе:

• баги сведены к минимуму
• предрелизная версия приложения.

Действие шестое — Релиз

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

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

На выходе:

• приложение в сторе.

Действие седьмое — Техподдержка и развитие

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

На выходе:

• 1 год гарантии на багфиксинг
• договор сопровождения.

Эпилог

Разработка мобильного приложения это непросто. Нет такой схемы “Раз-два, и готово”. Многие этапы могут пересекаться друг с другом или идти параллельно. Инстаграму потребовалось больше трёх лет, чтобы стать удобным и любимым миллионами приложением. И они до сих пор продолжают вносить улучшения и добавлять новые фичи. Перед тем как фантазировать, куда вы вложите деньги от продажи своего приложения IT-гиганту вроде Google, приготовьтесь — будет много работы. Смотрите действие первое.