Один из слушателей задал мне такой вопрос. Вот что я ответил.
Обычно мы их в голове смешиваем, а, по сути, из одного следует другое.
Давайте разберемся. Начнем с определений.
Ограничение - это фактор, влияющий на ход исполнения портфеля, программы, проекта или процесса.
Требование – это условие или характеристика, которому должен соответствовать или которую должен иметь продукт, услуга или результат в соответствии с договором или другой формально предписанной спецификацией.
Коротко можно ответить так: сначала выявляются и фиксируются ограничения, затем формулируются требования к продукту. В первую очередь, на основе ограничений.
Можно, конечно, эту «двухходовку» прокрутить в голове. Для явных и простых ситуаций это допустимо. Но PMBoK «накрывает» все возможные ситуации, в том числе и не однозначные, и сложные, и (в начале проекта) невидимые и невзаимосвязанные.
Поэтому и предлагается более подробный подход.
То есть, ограничения должны быть выявлены как можно раньше и зафиксированы сначала в Уставе проекта, а затем в документе «Описании содержания». Там в отдельном разделе перечисляются и описываются конкретные ограничения проекта, связанные с его содержанием, ограничивающие возможности команды, например, предопределенный бюджет, любые установленные даты или контрольные события расписания, которые определены заказчиком или исполняющей организацией. Это могут быть ограничения по технологиям (нельзя применять что-то), ограничения по объемам (не более… , не менее…, не реже…, не чаще…) и др. Когда проект выполняется по Контракту, положения Контракта, как правило, являются ограничениями. Информация об ограничениях может быть указана в описании содержания проекта или в отдельном журнале.
Затем переходим к требованиям. Они, как правило, отражаются в документах: Устав проекта, План управления требованиями, Матрица отслеживания требований, Документация по требованиям.
Например, возьмем Устав проекта.
В нем можно отразить и требования к продукту, и ограничения (в том числе и по содержанию).
Если сформулировано ограничение, которое может повлиять на содержание продукта, его нужно отразить. Например, Система должна быть сдана в эксплуатацию не позднее…
Если уже сформулировано требование к продукту, то можно зафиксировать и его. Однако, на уровне Устава обычно фиксируют ограничения.
Согласны ли Вы с такой трактовкой?
Уважением, В. Абрамов
|
Р Дума
|
5 октября 2015 г., 16:06 |
я бы упростил
Я бы сказал так: суть в том, что ограничения больше применимы к проекту и его планированию, а требования - к продукту и его проверке. К сожалению, в PMBOK на эту тему все немного размыто и более того, на мой взгляд не совсем корректно. Например, ограничениями по содержанию являются: - миграция 10 информационных систем (при том что всего их 1000) - интеграция с внешними ИС не является предметом настоящего проекта. Перечисленные примеры не будут проверяться на этапах acceptance testing и не будут содержать критериев приемки, однако они крайне существенно влияют на содержание и далее на все характеристики проекта.
Какие ограничения описываете в проектах Вы?
Коллеги! Согласен с коллегой: в PMBoK этот вопрос не прояснен. Приходится догадываться или спрашивать у более опытных специалистов. Не всегда в проектах РП описывает ограничения и работает с ними. И эти забытые ограничения могут напортить ему в самое неподходящее время. Но требования ему приходится и формулировать и выполнять. Как же грамотнее связать ограничения по содержанию и требования? Какие ограничения в проектах описываете Вы как с ними работаете? С уважением, В. Абрамов
|
