Этапы разработки мобильного приложения: аналитика и техническое задание
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.
О чем рассказываем
Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.
Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.
В предыдущих материалах мы рассказывали:
Сейчас поговорим о том, как строится работа над созданием мобильного приложения: что включает в себя этап аналитики и что должно быть в техническом задании.
Этапы создания мобильного приложения
Мы в студии обычно строим работу так:
- аналитика;
- техническое задание;
- проектирование и дизайн;
- разработка;
- тестирование и стабилизация;
- публикация в сторах;
- поддержка и развитие.
Каждый проект — особенный. Для одного можно объединить несколько этапов в один, чтобы реализовать задуманное быстрее и дешевле. Для другого целесообразно пройти все этапы. Мы поможем выбрать оптимальный путь.
Этап 1. Аналитика
Каждое приложение начинается с идеи. Вы рассказываете нам, какие задачи должен решать будущий сервис, и мы приступаем к сбору аналитики. Глубокий срез рынка, анализ уже существующих решений, изучение конкурентов и моделей поведения покупателей… На каждом этапе анализа мы помним о конечном пользователе и продумываем жизненный цикл клиента. Это помогает нам вместе понять, как люди будут использовать новое приложение — и сделать его максимально удобным, понятным и полезным. Такой сервис принесет пользу и вашему бизнесу.
Что в результате: референсы по функциональности и дизайну.
Аналитика — принципиально важный этап. Не надо от него отказываться и начинать работу над проектом с технического задания. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать. Мы обычно собираем лучшие практики и предлагаем клиенту проверенные решения, которые 100% сработают.
Этап 2. Техническое задание
Мы составляем подробное описание функциональности и дизайна будущего приложения. Определяем персонажи пользователей, описываем пользовательские истории (User Story), составляем карту путешествия пользователей (Customer Journey Map) и формируем технические требования к сервису. То есть фиксируем, каким должно быть приложение, что оно должно уметь и как это будет работать.
Благодаря такому техническому заданию (ТЗ) наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею.
Что в результате:
- перечень функций, которые должны быть в приложении;
- требования к интерфейсу, ролям пользователя, безопасности, производительности и другие нефункциональные требования;
- описание того, как будут реализованы все эти требования;
- смета проекта.
Что такое пользовательские истории
Пользовательские истории (User Story) пошагово описывают, как пользователь ведет себя в приложении: проходит авторизацию, просматривает каталог, оформляет заказ, совершает покупку. Такая история описывает задачу пользователя, которую он решает с помощью и приложения, и его конечную выгоду. В результате мы получаем список требований, который позволяет определить функциональность будущего приложения и сделать его максимально удобным для пользователя.
Допустим, вы хотите сделать приложение, с помощью которого можно будет распечатывать фотографии как фотоальбом. Основными пользовательскими историями будут создание аккаунта, выбор фотографий из фотогалереи, выбор размера альбома, оплата за альбом с помощью карты, доступ к истории заказов. Мы всегда работаем над пользовательскими историями всей командой и обязательно вместе в заказчиком. Это помогает продумать все нюансы и взглянуть на всю систему целиком, а в будущем избежать сложностей на этапе проектирования и разработки.
Что такое карта путешествий пользователя
Карта путешествия пользователя (Customer Journey Map) позволяет наглядно представить, как разные персонажи будут пользоваться приложением в каждой из пользовательских историй. На такой карте виден весь путь пользователя — перемещение между экранами и клики на кнопки.
Составление карты помогает понять, как технически реализовать все функции приложения.
Мы делаем карту путешествия пользователя в Miro. Вся команда может работать над картой в реальном времени, а заказчик — смотреть результат в режиме презентации.
Чек-лист: что должно быть в ТЗ
У каждой студии разработки свой подход к составлению этого документа. Мы считаем, что для успешной реализации проекта в нем должно быть отражено следующее.
1. Общие сведения:
- цель создания сервиса;
- совместимость с платформами: это будет приложение для iOS, Android или других платформ;
- масштабируемость: умеет ли приложение быстро адаптироваться к внезапным изменениям и пиковым нагрузкам, например к росту числа пользователей или объема передачи данных;
- отказоустойчивость: должно ли приложение продолжить свою работу, если откажет один или несколько его компонентов.
2. Функциональные требования к приложению:
- роли пользователей: какие уровни доступа должны быть у разных пользователей, например у гостя и авторизованного пользователя;
- форматы данных: как будет реализован обмен данными в приложении;
- интеграция: должно ли приложение поддерживать совместную работу с другими сервисами, например с платежными системами и почтовыми серверами;
- интерфейсы доступа: как приложение будет обмениваться данными с внешними сервисами;
- дополнительные функции: должно ли приложение уметь что-то еще, например работать с файлами или библиотеками шифрования;
- конфигурация и администрирование: с помощью каких элементов администратор будет управлять приложением;
- состав системы: из чего состоит мобильное приложение, то есть экраны, пуш-уведомления, система аутентификации и т.д.
3. Нефункциональные требования к приложению:
- безопасность: требования к безопасности приложения;
- логирование: нужно ли системе формировать и сохранять отчеты об ошибках, которые возникли при работе приложения, и для каких типов событий это надо делать;
- производительность: требования к работе приложения, например к скорости работы базы данных;
- требования к аппаратному обеспечению сервера: перечень технических характеристик.
4. Реализация функциональности приложения:
- экран загрузки;
- регистрация и авторизация;
- основной экран;
- меню;
- поиск;
- …
- уведомления.
Коротко
Не отказывайтесь от этапа аналитики. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать.
Благодаря грамотно составленному ТЗ наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею. Чтобы правильно составить ТЗ, используйте наш чек-лист.
В следующем материале мы расскажем, что нужно знать заказчику про проектирование, дизайн и разработку.
Книга
Этот цикл статей основан на книге, которую мы недавно сделали для своих клиентов. В этой книге мы постарались ответить на основные вопросы, которые у них возникают:
- как понять, что моему бизнесу нужно мобильное приложение;
- для чего компании делают свои мобильные сервисы;
- сколько стоит разработка и как на ней сэкономить;
- как строится работа над мобильным приложением;
- с кем лучше работать — с фрилансером или студией;
- что делать после того, как приложение готово.
Читайте также:
Остались вопросы? Не согласны с нами? Хотите высказать свою точку зрения или поделиться опытом? Пишите в комментариях. Давайте обсуждать!