Spider Project – методология и пакет управления проектами

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

Методология, положенная в основу Spider Project, имеет целый ряд особенностей по сравнению с традиционными подходами к управлению проектами, описанными в PMBOK Guide. В соответствии с этим возможности пакета Spider Project во многом отличаются от того, что предлагается западными поставщиками программных продуктов в области управления проектами. Для того чтобы показать эти отличия, недостаточно просто описать технические характеристики пакета, поэтому в статье рассматриваются те его особенности, которые имеют отношение к предлагаемой методологии управления проектами Spider Project и представляются принципиально важными.

Программное обеспечение Spider Project предназначено для различных групп пользователей. В его составе имеется профессиональная система Spider Project Professional, а также более дешевые версии Desktop (однопользовательский вариант профессиональной системы) и Lite (вариант с ограниченными функциональными возможностями).

При внедрении пакета обычно используется следующая конфигурация.

• Spider Project Professional устанавливается в проектном офисе для мультипроектного моделирования и управления, а также в тех подразделениях, в которых принимаются решения по управлению организацией в целом (например, там, где планируется и осуществляется финансовое управление, снабжение).
• Spider Project Desktop используется для управления отдельными проектами, количество установок в организации определяется числом одновременно ведущихся проектов. Обычно на одно рабочее место Professional приходится четыре-пять рабочих мест Desktop.
• Spider Project Viewer предназначается для просмотра проектов, в этой версии не предусмотрено проведение расчетов. Обычно устанавливается у руководства. Статистика показывает, что на предприятии число используемых Spider Project Viewer примерно в два раза превосходит число используемых рабочих версий.
• Spider Project Lite – усеченная, рассчитанная на простые проекты версия пакета, функциональные возможности которой тем не менее достаточно серьезны (стоимостные компоненты, пулы назначений ресурсов, базы данных, оптимизация расписаний и пр.).

Функциональная архитектура Spider Project и основные отличия его облегченных версий, а также другие характеристики пакета представлены на врезках.

Существуют различные способы и рекомендации по построению иерархической структуры работ (ИСР) 1. Оптимальность здесь отсутствует, а удобство определяется конкретным проектом. В пакете Spider Project пользователям дается возможность ввода и параллельного использования неограниченного количества иерархических структур работ для операций одного проекта. Как правило, используется по меньшей мере три ИСР, позволяющие проанализировать проект с разных сторон.

ИСР по объектам получается, если результат проекта на самом верхнем уровне иерархии разбивается на результаты по отдельным объектам проекта (например, по модулям компьютерной программы, этажам здания и т. п.), а затем по процессам, видам работ или стадиям жизненного цикла проекта (например, проектирование, реализация и т. д.). Под объектами проекта в этом контексте понимаются компоненты его результата. Так, чтобы изготовить велосипед, следует изготовить раму, колеса, тормозную систему и т. д.

ИСР по процессам на верхнем уровне использует процессы, а на более низких – объекты проекта.

Кроме того, мы рекомендуем использовать и структуру ответственности, группируя операции в соответствии с распределением между отдельными исполнителями проекта ответственности за реализацию его частей.

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

Иерархические структуры могут иметь двойное назначение. При составлении компьютерной модели проекта ИСР помогает ввести (и не пропустить) операции 2 проекта, на которые разбивается нижний уровень ИСР и на исполнение которых впоследствии назначаются ресурсы. Для этого одна из структур используется в качестве основной, а использование других структур позволяет проконтролировать созданную структуру проекта и внести в нее необходимые дополнения. После создания компьютерной модели ИСР используются для агрегации проектной информации и подготовки требуемой отчетности. Поэтому возможно создание дополнительных структур, в том числе неполных (из которых исключены некоторые операции проекта), исходя из требований отчетности и анализа.

В Spider Project допускается использование неограниченного количества ИСР в каждом проекте, также не ограничивается количество уровней иерархии.

Аналогично можно создавать и использовать для целей анализа и агрегации информации множественные структуры ресурсов. Это особенно важно и полезно при мультипроектном управлении.

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

Количество иерархических структур ресурсов и уровней иерархии также не ограничивается.

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

Кроме того, полезно иметь возможность группировки материалов и ресурсов и получения отчетности не только по отдельным ресурсам и материалам, но и по этим группам, которые в пакете называются центрами ресурсов и материалов.

В проектах наряду с расходом ресурсов и материалов может встретиться их производство или поставки, наряду с расходами финансовых средств полезно моделировать и доходы. Особенно это важно для служб заказчиков, которые непосредственно ресурсами проектов не управляют, но управляют поставками основных материалов и финансированием работ. Кроме того, это очень важно для проектов, в которых на одних работах производятся ресурсы или материалы, необходимые для других работ. Spider Project позволяет моделировать производство и финансирование и использовать эту информацию для составления расписания работ с учетом ограниченности ресурсов, материалов и финансирования проекта.

Пользователи пакета могут рассчитать, как отразится на сроках реализации проекта та или иная схема поставок и финансирования, определить сроки окупаемости капиталовложений и получить соответствующие отчеты – cash flow по любым составляющим и центрам стоимостей, а также по любым материалам и центрам материалов проекта.

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

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

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

При моделировании неполной загрузки учитывается и количество назначенных ресурсов, и их загрузка. Это отличает подход Spider Project от подходов, используемых в других пакетах, в которых задается только суммарная загрузка ресурсов, но не их количество. При таком подходе моделирование неполной загрузки может быть некорректным, а информация о потребностях проекта в ресурсах — неверной.

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

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

Удобные инструменты для управления назначениями ресурсов открывают имеющиеся в пакете возможности назначения на операции мультиресурсов. Мультиресурс – это устойчивая группа вместе работающих ресурсов (например, бригада). Во-первых, назначая мультиресурс, пользователь назначает все входящие в него ресурсы, то есть облегчает свою работу. Но более интересно то, что в любой момент можно изменить состав мультиресурса и распространить эти изменения на все его назначения. Такая возможность облегчает анализ «что — если», позволяя эффективно подбирать и изменять составы назначенных бригад.

Отметим также, что Spider Project не накладывает ограничений ни на количество ресурсов, ни на количество назначений ресурсов на исполнение операций проекта.

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

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

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

Важной особенностью пакета является вычисление ресурсного критического пути, то есть тех операций проекта, задержка исполнения которых приводит к задержке завершения проекта, с учетом имеющихся ограничений на ресурсы. Механизм вычисления ресурсного критического пути был реализован еще в самой первой версии Spider Project в 1992 году. Критическая цепь (Critical Chain), о которой написал Голдратт в одноименной книге (Goldratt E. M. Critical Chain. North River Press, 1997) и которая сейчас широко обсуждается мировым сообществом менеджеров проектов, есть не что иное, как ресурсный критический путь. Практически все, что предлагается в теории критической цепи, реализовано в пакете Spider Project.

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

На 1 проиллюстрировано понятие ресурсного критического пути и резервов времени на исполнение операций. В проекте РКП на операции 2 и 4 назначен ресурс А, который имеется в одном экземпляре, а потому они не могут исполняться параллельно. Исполнение операций 1 и 5 может быть отложено до моментов, показанных на диаграмме полыми полосками.

1. Ресурсный критический путь

Ресурсный критический путь – операции 3, 4 и 2, задержка исполнения которых приводит к задержке проекта в целом.

Spider Project спроектирован таким образом, чтобы поддерживать корпоративные стандарты управления проектами. Для этого предусмотрена возможность создания непосредственно в пакете библиотек типовых фрагментов проектов, а также неограниченного количества всевозможных баз данных, включая производительности ресурсов на типовых назначениях, объемы и длительности типовых операций, расход материалов и расценки на единичных объемах типовых операций и назначений ресурсов и т. д. Пользователи могут создать (или импортировать из стандартных SQL баз, таких как Oracle, Access и т. д.) и любые другие базы данных и использовать их во всех проектах компании.

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

Опыт и анализ проектов показал, что детерминированные расписания имеют низкую (обычно 20 — 35%) вероятность успешного исполнения. Отметим, что без анализа рисков нельзя обеспечить качественный анализ и управление проектами. Встроенные в Spider Project инструменты анализа рисков предназначены для определения реальных сроков и бюджетов проектов и позволяют определять и анализировать вероятность успешного исполнения директивных параметров проекта.

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

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

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

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

В пакет Spider Project встроена система оперативного учета, которая позволяет собирать информацию по выполненным объемам, отработанной длительности, произведенным затратам и истраченным материалам по любой операции и любому ресурсу проекта, а также агрегировать эту информацию по любой из используемых в проекте иерархических структур работ и ресурсов. В результате пользователи могут получить полную информацию о работах, произведенных за любой период любым ресурсом, любым подразделением, на любой операции, фазе или по проекту в целом. Пакет также ведет архивы учета, что позволяет контролировать ту отчетность, которая послужила исходной учетной информацией.

В проектном управлении важно иметь срезы состояния проекта на различные моменты времени для анализа, подготовки отчетности и ведения архивов. При мультипроектном управлении, когда информация вводится в одну базу из разных мест, в разное время и по операциям, принадлежащим разным фазам, обеспечить такие срезы не просто. Кратко опишем технологию, принятую в Spider Project.

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

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

Отметим, что разработчики намеренно отказались от стандартной клиент-серверной технологии организации групповой работы, считая ее плохо приспособленной для особенностей решения задач управления проектами.

Spider Project поддерживает стандартные формы отчетности, имеющиеся в аналогичных программах, – таблицы, сетевые и организационные диаграммы, диаграмма Гантта. Однако можно получить и дополнительные графические формы отчетности, в частности диаграмму Гантта для ресурсов проекта и Линейную диаграмму.

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

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

В Линейной диаграмме по горизонтали откладывается метрика проекта, по вертикали – время. На диаграмме разными цветами и видами линий отображаются работы различных типов в виде графиков, отображающих плановое состояние данного типа работ в различное время (например, в какое время на каком километре должны проводиться работы определенного типа). Получается очень компактное и наглядное отображение проекта – на странице А4 можно отобразить ту же информацию, которая на диаграмме Гантта займет много листов формата А0.

Пример Линейной диаграммы (4-й поток строительства Каспийского трубопровода) представлен на 2.

2. Линейная диаграмма для некоторых работ строительства Каспийского трубопровода.

Характерная особенность Линейных диаграмм – простой визуальный контроль непротиворечивости и полноты имеющейся информации.

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

Подробнее об особенностях пакета (в том числе тех, что из-за недостатка места не освещены в данной статье) и его стоимости можно узнать на сайте www.spiderproject.ru. Там же можно списать работающие демо-версии Spider Project Professional и Spider Project Lite, руководство по работе с пакетом, а также различные статьи и презентации на тему управления проектами. В форуме по управлению проектами на этом же сайте можно задать вопросы и получить необходимые консультации.

Spider Project Professional — составление расписания исполнения работ проектов (а также программ и мультипроектов) с учетом ресурсных, финансовых и временных ограничений, бюджетирование проектов и стоимостной анализ их исполнения, ведение учета исполнения работ и архивов проектов, планирование и анализ работы ресурсов, анализ и управление рисками проектов, анализ отклонений хода работ от запланированного и прогнозирование вероятности успешного исполнения запланированных параметров и т. д.

Spider Project Desktop – версия, предназначенная для управления отдельными проектами. Не включает инструменты групповой работы над проектами, возможности расчета расписания работ с учетом ограничений на поставки материалов и финансирование проекта.

Spider Project Lite – облегченная версия, предназначенная для управления проектами, в которых нет сложных назначений ресурсов. Не включает анализа рисков, возможностей работы с мультиресурсами и независимыми командами ресурсов, моделирования переменной загрузки ресурсов. Ограниченные возможности управления мультипроектами. Упрощенный учет.

Spider Project Viewer – бесплатная версия, поставляемая вместе с рабочими программами и предназначенная для просмотра и анализа проектов руководством. Не поддерживает проведения расчетов.

Spider Project Demo – версия с ограничением на максимальное количество операций проекта - до 40.

Операционные системы Windows 95/98/NT/2000

Собственная СУБД с возможностью импорта и экспорта всей информации в стандартные СУБД (Oracle, Access, Interbase и т. д.), Lotus Notes, MS Office, CSV.
Во всех версиях обеспечивается удаленный доступ к проектам с использованием FTP-сервера непосредственно из пакета. При этом обеспечивается доступ ко всем функциям - проекты открываются непосредственно с FTP-сервера и могут отправляться на FTP-сервер. Браузер не требуется.

Рекомендации по объему оперативной памяти для серверов и рабочих станций основаны на собственном опыте работы с проектами указанных размерностей:

• 10 000 операций - 64 Мбайт,
• 40 000 операций - 128 Мбайт,
• 80 000 операций - 256 Мбайт,
• 160 000 операций - 512 Мбайт.

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

К объему дисковой памяти специальных требований не предъявляется - они зависят от объемов и количества ведущихся одновременно проектов.

Spider Project Lite - 499 долл. независимо от числа рабочих мест

1. Термин «Иерархическая структура работ» – перевод исходного термина Work Breakdown Structure. Отметим, что в литературе часто встречаются другие переводы этого термина – «структура декомпозиции работ», «структурная декомпозиция работ». – Прим. ред.
2. Операция – элемент проекта, на исполнение которого назначаются ресурсы. В русской литературе иначе называется работой или задачей, англоязычный термин – activity или task. Термин «операция» используется в России с середины 60-х годов в литературе по сетевому планированию, с 1992 года – в пакете Spider Project. Мы этот термин предпочли другим, потому что элементами проекта могут быть такие «работы», как поступление денег или набор прочности конструкции. – Прим. авт.

Статья опубликована в журнале "Директор ИС", #10, 2001 год