Всем привет! Меня зовут Настя, я аналитик в e-legion. Мы разрабатываем цифровые продукты на заказ, в том числе мобильные приложения, например, Мой Tele2, Альфа-Инвестиции, Пятерочка, My JetKid, Глобус и другие. 

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

Процесс анализа на проекте

Сейчас практически на каждом проекте мы используем гибкие методологии. Рано или поздно команды приходят к Dual-Track Agile, когда спринты разделены на Discovery и Delivery. Аналитики и дизайнеры (консультируясь с разработчиками, конечно) в спринте Discovery готовят беклог для Delivery спринта. Т.е. к разработчикам и тестировщикам попадают описанные и спроектированные фичи.

Таким образом мы уменьшаем неопределенность при разработке: требования прописаны точнее и сроки становятся прогнозируемее.

Общий процесс анализа такой:

• Определение потребности:

  • выявление бизнес-целей, бизнес-требований;

  • определение ограничений, правил;

  • выявление проблемы.

• Определение решения.

• Проектирование:

  • формирование пользовательских сценариев;

  • системное моделирование, разработка требований;

  • архитектура решения.

• Документирование.

• Управление требованиями.

Discovery track

В Discovery спринте аналитики тесно взаимодействуют с дизайнерами-проектировщиками, потому что в мобильных приложениях важен UX/UI. В процессе работы мы используем основы дизайн-мышления (методика, ориентированная на пользовательский опыт).

Мы выделили варианты взаимодействия аналитика и дизайнера:

• 1 вариант: аналитик -> дизайнер.

• 2 вариант: дизайнер -> аналитик.

• 3 вариант: дизайнер + аналитик.

• 4 вариант: дизайнер.

• 5 вариант: аналитик.

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

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

Ограничение при анализе

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

Потеря сигнала

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

РЕКОМЕНДАЦИЯ

Потеря сигнала обязывает аналитика продумывать кейсы, когда нет интернета (оффлайн режим, кеширование).

Фрагментация

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

На одном из проектов в 2016 году мы разрабатывали авторизацию по отпечатку пальцев. FingerPrint появился в 6-й версии Android. Но были устройства с версией ОС ниже, где не поддерживался FingerPrint операционкой, однако сканер отпечатка был на устройстве. Поэтому мы придумывали обходные пути, писали свою библиотеку.

РЕКОМЕНДАЦИЯ

Использовать системы метрик для статистики пула устройств приложения.

Обновление сборок

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

РЕКОМЕНДАЦИЯ

Можно предусматривать hard и soft update для управления обновлениями. 

Возможности устройств

Зачастую мобильные приложения требуют взаимодействия через Bluetooth (носимая электроника, фитнес-девайсы), NFC (сканирование, оплата), геолокацию (карты), камеру и тд.

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

РЕКОМЕНДАЦИЯ

Нужно прорабатывать сценарии, когда разрешения не дали.

Особенности платформ

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

Особенности не всегда означают ограничения, а дают дополнительные возможности для бизнеса:

• Apple Pay, GPay — упрощение пользовательского сценария оплаты.

• Touch/Face ID, FingerPrint — упрощение пользовательского сценария авторизации или дополнительный фактор безопасности.

• Apple Wallet — в программах лояльности сохранение промокода, билетов, карточек.

• Deeplinking — тап на пуш или на ссылку из письма открывает конкретный экран.

Оптимизация работы

Хочу поделиться несколькими хаками по оптимизации работы аналитика.

Интерфейсные требования

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

Типизация

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

• Типовые элементы экранов: отображение состояний операций, типы и поведение тробберов, правила отображения web-view.

• Правила отображения типовых данных: обработка дат, обработка часовых поясов, отображение баланса, правила валидации.

• Типизация ошибок: таймаут, ошибки доступа, ошибки запросов, пустые состояния. 

Чек-листы

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

Чек-лист для ревью дизайн-макетов можно подсмотреть в статье Саши Маньковской.

Обратная связь

Сторы мобильных приложений дают ещё один инструмент для анализа — обратная связь от пользователей. Это может быть приятным бонусом и практически полезно. Например, в 2017 году, обрабатывая отзывы, мы увидели настойчивый запрос на виджет от пользователей. После выпуска виджета в прод, пользователи не заставили ждать с обратной связью, и рейтинг приложения пополз вверх.

Вывод

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