Больше 8 лет я использую Impact Map для аналитики IT-продуктов. Я довольно активно делился знаниями об этом подходе: писал статьи, выступал на конференциях с докладами и мастер-классами, рассказывал студентам в университетах и интернам в компании. Слушатели и участники мастер-классов легко улавливают, как создавать и использовать Impact Map, т.е. с теорией нет проблем. Тем не менее, я вижу большие затруднения с применением этого подхода в реальной практике, когда нужно придумать и описать идеи для сложного IT-продукта.

В этой статье я сделаю попытку объяснить, каким образом формулируются идеи, которые являются самой сложной и самой ценной частью Impact Map, а также поделюсь своим видением, как наиболее эффективно воспринимать каждую из частей Impact Map.

Статьи и выступления, в которых я собирал свой опыт работы через Impact Mapping:

1. Выступление на AgileDays 2015 Impact Mapping на практике.
2. Мастер-класс на AgileDays 2016 в рамках выступления Пять самых важных составляющих процесса выпуска продуктов.
3. Статья Impact Mapping на практике.
4. Статья Кнопочное мышление против целостного IT-продукта.
5. Описание аналитика IT-продукта, где первая часть — Impact Map.

Коротко об Impact Mapping

В своей книге Gojko Adzic, автор Impact Map, дает вот такую схему:

Идея в том, чтобы прорисовать связь от задач (Deliverable) к цели (Goal). По задумке, задачи оказывают воздействие (Impact) на какую-то группу (Actor) и это воздействие приводит бизнес к цели. Таким образом, нет бесполезных задач и четко видно что и зачем мы собираемся делать.

В этой, казалось бы, понятной схеме кроется много нюансов, которые вызывают ступор. Я приведу свою интерпретацию каждой части Impact Map и дам "ключи", чтобы вы могли точнее понять, что конкретно надо вписывать в каждую из них:

1. Goal – здесь нужно описать измеримый результат. "Ключом" будет ответ на вопрос, который вы зададите себе и бизнесу: "Представьте, что прошло время и мы уже сделали релиз. По каким критериям мы поймем, что достигли успеха?". Такой вопрос помогает перенестись мыслями в будущее и подумать, как мы собираемся оценивать результат. Формулировка выбрана так, чтобы человек начал рефлексировать, и это не тоже самое, что спросить "какая у вас цель?". Цели могут быть всякие разные, а вот конечный результат в будущем оценят по каким-то критичным для бизнеса параметрам, их и запишите в Goal.

2. Actor – на кого мы собираемся оказывать воздействие. Обычно сюда предлагают писать тех, кто нам можем помочь или помешать в достижении цели. Так можно делать, это неплохой совет, но он недостаточно фокусирует нас. Я предлагаю думать о том, жизнь кого мы хотим поменять с помощью воздействия, чтобы это изменение жизни привело нас к цели. Трюк в том, что мы не просто собираемся воздействовать, а мы надеемся, что наше воздействие изменит поведение людей в нужную сторону. Такой взгляд заставляет точнее очерчивать границы для Actor и приходится тщательней обдумывать Impact.

3. Impact – воздействие, которое мы собираемся сделать. Это самая сложная часть, которая мало кому дается. Я сравниваю ее с созданием гипотезы в научном методе или рождением идеи в ТРИЗ, т.е. техника понятна, но откуда берется идея, как она рождается в голове, как научить человека эти идеи создавать, решительно неясно. Здесь "ключом" может стать понимание, что в этой колонке мы описываем ключевые идеи нашего продукта, то, что в итоге принесет деньги. Если собрать все импакты из итоговой карты, то у нас должно получится уникальное торговое предложение. Об этой части Impact Map будет вся остальная статья, где я расскажу на примере притчи, как описываются идеи.

4. Deliverable – это список задач, тут всё просто.

Типичные ошибки Impact Mapping

Impact Map обычно не получается по следующим причинам:

1. Цели неизмеримы или неясны. Это тот случай, когда хочется сделать много чего, но непонятно зачем. Анти-паттерном будет закрыть глаза на отсутствие цели и накидать задач в работу, как делали во времена "плоских" ТЗ.

2. Описаны абстрактные юзеры, но неясно как наши воздействия поменяют их поведение. Анти-паттерном будет указать просто "пользователей", потому что потеряется связь с реальностью, в этих "пользователях" нет жизни и настоящих потребностей. Это приведет к тому, что мы опишем идеи, но не будем понимать, как они повлияют на мир.

3. Вместо идей и гипотез (Impact), написаны user story или задачи. Эта самая частая проблема. Я даже специально повторю, что это очень частая проблема, которая убивают всю идею Impact Map! В этом случае происходит подмена идей задачами, потому что у аналитиков нет идей и нет гипотез, и они по привычке пишут to-do list.

Подавляющее большинство неудачных Impact Map происходит из-за третьей причины, поэтому дальше я приведу пример, который должен помочь разобраться с этой проблемой.

Impact Mapping гончара

Я взял старую и известную притчу о гончаре. Гончар столкнется с проблемой, сформулирует цель и попробует придумать идею, как ему достигнуть цели.

Притча о гончаре и мальчишках

Жил на свете старый гончар. Он делал горшки, продавал их на базаре и на это жил. Но вот повадились соседские мальчишки бить его горшки. Он и просил их не делать этого, уговаривал, ругал, жаловался их родителям - ничего не помогало...

У гончара были три основные идеи и две группы людей, на которых он надеялся воздействовать, чтобы достичь своей цели. Изначально его Impact Map мог выглядеть так:

Обратите внимание, что у каждой идеи есть блок "чтобы", который открывает практическую ценность идеи, показывает ее основу.

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

...Тогда он позвал мальчишек к себе во двор и сказал, что за каждый разбитый горшок будет платить им рубль. Мальчишки обрадовались, перебили все горшки, получили деньги и убежали. На следующий день гончар сказал, что денег у него мало, платить он может только 50 коп.

Мальчишки опять перебили все горшки, получили свои деньги и убежали. Следующий день опять повторилось то же самое, только за каждый разбитый горшок гончар заплатил только 20 коп.

На следующее утро ребятня опять прибежала во двор. Старик вышел к ним и сказал: "Денег, ребятки, у меня почти совсем не осталось, потому что продавать мне было нечего. Теперь за каждый разбитый горшок я могу платить только одну копейку". "Нашел дураков бесплатно бить твои горшки!" - возмутились мальчишки. Больше горшков они не били.

Это очень важный момент! Я прошу вас не смотреть дальше, а самостоятельно сформулировать идею, которая помогла гончару достигнуть результата. Обязательно пропишите часть "чтобы". Опишите идею так, чтобы она была целиком и полностью понятна любому, кто ее прочитает, т.е. не оставляйте скрытых смыслов. К идее запишите набор задач, которые нужны для ее реализации.

.

.

.

Еще один абзац, пока вы думаете над формулировкой. Предлагаю вам собрать коллег и вместе попробовать сформулировать идею. Попробуйте записать несколько вариантов. Если у вас получится коротко и ясно записать идею, то можете считать, что вы готовы сделать Impact Map IT-продукта почти любой сложности.

.

.

.

Я надеюсь, что к этому моменту вы сформулировали минимум один вариант идеи, которая помогла гончару. Ниже я приведу свой вариант, который кажется мне достаточно хорошим:

Когда гончар разочаровался в разговорах и угрозах (первые две гипотезы не сработали), ему пришлось искать идею, которая бы на самом деле воздействовала на мальчишек. Он понял, что бить горшки для них – это весело и забавно, поэтому нацелился на основу их мотивации. Он превратил веселое хобби в работу, а потом перестал за нее платить.

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

Мне было бы интересно увидеть ваши варианты, пишите для обсуждения в комментариях.

Почему так сложно сформулировать идею?

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

Из практики я вижу, что формулировка идей очень тяжело дается. Почему так происходит? Мне на ум приходит аналогия с решением прямых и косвенных задач. Оказывается дошкольники довольно легко могут решить прямые задачи типа: На ветке было 3 птицы, прилетело еще 6 птиц. Сколько стало птиц на ветке? Дети отвечают 9. Если эту же задачу с этими же цифрами сделать косвенной, т.е. проблемно-ориентированной, то дети теряются: С ветки улетело 3 птицы, осталось 6 птиц. Сколько птиц изначально было на ветке? Во второй задаче нужно как бы задом наперед взглянуть на ситуацию. У взрослых с описанием идей возникает так же проблема: они хорошо пишут прямые задачи (Deliverable), но им тяжело даются косвенные/проблемные сценарии (Impact).

Рекомендую тренироваться в описании идей на простых жизненных сценариях и в повседневной жизни. Это очень помогает на реальной сессии Impact Map, когда нужно сформуировать идею достижения цели в сложном IT-продукте.

Заключение

Я надеюсь, что мои мысли и "ключи" помогут вам использовать Impact Map. Буду рад вашим вопросам и историям о том, что еще помогает создавать вам Impact Map в повседневной практике.