How?
На втором уровне нужно описать действия заинтересованных сторон для достижения целей. Мы ищем ответ на вопросы: Как они помогут бизнесу достичь целей? Как они могут помешать успеху продукта?
What?
После ответа на основные вопросы можно обсудить конкретные задачи. Третий уровень отвечает на вопросы: Что мы можем сделать как организация или команда разработки, чтобы стимулировать действия? Здесь будет описано что-то вроде технического задания.
Организация процесса
Приглашайте не больше 1015 человек на это мероприятие, иначе будет сложно проводить. Оптимально позвать по три-четыре человека со стороны бизнеса и со стороны команды продукта.
Со стороны бизнеса обязательно присутствие тех, кто принимает решения, а не только технических специалистов со сложившимся мнением насчёт конкретных реализаций поставленных целей.
Подготовьте карту и доску (или стену) заранее. Impact Mapping для решения задачи длительностью в шесть-восемь месяцев умещается на доске стандартного размера.
Составление карты займёт от одного часа до двух дней. Сроки сильно зависят от состава участников и ваших навыков проведения.
Каждый блок карты можно рисовать маркером или делать стикерами. Я предпочитаю стикеры, они более мобильны, а Impact Map будет часто меняться по ходу погружения в продукт.
Перед началом обязательно проговорите правила и цели составления карты. Если есть время, то разошлите всем материал по теме.
Если есть возможность и обстоятельства позволяют, то сделайте несколько упражнений на знакомство друг с другом, потому что техника подразумевает открытое общение.
И самое главное процесс должен проходить легко и весело. Не добавляйте в него бюрократии!
Пример из практики
Разберём пример, очень приближенный к реальному проекту, для которого мы сделали Impact Mapping. Остановимся на ключевых моментах при составлении Impact Mapping и фатальных ошибках.
Why?
Корневым элементом нашей карты будет список бизнес-целей. Например, это может быть увеличение удовлетворённости пользователей в два раза. Важно, что удовлетворённость пользователей это индекс, то есть конкретная цифра, которую можно взять из CRM, а не мнение/ощущение заказчика. Мы же хотим после поставки фич измерить достижение цели и понять, в том направлении мы идём или нет. Если бы удовлетворённость пользователей была не цифрой, то как бы мы узнали, что достигли цели? Важно, что мы написали именно в два раза, а не просто увеличение. Хорошие цели должны быть SMART[16] (рис. 6).
Рис. 6. Измеримая цель в Impact Map
Во время обсуждения головы кипят, потому что приходится много анализировать и рефлексировать. Первые пара часов работы довольно сложны, но на старте закладывается правильный импульс для составления остальной карты и создаётся атмосфера доверия среди участников. Что я могу посоветовать, исходя из своей практики[17]:
1. Не торопитесь предлагать решения на этом этапе. Выслушайте заказчика, по-настоящему выслушайте. В ходе обсуждения вы успеете всё скорректировать и причесать, а пока запишите то, что есть у него в голове.
2. Самая распространённая проблема заключается в навязывании решений (этап What?) до того, как цели стали понятны. Инженерная мысль летит со скоростью света заказчик только открыл рот, только начал говорить о своих целях, а мы уже создали в голове БД со всеми таблицами, придумали архитектуру и накидали куски кода. Зачем слушать дальше, если мы и так всё придумали? Будет ошибкой начать перебивать заказчика и предлагать решения. Запомните анекдот на тему: «Дима сказал Привет, а Даша мысленно сыграла свадьбу и родила троих детей».
3. Не переубеждайте заказчика на этом этапе. В самом начале вы не знаете его бизнес во всех тонкостях. Заказчики могут вам доверять как профессионалам в IT, и из-за этого быстро соглашаться с вашими предложениями. Вы сами не заметите, как на доске окажутся только те цели, которые вы навязали, а не те, с которыми заказчик жил всё это время.
4. Даже если цель трудноизмерима, то постарайтесь придумать критерий её достижения. Мысленно перенеситесь на финал проекта и подумайте, как вы узнаете, достигнута цель или нет.