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

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

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

Для решения этих задач необходимо разработать компьютерную модель проекта, адекватно отражающую особенности его работ, ресурсов, технологических и временных ограничений [1-3]. На примере пакета Spider Project Professional рассмотрим, как решаются перечисленные задачи.

Разработка компьютерной модели проекта

Для создания компьютерной модели проекта в Spider Project необходимо проделать следующие шаги:

  1. укрупненно описать проект, создав Иерархическую структуру работ (ИСР);
  2. задать составляющие стоимости для финансового анализа и управления проектом;
  3. составить перечень и характеристики операций (работ, задач) и ресурсов проекта;
  4. задать взаимосвязи (ограничения на порядок исполнения) операций проекта и назначить ресурсы;
  5. назначить стоимости на операции, ресурсы и назначения проекта;
  6. задать ограничения на финансирование, поставки, сроки исполнения операций;
  7. составить расписание исполнения работ проекта с учетом всех ограничений;
  8. оптимизировать состав используемых ресурсов;
  9. определить бюджет и распределение во времени плановых затрат проекта;
  10. определить и смоделировать риски;
  11. определить необходимые резервы на сроки, стоимости и потребности в материалах для исполнения запланированных показателей с заданной надежностью;
  12. если заданы директивные сроки, стоимости, ограничения по поставкам, то определить вероятность их успешного соблюдения;
  13. представить плановую информацию руководству и исполнителям.

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

Иерархическая структура работ проекта

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

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

Составляющие стоимости и операции

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

Характеристики операций проекта определяют показатели, которые в дальнейшем используются для моделирования проекта: длительность исполнения, объем работ на операции (особенность Spider Project), трудоемкость операции (ресурсо-часы, необходимые для ее исполнения), календарь операции, прямые затраты на операцию (по каждой составляющей затрат), тип операции (что является исходной информацией: длительность/трудоемкость или объем работ, или операция исполняется неопределенное время — от одного события до другого, или операция является вехой или контрольным событием, т. е. имеет нулевую длительность и определяет важные события проекта, например, завершение исполнения фаз), ограничения на сроки исполнения операции (например, начало не раньше определенной даты). Календарь операции используется как ограничение при составлении расписания исполнения работ проекта и определяет промежутки времени, когда можно исполнять операцию: только в дневное время, только летом и т.п. Основные типы операций: фиксированной длительностью; с фиксированным объемом (длительность — частное от деления объема на суммарную производительность назначенных ресурсов); гамак — такие операции длятся от выполнения связи на старт до выполнения связи на финиш (от события и до события); вехи или контрольные события — операции нулевой длины, обычно отражающие наступление важных событий проекта, таких как окончание фазы и т.п. Кроме того, можно задать, допускает ли операция прерывание своего исполнения, если, например, ресурсы, исполняющие операцию, требуются на других, более приоритетных работах, а также исполнять ее сразу, как только для этого сложатся условия (тип «как можно раньше»), или откладывать исполнение до тех пор, пока дальнейшая задержка не повлечет за собой нарушение каких-либо директивных сроков, либо задержит срок завершения проекта.

Ресурсы проекта

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

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

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

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

Взаимосвязи операций

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

  • Финиш-Старт - следующая работа может начинаться после завершения предшествующей;
  • Старт-Старт - следующая работа может начинаться после начала предшествующей;
  • Финиш-Финиш - следующая работа завершается только после окончания предшествующей;
  • Старт-Финиш - следующая работа может завершиться только после начала предшествующей.

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

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

Назначение возобновляемых ресурсов и материалов

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

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

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

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

Поставки, финансирование и составление расписания

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

Для составления расписания без учета ограниченности ресурсов используется известный метод критического пути, но ситуация кардинально меняется, если при составлении расписания принимать во внимание ресурсные и стоимостные ограничения — в этом случае математические методы поиска оптимального решения не работают. В разных пакетах используются различные эвристические методы составления расписания исполнения проекта. В результате расписания, составленные для одного и того же проекта разными пакетами, могут кардинально отличаться. Оптимизация расписания очень важна и позволяет сэкономить затраты, однако не менее важно, чтобы составленное расписание оставалось стабильным в процессе реализации проекта. Если вы заключили контракты на поставки материалоы и привлечение рабочей силы, то внезапное кардинальное изменение расписания исполнения оставшихся работ приводит к катастрофическим последствиям для проекта, поэтому в Spider Project наряду с оптимизацией расписания пользователь может также задать опцию Поддержка предыдущей версии. При расчете расписания пакет расставит такие приоритеты операциям проекта, чтобы сохранить принятый в предыдущей версии порядок их исполнения за счет отказа от оптимизации. Еще можно составлять расписание вперед или назад, определив, когда проект закончится, если в определенный срок начнется, или наоборот, определить, когда его следует начать, чтобы завершить к директивной дате; учитывать или нет приоритеты фаз или подпроектов, заданные пользователями вручную; указать ограничения какие ресурсы следует учитывать, а по каким просто определить потребность и т.п. В составленном расписании определяется Ресурсный критический путь — операции проекта, задержка исполнения которых приводит к задержке окончания проекта или к нарушению директивных сроков завершения его работ, а также резервы времени исполнения операций проекта с учетом ограниченности имеющихся ресурсов.

Моделирование проектов

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

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

Типовой фрагмент — компьютерная модель небольшой фазы, которая встречается в проектах и обычно составляется для некоторого типового объема работ, а при вставке типового фрагмента в проект, пользователь отвечает на запрос о реальном объеме фрагмента в конкретном проекте. В зависимости от ответа, характеристики модели автоматически корректируются. Примеры типовых фрагментов: строительство одного километра линейного участка трубопровода в равнинно-холмистой местности на грунтах 1-2-ой категории, получение разрешения в определенной инстанции и т.п.

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

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

Рис.1. Диаграмма Гантта проекта выбора ПО

Данные компьютерного моделирования проектов могут быть представлены в разнообразных табличных и графических формах. На рис.1 представлена диаграмма Гантта проекта выбора программного обеспечения, отражающая не только сами работы проекта, но и назначения ресурсов.

Другие формы: сетевая диаграмма, организационные диаграммы — графические представления иерархических структур работ и ресурсов, гистограммы загрузки ресурсов, расхода материалов, диаграммы затрат, линейная диаграмма.

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

Линейная диаграмма, формируемая в Spider Project не имеет аналогов в других пакетах. В современных проектах имеются тысячи работ, поэтому даже столь компактное отображение, как диаграмма Гантта становится ненаглядным. В процессе планирования строительства Каспийского трубопровода вместе с институтом Оргпроектэкономика была разработана графическая форма представления проекта, которую впоследствии и назвали линейной диаграммой — наглядное представление плана реализации любого проекта на листе формата А4. В этой форме по горизонтали откладывается метрика проекта, по вертикали — временная шкала (рис. 2). Работы проекта отображаются в виде совокупности кривых, координаты которых определяются временем и местом на метрике проекта, где работы производились. При этом работы разных типов отображаются кривыми с различными атрибутами. Типы работ, которые отображаются на линейной диаграмме, а также участки метрики и масштаб временной шкалы выбираются пользователем. В качестве метрики в проекте по трубопроводу используются километры его трассы, но могут использоваться и качественные показатели (этапы жизненного цикла, например).

Анализ рисков

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

В западных пакетах используется либо метод PERT, который не дает информации для построения управления на базе анализа рисков, либо имитационное моделирование (метод Монте-Карло) — простой и интуитивно понятный метод моделирования рисков, однако для получения достоверного статистического распределения результатов моделирования необходимо сделать столько проходов (испытаний), что моделирование реального проекта займет годы. Как же в западных пакетах решается эта проблема? При запуске имитационного моделирования пользователю предлагается задать устраивающее его число проходов модели. При этом по умолчанию предлагается заведомо недостаточное число, (например, пакет Open Plan предлагает сделать 10 проходов) — в реальных проектах число проходов должно исчисляться миллионами. При этом время просчета параметров проекта в каждом проходе может исчисляться минутами. В Spider Project мы отказались от моделирования по Монте-Карло и предлагаем упрощенный метод, который позволяет оценить распределение вероятности параметров, и, хотя точность оценки не высока, она мало отличается от точности, достижимой при разумном применении метода Монте-Карло.

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

Рис.3. Целевое расписание исполнения проекта выбора программного обеспечения, составленное для обеспечения 70% вероятности успешного соблюдения запланированных сроков

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

Организация групповой работы с моделью

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

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

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

Учет и анализ исполнения

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

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

Рис.4. Тренды вероятностей успеха проекта выбора ПО

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

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

Заключение

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

Литература

[1] Директор информационной службы (CIO), 2001, № 4. Выпуск посвящен программам управления проектами

[2] Виктор Терехин. Какой С.У.П. вам нужен. Потребитель. Компьютеры и программы, 2002, № 6, раздел Экспертиза и тесты

[3] A Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute

Владимир Либерзон (spider@mail.cnt.ru) — генеральный директор компании «Технологии управления Спайдер» (Москва)

Пакет Spider Project

В конце 80-х годов в России появились эмиссары западных компаний, которые искали кадры и инновационные идеи для создания собственных конкурентоспособных решений, а мы тогда многого не знали и не понимали. Было просто интересно пообщаться с западными коллегами. Поэтому, когда наше выступление перед представителями британской компании Knowledge Engineers с рассказом о состоянии работ в области сетевого планирования вызвало предложение по совместной работе, мы были польщены. Однако впоследствии сотрудничество пришлось прервать из-за непонятных перерывов в коммуникациях. Правда, мы получили демо-версии наиболее известных пакетов управления проектами и информацию о состоянии рынка программного обеспечения управления проектами того времени.

Тестирование западных пакетов показало, что в области оптимизации расписания исполнения проекта при ограниченных ресурсах российские разработчики действительно впереди — далее простого ручного выбора приоритетов при назначении ресурсов среди полей операций ни один из западных пакетов не пошел. Более того, сама технология моделирования работы ресурсов была достаточно примитивной и не позволяла использовать приемы планирования, которыми мы уже активно пользовались. Наш небольшой коллектив программистов разработал программу, рассчитывающую расписание исполнения проекта с учетом ресурсных ограничений, которое, как правило, было более коротким, чем расписания для тех же проектов, составленные западными пакетами. Однако у нас не было сил и средств, чтобы довести систему до товарного вида. К тому же Управление Проектами в то время было в России непонятным словосочетанием, а потому разработанный нами модуль был англоязычным. С этим модулем в 1990 году мы направились в Лондон искать партнеров среди поставщиков программ управления проектами, однако не получили иных предложений, кроме желания купить разработанные алгоритмы. Как нам объяснили в компании K&H (впоследствии она была куплена Artemis), производители программ управления проектами не могли быть заинтересованы в разработке еще одной конкурирующей программы, а вывод новой программы на рынок обойдется примерно в 1 млн. фунтов.

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

Технология управления Spider

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

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