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

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

Соображение первое – сколько всего ограничений?

Разумеется, мы включим в список упомянутые выше сроки, бюджет и качество. Но полон ли такой список? Для проектов среднего и большого размера, думаю, нет: следует добавить в него ещё и охват, при этом я бы не стал объединять охват и качество в единую сущность, как предлагают некоторые методологии.

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

Но только ли охват следует добавить в список? Знатоки PMBoK, конечно же, вспомнят, что в данном талмуде источнике знаний рассматривается аж шесть ограничений, иллюстрируемых причудливой формой:

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

Не менее запутанная ситуация и с рисками. Мне кажется, что управление рисками не следует смешивать с управлением ограничениями проекта.

Итак, во многих случаях необходимым и достаточным будет список из четырёх пунктов. Соль и перец добавляем по вкусу.

Соображение второе – действительно ли ограничения жёстко взаимосвязаны?

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

Соображение третье – что делать с ограничениями?

Источники знаний по управлению проектами зачастую не детализируют этот вопрос, рекомендуя менеджеру "держать руку на пульсе", а также "контролировать ключевые параметры проекта". Это прекрасно, но что конкретно нужно делать? По моему мнению, список действий менеджера проекта по работе с проектными ограничениями предельно прост. При выявлении выхода или угрозы выхода за установленные органичения менеджер должен:

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

Соображение четвёртое – "водопад" и Agile смотрят на ограничения по-разному

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

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

• "неплохо бы стоять к клиенту лицом"
• "правильная приоритизация не повредит"
• "выдаём как можно скорее результат, который можно использовать"
• "корректируем ожидаемый конечный результат по мере продвижения проекта и накопления опыта"

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

На фото: проектный офис игры, которая была в пятницу, готов к работе, но пока даже не догадывается, что его ожидает.

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы