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