Расскажите о задаче с неясными требованиями. Как вы довели её до понятного решения?

Шаг 4: Написание user story и acceptance criteria

После сбора информации я оформил задачу как user story в Jira:

As a read-only project member,
I want to opt out of activity notifications for specific projects,
So that I don't receive noise about changes I cannot influence.

Acceptance criteria написал в формате Given/When/Then:

• Given: у меня роль viewer в проекте — When: я перехожу в настройки проекта — Then: вижу тоггл «Уведомления: вкл/выкл»
• Given: я отключил уведомления — When: другой участник делает commit — Then: я НЕ получаю email и push
• Given: меня явно @упоминают в комментарии — When: у меня отключены уведомления — Then: я ВСЁ РАВНО получаю уведомление об упоминании

Контекст задачи

На одном из проектов мне передали задачу: «Сделать, чтобы пользователи могли лучше управлять уведомлениями». Никаких wireframes, никаких критериев — только это предложение. Дедлайн — три спринта.

Шаг 1: Признать неопределённость явно

Первое, что я сделал, — зафиксировал в Confluence страницу с заголовком «Открытые вопросы по задаче X» и разослал её product owner и ключевым stakeholders. Это переводит размытое ощущение «нам что-то непонятно» в конкретный список пунктов, которые надо закрыть. Структура была простой:

• Что мы знаем точно
• Что предполагаем, но не подтвердили
• Что полностью неизвестно

Шаг 2: Интервью с пользователями и поддержкой

Я провёл пять коротких интервью (20–30 минут) с реальными пользователями по методу Jobs-to-be-Done: «Расскажи мне о последнем случае, когда уведомление тебя раздражало или наоборот помогло». Параллельно изучил тикеты в службу поддержки — там всегда есть сигнал о реальных болях.

В итоге выяснилось, что пользователи не хотят «управлять уведомлениями» как таковыми — они хотят не получать уведомления о чужих действиях в проектах, к которым у них только read-access.

Шаг 3: Формализация через Event Storming

Вместе с разработчиками и PO провёл двухчасовой Event Storming: выписали все domain events, связанные с уведомлениями, на стикеры, сгруппировали по bounded contexts. Это дало общий язык и сразу вскрыло три edge cases, о которых никто не думал: уведомления при архивировании проекта, групповые упоминания и упоминания в удалённых комментариях.

Шаг 5: Валидация перед разработкой

Перед стартом спринта я сделал прототип в Figma (lo-fi, 3 экрана) и протестировал его с двумя пользователями из первой волны интервью. Они подтвердили, что решение отвечает их потребности. PO подписал scope.

Подводные камни

• Принимать «это понятно» за чистую монету: даже опытные PO часто имеют в голове картину, которую не артикулировали — всегда задавайте уточняющие вопросы.
• Начинать с решения, а не с проблемы: «управление уведомлениями» — это уже решение; настоящая проблема могла быть совсем другой.
• Игнорировать тикеты поддержки: это дешёвый источник реальных болей, который часто недооценивают.
• Проводить интервью с одними и теми же людьми: нужны разные роли и уровни опыта пользователей.
• Пропускать edge cases при написании AC: особенно случаи с удалёнными данными, конкурентными изменениями и граничными правами доступа.
• Не фиксировать промежуточные решения: устные договорённости забываются — всё должно быть в письменном виде до старта разработки.

• Принять формулировку stakeholder как готовое требование.
• Слишком рано уйти в детали UI или таблиц.
• Не согласовать критерии, по которым решение будет принято.

• Умеет проводить discovery.
• Отделяет цель от предлагаемого решения.
• Фиксирует требования в проверяемой форме.