Управление проектами. Фундаментальный курс - Коллектив авторов

Рис. 10.5. Процесс управления расписанием

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

В результате процессы разработки и управления расписанием должны содержать:

1. Построение сетевой модели проекта (учет взаимосвязей между работами).

2. Получение информации о работах: продолжительность, стоимость, ресурсы.

3. Методы разработки и анализа расписания проекта.

4. Инструменты, используемые для управления расписанием.

Основы сетевого моделирования

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

Связи (или взаимосвязи) между работами могут быть различными. Обычно выделяют:

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

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

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

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

Простое отношение предшествования

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

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

Отношения предшествования обладают свойством транзитивности: если А→В и В→С, то это означает, что А→С. Данное свойство позволяет вводить в модель только те связи, которые существуют между работами без посредников, т. е. в приведенном примере связь между А и С подразумевается и ее не нужно описывать дополнительно. На примере проекта строительства дома, в котором работа А – это фундамент, В – этажи и С – крыша, необходимо описать всего две связи: А→В и В→С. Чем меньше будет связей в модели, тем она будет проще и тем проще будет на ее основе найти эффективное решение.