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