Определение границ — структура, а не смирительная рубашка. Бизнес-требования и понимание того, как клиенты будут использовать продукт, ценны при работе с границами проекта.
В изменении объема как такового нет ничего плохого, если это помогает вам направить проект в сторону удовлетворения растущих потребностей клиентов. Документ о концепции и границах позволяет оценить, действительно ли предложенные функции и требования стоит включать в проект. Можно менять границы будущей итерации или целого проекта, если это делается осознанно, «правильными» людьми, по правильными бизнес-основаниям и с пониманием и принятием всех последствий.
Помните, каждый раз, когда кто-то выдвигает новое требование, аналитик должен спросить: «Попадает ли оно в рамки проекта?»
Один из возможных ответов: требование явно выходит за границы проекта. Оно может быть интересным, но его следует переадресовать будущим версиям или другому проекту.
Другой ответ: требование попадает в границы проекта. Вы можете включить такие требования в проект, если они обладают высоким приоритетом по сравнению с теми требованиями, которые уже описаны в проекте. При этом зачастую приходится решать, отложить или отклонить другие запланированные требования, если только вы не готовы расширить временные рамки проекта.
Третий вариант ответа: предложенное новое требование выходит за рамки проекта, но идея так хороша, что следует изменить границы проекта, чтобы требование попало в него с соответствующими коррективами бюджета, графика и ресурсов. То есть существует обратная связь между пользовательскими требованиями и бизнес-требованиями. При этом вам придется обновить документ о концепции и границах, изменения в котором должны отслеживаться в системе управления версиями с момента создания его базовой версии. Отслеживайте, почему отвергаются требования, потому что они имеют свойство возникать вновь.
Бизнес-цели — самый важный фактор, который нужно учитывать, принимая решения о границах проекта. Определите, какие из предложенных функций или пользовательских требований приносят самую большую выгоду с точки зрения бизнес-целей и запланируйте их на самые первые выпуски.
Когда заинтересованное лицо просит добавить функциональность, определите, как это изменение соотносится с бизнес-целями. Например, бизнес-цель, предусматривающая получение максимального дохода от интерактивного терминала, подразумевает раннюю реализацию функций, которые способствуют продаже большего объема товаров и услуг клиентам. Не стоит назначать высокий приоритет броским функциям, которые интересуют только любителей новых технологий и ничего не привносят в достижение бизнес-цели.
Если возможно, оцените количественно вклад функции в достижение бизнес-цели, чтобы решения о границах принимались на основе фактов, а не эмоций. Какой будет вклад новой функции — тысяча, сто тысяч или миллион? Когда топ-менеджер просит добавить новую функцию, которую придумал за выходные, нужно применить численный анализ, чтобы определить, правильно ли бизнес-решение добавить ее в продукт.
При увеличении границ проекта менеджеру обычно приходится повторно согласовывать запланированный бюджет, ресурсы, график и/или персонал. В идеале, исходный график и ресурсы рассчитаны на возможность определенных изменений благодаря наличию предусмотрительно запланированных резервов на случай непредвиденностей. В противном случае после одобрения изменений потребуется повторно выполнить планирование.
Обычный результат изменения границ заключается в том, что завершенные действия приходится переделывать. Если при добавлении новой функциональности не увеличиваются выделенные на проект время или ресурсы, часто страдает качество. Задокументированные бизнес-требования облегчают управление изменениями границ проекта при изменении рыночных условий или бизнес-потребностей. Они также облегчают задачу утомленному менеджеру проекта, когда ему нужно сказать «нет» или, по крайней мере, «не сейчас» влиятельным людям, старающимся впихнуть побольше функций в и так напряженный проект.
Для управления границами проектом гибкой разработки (agile), в котором разработка ведется сериями коротких итераций, нужно применять другой подход. Границы каждой итерации состоят их пользовательских историй, выбранных из динамического резерва (backlog) на основе их относительных приоритетов и расчетной производительности команды в каждой итерации.
Вместо того чтобы бороться с распуханием границ, в команде определяют приоритеты новых требований на основе существующих элементов резерва проекта и назначают их на будущие итерации.
Число итераций, а значит, и общая продолжительность проекта, все равно определяется общим объемом функциональности, которую нужно реализовать, но границы каждой итерации жестко контролируются, чтобы гарантировать ее своевременное завершение. С другой стороны, в некоторых проектах гибкой разработки фиксируется общая продолжительность проекта, а меняются границы. Число итераций может оставаться фиксированным, но рамки остающихся итераций изменяются в соответствии с относительными приоритетами существующих или новых пользовательских историй.
Команда может определить высокоуровневую дорожную карту итераций вначале проекта, но распределение пользовательских историй по итерациям может выполняться вначале каждой итерации. Обращение к бизнес требованиям при определении границ каждой последующей итерации помогает гарантировать, что будет поставлен продукт, отвечающий бизнес-целям. Подобная стратегия может применяться в любом проекте, состоящем из итераций (см. врезку «Управление объемом и разработка по итерациям»).
Энрике, менеджер проекта в Lightspeed Financial Systems, занимался выпуском интернет-версии ведущего программного продукта Lightspeed для управления портфелем ценных бумаг. Потребовались бы два года для поставки полнофункциональной версии приложения, однако компания должна была дать знать о себе в Интернете уже сейчас. Энрике выбрал прием «разработка по итерациям» и обещал выпускать новую версию каждые 90 дней. Его команда специалистов по маркетингу расставила приоритеты требований к продукту. В спецификацию требований для каждой ежеквартальной версии входил утвержденный набор новых и улучшенных функций, а также список «переходящих» требований низкого приоритета, которые предполагалось реализовать, если позволяло время. Команда Энрике не включала каждое такое требование в каждую версию, но они поставляли новую, стабильную версию каждые три месяца с помощью подхода, который учитывал график и управление границами итерации. График и качество — это естественные ограничения проекта «разработка по графику», а границы итерации представляли собой степень свободы.
Хотя в проектах гибкой разработки обычно и не создается формальный документ концепции и границ, содержимое шаблона на рис. 5-3 и относимо, и обязательно для поставки успешного продукта. Во многих проектах гибкой разработки выполняется начальная (нулевая) итерация планирования для определения общей концепции продукта и других требований проекта.
Бизнес-требования должны определяться во всех проектах разработки ПО независимо от модели разработки. Бизнес-цели описывают ожидаемую выгоду от проекта, а в проекте гибкой разработки они используются для облегчения определения приоритетов резерва (backlog), чтобы добиться максимальной ценности для бизнеса в самых ранних итерациях. Критерии успеха надо определить так, чтобы после развертывания можно было измерить успех и соответствующим образом скорректировать резерв проекта. Положение о концепции содержит долгосрочный план — то, чем должен стать продукт по завершении всех итераций.
Как узнать, когда можно завершить реализацию функциональности? Обычно управлением проектом и точкой его завершения занимается менеджер. Но бизнес-аналитик близко знаком с бизнес-целями и может помочь определить, когда она достигнута.
Если работа над проектом начинается с четкой концепции и если границы каждого выпуска или итерации включают лишь часть общей функциональности, тогда работу можно считать выполненной по завершении запланированных итераций. В результате завершения всех итераций должен получиться полностью реализованный продукт, удовлетворяющий бизнес-целям.
Однако именно в проектах с итеративной разработкой финальная точка может быть неопределенной. Для каждой итерации определяются ее границы. По мере продвижения проекта резерв незавершенной работы сокращается. Не всегда необходимо реализовать полный набор остающейся функциональности. Критически важно иметь четкие бизнес-цели, чтобы можно было двигаться к их удовлетворению поэтапно, по мере получения информации. Проект готов, когда критерии успеха указывают, что у вас хорошие шансы удовлетворить бизнес-цели. Нечеткие бизнес-цели — гарантия свободного проекта, в котором невозможно определить момент завершения. Финансирующим проект заказчикам это не нравится, потому что непонятно, как в таких проектах определить бюджет, график или план. Клиентам это не нравится, потому что они могут получить решение, которое поставляется в рамках бюджета и графика, но не предоставляет нужных им возможностей. Но этот риск присущ работе над продуктами, которые нельзя точно определить с самого начала, если только вы не уточните бизнес-цели в процессе работы над проектом.
Сосредоточьтесь на определении четких бизнес-требований во всех своих проектах, в противном случае вы будете двигаться без цели, надеясь сделать что-то полезное, но без возможности узнать, в правильном ли направлении вы движетесь.
| Способы представления границ проекта | Проверка знаний: Разработка требований |