Impact Mapping на практике

  • Tutorial


Когда читал книгу Impact Mapping первый раз, у меня было желание бросить её на середине. Всё, что там написано, слишком очевидно. Я нашел в себе силы и дочитал, благо книга коротная и с большими картинками. Как в последствии выяснилось, вся соль была в том, что все эти очевидные и простые практики из книги я не применял в своей работе.

Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.



История появления Impact Mapping



Раньше на старте проекта у нас были технические задания, схемы работы системы и, в хорошем варианте, прототипы интерфейса. В этих документах не хватало понимания динамики развития проекта и приоритетов в работе.

Мы начали писать User Story и делать Story Mapping. Эти практики добавили понимание того, как проект будет развиваться, какие сейчас приоритеты, дали нам возможность продуктивнее общаться с заказчиком. Чего не хватало? Продукты существуют не в вакууме, нужно видеть более глобальные задачи, которые лежат где-то выше историй использования системы. Не хватало простой игровой практики по постановке целей проекта, из которых потом будут появляться Story Mapping и список User Story.

Mijo Balic и Ingrid Ottersten в 2007 году написали статью Effect Managing IT (подробнее Agile product management using Effect Maps). Через 4 года в 2011 году Gojko Adzic выпустил книгу Specification by Example, где в главе «Deriving scope from goals» упоминает о технике под названием Effect mapping. Эта техника призвана помогать командам фокусироваться на бизнес-целях, выявлять заинтересованные стороны и их потребности.

Gojko Adzic со временем добавляет в Effect mapping несколько усовершенствований, таких как: приоритизация целей и воздействий, возможность уходить от технических деталей на уровне What, цикличность в предположениях и экспериментах и т.п. Лично мне кажется, что это важные изменения, они добавляют полезности в реальной жизни. После этого техника стала называться по-новому — Impact Mapping.

Сколько стоит килограмм кода?



Представьте себе ситуацию. К вам приходит заказчик. У него уже есть набор фич на покупку, он знает чего хочет. Он берёт корзину для покупок, как в магазине. Складывает в неё список технологий, десяток прототипов интерфейса, интеграцию с соц. сетями и т.п. Подходит к кассе и просит всё взвесить, реализовать и выставить ему счёт.



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

Будет ли такой проект успешным? Если у клиента живой бизнес и проект делается не «в стол», то успех можно оценить только эффектом, который был оказан на бизнес. Не количеством поставленных фич, не соблюдением сроков, не соблюдением бюджета, а только изменениями в бизнесе.

Скажем честно, сложно гарантировать, что проект станет успешным. Зато в наших силах увеличить шансы на успех за счёт того, что каждый в команде будет понимать и разделять цели бизнеса. Тогда любое решение — от именования переменной в коде до выбора архитектуры — будет приниматься, исходя из реальных потребностей бизнеса.

Остается вопрос, как вытащить из заказчика реальные цели бизнеса, которых мы хотим достичь? Как сделать так, чтобы команда услышала их, приняла и начала с ними работать?

Составляем Impact Mapping



Impact Mapping — это mind map по целям проекта с картой влияний, которые должны подтолкнуть бизнес заказчика к достижению целей.



Why?
Центральный элемент нашей карты, который отвечает на ключевой вопрос: Зачем мы это делаем? Это цель, которую бизнес пытается достичь.

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

How?
На втором уровне мы должны описать воздействия, которые должны оказать заинтересованные стороны, чтобы бизнес достиг целей. Мы ищем ответ на вопросы: Как они помогут бизнесу достичь целей? Как они могут помешать успеху проекта?

What?
После ответа на основные вопросы можно обсудить конкретные задачи. Третий уровень отвечает на вопросы: Что мы можем сделать как организация или команда разработки, чтобы создать необходимые воздействия? Здесь будет описан конечный результат нашей работы.

Организация процесса


  1. Приглашайте не больше 10-15 человек на это мероприятие, иначе будет сложно проводить. Оптимально позвать 3-4 человека со стороны заказчика и столько же со стороны команды.
  2. Со стороны заказчика обязательно взять представителей бизнеса, а не только технических специалистов, у которых уже сложилось мнение по поводу конкретных реализаций всех целей.
  3. Карту будете строить на доске или стене, подготовьте их заранее. Impact Mapping для задачи длительностью в 6-8 месяцев умещается на доске стандартного размера.
    Онлайн вариант этой техники я ещё не пробовал, но думаю подойдет любой интерактивный инструмент. Коммуникация будет не та, но вас может спасти, если вы лично знаете заказчика или являетесь отличным фасилитатором/модератором.
  4. Составление карты займёт от одного часа до двух дней. Эта цифра сильно зависит от состава участников и ваших навыков проведения.
  5. Каждый блок карты можно рисовать маркером или делать стикерами. Я предпочитаю стикеры, потому что они более мобильны, а impact map будет часто сортироваться и меняться по ходу погружения в проект.
  6. Перед началом обязательно проговорите правила и цели составления карты. Если есть время, то разошлите всем материал по теме для подготовки
  7. Если есть возможность и обстоятельства позволяют, то сделайте несколько Icebreaker'ов.
  8. И самое главное — сам процесс должен проходить легко и весело. Не добавляйте в него бюрократии!


Пример из практики



Разберём пример, очень приближенный реальному проекту, для которого в начале мы сделали Impact Mapping. Остановимся на ключевых моментах при составлении Impact Mapping и на ошибках, которые могу погубить всю идею.

Why?


Корневым элементом нашей карты будет список бизнес-целей. Например, это может быть увеличение удовлетворенности пользователей в 2 раза. Важно, что удовлетворенность пользователей — это индекс, т.е. конкретная цифра, которую можно взять из CRM, а не мнение/ощущение заказчика. Мы же хотим после поставки фич измерить достижение цели и понять, в том направлении мы идём или нет. Если бы удовлетворенность пользователей была не цифрой, то как бы мы узнали, что достигли цели? Ещё важно, что мы написали именно в 2 раза, а не просто увеличение. Хорошие цели должны быть SMART:



Первый этап довольно сложный, он должен дать импульс для составления остальной карты и создать доверие между участниками. Что я могу посоветовать, исходя из своей практики:
  1. Не торопитесь предлагать решения на этом этапе. Выслушайте заказчика, по-настоящему выслушайте. В ходе дальнейшего обсуждения вы успеете всё откорректировать и причесать, а пока запишите то, что есть у него в голове.
  2. Самая распространенная проблема заключается в навязывании решений (этап What?) до того, как цели стали понятны. Инженерная мысль летит со скорость света — заказчик только открыл рот, только начал говорить о своих целях, а мы уже создали в голове БД со всеми таблицами, придумали архитектуру и накидали куски кода. Зачем слушать дальше, если мы и так всё придумали? Будет ошибкой начать перебивать заказчика и предлагать решения. Запомните анекдот на эту тему и постарайтесь избежать проблемы: «Дима сказал «Привет», а Даша мысленно сыграла свадьбу и родила троих детей».
  3. Не переубеждайте заказчизка на этом этапе. В самом начале вы не знаете его бизнес во всех тонкостях. Заказчики могут вам доверять, как профессионалам в IT, и из-за этого быстро соглашаться на ваши корректировки. Вы сами не заметите как на доске окажутся только те цели, которые вы навязали, а не те, с которыми заказчик жил всё это время.
  4. Даже если цель трудноизмерима, то постарайтесь придумать критерий её достижения. Мысленно перенеситесь на финал проекта и подумайте, как вы узнаете достигнута цель или нет?
  5. Процесс выработки целей итерационный, не обязательно выжамать из заказчика все цели на первом круге.
  6. Не надо вытягивать искусственные цели. Бывают проекты, которые просто есть, потому что инвесторам хочется поиграть в создателей ПО. С этим нужно смириться и свернуть работу по составлению Impact Mapping.


На HappyDev 2014 я проводил мастер-класс по составлению Impact Mapping и Story Mapping. Играть роль заказчика согласился руководитель проекта по обработке заявок на строительство. Все, кто пришел на тренинг, были очень активными и сразу втянулись в процесс. Со временем мы осознали, что довольно сложно просто слушать заказчика и понять его проблему. Коллеги наперебой предлагали свои решения. В какой-то момент приходилось прерывать работу группы, напоминать, что мы должны больше слушать. Несколько раз из-за напряженной атмосферы и давления участников, заказчик принимал наши решения, откзываясь от своих. Я думаю, что все участники почувствовали важный баланс между тем, когда надо слушать заказчика, а когда надо предлагать решения.


Who?


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



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

How?


Теперь нам надо определить те воздействия, которые будут сделаны для достижения цели. Например, модератор форума может попробовать давать ответы на вопросы в течение 1 минуты. Как вы думаете, повысит это удовлетворенность пользователей? У нас есть предположение, что повысит, поэтому записываем этот «impact». Тоже самое делаем для остальных ролей:



Несколько рекомендаций:
  1. Необязательно, но желательно, чтобы воздействия тоже были измеримимыми. Мы написали не просто Отвечать на форуме, а Отвечать на форуме в течение 1 минуты.
  2. Не записывайте все возможные воздействия каждой роли. Нам нужны только те активности, которые приводят к достижению цели.


What?


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



Несколько замечаний и рекомендаций:
  1. В конечных узлах карты можно написать User Story или названия модулей/подсистем.
  2. Эту часть карты можно подбробно не расписывать, можно даже вообще не заполнять, а только проговорить её основные моменты. Полный список всех User Story вы успеете создать на Story Mappging'е.
  3. Здесь не обязательно описывать IT-задачи. Вместо этого можно написать какие-то организационные преобразования и вообще любые действия для реализации воздействия на цель.
  4. Понимание целей даёт нам возможность создавать более дешёвые и быстрые решения по достижению этих целей. За счёт карты мы начинаем использовать не только руки разработчиков, но и голову — каждый член команды может принимать обоснованные решения.


Результаты создания Impact Mapping



Вот и готов наш Impact Mapping. Осталось приоритизировать каждую колонку. Не все цели одинаково важны, тоже самое можно сказать про остальные узлы карты. Есть разные способы приоритизировать. Т.к. мы идем по пути простоты и визуализации, то я могу рекомендовать ставить звездочки. Каждому участнику даете по 5 звезд и он может ставить их куда хочет. Таким образом, можно выявить самые приоритетные узлы.

Результат работы нужно повесить у всех на виду. Если команда распределенная, то надо выложить Impact Mapping в общую базу знаний или повесить перед экраном, который видят все участники разработки. Главная цель — обеспечить видимость и достижимость этой информации, ведь мы опираемся на неё при работе над проектом.

Когда я рассказывал про Impact Mapping на AgileClub, коллеги заметили, что есть и другие способы понять стратегические цели. Например, можно использовать Lean Canvas или собрать требования в проектной документации с описанием целей и заинтересованных сторон. На самом деле Impact Mapping не противоречит другим подходам и может использовать вместе с ними. Лично мне он больше нравится, потому что:
  • Это простая техника, которая способствует общению и взаимодействию, в ней нет бюрократии.
  • Заказчикам, которые не разбираются в IT и производстве ПО, такой подход очень просто объяснить, хватает пары минут.
  • Визуализация в виде mind map



Фильтр входящих задач




Даже когда все согласились с целями проекта и способами их достижения, заказчик может добавить в проект фичу, которая ему очень нравится — pet feature. Мы можем отфильтровать её через цели, показать что эта фича никаким образом не приведет нас к достижению целей.

Аналогично мы будем фильтровать идеи по архитектуре и дизайну системы, которые исходят от команды разработки. Ведёт ли переделка архитектуры к более быстром и дешевому достижению цели? Если нет, то зачем нам это делать?

Модернизация Kanban-доски

Какая колонка идет последней на вашей Kanban-доске? Могу поспорить, что это Release, Deploy, Done или что-то в этом духе. Последней колонкой на доске должна стать — проверка достижения цели. Недостаточно просто залить фичу на сервер, нам нужно проверить достигли мы цели, как предполагали или нет.

FAQ


  • Как продать создание Impact Mapping заказчику перед началом проекта?
    Лучше всего идти от проблемы. Попросите заказчика вспомнить случаи, когда было сделано много фич, а бизнес от этого только пострадал. Почему так произошло? Может надо явно описать цели?
  • Должна ли эта работа оплачиваться?
    Да, обязательно. Составление Impact Mapping может занять несколько дней и несёт ценность бизнесу, не рекомендую делать это бесплатно.
  • Что если заказчик не хочет этого делать?
    Вы, как профессионал, должны предоставить заказчику прогноз на будущее. Расскажите про возможные проблемы, опишите риски и их опасность. После этого дайте клиенту выбрать. Если вы донесли возможное проблемное будущее и клиент принял его, отказался от Impact Mapping'а при полной ясности последствий, то теперь это не ваша проблема, просто делайте ему фич.


Impact Mapping является одной из активностей, которые сделают и заказчиков и разработчиков более счастливыми и эффективными. Ставьте правильные цели правильно!




Ссылки:

How to get the most out of impact mapping, Gojko Adzic

How I Learned to Stop Worrying and Love Flexible Scope, Gojko Adzic

Impact Mapping — как dev-команде перестать делать то, что требуют, и начать делать то, что нужно?, Дмитрий Петрашев
Метки:
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 12
  • +1
    Александр, а работает ли Impact Mapping для работы с уделенными заказчиками?
    • +1
      Добрый день! Я писал в статье, что сам так никогда не делал. Всё-таки важный этап проекта и можно постараться увидеться. Но если лично провести Impact Mapping никак не получается, то есть gojko.net/2014/06/04/six-ways-to-make-impact-maps-more-effective или realtimeboard.com/ru.

      Проблемы могут быть типичные для не-живого общения. Снизить риски неудачного маппинга можно, если вы лично знаете заказчика, делали с ним несколько проектов и хорошо понимаете как устроена динамика общения онлайн.
      • +1
        qwertmax, я много работал с удаленными заказчиками.
        Обычно первичный Impact Mapping делается во время первой встречи по проекту — тут, конечно, желательно личное общение для ускорения процесса. Доска, маркеры и стикеры — это наше все :-)

        Когда разьезжаемся по своим локациям, тогда и нужны инструменты для дальнейшего общения и доработки карты. Тут мне помогают такие инструменты:
        1. Онлайн MindMap
        впринципе, любой инструмент, где можно создавать, хранить и шарить карту между несколькими участниками.
        Из бесплатных могу посоветовать http://mindmup.com, а из платных однозначно http://mindmeister.com

        2. Специализированный инструмент под Impact Mapping
        Если все-таки хочется полностью работать с Impact Mapping на всех уровнях, от формирования идеи, до детального бэклога продукта, то тут я нашел интересный инструмент Effect Cup (http://effectcup.com/).
        По сути он берет на себя функцию Wizard и задает вопросы при записей формировании каждого уровня, а потом визуализирует все, как теже интеллект-карты. А еще плюс к этому выдает бэклог, который можно даже привязать к JIRA или другим тулам ведения проекта разработки.

        Ну а дальше все просто: договариваемся о регулярных сессиях с ключевыми людьми, нужными для разработки карты эффектов (Impact Map) и созваниваемся через Skype, где через join.me я показываю свой экран. Все могут видеть, как я записываю договоренности и идеи, плюс потом отследить в своем экране инструмента из списка выше.

        Так и сокращаем расстояния ;-)
        • 0
          огромное спасибо за столь развернутый ответ и кучу полезняшек!
    • 0
      Напоминает методологию Tropos, там, правда, все идет от Участников, Целей и Зависимостей, а схемы более продвинутые, i* и UML
      • 0
        Вы на практике ее использовали? Можете рассказать про отличия, преимущества, недостатки в сравнении? Мне интересно, потому что Tropos на практике не применял.
        • 0
          Нет. Отличие в том, что вышеприведенные схемы работают на этапе инициации, если говорить о стандартном PMBOK/ISO21500, а Tropos покрывает и планирование. Сходство в том, что и в том, и в другом случае идет привязка к агентам. Однако, кроме идеологии, моделировать нужно не только идею проекта, но и реализации, и архитектуру. А после всего — еще и выдавать определенные выходные документы. Что-то мне подсказывает, что вышеприведенное будет трудно утверждать у заказчика, если, конечно, не сам заказчик это рисует для себя.
          • 0
            Мне еще не приходилось «утверждать» результаты Impact Mapping у заказчика. Дело в том, что эта карта должна оставаться очень гибкой к любым изменениям, чтобы быть адекватной текущему понимаю проекта. Если мы фиксируем карту в ТЗ или чем-то подобном, то с вероятностью 100% придется всё пересогласовывать.
      • 0
        Вы на практике ее использовали? Можете рассказать про отличия, преимущества, недостатки в сравнении? Мне интересно, потому что Tropos на практике не применял.
        • +2
          AlexanderByndyu, спасибо за отличный обзор техники (подхода?)!
          Он действительно выглядит просто и его сила именно в практическом применении. Пока всеобщую популярность еще не завоевал, к сожалению.

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

          Есть другие техники, например, Story Mapping, которые покрывают меньшие объемы информации, с другой стороны проще во внедрении на среднем и нижних уровнях организации (PO+Team).

          Если интересно дальше разбираться и делиться опытом про Impact Mapping, то Гойко Аджич меня когда-то позвал в тематическую Гугл Группу по Impact Mapping.

          Буду ждать еще статей про ваш опыт применения разных Agile техник. В опыте вся сила :-)
          • 0
            Спасибо за ссылку, буду следить за новыми сообщениями в группе.
          • 0
            Правильно ли я понял, что на первом уровне может быть несколько целей?

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.