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