# Карта допущений (assumption mapping): что проверять до разработки

> Карта допущений по Дэвиду Бланду: как за час найти убеждения, от которых зависит продукт, и оплатить их проверку раньше, чем разработку фичи.

Статья · Алексей Ишманов · 18 октября 2026 · https://aleksishmanov.ru/blog/assumption-mapping-karta-dopushcheniy/

Карта допущений (assumption mapping) — командное упражнение, в котором все убеждения, на которых держится инициатива, выписывают явно и раскладывают на матрице «важно / неважно × есть доказательства / нет доказательств». Первыми проверяют допущения из угла «важно и нет доказательств»: если они ложны, продукт не взлетит, как бы хорошо его ни построили. Для руководителя это способ решить, за что платить сейчас — за эксперимент или за разработку.

Позиция этой статьи: проверять первым надо не самое сложное, а самое непокупаемое. Качество модели нередко можно докупить временем инженеров. Готовность клиента платить за результат модели временем инженеров не купишь.

Любая инициатива в роадмапе — пачка убеждений: «клиенты хотят», «заплатят столько-то», «соберём за квартал», «регулятор не помешает». Обычно их никто не записывает.

Проблема не в том, что команды не проверяют гипотез. Проверяют, и много. Проблема в том, что проверяют удобное.

## Что такое карта допущений и откуда метод

Метод в нынешнем виде популяризировал Дэвид Бланд (David J. Bland) — консультант по продуктовым экспериментам, основатель компании Precoil. Главный источник — книга «Testing Business Ideas: A Field Guide for Rapid Experimentation», которую Бланд написал с Александром Остервальдером (Wiley, 2019).

В книге 44 эксперимента, а карта допущений — входная точка: она отвечает, какой из них запускать первым.

Сам Бланд не называет себя автором идеи. В статье для Strategyzer (август 2020) он пишет, что впервые увидел такой способ картировать риск, работая с Джеффом Готельфом и Джошем Сейденом, авторами Lean UX. В той же статье он добавляет к трём классическим типам риска четвёртый — adaptability.

Карта допущений — один из восьми методов, которые мы разбираем в материале о [продуктовых решениях при неопределённости](/blog/produktovye-resheniya-pri-neopredelennosti/). В цикле решения она стоит на шаге «выбрать»: сразу после того, как команда построила [дерево возможностей](/blog/opportunity-solution-tree/) и выбрала решение, которое собирается проверять.

## Почему руководителю это важно: команды тестируют не то, что убивает бизнес

Команды копят доказательства там, где их дёшево добыть, а не там, где их не хватает: технический спайк проще, чем услышать от клиента «не заплачу». Бланд начинает статью с наблюдения: команды, вдохновлённые идеей экспериментов, запускают лендинги и интервью, но обходят стороной самые рискованные допущения своей стратегии. Время уходит, окно возможностей закрывается.

Почему так происходит, легко понять по устройству работы. Вопрос «сможем ли мы это сделать» (feasibility) команда разработки решает сама: прототип, спайк, нагрузочный тест. Это привычно, измеримо и не требует выходить из здания.

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

В итоге карта доказательств перекашивается в сторону реализуемости. Получается та же ловушка, что в материале про [confirmation bias в данных](/blog/confirmation-bias-v-dannyh-komanda-6-mesyatsev-validiruet-to-vo/): месяцы «валидации» того, во что команда уже верит.

Цену ошибки Бланд в интервью InfoQ формулирует без цифр, но точно. Компании тратят сотни тысяч долларов на решение, ни разу не поговорив с клиентом.

Если угадали — вы гений. Но ошибаются многие, и это «очень медленный и дорогой способ провалиться».

## Четыре типа допущений: desirability, viability, feasibility, adaptability

В книге риск бизнес-идеи раскладывают на три типа, в статье 2020 года Бланд добавляет четвёртый. Формулировки вопросов — из его статьи, описание риска — из книги.

| Тип | Вопрос Бланда | В чём риск | Чем обычно доказывают |
|---|---|---|---|
| Desirability (желанность) | Хочет ли рынок эту идею? | Рынок мал, ценностное предложение нужно немногим, клиентов не удаётся привлечь и удержать | Интервью о прошлом поведении, фейковая дверь, предзаказ |
| Viability (жизнеспособность) | Достаточно ли идея прибыльна? | Клиенты не платят или платят мало, издержки съедают маржу | Тест цены, предоплата, расчёт юнит-экономики на реальных данных |
| Feasibility (реализуемость) | Сможем ли мы поставлять это в масштабе? | Нет доступа к ключевым ресурсам, технологиям, партнёрам, компетенциям | Прототип, спайк, пилот у одного клиента |
| Adaptability (адаптивность) | Выживет ли идея в меняющейся среде? | Конкуренты, сдвиг технологий, регулирование | Сценарии, разбор регуляторики, мониторинг рынка |

Для AI-продуктов таблица особенно полезна. Feasibility в них кажется главным риском — модель то ошибается, то нет. Но это риск, который снижается работой инженеров, а desirability и viability работой инженеров не снижаются: их проверяют только на клиентах.

## Как сформулировать допущение: «Мы верим, что…»

Бланд просит писать допущения в формате «Мы верим, что…» (We believe that…). Формулировка сразу напоминает: это убеждение, и оно может оказаться ложным.

Хорошая гипотеза, по Бланду, проверяема, точна и дискретна.

Проверяема — можно придумать наблюдение, которое её опровергнет. Точна — понятно, кто, что и сколько. Дискретна — в одной фразе одно утверждение, а не три через «и».

| Плохо | Хорошо |
|---|---|
| «Клиентам нужен AI» | «Мы верим, что операторы поддержки отправляют AI-черновик ответа с минимальными правками хотя бы в половине тикетов» |
| «Продукт будет прибыльным» | «Мы верим, что клиенты на тарифе Business заплатят за модуль надбавку к текущему тарифу» |
| «Интеграция несложная» | «Мы верим, что подключим базу знаний клиента без участия его ИТ-отдела» |
| «Рынок большой и растёт» | «Мы верим, что в сегменте есть не меньше N компаний с отделом поддержки от 20 человек» |

Разница между допущением и гипотезой, по Бланду, в том, что гипотезу можно проверить. Формулировки нормально уточнять по ходу сессии.

## Матрица 2×2: настоящие оси Бланда

На картах допущений в интернете оси часто подписывают «риск × неопределённость» или «влияние × уверенность». У Бланда они другие, и это принципиально.

- **Вертикальная ось — важность.** Вопрос для каждой карточки: если это допущение окажется ложным, провалится ли идея? Наверх — то, без чего бизнес не работает. Вниз — то, что неприятно, но не смертельно.
- **Горизонтальная ось — доказательства.** Есть ли у команды наблюдаемые доказательства, качественные или количественные? Справа — нет доказательств, слева — есть. Мнение основателя, слайд аналитика и «все так делают» доказательствами не считаются.

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

| Квадрант | Что там лежит | Что делать |
|---|---|---|
| Важно, нет доказательств | Убеждения, от которых зависит успех и которые никто не проверял | Эксперименты в ближайшие недели |
| Важно, есть доказательства | Проверенный фундамент | Опираться и периодически перепроверять — доказательства устаревают |
| Неважно, нет доказательств | Любопытные вопросы | Отложить, не тратить на них бюджет |
| Неважно, есть доказательства | Известное и некритичное | Не трогать |

## Как провести сессию картирования допущений за 60 минут

В комнате — люди, отвечающие за разные риски: продукт, дизайн, разработка, продажи или маркетинг, финансы. Ведёт продакт или фасилитатор.

Руководитель полезен как источник допущений, но опасен как арбитр: если он двигает карточки, команда перестаёт спорить.

До встречи соберите описание идеи на одном листе — Бланд строит сессию вокруг Business Model Canvas или Value Proposition Canvas.

1. **0–5 минут. Назовите решение.** Не «обсудить AI-фичу», а «решаем, вкладывать ли квартал команды в модуль AI-черновиков». Без решения карта превращается в мозговой штурм.
2. **5–20 минут. Молча выпишите допущения.** Каждый пишет свои карточки в формате «Мы верим, что…». Один цвет на тип: desirability, viability, feasibility, adaptability. Молча — чтобы голос самого старшего не задал рамку.
3. **20–30 минут. Почистите формулировки.** Склейте дубли, разбейте составные утверждения, перепишите размытые. Проверка — у каждой карточки должно существовать наблюдение, которое её опровергнет.
4. **30–45 минут. Разложите по матрице.** Сначала важность, потом доказательства. Бланд предлагает идти по типам в порядке: desirability, feasibility, viability, adaptability. Спор о положении карточки — полезный сигнал: у команды разные картины мира.
5. **45–55 минут. Выберите три карточки в правом верхнем углу.** Не десять. Три самых важных и наименее доказанных, по одной на ответственного.
6. **55–60 минут. Назначьте владельцев и сроки.** Каждый владелец до конца недели приносит план эксперимента по шаблону ниже.

## Как выбрать самый дешёвый эксперимент для правого верхнего квадранта

У Strategyzer есть Test Card — карточка эксперимента из четырёх вопросов. Остервальдер описал её в 2015 году, и её удобно заполнять сразу после карты:

```text
1. Мы верим, что <допущение с карты>.
2. Чтобы проверить, мы <эксперимент>.
3. И измерим <метрика>.
4. Мы правы, если <порог, записанный до запуска>.
```

Порог в четвёртом пункте — самое важное. Если его нет, любой результат можно объявить успехом.

Дальше действует правило, которое Остервальдер сформулировал в интервью InfoQ: начинайте со слабых доказательств и переходите ко всё более сильным для той же гипотезы. Пример из того же интервью — сначала на интервью спросить о бюджете, затем попросить предоплату. Мнение «я бы заплатил» слабее факта «когда вы в последний раз покупали это и сколько отдали».

В книге этот путь разделён на две фазы, взятые у Стива Бланка: discovery — понять, верно ли общее направление, и validation — подтвердить направление сильными доказательствами.

Практическая лестница для руководителя:

- **Discovery, дни.** Интервью о прошлом поведении — по правилам [Mom Test](/blog/mom-test-intervyu-s-klientami/), разбор уже имеющихся данных, ручная проверка на десятке реальных случаев.
- **Discovery, недели.** Фейковая дверь в интерфейсе, лендинг с конкретной ценой, «волшебник страны Оз» — функцию выполняет человек, а клиент видит результат.
- **Validation, недели и месяцы.** Предзаказ, подписанное письмо о намерениях, платный пилот, ограниченный релиз.

Сколько можно потратить на эксперимент, подскажет [ценность информации по Хаббарду](/blog/value-of-information-hubbard/): проверка не должна стоить больше, чем ожидаемые потери от ошибки по этому допущению.

## Пример: карта допущений для AI-фичи

Ситуация условная, числа — для иллюстрации. B2B SaaS для службы поддержки хочет выпустить модуль, который пишет оператору черновик ответа по базе знаний клиента. Команда разработки предлагает шесть недель на RAG-пайплайн и оценку качества модели.

Карта после часовой сессии:

| Допущение «Мы верим, что…» | Тип | Важность | Доказательства | Квадрант |
|---|---|---|---|---|
| …операторы отправляют черновик с минимальными правками хотя бы в половине тикетов | Desirability | Высокая | Нет | Правый верхний |
| …руководители поддержки заплатят за модуль надбавку к тарифу | Viability | Высокая | Нет | Правый верхний |
| …стоимость генерации на тикет ниже надбавки с запасом | Viability | Высокая | Частично: есть прайс провайдера модели | Ближе к центру |
| …модель отвечает по базе знаний без грубых ошибок | Feasibility | Высокая | Есть прототип на демо-данных | Левый верхний |
| …служба безопасности клиента разрешит отправлять тикеты внешней модели | Feasibility | Высокая | Нет | Правый верхний |
| …операторам понравится дизайн панели | Desirability | Низкая | Нет | Правый нижний |

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

- **Правки операторов.** Взять 200 закрытых тикетов, сгенерировать черновики текущим прототипом, дать пятерым операторам отредактировать. Мера — доля черновиков, отправленных с мелкими правками. Порог задан заранее. Неделя работы.
- **Готовность платить.** Показать десяти действующим клиентам описание модуля с конкретной надбавкой и предложить платный пилот. Мера — сколько согласились платить, а не сколько «интересно». Две недели.
- **Безопасность.** Отправить опросник по обработке данных трём крупнейшим клиентам до любой разработки. Если двое из трёх требуют размещения модели в своём контуре — архитектура и экономика меняются целиком.

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

## Как руководителю использовать карту на инвест-комитете и в квартальном планировании

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

На инвест-комитете или защите инициативы попросите показать карту, а не бизнес-план. Вопросы для разбора:

- Какие три допущения в правом верхнем углу?
- Какое из них убьёт идею, если окажется ложным?
- Что считается доказательством и какой порог успеха записан заранее?
- Сколько стоит эксперимент и сколько — разработка, которую он страхует?
- Что изменится в решении при каждом исходе?

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

Квартальное планирование под это ложится хорошо. Бланд говорит, что для уверенности в направлении часто нужен как минимум один эксперимент в неделю на протяжении 12 недель — почти ровно квартал.

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

Это же защищает от [ловушки тяжёлого ТЗ](/blog/lovushka-tyazhelogo-tz-30-stranits-vmesto-2-nedelnogo-testa/): 30-страничный документ не двигает ни одну карточку, двухнедельный тест — двигает.

## Ошибки при картировании допущений

- **Карта без решения.** Выписали 80 карточек «про продукт вообще», ни одна не связана с конкретной ставкой. Нет решения — нечего ранжировать.
- **Мнение вместо доказательства.** «Мы говорили с клиентами» — не доказательство, пока не сказано, с какими, о чём и что они сделали.
- **Перекос в feasibility.** Половина карточек технические, потому что инженеров в комнате больше всех. Проверьте баланс цветов до раскладки.
- **Эксперимент без порога.** Порог придумывают после результатов — и любой результат оказывается успехом.
- **Карта на стене, а не в работе.** Её нарисовали один раз на старте. Доказательства устаревают, рынок меняется, карту надо пересобирать после каждого значимого эксперимента.

## Когда карта допущений не нужна

- **Решение дешёвое и обратимое.** Поменять текст кнопки проще и быстрее, чем провести сессию.
- **Неопределённость низкая.** Вы повторяете то, что уже делали, на том же рынке. Большинство карточек окажутся в левой половине.
- **Ошибку нельзя проверить заранее.** Сделка с одним крупным клиентом, где эксперимент невозможен. Тогда полезнее разбор сценариев и [премортем](/blog/premortem-analiz-proval-do-zapuska/).
- **Ещё не понятна задача клиента.** Если команда не знает, какую проблему решает, карта допущений о решении преждевременна. Сначала исследование проблемы и дерево возможностей.

Ограничение самого метода: важность и доказательства оцениваются на глаз. Матрица выравнивает картину мира в команде, но не считает деньги — для крупной ставки добавьте расчёт цены ошибки.

## Чек-лист: как внедрить за неделю

- **День 1.** Выберите одну инициативу, по которой решение о бюджете будет в ближайший месяц.
- **День 2.** Проведите 60-минутную сессию с представителями продукта, разработки, продаж и финансов.
- **День 3.** Получите от владельцев три Test Card с порогами успеха, записанными до запуска.
- **День 4.** Утвердите бюджет и срок на эксперименты; разработку по инициативе пока не финансируйте.
- **День 5.** Договоритесь о формате отчёта: какие карточки переехали, какое решение из этого следует. Назначьте пересборку карты через две-три недели.

## Частые вопросы

### Чем карта допущений отличается от матрицы рисков?

Матрица рисков оценивает вероятность и ущерб от событий, которые могут случиться с проектом. Карта допущений оценивает убеждения, на которых стоит сама идея, и ранжирует их по важности и наличию доказательств. Её результат — не план митигации, а список экспериментов.

### Assumption mapping vs дерево возможностей: что делать первым?

Сначала дерево возможностей: оно помогает выбрать, какую возможность и какое решение рассматривать. Затем карта допущений по выбранному решению показывает, что в нём проверять первым. У Терезы Торрес нижний уровень [дерева возможностей](/blog/opportunity-solution-tree/) — как раз тесты допущений (assumption tests).

### Сколько допущений должно быть на карте?

Фиксированного числа Бланд не задаёт. Важнее, сколько карточек берут в работу: на ближайшие недели — три-пять из правого верхнего угла. Если там оказалась почти вся карта, вопрос о важности задан недостаточно жёстко.

### Как часто обновлять карту допущений?

После каждого эксперимента, который сдвинул карточку, и при любом серьёзном изменении на рынке. Для квартального планирования удобно пересобирать карту в начале квартала и сверять в середине.

### Что считать доказательством на карте?

Наблюдаемые данные, качественные или количественные: что клиенты сделали, сколько заплатили, как себя вели в эксперименте. Мнения, прогнозы и «экспертная уверенность» на горизонтальной оси держат карточку справа. Сила доказательства растёт от слов к действиям: от «я бы купил» к предоплате. Чтобы заполнять ось доказательств по записям, а не по памяти, пригодится [база атомарных исследований](/blog/atomic-research-atomarnye-issledovaniya/).

## Источники

- David J. Bland. [How assumptions mapping can focus your teams on running experiments that matter](https://www.strategyzer.com/library/how-assumptions-mapping-can-focus-your-teams-on-running-experiments-that-matter). Strategyzer, 4 августа 2020.
- David J. Bland, Alex Osterwalder. *Testing Business Ideas: A Field Guide for Rapid Experimentation.* Wiley, 2019. [Ознакомительный фрагмент](https://content.e-bookshelf.de/media/reading/L-13331335-cf42c802cd.pdf).
- [Q&A on the Book Testing Business Ideas](https://www.infoq.com/articles/book-review-testing-business-ideas). Интервью с Дэвидом Бландом и Александром Остервальдером, InfoQ, 22 января 2020.
- Alex Osterwalder. [Validate your ideas with the Test Card](https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card). Strategyzer, 5 марта 2015.
- [Precoil — о компании](https://www.precoil.com/about).
- Teresa Torres. [Opportunity Solution Trees](https://www.producttalk.org/opportunity-solution-trees/). Product Talk — нижний уровень дерева: тесты допущений.