Пакет позволяет использовать неограниченное количество составляющих стоимости, причем в разных валютах. Так же можно создать неограниченное количество различных иерархических структур работ и ресурсов.
Для анализа исполнения проекта, а также для анализа “что если” очень важно иметь возможность сохранять прежние версии проекта и иметь возможности для сравнения и анализа отклонений текущей версии проекта от предыдущих. В Spider Project есть возможность хранить неограниченное количество версий проекта и анализировать ход исполнения работ не только по сравнению с какой-то базовой версией, но и с любой другой.
Расчет расписания проекта методом критического пути производится без учета ограничения по ресурсам и имеет точное математическое решение. Если же при расчетах учитывается ограниченность ресурсов, то понятие резервов, в том числе и полного резерва (total float) теряет смысл. В Spider Project вычисляется ресурсный критический путь и резервы сроков исполнения операций с учетом ограниченности ресурсов.
Алгоритм анализа рисков так же отличается от реализованного в других системах. При моделировании рисков в качестве исходной информации используются не оценки длительности (оптимистические, пессимистические), а оценки производительности ресурсов.
Непривычно, но достаточно продумано, реализована поддержка групповой работы над проектом. В Spider Project нет одновременного доступа на изменение данных. Ответственный за свою часть проекта (фазу) представляет менеджеру проекта свои файлы. И решение принять или отвергнуть изменения остается за менеджером проекта. Именно такое решение, по мнению разработчиков, позволяет избежать неразберихи при изменении проектных данных, и, как следствие, траты времени на вылавливание багов. С этих позиций разработана и система групповой работы через интернет.
Система взаимодействия между участниками проекта с использованием внутрифирменной Intranet или Internet по следующему механизму:
- созданная главным менеджером полная версия проекта передается на сервер с указанием списка пользователей и уровня доступа тех, которым она предназначается,
- пользователи системы согласно включенным в список ограничениям по доступу к проектам, могут получить план проекта – только для чтения или его фазу (подфазу) для управления реализацией,
- в результате выполнения функции управления пользователь передает измененный план (фазы, подфазы) обратно на сервер, откуда он может быть получен руководителем проекта.
При обращении к серверу система проводит идентификацию пользователя, обеспечивая, таким образом, разграничение доступа к проектам.
Обмен данными между сервером и клиентами осуществляется с использованием протокола FTP, что позволяет развернуть систему на любой платформе. Проект отправляется на сервер непосредственно из пакета при выборе пункта меню "Отправить". FTP сервер служит таким же хранилищем проектов, как и другие директории (Рабочее, Центр, Архив) - входя на сервер, пользователь видит список доступных для него проектов и открывает их прямо в Спайдере.
Взаимодействие между участниками проекта можно осуществлять через несколько серверов. Например, главный менеджер отправлять проекты может на один сервер, а получать с другого.
SpiderProject поддерживает OLE (в визуальные представления можно вставлять текст и графику).
Экспорт данных проекта в другие приложения осуществляется с помощью формата csv.
Так же следует отметить хорошую справочную систему продукта, в которую, помимо руководства пользователя включен переработанный русский перевод PMBok (ProjectManagementBodyofKnowledge).
На веб-сайте компании доступна демо-версия продукта, умещающаяся на 4 трехдюймовых дискетах. Демо-версия ограничена количеством работ в проекте – 40 без учета фаз и отсутствием функций экспорта данных.
Из наиболее известных проектов, при управлении которыми применялся SpiderProject, называются строительство в 1997г. Олимпийской деревни для Всемирных Юношеских Игр в Москве (бюджет $250 млн), строительство Каспийского трубопровода, реконструкция Рязанского НПЗ.
Плата за популярность?
Все большая потребность компаний в системах управления проектами подтверждается не только присутствием разработчиков и продавцов на IT-шных (Softool) и специализированных («Управление-2000») выставках, но и интересом к ним бутлегеров. Многие из описанных систем при желании, можно найти на «Горбушке» или в интернете. Конечно, об этом знают и разработчики. Причем отмечается две позиции:
1. «Пусть воруют – нам нужна лишняя реклама; серьезным пользователям нужна поддержка, а за ней к нам придут». Такую позицию занимают разработчики системы Spider.
2. Усиление и усложнение систем защиты от копирования. Если ранние версии систем (P3 1.0 и OpenPlan 2.1) защищались только ключом (hardkey), то следующие версии (OpenPlan 2.5) имеют изощренные инсталляторы с привязкой к hard’у и последующим получением кода авторизации непосредственно у разработчиков.
Оценку адекватности взглядов разработчиков оставим читателю.
Камни в огород
По оценкам специалистов, основным недостатком западных систем, с точки зрения российских традиций управления, является отсутствие понятия «объем работ». Планирование осуществляется в терминах продолжительности операции (original duration). И если в одних типах проектов (инновационные) это не проблема, то в других, в частности, строительных, создание модели проекта без применения понятия «объем работ» - заведомое признание того, что модель имеет большие допущения.
Возможные решения этой проблемы:
Радикальный – использовать системы, в логике алгоритмов которых изначально присутствует понятие «объем работ». Примером такой системы может служить отечественная разработка Spider (www.spiderproject.ru).
Другое решение – более гибко. Искусственная реализация понятия «объем работ». Можно изменить структуру базы данных проекта или воспользоваться встроенными пользовательскими полями и логически связать их с проектными данными с помощью встроенных макроязыков или внешних программных модулей.
Выбор системы
Если потребность бизнеса приведет вас к решению о внедрении СКПК, перед вами встанет вопрос выбора той или иной системы. Очень советую вспомнить мысль о названии яхты и ее плавании.
Наилучшим методом автору представляется такой: построить матрицу, строки которой – необходимые вам функции и ваши требования к системе, а в столбцах – оценки рассматриваемых систем. Причем не оценки, взятые из рекламных буклетов и различных сравнительных таблиц», надерганных с сайтов разработчиков, а оценки выставленные пользователями.
Требования могут быть, например, такими: «нам обязательно нужен русский интерфейс пользователя», «как хранит данные проекта система – в собственном формате или она умеет работать с СУБД; а нужно ли нам это умение».
Хотя выбор системы должен быть оптимальным, не стоит забывать, что программная СУП – всего лишь мощный инструмент, позволяющий если не исключить, то сильно уменьшить количество рутинных операций.
Список литературы
Валерий Вязовой. Неформальный справочник по системам управления проектами