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

Мы начали писать 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.