Список функций редко объясняет, почему одну идею стоит рассматривать раньше другой. Панель аналитики, напоминание по электронной почте и новый экран первого знакомства с продуктом могут казаться полезными, но служить разным целям. Совместная оценка даст аккуратный рейтинг, не разрешив этого противоречия.
Impact Mapping — построение карты влияния — помогает связать выбор функций с бизнес-целью через изменения в поведении людей. Используйте этот подход до утверждения приоритетов бэклога, особенно если участники постоянно предлагают решения, не договорившись, какую проблему нужно решить.
Правильно разделяйте четыре уровня
Руководство Гойко Аджича по Impact Mapping строит обсуждение вокруг цели, участников, изменений поведения и результатов работы. Участники — это люди или группы, которые могут повлиять на итог. Изменения поведения описывают, что они должны начать делать иначе. Результаты работы — то, что организация может предоставить, чтобы поддержать такое изменение.
Различие принципиально. «Создать список шагов для начала работы» — результат работы. «Новые администраторы выполняют первую настройку без помощи» — изменение поведения. «Повысить успешность активации» — цель, которой ещё нужно дать измеримое определение. Смешение уровней делает карту внешне завершённой, но оставляет логику неясной.
Общее знакомство с методом можно начать с обзора Impact Mapping. Здесь задача уже: использовать карту для выбора между конкурирующими предложениями функций.
Сформулируйте одну цель и её границы
Пригласите того, кто принимает продуктовые решения, человека, понимающего пользователей, и специалиста, знающего ограничения реализации. Запишите одну цель, указав целевую группу, наблюдаемый результат и срок. Добавьте исходное значение показателя, если у вас есть надёжные данные. Если их нет, отдельно запланируйте сбор, а не подставляйте догадку.
Например, условный сервис записи хочет, чтобы больше новых администраторов команд получали реальную запись в первую неделю. Команда определяет «реальную» запись так, чтобы исключить тестовые, и указывает сегмент клиентов, за которым может наблюдать. Она также задаёт ограничения: не допустить резкого роста нагрузки на поддержку и не склонять пользователей к нежелательным уведомлениям.
Не помещайте в центр «запустить панель аналитики»: это заранее выбирает решение. Если заказчик настаивает на конкретном результате работы, спросите, какой эффект оправдает его создание. Иногда вопрос выявляет фиксированное договорное обязательство; такую работу нужно отделять от необязательных инициатив, выбираемых ради ожидаемого эффекта.
Сначала определите участников, затем решения
Перечислите людей, способных помочь достижению цели или помешать ему. В сервисе записи новые администраторы настраивают доступное время, приглашённые пользователи записываются, а сотрудники поддержки помогают преодолеть трудности настройки. «База данных» в этом смысле не является участником, хотя ограничения данных могут влиять на реализацию.
Для каждого участника опишите конкретное поведение, полезное для цели. «Опубликовать доступный интервал времени» лучше, чем «быть более вовлечённым». Уточните, как вы распознаете изменение в наблюдении, разговоре или событии, зафиксированном продуктом.
По возможности исходите из уже известных трудностей пользователей. Обобщение клиентской обратной связи помогает упорядочить подтверждающие наблюдения, но непроверенные предположения должны оставаться помеченными. Убедительно выглядящая ветвь карты — гипотеза о причинно-следственной связи, а не доказанный результат.
Пример: четыре запроса с разными основаниями
Команда сервиса записи получила запросы на панель аналитики, пошаговую настройку, напоминания о приглашениях и шаблон ответа поддержки. Вместо немедленной оценки функций она отмечает, на какое поведение должна повлиять каждая из них.
| Участник | Желаемое поведение | Возможные результаты работы | Вопрос перед вложением ресурсов |
|---|---|---|---|
| Новый администратор | Публикует пригодную для использования ссылку на запись | Пошаговая настройка; пример доступного времени; короткий звонок для настройки | Какой шаг настройки мешает публикации? |
| Приглашённый пользователь | Завершает запись по приглашению | Более понятный текст приглашения; упрощённая страница записи; напоминание | Пользователь не замечает сообщение или уходит со страницы? |
| Сотрудник поддержки | Решает проблему настройки без многократной переписки | Руководство по устранению неполадок; шаблон ответа; диагностические сведения | Какой информации не хватает в первом обращении? |
| Опытный администратор | Анализирует динамику записей за длительный период | Панель аналитики | Помогает ли это поведение достичь цели первой недели? |
Панель аналитики может быть ценной, но команда пока не может объяснить её вклад в эту цель. Запрос переносится в отдельный список возможностей. Это не означает, что аналитика неважна: команда решила не смешивать задачи удержания с проблемой активации.
Карта также показывает, что пошаговая настройка и короткий звонок — альтернативные способы проверить одно и то же поведение. Они не должны автоматически становиться двумя обязательными задачами бэклога.
Сначала выбирайте ветви, затем конкретные решения
Обсудите, какое изменение поведения важнее для цели и какое лучше подтверждено данными. Затем оцените неопределённость, трудозатраты и обратимость возможных действий. Не уделяйте всем ветвям одинаковое внимание только потому, что они занимают одинаковое место на доске.
Допустим, в обращениях в поддержку постоянно выясняется, что администраторы не понимают настройки доступного времени. Команда может сначала понаблюдать за несколькими сеансами настройки и проверить более понятные примеры. Если приглашённые вообще не доходят до страницы записи, её упрощение может решать не ту проблему. Порядок работы определяется данными, а не тем, для какой функции проще оценить трудозатраты.
Не превращайте приблизительные оценки в соревнование по точности. Балл может кратко выразить итог обсуждения, но объяснение должно оставаться понятным и без числа. Подпишите выбранную ветвь и основную причину: «Исследовать настройку доступного времени, потому что трудности на этом шаге не позволяют администраторам поделиться ссылкой на запись».
Выберите небольшое решение для проверки логики
Для выбранной ветви найдите минимальное действие, которое поможет понять, возможно ли предполагаемое изменение поведения. Это может быть прототип, услуга, оказываемая вручную, более понятная инструкция или ограниченное изменение продукта. Новая функция нужна не всегда.
В примере сервиса записи команда проверяет образец расписания с новыми администраторами. Она наблюдает, могут ли они создать подходящий интервал и объяснить, что увидит приглашённый пользователь. Затем команда проверяет, приводит ли полученная ссылка к реальным записям. Одно лишь завершение настройки ещё не подтверждает достижение конечной цели.
Запишите, при каких результатах команда продолжит работу, изменит решение или откажется от него. Если действие помогает только пользователям с простым недельным расписанием, сохраните это ограничение явно. Не выдавайте частичное подтверждение за универсальный успех.
Не смешивайте карту и бэклог
Карта содержит варианты и объяснения причинно-следственных связей; бэклог — работу, которую команда рассматривает или готовится выполнить. Копирование каждой конечной ветви в бэклог превращает возможности в подразумеваемые обязательства. Переносите только выбранные задачи и сохраняйте связь с поведением, которое они должны поддержать.
Начните с шаблона карты влияния или откройте Boardmix и нарисуйте четыре уровня на пустом холсте. Для сервиса записи свяжите цель первой записи за неделю с новыми администраторами, а затем — с публикацией пригодной для использования ссылки на запись. Разветвите карту на пример доступного времени, пошаговую настройку и короткий звонок. Пометьте пример доступного времени как «Исследовать первым», не принимая обязательств по остальным вариантам. Несвязанный запрос на аналитику поместите отдельно: он останется видимым, но не станет частью этой цели.
Когда появятся результаты, прежде чем расширять функцию, вернитесь к связи между решением и поведением. Если проблему решает более понятное приглашение, карта даёт основание не создавать систему напоминаний. Решение выполнить меньше работы может оказаться самым полезным итогом сессии приоритизации.
