Assumption mapping — карта допущений

(или «давайте честно признаемся, что мы не знаем»)

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

Они выглядят как требования.
Звучат как требования.
Защищаются как требования.

А по факту — это коллективные догадки, которым просто повезло прожить пару встреч.

⸻

Где техника реально нужна
Assumption mapping включается не «в начале проекта», а в конкретных состояниях:
• все вроде согласны, но решения буксуют
• обсуждение крутится по кругу
• требования есть, но доверия к ним нет
• фраза «ну, это очевидно» звучит слишком часто

Это почти всегда признак того, что допущения замаскированы под факты.

⸻

Что я называю допущением (важный момент)
Допущение — это не «мы не знаем».

Это:
• мы верим, что пользователь ведёт себя так
• мы исходим из того, что ограничение реально
• мы считаем, что данные доступны
• мы предполагаем, что этот процесс вообще кому-то нужен

Ключевое:
если утверждение не проверено, но влияет на решение — это допущение.
Даже если его произнёс самый уважаемый человек в комнате.

⸻

Как я это делаю на практике (без методологического цирка)
Шаг 1. Явно меняю режим разговора
Я прямо говорю что-то вроде:

«Давайте на 20 минут перестанем обсуждать решения
и выпишем всё, во что мы сейчас верим»

Это важно.
Пока люди думают, что они «фиксируют требования», честности не будет.

⸻

Шаг 2. Выписываем утверждения, а не идеи
Мы не генерируем варианты.
Мы вытаскиваем утверждения, которые уже живут в головах:
• пользователь готов ждать 2 секунды
• оператор всегда онлайн
• интеграция возможна
• бизнесу реально важен этот сценарий

Без оценки. Без споров. Просто фиксируем.

На этом этапе обычно возникает первое напряжение:

«Подожди, а это точно правда?»
Отлично. Значит, мы в нужном месте.

⸻

Шаг 3. Разделяем: знаем / предполагаем / не знаем
Я очень не люблю сложные матрицы, поэтому чаще всего делаю грубо:
• ✅ Знаем (есть данные / опыт / подтверждение)
• ❓ Предполагаем
• ⚠️ Не знаем, но ведём себя так, будто знаем

Последняя категория — самая токсичная и самая ценная.

⸻

Шаг 4. Смотрим не на количество, а на влияние
Критичный момент.

Важно не то, сколько допущений,
а какие решения на них опираются.

Я почти всегда задаю вопрос:

«Если это окажется неверным — что сломается?»

Если ответ — «всё»,
а допущение — в зоне ❓ или ⚠️,
то у нас не требования, а карточный домик.

⸻

Что обычно происходит (и почему это неприятно)
Assumption mapping почти всегда ломает иллюзию прогресса.

Вдруг выясняется, что:
• ключевой сценарий держится на одном непроверенном предположении
• «понятный пользователь» существует только в презентации
• половина требований — это удобные догадки

Людям это не нравится.
Потому что карта допущений не предлагает решений.
Она предлагает честность.

⸻

Что это даёт на самом деле
Самый важный эффект — меняется направление работы.

Вместо:

«давайте допилим требования»

возникает:

«что мы должны проверить в первую очередь?»
«какое допущение самое опасное?»
«где минимальный эксперимент?»

И вот это уже нормальная работа в неопределённости.

⸻

Ограничение техники (чтобы не было иллюзий)
Assumption mapping:
• не снимает неопределённость
• не заменяет анализ
• не гарантирует правильных решений

Она делает другое:
лишает вас права притворяться, что вы всё понимаете.

И, честно говоря, для системного аналитика
это иногда самый ценный инструмент.