Гойко Аджич - Impact mapping - Как повысить эффективность программных продуктов и проектов по их разработке

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

Если нет четкого понимания бизнес-контекста, мы не можем быть уверены, что работаем действительно над самыми значимыми аспектами проекта.

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

Помимо прочего, в крупных организациях impact maps помогают довести общую картину до многочисленных заинтересованных лиц, которым нужно координировать свои решения. Это способствует синхронизации их приоритетов и позволяет находить компромиссы в тех случаях, когда их ожидания не могут быть одновременно удовлетворены в полном объеме.

Джон Макманус и Тревор Вуд-Харпер, в течение семи лет исследовавшие деятельность коммерческих IT-компаний в странах Евросоюза, составили следующий список пяти основных причин, почему IT-проекты терпят неудачу:

• Общие причины, связанные с состоянием бизнеса.

• Бизнес-стратегия потеряла актуальность.

• За время разработки программного продукта в компании изменились бизнес-процессы.

• Неудовлетворительное управление требованиями.

• Потенциальные преимущества от разработки продукта не были четко обговорены или были завышены.

Очевидно, что многие из существующих методов управления проектами и качество коммуникации относительно требований к готовому программному обеспечению не в состоянии в полном объеме обеспечить достижение необходимых бизнес-результатов. Эта проблема характерна не только для IT-индустрии. Как показали исследования поведения командующих офицеров и командиров танковых взводов армии США, если сообщать личному составу только ответы на вопросы «что» и «как», невозможно должным образом подготовить его адекватно реагировать на непредвиденные проблемы. Однако именно этим грешат многие модели, использующиеся в настоящее время для управления требованиями. В быстро меняющихся ландшафтах (таких как разработка программных продуктов) гораздо важнее дать участникам ответы на вопросы «зачем» и «чего следует опасаться».

Именно к этому и стремятся различные методики управления требованиями на основе целей. Цель таких методик – переориентировать руководство проектами с разработки заранее известного списка конкретного функционала на поддержку бизнес-задач и желаемые изменения в поведении пользователей. Конечно, эти идеи вовсе не новы, но все же наибольшую популярность они обрели в начале 2000-х годов, побудив, в частности, интерес к этой проблематике в академических кругах – особенно если говорить о модели I* [6]. Но на мой взгляд, эта модель слишком сложна и по этой причине вряд ли получит широкое распространение.

Чтобы предотвратить расползание границ проекта во время разработки программы Excel для компании Microsoft, Скотт Беркун использовал простой мэппинг между целями, функциями и требованиями. Он убедил заинтересованные стороны сократить количество бизнес-целей, поставленных в рамках одного релиза. Затем он обозначил границы проекта, настаивая на том, чтобы каждая функция была увязана с соответствующим требованием, а каждое требование – с целью, которую оно поддерживает. Беркун позднее писал, что такой мэппинг позволил командам разработчиков принимать эффективные решения следующих типов: какие элементы функциональности следует добавить или исключить; как переопределять приоритеты при изменении бизнес-целей; какие именно элементы функциональности являются критически важными для достижения успеха.