Поиск edge cases
Ты — продуктовый менеджер, который ловит нестандартные сценарии до разработки. Помоги найти edge cases в описанной функциональности: граничный сценарий, найденный в спеке, дешевле, чем баг на проде.
Входные данные: — продукт: [вставьте краткое описание продукта]; — функциональность: [вставьте описание функциональности: что делает пользователь, что происходит в системе].
Сделай следующее:
- Перебери функциональность по четырём категориям граничных сценариев: пустые и неполные данные; ошибки и сбои; права и роли; параллельные и конфликтующие действия.
- В каждой категории перечисли конкретные сценарии в формате «ситуация — что пойдёт не так, если не обработать».
- После списков дай раздел «Вопросы к решению»: продуктовые вопросы, которые нужно закрыть, чтобы определить поведение системы.
Ограничения: — не придумывай функции, которых нет в описании: сценарии только для описанного поведения; — если категория к функциональности неприменима, напиши это явно вместо выдуманных примеров; — не решай за команду: в вопросах предлагай варианты, а не выбранный ответ; — если данных не хватает, отметь это.
Пример данных
Данные вымышлены. Замени их информацией о своей задаче.
Продукт: Дентафлоу — b2b-сервис онлайн-записи пациентов для частных стоматологий. Функциональность: перенос записи пациента на другое время. Описание: администратор находит запись пациента в расписании, выбирает «Перенести», указывает новую дату и время и сохраняет. Пациенту уходит уведомление о новом времени. Старый слот освобождается.
Пример ответа
Один из возможных результатов. Проверь факты и адаптируй текст перед использованием.
Пустые и неполные данные
- В карточке пациента нет телефона или мессенджера — уведомление о новом времени отправить некуда, пациент придёт на старое время.
- Администратор сохраняет перенос, не указав новую дату или время, — система получает неполную форму.
- Новая дата в прошлом — перенос указывает на несуществующий слот.
Ошибки и сбои
- Новый слот уже занят другим пациентом — сохранение переноса конфликтует с расписанием.
- Запись пациента не найдена в момент сохранения: её отменили в другой вкладке, пока администратор заполнял форму.
- Уведомление не отправилось из-за сбоя — старый слот уже освобождён, а пациент знает только старое время.
- Сервис уведомлений недоступен в момент сохранения — непонятно, состоялся ли перенос.
Права и роли
- Врач клиники пытается перенести запись: в описании действие есть только у администратора, права врачей не заданы.
- Администратор одной клиники открывает расписание другой: сервис b2b, клиник несколько, границы доступа не описаны.
- Отключённый администратор остаётся с доступом к переносам: про отключение доступа в описании ничего нет.
Параллельные и конфликтующие действия
- Два администратора переносят одну и ту же запись одновременно в разных вкладках.
- Пациент бронирует освободившийся старый слот через виджет в момент, когда администратор ещё не сохранил перенос.
- Два переноса разных пациентов претендуют на один новый слот одновременно.
Категория прав применима, но в описании фигурирует только администратор: поведение врачей и границы между клиниками в данных не заданы, сценарии раздела построены на этом разрыве.
Вопросы к решению
- Что показывать администратору, если новый слот занят в момент сохранения: блокировать, предлагать ближайшие свободные слоты или перезаписывать?
- Повторять ли отправку уведомления при сбое и по какому каналу тогда?
- Считается ли перенос состоявшимся сразу или нужно подтверждение пациента на новое время?
- Есть ли лимит переносов одной записи и нужно ли ограничение по времени до приёма?
Проверьте факты
- Сверить роли: в описании действует только администратор, поведение врачей и виджета выводится из конфликтных сценариев, а не из данных.
- Проверить, какие из сценариев система уже обрабатывает по умолчанию, прежде чем ставить их в разработку.
- Канал уведомлений в описании не назван — уточни до проработки вопросов.
- Вопросы к решению требуют продуктового решения: не превращай их в задачи без ответов.
Из главы: PRD и документация