Spider Project

(разработчик/представитель в России – компания “Технологии управления “Спайдер”, www.spiderproject.ru)

Без преувеличения можно сказать, что Spider Project лучшая отечественная система управления проектами. Версия под DOS появилась еще в 1992 году. От версии к версии заметно улучшается не только интерфейс системы, но и ее функциональность. Текущей является версия 7.23 под Windows 9x/NT/2000.

Минимальные требования к системе: процессор i486 или выше; операционная система Windows (95, 98, 2000, NT); оперативная память не менее 32М; свободное место на диске для установки программы не менее 25М, свободное место на диске для хранения проектов около 1500К на каждые 1000 операций проекта.

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

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

Кроме отдельных ресурсов можно задавать мультиресурсы и пулы.

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

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

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

Расчет расписания проекта методом критического пути производится без учета ограничения по ресурсам и имеет точное математическое решение. Если же при расчетах учитывается ограниченность ресурсов, то понятие резервов, в том числе и полного резерва (total float) теряет смысл. В Spider Project вычисляется ресурсный критический путь и резервы сроков исполнения операций с учетом ограниченности ресурсов.

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

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

Система взаимодействия между участниками проекта с использованием внутрифирменной Intranet или Internet по следующему механизму:

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

· пользователи системы согласно включенным в список ограничениям по доступу к проектам, могут получить план проекта – только для чтения или его фазу (подфазу) для управления реализацией,

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

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

Обмен данными между сервером и клиентами осуществляется с использованием протокола FTP, что позволяет развернуть систему на любой платформе. Проект отправляется на сервер непосредственно из пакета при выборе пункта меню " Отправить". FTP сервер служит таким же хранилищем проектов, как и другие директории (Рабочее, Центр, Архив) - входя на сервер, пользователь видит список доступных для него проектов и открывает их прямо в Спайдере.

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

Spider Project поддерживает OLE (в визуальные представления можно вставлять текст и графику).

Экспорт данных проекта в другие приложения осуществляется с помощью формата csv.

Так же следует отметить хорошую справочную систему продукта, в которую, помимо руководства пользователя включен переработанный русский перевод PMBok (Project Management Body of Knowledge).

На веб-сайте компании доступна демо-версия продукта, умещающаяся на 4 трехдюймовых дискетах. Демо-версия ограничена количеством работ в проекте – 40 без учета фаз и отсутствием функций экспорта данных.

Из наиболее известных проектов, при управлении которыми применялся Spider Project, называются строительство в 1997г. Олимпийской деревни для Всемирных Юношеских Игр в Москве (бюджет $250 млн), строительство Каспийского трубопровода, реконструкция Рязанского НПЗ.

Все большая потребность компаний в системах управления проектами подтверждается не только присутствием разработчиков и продавцов на IT-шных (Softool) и специализированных (“Управление-2000”) выставках, но и интересом к ним бутлегеров. Многие из описанных систем при желании, можно найти на “Горбушке” или в интернете. Конечно, об этом знают и разработчики. Причем отмечается две позиции:

1. “Пусть воруют – нам нужна лишняя реклама; серьезным пользователям нужна поддержка, а за ней к нам придут”. Такую позицию занимают разработчики системы Spider.

2. Усиление и усложнение систем защиты от копирования. Если ранние версии систем (P3 1.0 и OpenPlan 2.1) защищались только ключом (hard key), то следующие версии (OpenPlan 2.5) имеют изощренные инсталляторы с привязкой к hard’у и последующим получением кода авторизации непосредственно у разработчиков.

Оценку адекватности взглядов разработчиков оставим читателю.

По оценкам специалистов, основным недостатком западных систем, с точки зрения российских традиций управления, является отсутствие понятия “объем работ”. Планирование осуществляется в терминах продолжительности операции (original duration). И если в одних типах проектов (инновационные) это не проблема, то в других, в частности, строительных, создание модели проекта без применения понятия “объем работ” - заведомое признание того, что модель имеет большие допущения.

Возможные решения этой проблемы:

· Радикальный – использовать системы, в логике алгоритмов которых изначально присутствует понятие “объем работ”. Примером такой системы может служить отечественная разработка Spider (www.spiderproject.ru).

· Другое решение – более гибко. Искусственная реализация понятия “объем работ”. Можно изменить структуру базы данных проекта или воспользоваться встроенными пользовательскими полями и логически связать их с проектными данными с помощью встроенных макроязыков или внешних программных модулей.

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

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

Требования могут быть, например, такими: “нам обязательно нужен русский интерфейс пользователя”, “как хранит данные проекта система – в собственном формате или она умеет работать с СУБД; а нужно ли нам это умение”.

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