Что определяют рамки проекта

Управление «расползанием» границ проекта: почему, когда и как

Требования меняются и расширяются в ходе любого проекта. Это естественный аспект разработки программного обеспечения. Менеджер проекта должен предвидеть и планировать это, например, путем включения буферов в планы на случай непредвиденных обстоятельств при взятии на себя обязательств. Расползание границ (от англ. «scope creep», также известное как расползание возможностей и расползание требований), однако, относится к неконтролируемому расширению возможностей, которые команда пытается запихнуть в уже переполненный проект. Все это не помещается.

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

Определение границ

Первым шагом в борьбе с расползанием границ является документирование четко сформулированных и согласованных границ проекта. Без определения этих границ вы не сможете даже понять, что у вас наблюдается расползание границ. Техники, описанные в моей статье «Определение границ проекта», содержат несколько методов определения. Agile-проекты должны составлять краткое описание границ для каждой итерации, чтобы убедиться, что все понимают, что будет и что не будет реализовано в ходе данной итерации. В качестве альтернативы можно дать каждой итерации краткое название, передающее ее цель.

Шаблон документа «Видение и рамки», который я рекомендую, включает раздел «Ограничения и исключения». Здесь вы можете перечислить все возможности или характеристики продукта, которые заинтересованные лица могут ожидать, но которые заведомо не планируются к добавлению в продукт или в конкретный релиз. Можно также перечислить элементы, которые были исключены из границ проекта, чтобы не забыть о решении по данным рамкам. Подобное перечисление известных ограничений помогает команде быстро принимать решения, если поступает запрос на изменение какой-либо возможности, включенной в список исключений.

Входит ли это в рамки?

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

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

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

Корректировка границ

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

Иногда, однако, запрашиваемая функциональность выходит за рамки проекта в том виде, в котором она определена в настоящее время, но это настолько хорошая идея, что рамки должны быть расширены, чтобы вместить ее. Решение о расширении границ проекта — это бизнес-решение. Лица, принимающие ключевые решения, должны учитывать стоимость, риски, график и последствия для рынка. Это требует того, чтобы менеджер проекта, спонсор управления и ключевые клиенты проводили переговоры, чтобы определить, как лучше поступить с изменением границ проекта. Владелец бизнес-требований — спонсор управления — должен решить, станут ли предлагаемые изменения в пользовательских или функциональных требованиях ответственностью менеджера проекта в результате расширения границ (рис. 1).

Работа с расползанием границ

Ниже приведены некоторые возможные стратегии для преодоления неожиданного увеличения требований:

Отложить или исключить некоторые другие, менее приоритетные функциональные возможности, которые были запланированы в текущем релизе.

Нанять дополнительных сотрудников для выполнения дополнительной работы.

Получить дополнительное финансирование, возможно, для оплаты сверхурочных (ладно, это просто шутка), передать часть работы на аутсорсинг или приобрести инструменты, повышающие производительность.

Расширить график выпуска текущего релиза, чтобы учесть дополнительную функциональность (это не шутка).

Идти на компромисс с качеством, делая наспех работу, которую потом придется исправлять (не лучший вариант).

Расширение границ всегда имеет свою цену. Люди, финансирующие проект, должны принять взвешенное решение о том, какая стратегия управления рамками проекта является наиболее подходящей в каждой конкретной ситуации. Цель всегда состоит в том, чтобы обеспечить максимальную потребительскую ценность, согласованную с достижением определенных бизнес-целей и критериев успеха проекта, в рамках существующих ограничений.

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

Грамотное управление рамками проекта требует соблюдения нескольких условий:

Требования должны быть приоритетными, чтобы лица, принимающие решения, могли выбрать возможности для добавления в следующий релиз или итерацию и могли оценить запросы на изменения с учетом приоритетов требований в текущей базовой структуре. Это цель бэклога в agile-проекте (на самом деле, в любом проекте!).

Размер требований должен быть оценен для того, чтобы команда имела приблизительное представление о том, сколько усилий потребуется для их реализации. Для этого и нужны относительные единицы объема работы.

Команда должна знать свою среднюю производительность (скорость в agile-проекте), чтобы иметь представление о том, сколько требований, измеряемых в единицах размера, она может реализовать и проверить за единицу времени.

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

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

Коммуникация — еще один важный элемент для управления scope creep. Вам необходимо обучить заинтересованные стороны, чтобы они понимали важность всех запросов на изменения через определенный (и эффективный!) процесс управления изменениями. Процесс управления изменениями — это не барьер, а скорее ворота, механизм, с помощью которого нужные люди могут принимать правильные решения для внедрения нужных изменений в нужное время. Сообщайте о решениях по утвержденным запросам на изменения всем соответствующим заинтересованным сторонам, чтобы они знали, как развивается проект и как это влияет на них.

Не становитесь жертвой расползания границ и не пытайтесь тщетно подавить изменения. Вместо этого четко определите рамки на ранней стадии проекта, а затем следуйте практическому процессу контроля изменений, чтобы справиться с неизбежной эволюцией требований. Дополнительные идеи о том, как справиться с этой вездесущей проблемой проекта, см. в статье «Как предотвратить и управлять расползанием границ проекта».

Изменения случаются: справляйтесь с ними.

Перевод материала подготовлен в рамках курса «Системный аналитик. Basic». Если интересно узнать подробнее о формате обучения и программе курса, регистрируйтесь на день открытых дверей онлайн.

Источник

IT1410: Разработка требований к программному обеспечению

Когда химик изобретает новую химическую реакцию, которая преобразует одно вещество в другое, он пишет документ, в который входит раздел «Рамки и ограничения», где описывает, что получится и не получится в результате этой реакции. Точно так же для проекта по разработке ПО следует определить его рамки и ограничения.

Вам необходимо указать, что может делать система, а что не может.

Многие проекты страдают «распуханием границ» — резким ростом из-за активного расширения функциональности продукта. Первый шаг на пути к обузданию распухания границ — определение рамок проекта. Границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не будут включены в продукт. Рамки и ограничения помогают установить реалистичные ожидания заинтересованных лиц, потому что иногда клиенты запрашивают функции, слишком дорогостоящие или выходящие за предполагаемые границы продукта.

Рамки проекта могут представляться различными способами. На самом высоком уровне границы определяются, когда клиент решает, какие бизнес-цели преследовать. На низком уровне границы определяются на уровне функций, пользовательских историй, вариантов использования или событий и реакции на них.

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

Например, находящиеся в границах пользовательские требования должны соответствовать бизнес-целям, а функциональные требования — пользовательским требованиям в заданных границах.

Нереалистичные требования

Однажды менеджер в компании-разработчике, проект которого страдал от практически катастрофического распухания границ, печально сказал: «Мы слишком нереалистично отнеслись к требованиям». Он имел в виду, что все идеи, какие у кого-либо были, включили в требования. У компании крепкая концепция продукта, но в ней не управляли границами проекта путем планирования серии выпусков и откладывания некоторых функций на более поздние выпуски (или навсегда). В конце концов, команда выпустила «перекачанный» продукт лишь после четырех лет разработки.

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

2.1 Основные функции

Опишите основные функции продукта или возможности пользователей, уделив основное внимание тому, что отличает продукт от предыдущей версии или конкурирующих продуктов.

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

2.2 Объем первоначально запланированной версии

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

Если ваша задача — сосредоточиться на разработке и уложиться в график, вам следует избегать искушения включить в версию 1.0 каждую функцию, которая когда-нибудь в будущем может понадобиться какомуто потенциальному покупателю. Распухание кода и сдвиг графика — типичные исходы такого коварного набивания объема. Сосредоточьтесь на наиболее ценных функциях, имеющих максимально приемлемую стоимость, годных для самой широкой целевой аудитории, которые удастся создать как можно раньше.

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

2.3 Объем последующих версий

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

2.4 Ограничения и исключения

Перечислите все возможности или характеристики, которых могут ожидать заинтересованные в проекте лица, но включение которых в продукт или в определенную версию не запланировано.

Перечислите изъятые элементы, чтобы не забыть решения по границам проекта. Если пользователь запросил возможность доступа к системе с телефона, когда он не находится на рабочем месте, и эта функция была признанной не входящей в границы проекта, тогда четко запишите в соответствующем разделе: «Новая система не поддерживает доступа с мобильных устройств».

Источник

Оценка проекта

Одна из серьезных проблем в проектах – превышение сроков и бюджета. Можно даже сказать, что провальных проектов как бы и нет вовсе, а есть такие, срок которых увеличен до бесконечности, а бюджет пока закончился. Примечательно, что от превышения сроков страдают и исполнитель и заказчик.

Заказчик не получает ожидаемого результата, а исполнитель – ожидаемых денег. Казалось бы, общая проблема должна объединять, но она зачастую только создает дополнительные проблемы между сторонами. Как сделать так, чтобы сроки и бюджет всегда выдерживались? Кое-чего в этом направлении нам удалось достичь.

Перед тем как рассказать о своем опыте, хотелось бы ответить на несколько принципиальных вопросов: чего хочет заказчик и чего хочет исполнитель при выполнении проектов? Будем исходить из того, что заказчик действительно хочет сделать проект. У него есть определенный бюджет, и он не собирается «кидать», а готов заплатить оговоренные деньги за получаемый результат. Понятно, что он хочет сделать за свои деньги как можно больше. А вы, когда делаете дома ремонт, разве этого не хотите? И как каждый хозяин, нанимающий бригаду строителей, заказчик, возможно, подозревает, что исполнитель будет его надувать раздувать бюджет. Что поделать, такова наша действительность.

Чего хочет исполнитель? В подавляющем большинстве случаев, проектная команда хочет сделать работу, а руководство хочет получить контрактные деньги. Но поскольку опытный исполнитель знает, чего хочет заказчик, и знает, что бюджет имеет тенденцию заканчиваться в самый разгар его желаний, то исполнитель стремится максимально раздуть бюджет.

Каждая из сторон, по-своему, права. С этим приходится мириться и в таких условиях, не договорившись окончательно, начинать проекты. Но изначальное недопонимание, как правило, в ходе проекта только увеличивается и приводит… не будем о грустном. Расскажу о принципах и методах ведения проекта, используемых нами, которые, так или иначе, имеют отношение к соблюдению сроков и бюджета. Возможно, кому-то это поможет улучшить качество собственных проектов.

Рамки проекта

Первый ключевой момент – проработка рамок. Рамки проекта – это документ, в котором написаны требования заказчика к системе, но не настолько фундаментальный как ТЗ. Функциональные рамки проекта составляет консультант/аналитик – сотрудник проектной команды исполнителя – на основе интервью с ключевыми специалистами заказчика.

Рамки проекта – это полное понимание всех задач, которые нужно решить в ходе проекта, но без детализации. Это также перечень задач, которые не будут решены в ходе проекта. Этот вопрос занимает одну-две недели. Столько же может занять согласование и уточнение.

Обращаю внимание, что в этот момент еще нет контракта и нет проекта. И это риск, проект может так и не начаться. Кто оплатит работы исполнителя на составление рамок, оценку, планирование, подготовку бюджета? На этот вопрос предлагаю ответить вам самостоятельно. Могу лишь утверждать, что оценка проекта, его сроков и бюджета, полученные без проработки рамок проекта – это фантазии, не имеющие отношения к реальности. Ничего удивительного в том, что в ходе проекта бюджет и сроки ползут, едут, летят.

Проработка архитектуры

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

В результате появляется пара абзацев текста общей архитектуры – какие технологии предполагается использовать, и пару предложений по каждому требованию – какие компоненты предлагается разработать и какая ожидается трудоемкость в днях.

Это отлично, ведь уменьшаются риски возникновения данных проблем в ходе проекта. Проработку архитектуры и формирование вопросов архитектор может сделать самостоятельно. Но финальное совещание по обсуждению и оценке требований проектная команда проводит вместе, как минимум в составе: консультант, архитектор, руководитель проекта.

Архитектурные ограничения системы, вытекающие из решения, также фиксируются в документе «Рамки проекта». Помимо этого, в документе фиксируются события, значимые для проекта – необходимые ресурсы, которые должен предоставить заказчик, сроки подготовки оборудования, классов обучения и т.п.

Планирование работ

После проработки требований и понимания их реализации, производится предварительное планирование работ и ресурсов – архитектор определяет, каких исполнителей для реализации тех или иных требований можно привлечь, в каком порядке критично требования выполнять, какие существуют взаимозависимости между требованиями. Всю информацию аккумулирует руководитель проекта, перенося ее в план проекта.

В этот момент рождаются сроки проекта. Сначала все работы выстраиваются линейно. Далее задачи распределяются по ресурсам. Исходя из пожеланий, высказанных заказчиком по срокам, а также из оптимального сочетания привлекаемых ресурсов определяется длительность проекта.

Под «оптимальным сочетанием привлекаемых ресурсом» имеется в виду простая мысль – сроки проекта должны быть минимальны, людей надо привлечь как можно меньше, но задействовать их максимально. Так появляются оценки длительности пребывания людей на проекте, которые являются основой для составления бюджета проекта.

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

Для корректировки оценки важно знать продуктивность каждого конкретного разработчика. Это третий ключевой момент. То же самое относится к остальным работам – инсталляция системы, подготовка технического задания, тестирование и т.п. Чтобы знать, сколько работа займет времени, мы должны знать, кто эту работу будет делать. Фактически, для планирования и оценки проекта, мы должны собрать проектную команду.

Оценка бюджета

В результате планирования работ появляются роли и люди, участвующие в проекте и длительность их пребывания на проекте.

Дальнейшие расчеты я, как руководитель проекта, делаю в таблице Excel. Примерно так:

В результате появляется бюджет проекта. На планирование и составление бюджета уходит еще примерно два-три дня.

Четвертый ключевой момент при составлении бюджета заключается в том, что мы переходим от трудоемкости задач, выставленной в плане, к длительности привлечения ресурсов. Логика простая. Основной статьей расходов исполнителя является оплата труда персонала. Если люди находятся на проекте дольше оплаченного времени, то компания исполнителя несет прямые убытки.

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

Уточнение рамок, срока, бюджета

В результате проделанной работы мы получили документы:

Это полное понимание того, что необходимо сделать, как это предполагается сделать, какое время это может занять, и сколько это будет стоить. Все четыре результата необходимо представить заказчику.

Бюджет проекта и сроки – это параметры, на основе которых заказчик будет принимать решение. Требования – это параметр, которым будут управлять заказчик и исполнитель для корректировки бюджета и сроков.

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

После пересмотра требований, руководитель проекта производит перепланирование, руководствуясь теми же принципами: минимальные сроки – оптимальная загрузка ресурсов. После перепланирования корректируется бюджет. Рамки, сроки и бюджет являются предметной частью контракта. Вся работа по формированию рамок, планированию и оценке у нас занимает две-шесть недель.

Вы уже ответили на вопрос, кто за это платит? На мой взгляд, платить должны и исполнитель и заказчик. Готовность заказчика понести расход на оценку свидетельствует о серьезности намерений в реализации проекта. Расходы исполнителя, точнее выполнение работ по себестоимости или ниже ее, свидетельствуют о его заинтересованности в проекте. Это мотивирует его сделать оценку в минимальные сроки. Это работа в убыток сейчас, но с максимальной проработкой, ведь это его риски в будущем. В каждом конкретном случае, ситуация может отличаться.

Управление сроком и бюджетом

Мы выполнили оценку, согласовали бюджет и сроки. Готовы к заключению контракта и выполнению работ. Но необходимо ответить еще на один вопрос – что исполнитель продает заказчику? С одной стороны он продает результат – в контракте содержатся рамки работ, которые обязуется выполнить исполнитель. Это договор типа «fix price». С другой стороны он продает ресурсы – бюджет составляется на основании длительности привлечения ресурсов, то есть «time & materials». Это разные типы взаимоотношений.

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

Суть их заключается в следующем:

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

Подведем итоги. Ключевые моменты соблюдения бюджета и сроков закладываются в самом начале проекта при проведении оценки и закрепляются в контракте:

В дальнейшем, в ходе проекта, остается только четко следить за соблюдением рамок проекта и за соблюдением взаимных обязательств.

Олег Пашинин
Генеральный директор, Информационные и высокие технологии, Москва

Источник