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