Выберите действие, ради которого открывают приложение
Первая версия мобильного приложения должна давать человеку законченный результат. Формулировка «каталог, профиль и уведомления» описывает части интерфейса, но не объясняет, какую задачу они решают. Полезнее записать: сотрудник получает назначенное задание, добавляет фотографии и передаёт результат координатору. Тогда становится понятно, какие функции необходимы для запуска, а какие пока можно отложить.
MVP здесь означает минимальную версию для проверки выбранного сценария. Она может содержать немного возможностей, однако не должна оставлять пользователя перед неработающей кнопкой или непонятным статусом. Для каждого действия укажите начало, успешный конец и обстоятельства, при которых понадобится помощь.
Опишите первую аудиторию и условия использования
Один сценарий меняется в зависимости от того, кто выполняет задачу. Новый клиент нуждается в объяснениях; сотрудник, который пользуется приложением ежедневно, скорее ждёт быстрого повторения знакомого действия. Зафиксируйте первую группу пользователей и не объединяйте в одном запуске все возможные роли.
Разберите рабочий контекст: можно ли держать телефон двумя руками, нужна ли камера, насколько устойчива связь, будет ли человек отвлекаться. Определите, какие сведения приложение получает от сервера и какие пользователь вводит самостоятельно. Этот список помогает составить требования к данным ещё до подробных макетов и избежать экрана, который красив, но не поддерживает реальную работу.
Отделите обязательное от удобного дополнения
Рассмотрим условный пример приложения для выездных осмотров. Для первого запуска необходимы список назначенных осмотров, карточка задания, добавление результата и подтверждение его передачи. Чат, рейтинг сотрудников и сложный календарь могут подождать, если без них основной процесс остаётся понятным.
Разделите требования на три группы: без этого задача не завершается; это устраняет конкретное затруднение; это возможное развитие. У каждого отложенного пункта запишите причину возврата к нему. Например, группировка по районам понадобится, если участники проверки действительно тратят время на поиск ближайшего задания. Очередь следующих работ тогда опирается на наблюдения, а не на желание сразу повторить все функции большого продукта.
Продумайте потерю связи и незавершённое действие
В мобильном сценарии нужно отдельно договориться, что происходит при отключении сети. В нашем примере полезно сохранять введённое описание и показывать, что фотографии ещё не переданы. Сообщение «готово» допустимо только в том значении, которое согласовали команда и пользователь: сохранено на телефоне или принято сервером.
Руководство Android по работе без сети разделяет чтение локальных данных и синхронизацию с сетевым источником. Для задания на приложение отсюда следует практический вопрос: какие сведения должны оставаться доступными без подключения и как человек узнает об их обновлении?
Не обязательно включать полную автономную работу в первую версию. Можно ограничить отдельные действия доступной связью, но тогда это ограничение следует объяснить до потери введённых данных. Проверяйте также закрытие приложения посреди задачи и повторное открытие.
Согласуйте проверяемые условия приёмки
Требование «отправка работает» оставляет слишком много трактовок. В условном приложении можно записать: сотрудник добавляет описание и два снимка, координатор видит их в назначенном задании, повторное нажатие не создаёт вторую запись. Если передача не завершилась, пользователь видит причину и может продолжить действие.
Пройдите не только удачный путь. Проверьте отсутствие заданий, неверные данные, недоступный сервер и отказ в доступе к камере. Для каждой ситуации нужны ожидаемый результат и понятный следующий шаг. Список проверок включите в задание: исполнителю и заказчику проще обсуждать один набор условий, чем сравнивать разные представления о готовности.
Проведите ограниченный пробный запуск
Перед широким распространением дайте первой группе пользователей пройти согласованный сценарий в своей рабочей обстановке. Записывайте места, где они останавливаются, ищут объяснение или выполняют действие повторно. Отделяйте поломку от пожелания: невозможность передать осмотр мешает запуску, а дополнительный способ сортировки требует отдельного решения.
Назначьте человека, который собирает обратную связь и принимает решения о следующей версии. Каждое предложение сопоставляйте с исходной задачей. Если нужны другие роли или совершенно новый процесс, сначала уточните состав работ, а затем расширяйте продукт. Подход к описанию сценариев есть также в материале о подготовке задания на цифровой проект.
Что подготовить к обсуждению
Перед оценкой мобильного приложения соберите короткий документ:
- Первую аудиторию и действие с понятным результатом.
- Обязательные функции и отдельно отложенные возможности.
- Источники данных и ответственного за их актуальность.
- Правила работы без связи и восстановления незавершённой задачи.
- Условия приёмки, проверочные устройства и ответственного за пробный запуск.
Такой документ не заменяет проектирование, но делает разговор предметным: можно обсуждать конкретный путь пользователя, ограничения первой версии и основания для дальнейшего развития.
