В современных гибких методологиях стандартом при управлении проектами де-факто являются пользовательские истории. Они нужны, чтобы определить границы проекта (не привлекая чрезмерные усилия к предпроектному анализу) и обеспечить гарантии, что на каждом этапе проекта будет создана очевидная бизнес-ценность.

У многих организаций не получается воспользоваться всеми преимуществами пользовательских историй, поскольку изначально их создают слишком много, пытаясь охватить весь проект и ничего не упустить. Да, при таком подходе необходимость в тяжеловесном предпроектном анализе снижается, но мы все равно остаемся со слишком масштабным списком пользовательских историй. Всеми этими историями необходимо управлять, что приводит к пустой трате времени. Хуже того, если в бизнесе заказчика что-то изменилось и требуется масса усилий, чтобы заново расставить приоритеты или даже вообще разобраться в этих перечнях. Джим Шор называет подобную ситуацию «ад пользовательских историй».

Impact maps позволяют избежать этих проблем. Причина, почему организации попадают в подобные ситуации, – им трудно отказаться от своей привычки к долгосрочному планированию. Заинтересованные лица, опасаясь, что их потребности будут по каким-либо причинам забыты и не удовлетворены, настаивают на том, чтобы эти потребности были каким-то образом зафиксированы. Вместо того, чтобы писать сотни пользовательских историй низкого уровня, impact maps позволяют отобразить потребности как желательные изменения в поведении действующих лиц. Возникает возможность с самого начала проекта ограничиться обсуждением только наиболее важных влияний на наиболее важных действующих лиц. Когда мы приступим к работе над тем или иным значимым воздействием, мы сможем дополнительно уточнить границы проекта. Вместо того чтобы работать с сотней пользовательских историй одновременно, мы занимаемся картой и лишь десятком историй.

На карте исходные бизнес-гипотезы и влияний показаны в виде иерархии, поэтому расставлять приоритеты, касающиеся целых направлений разработки, легко. Если ситуация на рынке изменилась и одна из наших исходных гипотез утратила силу, то для нас не составит никакого труда понять, какие из предусмотренных элементов функционала больше не нужны и работу над которыми следует прекратить.

Еще одна распространенная проблема с пользовательскими историями, особенно если их много, – они создаются лишь для того, чтобы описать технические характеристики будущего решения. Самый популярный формат, в котором представляются пользовательские истории, – перечисление ожидаемых преимуществ для данного бизнеса и групп пользователей, которые извлекут выгоду из конкретной истории, а также на достаточно высоком уровне обозначение границ проекта. Смысл такого формата – гарантировать, что мы точно понимаем, почему каждая история имеет важное значение, и тем самым повысить эффективность планирования.

Часто бывает, что заказчику в силу личных предпочтений просто очень нравится какой-либо функционал и он предпринимает попытку продвинуть необходимость его реализации, замаскировав свое пожелание под пользовательскую историю. Обычно такие истории сформулированы весьма расплывчато, в них может отсутствовать указание на бизнес-ценность, или же они содержат очевидные логические ошибки («порочный круг»). Классическими примерами являются тексты вроде «Я трейдер, и мне необходимо торговать, поскольку я являюсь трейдером» или «Мне нужно, чтобы из системы можно было распечатать отчет по отдельно взятому клиенту».

Impact maps помогают сохранить пользовательские истории честными – поскольку каждая история должна занять свое логичное место на карте. Но, чтобы мы смогли найти для нее это место, в ней должно быть указано соответствующее заинтересованное лицо и желательное влияние. Это заставляет участников проекта более тщательно продумывать пользовательские истории и точнее их формулировать. Если для пользовательской истории на карте не находится подходящего положения, то, по всей вероятности, ее следует исключить из текущего цикла разработки.