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