Требования меняются и расширяются в ходе любого проекта. Это естественный аспект разработки программного обеспечения. Менеджер проекта должен предвидеть и планировать это, например, путем включения буферов в планы на случай непредвиденных обстоятельств при взятии на себя обязательств. Расползание рамок (от англ. "scope creep", также известное как расползание возможностей и расползание требований), однако, относится к неконтролируемому расширению возможностей, которые команда пытается запихнуть в уже переполненный проект. Все это не помещается.
Постоянное изменение и расширение требований затрудняет своевременную реализацию приоритетных функций. Постоянное расширение функциональности приводит к задержкам, проблемам с качеством и нерациональному использованию энергии. Расползание рамок — одна из самых распространенных проблем в разработке программного обеспечения.
Определение рамок
Первым шагом в борьбе с расползанием рамок является документирование четко сформулированных и согласованных рамок проекта. Без определения этих рамок вы не сможете даже понять, что у вас наблюдается расползание рамок. Техники, описанные в моей статье "Определение рамок проекта", содержат несколько методов определения. Agile-проекты должны составлять краткое описание рамок для каждой итерации, чтобы убедиться, что все понимают, что будет и что не будет реализовано в ходе данной итерации. В качестве альтернативы можно дать каждой итерации краткое название, передающее ее цель.
Шаблон документа «Видение и рамки», который я рекомендую, включает раздел «Ограничения и исключения». Здесь вы можете перечислить все возможности или характеристики продукта, которые заинтересованные лица могут ожидать, но которые заведомо не планируются к добавлению в продукт или в конкретный релиз. Можно также перечислить элементы, которые были исключены из рамок проекта, чтобы не забыть о решении по данным рамкам. Подобное перечисление известных ограничений помогает команде быстро принимать решения, если поступает запрос на изменение какой-либо возможности, включенной в список исключений.
Входит ли это в рамки?
Вторым шагом в управлении расползанием рамок является вопрос «Входит ли это в сами рамки?» всякий раз, когда кто-то предлагает какую-то дополнительную возможность продукта, например, вариант использования, пользовательскую историю, функциональное требование, функцию или результат обратите внимание, что рамки проекта могут охватывать деятельность и результаты помимо поставляемых программных продуктов. Возможно, ваши заказчики просят предоставить онлайн учебник, чтобы помочь своим пользователям освоить новую систему. Это не меняет сам программный продукт, но, безусловно, расширяет рамки общей работы по проекту, которую необходимо выполнить.
В одной из ситуаций клиент заключил контракт с поставщиком пакетного решения на перенос трех наборов архивных данных в новый пакет. В ходе выполнения проекта заказчик пришел к выводу, что необходимо выполнить еще шесть преобразований данных. Заказчик посчитал, что эта дополнительная работа входит в согласованный объем; поставщик утверждал, что она не входит в рамки проекта, и потребовал дополнительной оплаты.
Это был один из факторов, который привел к аннулированию проекта, судебному иску и консалтинговой задаче, в ходе которого я помог определить причину неудачи проекта. Более четкое определение рамок объема работ на начальном этапе, а также соглашение о том, как и кем будут покрываться расходы, связанные с изменением рамок проектных работ, могли бы предотвратить этот печальный исход.
Корректировка рамок
Есть три возможных ответа на вопрос «Входит ли это в рамки проекта?». Если новая возможность явно входит в рамки проекта, то команде необходимо заняться этим вопросом. Если она явно выходит за рамки, команде не нужно с ней работать, по крайней мере, сейчас. Они могут запланировать новую функциональность на более поздний релиз или итерацию.
Иногда, однако, запрашиваемая функциональность выходит за рамки проекта в том виде, в котором она определена в настоящее время, но это настолько хорошая идея, что рамки должны быть расширены, чтобы вместить ее. Решение об увеличении рамок проекта — это бизнес-решение. Лица, принимающие ключевые решения, должны учитывать стоимость, риски, график и последствия для рынка. Это требует того, чтобы менеджер проекта, спонсор управления и ключевые клиенты проводили переговоры, чтобы определить, как лучше поступить с изменением рамок проекта. Владелец бизнес-требований — спонсор управления — должен решить, станут ли предлагаемые изменения в пользовательских или функциональных требованиях ответственностью менеджера проекта в результате расширения рамок (рис. 1).
Работа с расползанием рамок
Ниже приведены некоторые возможные стратегии для преодоления неожиданного увеличения требований:
Отложить или исключить некоторые другие, менее приоритетные функциональные возможности, которые были запланированы в текущем релизе.
Нанять дополнительных сотрудников для выполнения дополнительной работы.
Получить дополнительное финансирование, возможно, для оплаты сверхурочных (ладно, это просто шутка), передать часть работы на аутсорсинг или приобрести инструменты, повышающие производительность.
Расширить график выпуска текущего релиза, чтобы учесть дополнительную функциональность (это не шутка).
Идти на компромисс с качеством, делая наспех работу, которую потом придется исправлять (не лучший вариант).
Расширение рамок всегда имеет свою цену. Люди, финансирующие проект, должны принять взвешенное решение о том, какая стратегия управления рамками проекта является наиболее подходящей в каждой конкретной ситуации. Цель всегда состоит в том, чтобы обеспечить максимальную потребительскую ценность, согласованную с достижением определенных бизнес-целей и критериев успеха проекта, в рамках существующих ограничений.
Нет смысла притворяться, что команда проекта может реализовать все большее количество функциональных возможностей, не заплатив за это определенную цену. Кроме того, всегда разумно предвидеть определенный расширение рамок работ в ходе проекта. Опытный руководитель проекта включит в проектные планы буферы на случай непредвиденных обстоятельств, чтобы команда могла в разумных пределах приспособиться к расширению рамок, не нарушая при этом своих обязательств по графику.
Грамотное управление рамками проекта требует соблюдения нескольких условий:
Требования должны быть приоритетными, чтобы лица, принимающие решения, могли выбрать возможности для добавления в следующий релиз или итерацию и могли оценить запросы на изменения с учетом приоритетов требований в текущей базовой структуре. Это цель бэклога в agile-проекте (на самом деле, в любом проекте!).
Размер требований должен быть оценен для того, чтобы команда имела приблизительное представление о том, сколько усилий потребуется для их реализации. Для этого и нужны относительные единицы объема работы.
Команда должна знать свою среднюю производительность (скорость в agile-проекте), чтобы иметь представление о том, сколько требований, измеряемых в единицах размера, она может реализовать и проверить за единицу времени.
Запросы на изменения должны пройти анализ влияния изменений, чтобы команда хорошо понимала, сколько будет стоить реализация каждого из них и каковы будут последствия для проекта.
Необходимо определить лиц, принимающих решения по проекту, и определить процесс принятия ими решений, чтобы они могли эффективно принимать решения об изменении рамок работ в случае необходимости.
Коммуникация — еще один важный элемент для управления scope creep. Вам необходимо обучить заинтересованные стороны, чтобы они понимали важность всех запросов на изменения через определенный (и эффективный!) процесс управления изменениями. Процесс управления изменениями — это не барьер, а скорее ворота, механизм, с помощью которого нужные люди могут принимать правильные решения для внедрения нужных изменений в нужное время. Сообщайте о решениях по утвержденным запросам на изменения всем соответствующим заинтересованным сторонам, чтобы они знали, как развивается проект и как это влияет на них.
Не становитесь жертвой расползания рамок и не пытайтесь тщетно подавить изменения. Вместо этого четко определите рамки на ранней стадии проекта, а затем следуйте практическому процессу контроля изменений, чтобы справиться с неизбежной эволюцией требований. Дополнительные идеи о том, как справиться с этой вездесущей проблемой проекта, см. в статье "Как предотвратить и управлять расползанием рамок проекта".
Изменения случаются: справляйтесь с ними.
Эта статья адаптирована из книги Карла Вигерса "More About Software Requirements".
Перевод материала подготовлен в рамках курса "Системный аналитик. Basic". Если интересно узнать подробнее о формате обучения и программе курса, регистрируйтесь на день открытых дверей онлайн.
