Impact mapping
Impact mapping — техника планирования, которая помогает связать требования с бизнес-результатом
Результат — визуальная карта, отвечающая на вопросы по порядку:
- Зачем это делаем? (Цель)
- Кто может помочь или помешать? (Актор)
- Как должно измениться их поведение? (Влияние)
- Что можем создать, чтобы вызвать это изменение? (Результат)
Ключевая идея:
Не строим функции. Меняем поведение акторов для достижения цели.
Какую проблему решает
Часто требования формируются как список функций. Эт о приводит к проблемам:
- Нет связи между функциями и бизнес-целями
- Бэклог переполнен
- Приоритеты определяются субъективно
- Команда становится “feature factory”
Традиционные артефакты (user stories, use cases):
- описывают что сделать
- но не требуют объяснения зачем
Impact Mapping вводит причинно-следственную модель:
цель → акторы → изменения поведения → решения
И обратную проверку:
решение → влияние → актор → цель
Если цепочка не работает в обе стороны — элемент не нужен.
Основные элементы
Важное правило: всегда 4 уровня. Без исключений.
1. Цель
Не “что улучшить”, а “какой результат получить”.
Пример
Не подходит: Улучшить UX
Подходит: Увеличить конверсию с 2% до 3% за 3 месяца
Не подходит: “Сделать приложение быстрее”. Подходит: “Сократить среднее время оформления заказа с 90 секунд до менее чем 30 секунд к Q3”.
→ без метрики невозможно понять, работает ли решение
2. Акторы
Это люди или группы, которые могут повлиять на цель. Они могут помогать или мешать.
НЕ системные компоненты. Это не БД и не API. Это роли с поведением.
Примеры акторов
- Гостевой пользователь (без аккаунта)
- Авторизованный премиум-подписчик
- Агент поддержки
- Сотрудник комплаенс-отдела
- Кладовщик на складе
Не подходит: “Система оплаты”
Подходит: “Пользователь”, “Оператор поддержки”
3. Влияния
Это изменение поведения актора. НЕ функция и НЕ действие системы..
Пример
Функция: “Добавить тёмную тему”.
Влияние: “Пользователь читает приложение дольше в часы до 8 утра”.
Функция: “Показывать всплывающее окно со скидкой”.
Влияние: “Гостевой пользователь завершает оформление заказа вместо ухода”.
Влияние должно быть наблюдаемым. Если невозможно измерить, изменилось ли поведение, это не влияние.
→ поведение можно измерить, эмоции — нет
4. Результаты
То, что создаёт команда: функции, истории, задачи, API, UI-компоненты, отчёты. Результат попадает на карту, только если он напрямую поддерживает влияние.
Несколько результатов могут поддерживать одно влияние. Один результат может поддержива ть несколько влияний
“Если мы сделаем X → поведение изменится”
Важно:
- не искать “лучшее решение”
- искать минимальное решение для проверки гипотезы
Пример
Цель: Увеличить долю повторных покупок с 30% до 45% к 31 дек
│
├── Актор: Авторизованный клиент
│ ├── Влияние: Возвращается на сайт в течение 7 дней без напоминания
│ │ ├── Результат: Персонализированная главная с недавно просмотренными товарами
│ │ └── Результат: Сохранение корзины между сессиями с визуальным инд икатором
│ └── Влияние: Добавляет товары в корзину быстрее, чем в прошлый раз
│ └── Результат: Повторный заказ в один клик из истории заказов
│
├── Актор: Покупатель впервые
│ └── Влияние: Создаёт аккаунт после покупки (а не до)
│ └── Результат: Предложение создать аккаунт после оформления заказа (без принудительного входа)
│
└── Актор: Агент поддержки
└── Влияние: Решает проблемы с аккаунтом без эскалации в инженерию
└── Результат: Самостоятельный сброс пароля с SMS-подтверждением
Правила приоритизации
В Impact Mapping строгие правила приоритизации. Нарушение их ломает технику.
Правило 1: Никогда не приоритизируйте результаты без обратной трассировки
У результата нет собственного приоритета. Его приоритет определяется:
- Влиянием, которому он служит
- Актором этого влияния
- Целью, которой служит этот актор
Трассировка: результат → влияние → актор → цель.
Если какая-то связь слабая или отсутствует, переместить результат вниз или удалите.
Правило 2: Фильтрация через влияние
Когда предлагается новая функция: “Какое влияние это вызовет?”
- Если нет ответа, отклоните функцию.
- Если называется влияние, которого нет на карте, рассмотреть возможность добавления (с доказательством, что это изменение поведения действительно важно для цели).
Правило 3: Полное покрытие актора важнее, чем распыление
Лучше полностью покрыть одного актора (все его высокоприоритетные влияния поддерживаются результатами), чем частично покрыть пятерых.
Частичное покрытие создаёт путаницу. Ни один актор не получает достаточно поддержки для изменения поведения. Результаты не появляются.
Правило 4: Три измерения приоритизации
Использовать эти измерения в указанном порядке:
- Вес влияния – Насколько сильно это влияние продвигает цель? (Высокий/Средний/Низкий)
- Риск допущения – Насколько не уверены, что этот результат вызовет влияние?
- Сколько стоит – Среди результатов с одинаковым весом влияния и похожим риском выбирать те, которые требуют меньше всего усилий.
Правило 5: Одна карта — одна цель
Не помещать несколько целей на одну карту. Одна карта с двумя целями делает приоритизацию невозможной,так как результ ат для цели А может навредить цели Б.
Пример
Интернет-магазин имеет 70% брошенных корзин на этапе оформления заказа. Средний показатель по отрасли — 50–60%.
Цель (Уровень 1) Снизить долю брошенных корзин с 70% до 50% к концу Q3.
Акторы (Уровень 2)
- Гостевой пользователь (без аккаунта)
- Авторизованный пользователь (есть аккаунт)
- Агент поддержки
Влияния и результаты (Уровни 3 и 4)
Актор: Гостевой пользователь
- Влияние 1: Завершает покупку без создания аккаунта
- Результат 1.1: Оформление заказа в один клик для гостя (без поля с паролем)
- Результат 1.2: Полностью убрать экран “Создайте аккаунт, чтобы продолжить”
- Влияние 2: Не бросает корзину, когда его просят ввести email
- Результат 2.1: Поле email — опционально до ввода адреса доставки
- Результат 2.2: Подсказка “Зачем нам ваш email” при наведении
- Влияние 3: Возвращается, чтобы завершить покупку после ухода
- Результат 3.1: Корзина сохраня ется на 30 дней в локальном хранилище браузера
- Результат 3.2: Без сообщения “Войдите, чтобы сохранить корзину”
Актор: Авторизованный пользователь
- Влияние 1: Завершает оформление заказа менее чем за 60 секунд
- Результат 1.1: Автозаполнение сохранённых адресов доставки (выбор в один клик)
- Результат 1.2: По умолчанию выбран последний использованный способ оплаты
- Влияние 2: Не уходит проверять цены у конкурентов
- Результат 2.1: Бейдж сравнения цен (“Ниже, чем на Amazon на X ₽”)
- Результат 2.2: Блокировка цены на 10 минут после добавления в корзину
Актор: Агент поддержки
- Влияние 1: Решает проблемы с неудачным оформлением заказа менее чем за 2 минуты
- Результат 1.1: Просмотр логов бэкенда с кодом причины сбоя
- Результат 1.2: Кнопка возврата в один клик из интерфейса тикета
- Влияние 2: Проактивно связывается с пользователями, застрявшими на экране оплаты
- Результат 2.1: Дашборд в реальном времени с пользователями на экране оплаты >90 секунд
- Результат 2.2: Триггер чата для агента, чтобы написать пользователю
Как карта предотвращает потери
До построения карты планировались функции:
- Загрузка фото профиля
- Социальный вход (Google, VK)
- Звёздочки отзывов на странице оформления заказа
- Анимированное конфетти после покупки
После построения карты все удалили. Так как:
- Фото профиля не вызывает никакого влияния ни для одного актора.
- Социальный вход не заставляет гостевых пользователей завершать покупку (он добавляет трение).
- Звёздочки отзывов на оформлении заказа не меняют поведения бросания корзины.
- Конфетти не снижает число брошенных корзин (оно происходит после покупки).
Вместо этого создан гостевой заказ, сохранение корзины и инструменты для агентов.
Типичные ошибки
Размытая цель
- Не ок: “Улучшить онбординг”
- Ок: “Увеличить регистрацию с 40% до 60%”
Акторы = системы
- Не ок: API, БД, микросервис
- Ок: Человеческие роли. “API” становится “внешний разработчик”. “БД” становится “DBA на дежурстве”. Системы не меняют поведение намеренно. Люди — да.
Влияние = функция
- Не ок: “показать”, “отобразить”, “отправить”, “добавить
- Ок: “пользователь быстрее переходит к оплате”
Нет связи с влиянием
- Не ок: “Добавить тёмную тему” (без объяснения)
Слишком много акторов → невозможно приоритизировать
Карта не обновляется → Решения больше не актуальны Пересматривать карту каждый цикл планирования (спринт, месяц, квартал). Обновлять влияния на основе готовых результатов.
Влияние без наблюдаемости
- Не ок: “пользователь чувствует уверенность”, “пользователь доверяет платформе”).
- Ок: Наблюдаемое поведение: “Пользователь завершает оформление заказа без обращения в поддержку”. “Пользователь переходит на третью страницу резул ьтатов поиска”.
Роль аналитика
Аналитик — не “собиратель требований”, а управляющий логикой
- следит за причинно-следственными связями
- убирает всё без влияния
- превращает идеи в проверяемые утверждения
Когда использовать или нет
- Исследование нового продукта
- Разработка функции на нескольких спринтов. Impact mapping гарантирует, что каждая часть связана с изменением поведения.
- Кросс-функциональная работа с участием продакта, инженерии, маркетинга, продаж. Карта создаёт общий язык.
- Планирование. Прежде чем заполнять бэклог, создать impact-карты для каждой цели. Затем извлечь функции из карт.
- Много функций, но нет бизнес-результатов.
Не стоит использовать:
- Исправление багов
- Задачи только ради соответствия требованиям (compliance)– Изменения поведения нет.
- Уже создавались подобные инструменты
- Инфраструктурная работа (обновление БД, миграция серверов). Можно применить карту на уровне возможностей: “Актор: Разработчик. Влияние: Разворачивает код 3 раза в день без инцидентов. Результат: Новый кластер БД”.
Интеграция с другими методами
- Scrum – Создать impact-карту во время уточнения бэклога или спринта. Написать пользовательские истории на основе результатов с карты.
- Kanban – Для приоритизации бэклога.
- Lean Startup – Рассматривать результаты как эксперименты. Каждый результат проверяет происходит ли предполагаемое влияние. Если влияние не происходит — повернуть (pivot), изменив результат или отказавшись от влияния.
- OKR – Цель на impact-карте становится Objective (Задачей). Влияние - Key Result (Ключевым результатом) — поведенческим. Результаты - инициативами. Вот исправленный список, где нумерация в каждом разделе начинается заново.
Материалы
- Impact Mapping на практике
- Как создать работающий Impact Map
- Impact Mapping на практике
- Кнопочное мышление против целостного IT-продукта
- Ваша карта не будет бита: как добавить Impact Map, CJM и USM в документ и не пострадать
- Анализ и проектирование социотехнических систем
- Impact Mapping — как dev-команде перестать делать то, что требуют, и начать делать то, что нужно?
- Как плани ровать работу команды, чтобы не делать бесполезные вещи?
- Сайт книги от создателя подхода "Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке | Аджич Гойко"
Видео
- Что такое Impact Mapping за 3 минуты
- Что такое Impact Map (на конкретном примере)
- Impact Mapping для стратегического планирования / Анна Лопатухина, Яндекс.Недвижимость