Ниже — конкретные техники, которые я реально использую. Не «в каждый проект», не «по методологии», а по ситуации. Без сакрализации.

⸻

1. Assumption mapping (карта допущений)

Я почти всегда начинаю с явного выписывания допущений.

Прямо так и пишу:
• мы предполагаем, что пользователь делает Х
• мы верим, что ограничение Y реально
• мы не проверяли Z, но все ведут себя так, будто это факт

Иногда это таблица, иногда список на доске.
Ценность не в формате, а в том, что допущения перестают маскироваться под требования.

Часто половина «требований» рассыпается уже на этом этапе.

⸻

2. Question backlog

Когда неопределённости много, я веду отдельный бэклог вопросов.

Не рисков, не задач — именно вопросов:
• на что на самом деле влияет это решение?
• кто будет страдать, если мы ошибёмся?
• а что должно быть правдой, чтобы этот сценарий имел смысл?

Фокус простой:
если вопрос влияет на решение — он должен быть видимым.
Если он неудобный — тем более.

⸻

3. Event storming (обрезанный и грязный)

Я часто использую event storming, но без фанатизма.

Не «правильный воркшоп», а:
• что в системе происходит
• какие события вообще существуют
• где мы не можем договориться, что первично

Очень быстро видно:
• где у нас разные картины мира
• где мы проектируем поведение, которого нет

И да — я почти никогда не довожу его до «красоты».

⸻

4. Context sketch вместо полноценного context map

В неопределённости я редко делаю «правильный» context map.

Обычно это:
• грубый скетч границ
• стрелки «что с чем как-то взаимодействует»
• пометки «граница сомнительная»

Это не артефакт для Confluence.
Это инструмент, чтобы поймать момент, где мы спорим о границах, сами того не замечая.

⸻

5. Scenario slicing

Вместо «одного целевого флоу» я часто делаю 2–3 сценария:
• если всё пойдёт хорошо
• если всё пойдёт плохо
• если всё пойдёт как обычно

И прогоняю требования через них.

Если решение работает только в одном сценарии — это не решение, а ставка.
Иногда так и надо, но лучше знать, что ты ставишь.

⸻

6. Reverse requirements

Иногда полезнее зафиксировать не «что должно быть», а:
• чего система точно не должна делать
• какие решения мы сознательно не принимаем сейчас

Это снижает давление «ну давайте хоть что-нибудь зафиксируем»
и защищает от случайной переопределённости.

⸻

7. Short-lived artifacts

Сознательно делаю артефакты с коротким сроком жизни.

Прямо проговариваю:

эта схема нужна на 2 недели
потом мы либо её убьём, либо перерисуем

Психологически это сильно меняет отношение команды:
меньше защиты, больше честности.

⸻

8. «Проговаривание интерпретаций»

Техника максимально приземлённая и неловкая, но рабочая.

Я регулярно делаю паузы и говорю что-то вроде:

«Я сейчас это понимаю так: … Скажите, где я уехал»

Не «подтвердите требования», а подтвердите моё понимание.
В условиях неопределённости это принципиально разные вещи.

⸻

Если всё это собрать, картина простая и не божественная.

Я не управляю неопределённостью.
Я просто:
• делаю её видимой
• снижаю цену ошибки
• и не позволяю инструментам притворяться истиной

И, честно говоря, это довольно приземлённая работа.
Много разговоров.
Много временных решений.
Много «давайте пока оставим так».