Важно! На данный момент я уже заменил этот метод на Карту гипотез – метод стратегического планирования. Если вы хотите узнать более углубленный вариант работы со стратегией, то можно пропустить главы об Impact Mapping и прочитать книгу о Карте гипотез.
История появления Impact Mapping
Раньше на старте проекта у нас были технические задания, схемы работы системы и в лучшем случае прототипы интерфейса. В этих документах не хватало понимания динамики развития проекта и приоритетов в работе.
Мы начали писать User Story[12] и делать User Story Mapping. Эти практики добавили понимание логики развития проекта и наших приоритетов, дали возможность плодотворнее общаться с заказчиком. Чего не хватало? Продукты существуют не в вакууме: нужно уметь видеть более глобальные задачи, которые лежат где-то выше историй использования системы. Не хватало простой игровой практики по постановке целей проекта, из которых потом будут появляться User Story Map и список User Story на релиз.
Mijo Balic и Ingrid Ottersten в 2007 году написали статью «Effect Managing IT» (подробнее Agile product management using Effect Maps[13]). Через четыре года Gojko Adzic[14] выпустил книгу «Specification by Example»[15], где в главе «Deriving scope from goals» упоминает о технике под названием Effect mapping. Эта техника призвана помогать командам фокусироваться на бизнес-целях, выявлять заинтересованные стороны и их потребности.
Gojko Adzic со временем добавляет в Effect mapping несколько усовершенствований, таких как: приоритизация целей и воздействий, возможность уходить от технических деталей на уровне What, цикличность в предположениях и экспериментах. На мой взгляд, это действительно важные изменения, они помогают в реальной жизни. После этого техника стала называться по-новому – Impact Mapping.
Руки без головы
Представьте, что вы владелец магазина. К вам приходит заказчик. У него в голове уже есть набор фич на покупку, он знает чего хочет. Он берёт корзину для покупок, складывает в неё список технологий, десяток прототипов интерфейса, интеграцию с соцсетями и т. п. Подходит к кассе и просит всё взвесить, реализовать и выставить ему счёт.
Получается, что заказчик пришёл к вам с готовыми решениями каких-то своих проблем. В такой ситуации заказчик купит только руки разработчика, но не голову. Разработчик не сможет критически оценить предложенные решения. Будет ли успешным проект с подходом, где купили только «руки»? Шанс невысок.
Зато в наших силах увеличить шансы на успех за счёт того, что каждый в команде будет понимать и разделять цели бизнеса. Тогда любое решение – от именования переменной в коде до выбора архитектуры – будет приниматься с учётом реальных потребностей бизнеса.
Остаётся вопрос, как вытащить из бизнеса истинные цели, которых мы хотим достичь? Как сделать так, чтобы команда услышала их, приняла и начала с ними работать?