Читать книгу Антихрупкость в IT - Александр Васильевич Бындю - Страница 23

Разбор нюансов создания Impact Map на примере притчи

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

Мы уже познакомились с этой техникой в прошлой главе, а сейчас я расскажу, каким образом формулируются идеи, которые являются самой сложной и самой ценной частью Impact Map. И ещё поделюсь своим ви́дением, как наиболее эффективно воспринимать каждую из частей Impact Map.

Нюансы Impact Mapping

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

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

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

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

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

Deliverable – это список задач или историй. В этой области все отлично умеют действовать.

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

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

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

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

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

Приведу пример, который поможет вам во всём разобраться.

Impact Mapping гончара

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

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

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

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

Рис. 10. Первые гипотезы и задачи гончара по достижению своей цели

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

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

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

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

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

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

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

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

Рис. 11. Появление новой гипотезы у гончара

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

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

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

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

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

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

19

Стать в блоге компании ScrumTrek. Impact Mapping – инструкция по применению