Применение рекомендаций стандарта PMBOK® к реальным проектам АСУ ТП

Введение

В мире существует несколько стандартов, описывающих процесс управления проектами. Это IPMA, PRINCE, AIPM, P2M и другие. К созданию стандартов управления проектами приложили руку почти все широко известные компании, присутствующие на рынке АСУП. Один из них разработан Project Management Institute (PMI®).

Сборник опыта по управлению проектами был оформлен в виде стандарта ANSI PMI PMBOK® 3rd Edition (2004). Как следует из названия, это уже 3-я версия. В текущем году должна появиться четвертая.

Описание

Существует расхожее мнение о том, что зарубежные стандарты не применимы в условиях России. Однако, как показывает практика, неприменимость — это скорее исключение. Последнее время всё больше международных стандартов появляется под аббревиатурой «ГОСТ Р». Мы привыкли, что стандарт — это свод законов, обязательных к применению. Но если рассматривать стандарт как живое руководство к действию и дополнить его некоторыми нашими (отечественными) методиками и подходами, то получится очень мощный и полезный инструмент.

Рассмотрим подробнее подход стандарта PMBOK® к задаче управления проектом. Тут принято различать ряд стадий прохождения проекта:

• инициация;

• планирование;

• исполнение и управление;

• завершение.

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

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

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

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

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

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

Применение

Рассмотрим применение PMBOK® на примере небольшого проекта АСУ ТП.

Сначала о самом проекте. Однажды тёплым весенним утром у меня зазвонил телефон. Заказчик на другом конце провода хотел очень быстро внедрить очень маленькую и простую систему мониторинга инфраструктуры информационной сети. Техническое задание состояло из нескольких листов и в основном содержало таблицы сигналов.

Сама система оказалась настолько типовой, что я предложил заказчику готовое решение, состоящее из каплера (коммуникационного контроллера, УСО) с интерфейсом Modbus TCP, OPC-сервера, SCADA-системы (рис. 1) и минимального комплекта эксплуатационной документации.

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

И началась работа.

В это время нашего полку прибыло, и я решил, что данный проект — отличный шанс для новых сотрудников набраться опыта. Они прошли подготовку в учебном центре компании ПРОСОФТ по курсам GENESIS32 и применения ПЛК. Знаний, которые можно получить на этих курсах, вполне достаточно, чтобы сделать такой проект.

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

Итак, подойдём формально. Подготовим по порядку «Устав проекта», «Описание содержания проекта», «Реестр рисков».

В «Реестре рисков» опишем возможные риски и способы реагирования на них, срок их актуальности, стоимость устранения. Стандарт рекомендует предусмотреть максимально возможное количество рисков. Но тут нужно удержаться от паранойи и исключить риски типа «если небо упадёт на землю». В этом важном документе мы создаём себе «подушку безопасности».

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

Ещё день ушёл на «План управле-ния проектом». На этом этапе были подготовлены календарный и стоимостной планы проекта, распределены участники проекта по задачам. Все эти документы составляют так называемый базовый план. К нему нужно стремиться при выполнении проекта, с ним сравнивать действительное положение дел.

Теперь можно легко посчитать стоимость с учётом разумной прибыли.

Чтобы не промахнуться и случайно не взять лишних денег, предлагаю воспользоваться рекомендациями Минпрома России. Для этого существует «Справочник базовых цен на разработку технической документа-ции на автоматизированные системы управления технологическими процессами (АСУ ТП)», разработанный НПЦ «ВНИПИ САУ-40» и ГП «ЦЕНТР-ИНВЕСТпроект» Минстроя России. Произведённый расчёт по отечественному справочнику дал в моём случае разницу менее 10%, значит, расчёт произведён верно.

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

Подготовим технико-коммерческое предложение и отправим. В моём случае ответ не заставил себя долго ждать.

Формально проект начинается с момента подписания договора. Взяли типовой шаблон договора, заполнили пустые места и… Но не тут-то было! Договор был запущен в долгий круг согласования. Хождение по кабинетам заняло у меня более 3 дней, и почти две недели ушло на различных согласователей.

Ну, теперь, когда самое страшное позади, началась работа над проек-том. Для ведения проекта существует множество бесплатных, как например OpenProj, и коммерческих программ (рис. 2). PMBOK® предоставляет ряд удобных инструментов для контроля за ходом реализации проекта и за расходованием денежных средств, но в маленьком проекте полезны только некоторые из них.

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

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

Таким образом, сработал один из пунктов «Реестра рисков», за ним сра-зу же последовал второй — задержка поставки. Стало понятно, что сроки выполнения работ могут быть провалены. Но тщательно проработанные меры по устранению влияния рисков, сделанные на начальном этапе, дали свои плоды. С заказчиком удалось договориться полюбовно и получить дополнительное время на корректировку программного обеспечения, вызванную изменением технического задания. В это время мы смогли реализовать запасной план по спасению поставки, предусмотренный в «Реестре рисков». Итак, проект был успешно завершён с опозданием всего на неделю. Теперь можно не спеша приступать к стадии закрытия.

Результаты

Что же было сделано? Создана конфигурация Modbus OPC-сервера для каплера системы. Настроены компоненты SCADA-системы GENESIS32.

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

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

Для системы мониторинга был подготовлен необходимый комплект документов. Документация состояла из сборочных чертежей, инструкции по инсталляции и настройке, руководства оператора. Подробность и доходчивость документации была проверена перед передачей её заказчику. С этой целью был выбран один из наших инженеров, не имеющий представления о данном проекте и не знакомый с техникой и программным обеспечением, использованным в нём. Он успешно произвёл монтаж и запуск системы на испытательном стенде в учебном классе ПРОСОФТ, пользуясь только пакетом документации. Я считаю, что это хороший показатель качества работы команды проекта.

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

Завершение

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

• ведение документации о ходе про-екта занимает около 0,5% стоимос-ти проекта;

• плохо подготовленное техническое задание может увеличить стоимость разработки программного обеспечения вдвое и сорвать сроки выполнения всего проекта;

• за время движения договора по кабинетам цены на покупные изделия поднялись в среднем на 1,2%; так проект, не успев начаться, уже потерял часть прибыли.

Я не претендую на сногсшибательное открытие, эти истины и так лежат на поверхности, но оценить все статьи проекта численно для каждого отдельно взятого проекта — это достижение (рис. 6).

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

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

Автор — сотрудник фирмы ПРОСОФТ
Телефон: (495) 234-0636
E-mail: karpov.v@prosoft.ru