Масштабная трансформация
Сбербанка в прямом эфире
LIVE

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

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

В закладки

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

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

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

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

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

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

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

  • аналитика;
  • техническое задание;
  • проектирование и дизайн;
  • разработка;
  • тестирование и стабилизация;
  • публикация в сторах;
  • поддержка и развитие.

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

Рустам Мухамедьянов
руководитель студии Winfox

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

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

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

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

Валерий Сорокин
менеджер проектов студии Winfox

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

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

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

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

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

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

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

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

Рустам Мухамедьянов
руководитель студии Winfox

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

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

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

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

Александр Хрущев
технический директор студии Winfox

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

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

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

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

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

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

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

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

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

  • экран загрузки;
  • регистрация и авторизация;
  • основной экран;
  • меню;
  • поиск;
  • уведомления.

Коротко

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

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

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

Книга

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

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

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

Остались вопросы? Не согласны с нами? Хотите высказать свою точку зрения или поделиться опытом? Пишите в комментариях. Давайте обсуждать!

{ "author_name": "Елизавета Чёрная", "author_type": "self", "tags": [], "comments": 14, "likes": 38, "favorites": 87, "is_advertisement": false, "subsite_label": "dev", "id": 142571, "is_wide": true, "is_ugc": true, "date": "Thu, 30 Jul 2020 10:45:06 +0300", "is_special": false }
Объявление на vc.ru
0
14 комментариев
Популярные
По порядку
Написать комментарий...
1

Да, сколько общаюсь со студиями и разработчиками, у всех свой подход к ТЗ. Кто-то все полностью прописывает, кто оставляет место для маневров) Чтобы потом, в случае чего, можно было сказать «Мы об этом не договаривались, можем сделать, на за доп плату»))))

Ответить
0

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

Ответить
0

Вам не кажется, что не просто так модель водопада практически умерла?)

Ответить
0

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

Ответить
1

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

Ответить
1

но обычно разрабы на себя берут такие риски если проект по фикс прайс

Ответить
1

Спасибо за статью, ждем следующую серию! 

Ответить
0

она скоро будет)

Ответить
1

Про аналитику как-то мало совсем написали…

Ответить
0

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

Ответить
1

Проблема в том, что написанное ТЗ большинство клиентов не читают. То есть тратите 2 недели на написание ТЗ, клиент утверждает, а в определённый момент времени появляются претензии - а почему тут так. Показываешь ТЗ, а он  говорит, что не особо читал. Понятно, что это со стороны клиента вроде всё чётко, но проблему это не убирает. Именно поэтому мы стараемся не писать ТЗ, а работать именно по прототипам/дизайну, составленному на основе требований клиента. Большинство людей визуалы и дизайн лучше,чем 60 листов текста. Это по своему опыту разработки.

Ответить
0

сложно все это читать блэт

Ответить
0

Почему сложно? Поясните, пожалуйста. Так мы сможем в будущем готовить еще более полезный и удобный для чтения контент.

Ответить
0

Хрущев дело говорит

Ответить

Комментарии