Как создать работающий Impact Map
Больше 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 и дам «ключи», чтобы вы могли точнее понять, что конкретно надо вписывать в каждую из них:
Goal — здесь нужно описать измеримый результат. «Ключом» будет ответ на вопрос, который вы зададите себе и бизнесу: «Представьте, что прошло время и мы уже сделали релиз. По каким критериям мы поймем, что достигли успеха?». Такой вопрос помогает перенестись мыслями в будущее и подумать, как мы собираемся оценивать результат. Формулировка выбрана так, чтобы человек начал рефлексировать, и это не тоже самое, что спросить «какая у вас цель?». Цели могут быть всякие разные, а вот конечный результат в будущем оценят по каким-то критичным для бизнеса параметрам, их и запишите в Goal.
Actor — на кого мы собираемся оказывать воздействие. Обычно сюда предлагают писать тех, кто нам можем помочь или помешает в достичь цель. Так можно делать, это неплохой совет, но он недостаточно фокусирует нас. Я предлагаю думать о том, жизнь кого мы хотим поменять с помощью воздействия, чтобы это изменение жизни привело нас к цели. Трюк в том, что мы не просто собираемся воздействовать, а мы надеемся, что наше воздействие изменит поведение людей в нужную сторону. Такой взгляд заставляет точнее очерчивать границы для Actor и приходится тщательней обдумывать Impact.
Impact — воздействие, которое мы собираемся сделать. Это самая сложная часть, которая мало кому дается. Я сравниваю ее с созданием гипотезы в научном методе или рождением идеи в ТРИЗ, т.е. техника понятна, но откуда берется идея, как она рождается в голове, как научить человека эти идеи создавать, решительно неясно. Здесь «ключом» может стать понимание, что в этой колонке мы описываем ключевые идеи нашего продукта, то, что в итоге принесет деньги. Если собрать все импакты из итоговой карты, то у нас должно получится уникальное торговое предложение. Об этой части Impact Map будет вся остальная статья, где я расскажу на примере притчи, как описываются идеи.
Deliverable — это список задач, тут всё просто.
Типичные ошибки Impact Mapping
Impact Map обычно не получается по следующим причинам:
Цели неизмеримы или неясны. Это тот случай, когда хочется сделать много чего, но непонятно зачем. Анти-паттерном будет закрыть глаза на отсутствие цели и накидать задач в работу, как делали во времена «плоских» ТЗ.
Описаны абстрактные юзеры, , но неясно как наши воздействия поменяют их поведение. Анти-паттерном будет указать просто «пользователей», потому что потеряется связь с реальностью, в этих «пользователях» нет жизни и настоящих потребностей. Это приведет к тому, что мы опишем идеи, но не будем понимать, как они повлияют на мир.
Вместо идей и гипотез (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 в повседневной практике.
