«Любимчики» или ненужная функциональность
Impact maps позволяют быстро идентифицировать функциональные возможности, на включении которых, возможно, настаивают те или иные заинтересованные лица, кому по каким-то субъективным причинам эта функциональность просто нравится. На деле она может не поддерживать ни одну из заявленных целей. На impact map ее просто некуда поместить. Это помогает либо вообще отказаться от ее введения, либо как минимум не откладывать решение вопроса о ее необходимости.
Неверные исходные предположения
Очень важно с самого начала заявить очевидным образом исходные предположения. В противном случае, когда в ходе разработки ситуация на рынке аналогичных продуктов серьезно поменяется, будет невозможно понять, какие из решений, которые предполагалось воплотить в данном продукте, уже утратили актуальность. Impact maps требуют изначально четко формулировать все исходные гипотезы, что позволяет этим гипотезам оставаться на виду и дает разработчикам возможность регулярно контролировать их важность.
Возможность избежать случайных приоритетов
Если нет четкого понимания бизнес-контекста, мы не можем быть уверены, что работаем действительно над самыми значимыми аспектами проекта.
Impact maps увязывают вводимый в продукт функционал с желаемыми изменениями в поведении пользователей, и это позволяет заинтересованным сторонам лучше понять те выигрыши, которые они получат в результате. Это повышает их способность верно расставлять приоритеты. Мы получаем возможность принимать решения, исходя из четкого понимания, какими влияниями или удовлетворением запросов каких действующих лиц нам следует заняться в первую очередь. В итоге значительно сокращается время выхода продукта на рынок.
Помимо прочего, в крупных организациях impact maps помогают довести общую картину до многочисленных заинтересованных лиц, которым нужно координировать свои решения. Это способствует синхронизации их приоритетов и позволяет находить компромиссы в тех случаях, когда их ожидания не могут быть одновременно удовлетворены в полном объеме.
Решение бизнес-задач, а не функционал как таковой
Джон Макманус и Тревор Вуд-Харпер, в течение семи лет исследовавшие деятельность коммерческих IT-компаний в странах Евросоюза, составили следующий список пяти основных причин, почему IT-проекты терпят неудачу:
• Общие причины, связанные с состоянием бизнеса.
• Бизнес-стратегия потеряла актуальность.
• За время разработки программного продукта в компании изменились бизнес-процессы.
• Неудовлетворительное управление требованиями.
• Потенциальные преимущества от разработки продукта не были четко обговорены или были завышены.
Очевидно, что многие из существующих методов управления проектами и качество коммуникации относительно требований к готовому программному обеспечению не в состоянии в полном объеме обеспечить достижение необходимых бизнес-результатов. Эта проблема характерна не только для IT-индустрии. Как показали исследования поведения командующих офицеров и командиров танковых взводов армии США, если сообщать личному составу только ответы на вопросы «что» и «как», невозможно должным образом подготовить его адекватно реагировать на непредвиденные проблемы. Однако именно этим грешат многие модели, использующиеся в настоящее время для управления требованиями. В быстро меняющихся ландшафтах (таких как разработка программных продуктов) гораздо важнее дать участникам ответы на вопросы «зачем» и «чего следует опасаться».