В этом посте я хочу поговорить о разработке мобильных приложений. А конкретнее — про анализ требований на этапе аналитики.
На что следует обратить внимание в первую очередь при проектировании пользовательского поведения? Какие бывают технологические ограничения? Каким образом лучше проводить согласование работ?
Пост основан на докладе, с которым я выступала на Летнем Аналитическом Фестивале в 2016 году в Иваново.
Аспекты
Разработка мобильного приложения — такой же проект, как и любой другой. Но именно с мобильными приложениями мы опробовали особенный метод работы и остались им очень довольны.
Основа метода — постоянное тестирование разрабатываемых сценариев на реальных пользователях и проработка нефункциональных требований.
Рассмотрим два аспекта:
- Постоянное взаимодействие с реальными пользователями на этапе разработки сценариев
- Описание технологических ограничений и нефункциональных требований
Пост состоит из двух больших частей. Первая — это рассказ о методе, вторая — о технических ограничениях.
Подход
В компании мы обычно придерживаемся итерационного подхода к разработке. Делим весь процесс на итерации, а итерации — на этапы.
Мобильные приложения, которые мы разрабатываем, бывают, в основном, двух типов: поддержка бизнес-процесса компании или же приложение для широкой аудитории. Есть некоторые различия при проектировании каждого из типов. В первом случае, основное внимание уделяется особенности развития процессов в компании заказчика. Во втором — упор ставится на проектирование визуального взаимодействия пользователя с системой.
Процесс работы
Процесс работы на этапе аналитики включает в себя:
- Четкое описание целевой аудитории
- Описание ролей
- Фокус-группы
- Сценарии и варианты использования
- Карта экранов
- Интерактивные прототипы
- Функциональные требования
Всё звучит знакомо. Казалось бы, в чем тут фишка?
Самые главные этапы — это встречи с реальными пользователями, в ходе которых проводится прогон разработанных сценариев с использованием интерактивных прототипов.
В своем подходе мы придерживаемся главного правила — как можно больше общаться с реальными пользователями продукта. Благодаря специфике проектов у нас практически всегда есть возможность поработать с людьми.
В отличие от сфер, в которых появляется так называемый представитель пользователей, например, методист, который заявляет, что знает, что нужно пользователям системы. Однако, чаще всего это бывает далеко от истины. Так как описанные методистом регламенты работы могут быть не очень точны, а иногда и вовсе не соблюдаться. Например, работа диспетчеров в торговой компании, водители и т.д.
Далее перейдём к конкретике на примере мобильного приложения для службы доставки.
Подробности процесса
Приложение предназначено для водителей службы доставки еды ресторанного холдинга “Welcome Group”. Приложение обеспечивает выполнение одного из бизнес-процессов компании. В проекте разработки приложения я выступала в роли ведущего аналитика и менеджера проекта.
Задачи приложения:
- Поддержка существующего процесса доставки еды,
- Оптимизация процесса доставки,
- Усиление контроля,
- Улучшения отчетности.
Несколько интерфейсов для разных ролей и нативное мобильное приложение только для водителей-доставщиков.
Первый этап работы включал в себя опрос конечных пользователей приложения. Ребята-водители с шутками и смехом делились рассказами, как работают, как забирают и комплектуют заказы, как ищут адреса клиентов, как подменяют друг друга в случае форс-мажора.
Например, одна занимательная история о том, что клиент отказался оплачивать заказ, потому что жена ему денег не дала. И что же делать с заказом? Значит, необходимо обрабатывать случаи возврата.
И как быть с заказом, если произошло ДТП?
Что делать, если клиент отказался от части заказа?
Как быть, если водитель сел на коробку с пиццей?
На основе прослушанных историй мы подготовили возможные сценарии использования приложения:
- Авторизация
- Получение заказа
- Комплектация заказа
- Поездка до адреса
- Доставка заказа
- Приемка оплаты
- Отмена заказа
- Форс-мажор и авария
- Закрытие смены
Каждый из сценариев мы прорабатывали с группой водителей. В ходе обсуждения всплывали узкие места. Например, прием оплаты заказа наличными или картой. Каким образом тогда сдавать выручку в конце смены? Значит, стоит в приложении разделить заказы на оплаченные картой и оплаченные наличными, чтобы показать конечную сумму для сдачи в кассу.
По сценариям был разработан интерактивный прототип приложения. Проводился этап юзабилити-тестирования с замером времени на прохождение каждого из сценариев. Например, обработка ситуации с потерей сигнала, проверкой стадий готовности заказа, когда нужно ехать забирать, каким образом построить оптимальный маршрут доставки и сократить время.
При потере сигнала данные собираются на стороне приложения, при возвращении подключения данные отправляются на сервер и обновляются во всех интерфейсах системы.
Заказы назначаются на самого подходящего водителя в зависимости от текущего количества заказов и местоположения. Каждый заказ находится на разном этапе готовности. Водителю необходимо понимание срока готовности каждого, чтобы составить маршрут работы.
Водитель может указать в приложении, что произошел форс-мажорный случай. Изначально проектировали два типа экрана — Авария и Форс-мажор. После тестирования оставили только Аварию, так как два экрана вводили в заблуждение. При отметке об Аварии водитель сразу же становится неактивным, его заказы перераспределяются между остальными водителями. В случае, если заказы уже находились на стадии доставки клиенту, то исходя из указанной ситуации либо заказы забирались другим доставщиком, либо начинали готовиться заново. И для оператора это была проблемная ситуация.
Инструментарий
Прототипы мы разрабатываем при помощи различных инструментов: Axure, InVision, MS Visio, Figma, Sketch и т.д.
Для разработки сценариев пользуемся шаблонами use case и user story.
Результат
Столь тесное сотрудничество с конечными пользователями привносит в проект определенные плюсы:
В разработку попадают только те фичи, которые будут максимально решать сценарий.
- Определяется приоритет разработки.
- Закрываются узкие места во взаимодействии.
- Конечные пользователи уже на этапе проектирования знакомятся с продуктом и учатся его использовать.
- Сокращается время на внедрение.
- Ускоряется запуск реальной эксплуатации.
Видеозапись доклада можно посмотреть тут. Продолжение во второй части.
С любовью, Гузель
P.S. Посты канала «Байки из проектного офиса»
