Impact Mapping на практике
Когда читал книгу 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? После ответа на основные вопросы можно обсудить конкретные задачи. Третий уровень отвечает на вопросы: Что мы можем сделать как организация или команда разработки, чтобы создать необходимые воздействия? Здесь будет описан конечный результат нашей работы.
Организация процесса Приглашайте не больше 10–15 человек на это мероприятие, иначе будет сложно проводить. Оптимально позвать 3–4 человека со стороны заказчика и столько же со стороны команды. Со стороны заказчика обязательно взять представителей бизнеса, а не только технических специалистов, у которых уже сложилось мнение по поводу конкретных реализаций всех целей. Карту будете строить на доске или стене, подготовьте их заранее. Impact Mapping для задачи длительностью в 6–8 месяцев умещается на доске стандартного размера.Онлайн вариант этой техники я ещё не пробовал, но думаю подойдет любой интерактивный инструмент. Коммуникация будет не та, но вас может спасти, если вы лично знаете заказчика или являетесь отличным фасилитатором/модератором. Составление карты займёт от одного часа до двух дней. Эта цифра сильно зависит от состава участников и ваших навыков проведения. Каждый блок карты можно рисовать маркером или делать стикерами. Я предпочитаю стикеры, потому что они более мобильны, а impact map будет часто сортироваться и меняться по ходу погружения в проект. Перед началом обязательно проговорите правила и цели составления карты. Если есть время, то разошлите всем материал по теме для подготовки Если есть возможность и обстоятельства позволяют, то сделайте несколько Icebreaker’ов. И самое главное — сам процесс должен проходить легко и весело. Не добавляйте в него бюрократии! Пример из практики Разберём пример, очень приближенный реальному проекту, для которого в начале мы сделали Impact Mapping. Остановимся на ключевых моментах при составлении Impact Mapping и на ошибках, которые могу погубить всю идею.
Why? Корневым элементом нашей карты будет список бизнес-целей. Например, это может быть увеличение удовлетворенности пользователей в 2 раза. Важно, что удовлетворенность пользователей — это индекс, т.е. конкретная цифра, которую можно взять из CRM, а не мнение/ощущение заказчика. Мы же хотим после поставки фич измерить достижение цели и понять, в том направлении мы идём или нет. Если бы удовлетворенность пользователей была не цифрой, то как бы мы узнали, что достигли цели? Ещё важно, что мы написали именно в 2 раза, а не просто увеличение. Хорошие цели должны быть SMART:
Первый этап довольно сложный, он должен дать импульс для составления остальной карты и создать доверие между участниками. Что я могу посоветовать, исходя из своей практики:
Не торопитесь предлагать решения на этом этапе. Выслушайте заказчика, по-настоящему выслушайте. В ходе дальнейшего обсуждения вы успеете всё откорректировать и причесать, а пока запишите то, что есть у него в голове. Самая распространенная проблема заключается в навязывании решений (этап What?) до того, как цели стали понятны. Инженерная мысль летит со скорость света — заказчик только открыл рот, только начал говорить о своих целях, а мы уже создали в голове БД со всеми таблицами, придумали архитектуру и накидали куски кода. Зачем слушать дальше, если мы и так всё придумали? Будет ошибкой начать перебивать заказчика и предлагать решения. Запомните анекдот на эту тему и постарайтесь избежать проблемы: «Дима сказал «Привет», а Даша мысленно сыграла свадьбу и родила троих детей». Не переубеждайте заказчизка на этом этапе. В самом начале вы не знаете его бизнес во всех тонкостях. Заказчики могут вам доверять, как профессионалам в IT, и из-за этого быстро соглашаться на ваши корректировки. Вы сами не заметите как на доске окажутся только те цели, которые вы навязали, а не те, с которыми заказчик жил всё это время. Даже если цель трудноизмерима, то постарайтесь придумать критерий её достижения. Мысленно перенеситесь на финал проекта и подумайте, как вы узнаете достигнута цель или нет? Процесс выработки целей итерационный, не обязательно выжамать из заказчика все цели на первом круге. Не надо вытягивать искусственные цели. Бывают проекты, которые просто есть, потому что инвесторам хочется поиграть в создателей ПО. С этим нужно смириться и свернуть работу по составлению Impact Mapping. На HappyDev 2014 я проводил мастер-класс по составлению Impact Mapping и Story Mapping. Играть роль заказчика согласился руководитель проекта по обработке заявок на строительство. Все, кто пришел на тренинг, были очень активными и сразу втянулись в процесс. Со временем мы осознали, что довольно сложно просто слушать заказчика и понять его проблему. Коллеги наперебой предлагали свои решения. В какой-то момент приходилось прерывать работу группы, напоминать, что мы должны больше слушать. Несколько раз из-за напряженной атмосферы и давления участников, заказчик принимал наши решения, откзываясь от своих. Я думаю, что все участники почувствовали важный баланс между тем, когда надо слушать заказчика, а когда надо предлагать решения.
Who? На этом этапе мы должны выявить всех, кто поможет оказать влияние на цель, кто поспособствует её достижению или помешает. В нашем примере это будут Отдел маркетинга и Модератор форума. По мнению заказчика именно они могут изменить удовлетворенность пользователей:
Здесь мы можем указывать конкретных людей, названия отделов, сегменты рынка и т.д. Выбирайте любой уровень абстракции, лишь бы он был адекватен вашему проекту.
How? Теперь нам надо определить те воздействия, которые будут сделаны для достижения цели. Например, модератор форума может попробовать давать ответы на вопросы в течение 1 минуты. Как вы думаете, повысит это удовлетворенность пользователей? У нас есть предположение, что повысит, поэтому записываем этот «impact». Тоже самое делаем для остальных ролей:
Несколько рекомендаций:
Необязательно, но желательно, чтобы воздействия тоже были измеримимыми. Мы написали не просто Отвечать на форуме, а Отвечать на форуме в течение 1 минуты. Не записывайте все возможные воздействия каждой роли. Нам нужны только те активности, которые приводят к достижению цели. What? Мы дошли до самого несущественного в Impact Mapping. В последнем узле нашей карты находится та самая корзина с покупками, с которой обычно начинается работа над проектом. Разница в том, что теперь мы понимаем ценность каждой фичи, почему эта фича здесь и к чему приведет её реализация:
Несколько замечаний и рекомендаций:
В конечных узлах карты можно написать User Story или названия модулей/подсистем. Эту часть карты можно подбробно не расписывать, можно даже вообще не заполнять, а только проговорить её основные моменты. Полный список всех User Story вы успеете создать на Story Mappging’е. Здесь не обязательно описывать IT-задачи. Вместо этого можно написать какие-то организационные преобразования и вообще любые действия для реализации воздействия на цель. Понимание целей даёт нам возможность создавать более дешёвые и быстрые решения по достижению этих целей. За счёт карты мы начинаем использовать не только руки разработчиков, но и голову — каждый член команды может принимать обоснованные решения. Результаты создания 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-команде перестать делать то, что требуют, и начать делать то, что нужно?, Дмитрий Петрашев
