Если нет четкого понимания бизнес-контекста, мы не можем быть уверены, что работаем действительно над самыми значимыми аспектами проекта.
Решение бизнес-задач, а не функционал как таковой
Джон Макманус и Тревор Вуд-Харпер, в течение семи лет исследовавшие деятельность коммерческих IT-компаний в странах Евросоюза, составили следующий список пяти основных причин, почему IT-проекты терпят неудачу:
• Общие причины, связанные с состоянием бизнеса.
• Бизнес-стратегия потеряла актуальность.
• За время разработки программного продукта в компании изменились бизнес-процессы.
• Неудовлетворительное управление требованиями.
• Потенциальные преимущества от разработки продукта не были четко обговорены или были завышены.
Очевидно, что многие из существующих методов управления проектами и качество коммуникации относительно требований к готовому программному обеспечению не в состоянии в полном объеме обеспечить достижение необходимых бизнес-результатов. Эта проблема характерна не только для IT-индустрии. Как показали исследования поведения командующих офицеров и командиров танковых взводов армии США, если сообщать личному составу только ответы на вопросы «что» и «как», невозможно должным образом подготовить его адекватно реагировать на непредвиденные проблемы. Однако именно этим грешат многие модели, использующиеся в настоящее время для управления требованиями. В быстро меняющихся ландшафтах (таких как разработка программных продуктов) гораздо важнее дать участникам ответы на вопросы «зачем» и «чего следует опасаться».
Именно к этому и стремятся различные методики управления требованиями на основе целей. Цель таких методик – переориентировать руководство проектами с разработки заранее известного списка конкретного функционала на поддержку бизнес-задач и желаемые изменения в поведении пользователей. Конечно, эти идеи вовсе не новы, но все же наибольшую популярность они обрели в начале 2000-х годов, побудив, в частности, интерес к этой проблематике в академических кругах – особенно если говорить о модели I*[6]. Но на мой взгляд, эта модель слишком сложна и по этой причине вряд ли получит широкое распространение.
Чтобы предотвратить расползание границ проекта во время разработки программы Excel для компании Microsoft, Скотт Беркун использовал простой мэппинг между целями, функциями и требованиями. Он убедил заинтересованные стороны сократить количество бизнес-целей, поставленных в рамках одного релиза. Затем он обозначил границы проекта, настаивая на том, чтобы каждая функция была увязана с соответствующим требованием, а каждое требование – с целью, которую оно поддерживает. Беркун позднее писал, что такой мэппинг позволил командам разработчиков принимать эффективные решения следующих типов: какие элементы функциональности следует добавить или исключить; как переопределять приоритеты при изменении бизнес-целей; какие именно элементы функциональности являются критически важными для достижения успеха.
