Начните с проблемы, которую хотите решить

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

Опишите один обычный случай от начала до конца. Например, от появления обращения до выполненной услуги. Укажите, какие данные создаются на каждом этапе и кто принимает решение. Затем добавьте исключения: отказ, исправление, повторное обращение или отсутствие связи.

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

Отделите обязательное от желательного

Список идей обычно длиннее первой версии. Для каждой функции спросите: сможет ли человек выполнить основную задачу без неё? Если да, функцию можно рассмотреть позже. Если нет, опишите, почему она необходима и что именно должно происходить.

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

  • Главная задача продукта и его пользователи.
  • Критичные операции и ограничения.
  • Обязательный состав первой версии.
  • Идеи для следующих этапов.

Соберите исходные материалы

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

Не отправляйте рабочие пароли в текст задания. Обсуждение задачи и передача доступов — разные процессы. Сначала определяют, какие сведения нужны, затем согласуют способ работы с ними.

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

Проверьте, что стороны одинаково понимают результат

После разбора должна появиться запись с границами работы: что создаётся, что остаётся за пределами этапа и как принимается результат. Для главных действий нужны проверяемые сценарии. Формулировка «система работает» слишком общая, чтобы защитить интересы обеих сторон.

Хорошая постановка не устраняет все вопросы заранее. Она делает вопросы видимыми и позволяет решать их до дорогой переделки. Если большая часть требований ещё неизвестна, разумно сначала выделить исследование и проектирование.