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

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

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

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

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

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

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

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

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

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