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

Требованиями в DaShe называются позитивные условия осуществления проекта («обеспечить такую-то функциональность», «использовать такую-то технологию», «произвести пробное внедрение в такой-то компании»), а ограничениями – негативные условия («потратить не больше миллиона», «сделать не позже 7 ноября», «никакой утечки информации к конкуренту ХХХ», «офис закрывается в 20:00, всех выгоняем», «использовать только легальное программное обеспечение»). Например, когда Ашот хочет, чтобы разработка велась в современном красивом open space, куда постоянно ходили бы журналисты, – это требование; а когда Семен желает, чтобы о разработке знало как можно меньше людей, – это ограничение. Совместить требования и ограничения в одном и том же проекте непросто, но это и есть часть работы ПМ. Ну а чтобы совместить, нужно сначала их определить.

Требования и ограничения возникают не только как пожелания стейкхолдеров, но и в силу особенностей всех аффилянтов, а также объективных свойств используемых в проекте ресурсов (офис закрывается в 20:00, но зато он практически бесплатен). Основная цель выявления требований и ограничений остается прежней: это раннее выявление рисков (в данном случае – противоречивых свойств, приводящих к конфликтам) и их минимизация.

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

Ограничения могут возникать и из уже выявленных свойств аффилянтов. Например, под проект может быть выделена отличная команда разработчиков; но что, если тимлид этих разработчиков вдрызг разругался с ПМ несколько лет назад? Ресурс в виде «лучших разработчиков» оказывается ограничен уровнем сотрудничества тимлида. Или если финансовый директор явно продвигает интересы банка ХХХ: его настойчивые требования «пусть клиенты берут кредиты в правильных банках» обязательно войдут в противоречие с другими требованиями к продукту, и появятся ограничения либо на финансирование, либо на свойства продукта.

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