Проверка сценариев до разработки

В продуктовом каталоге МТС понадобилось сохранять основание изменения: кто, когда и почему обновил продукт. В постановке было мало деталей. Я разобрал задачу с аналитиком до подготовки макетов.

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

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

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

Я проверил крайний случай: один человек отправил версию на тестирование, другой вернул её на доработку. Нужна ли первому причина возврата? Этот сценарий оставили для дополнительного уточнения с владельцем процесса.

На финальном шаге уже было предложение перейти в контентный каталог и настроить базовый контент. Я указал на пересечение: добавление ещё одного окна меняет существующий путь.

Обсудили двухшаговый вариант: сначала указать основание изменения, затем перейти к настройке контента. Я отдельно уточнил обязательность комментария и поведение при незаполненном поле. Аналитик подтвердил проверку на стороне сервера до публикации.

Для первой редакции выбрали одно поле свободного текста. Это рабочая договорённость встречи; подтверждение реализации в архиве пока не найдено.

Рассматривали показ комментария в списке версий и в карточке продукта. Я предложил учитывать частоту обращения: причины изменений нужны при разборе спорных случаев, поэтому дополнительная информация не должна перегружать шапку.

Затем уточнил, как сохраняются повторные изменения внутри одной версии. В обсуждении возникла проблема перезаписи: одна версия может меняться несколько раз, а причины прежних изменений будут потеряны. Аналитик признал этот риск. Окончательная модель хранения в расшифровке не зафиксирована.

Задача получила конкретные точки заполнения, рабочую последовательность шагов, требование обязательности и вопросы к хранению истории. Вместе с этим остались явно обозначенные уточнения: причины возврата с тестирования, повторные изменения и окончательное место просмотра.

Эпизод восстановлен по рабочей встрече сентября 2025 года. Источник подтверждает обсуждение сценария и предварительные договорённости. Показ прототипа и итоговый выпуск этой функции в нём не зафиксированы.

Для спорных сценариев двух каталогов я собирал интерактивные прототипы в Figma Make и обсуждал их с командой до разработки. Часть гипотез отбрасывали на этом этапе. Затем я передал практику быстрого прототипирования дизайнерам трайба.

Прототипирование и стандарт передачи дизайна вместе сократили доработки со стороны разработки на 15%. Вклад каждого изменения отдельно не измерялся; метод подсчёта и период сравнения ещё восстанавливаю. Этот общий замер не относится отдельно к описанному эпизоду.