ЖУРНАЛ СТА 1/2009

Известно, что одному опытному спе циалисту достаточно нескольких дней, чтобы сделать такую систему диспет черского управления в объёме с пол сотни тегов. При очевидной простоте работы было принято решение напи сать графический интерфейс со слов и утвердить его у заказчика (пусть даже в несколько подходов). И началась работа. В это время нашего полку прибыло, и я решил, что данный проект — от личный шанс для новых сотрудников набраться опыта. Они прошли под готовку в учебном центре компании ПРОСОФТ по курсам GENESIS32 и применения ПЛК. Знаний, кото рые можно получить на этих курсах, вполне достаточно, чтобы сделать та кой проект. По нескольким причинам этот про ект рассматривался и как хороший шанс применить PMBOK ® . Во пер вых, проект небольшой и прозрач ный. Во вторых, он содержит риски, связанные с работой новых сотруд ников. В третьих, в нём проявляется явно выраженная в последнее время среди отечественных заказчиков тен денция нечётко формулировать тех ническое задание и стремиться к уточнению его в процессе работы над проектом. Итак, подойдём формально. Подго товим по порядку «Устав проекта», «Описание содержания проекта», «Ре естр рисков». В «Реестре рисков» опишем возмож ные риски и способы реагирования на них, срок их актуальности, стоимость устранения. Стандарт рекомендует предусмотреть максимально возмож ное количество рисков. Но тут нужно удержаться от паранойи и исключить риски типа «если небо упадёт на зем лю». В этом важном документе мы соз даём себе «подушку безопасности». На подготовку перечисленных доку ментов потрачено 4 часа. Это неболь шие, но очень полезные документы, которые достаточно глубоко описы вают разные аспекты проекта. Здесь были представлены цели, контактная информация всех участников проекта, ограничения и риски, детализированы задачи, собрана команда проекта и т.д. Для этого не надо быть семи пядей во лбу, просто нужно аккуратно перене сти всю имеющуюся информацию в уже готовые шаблоны документов. Ещё день ушёл на «План управле ния проектом». На этом этапе были подготовлены календарный и стоимо стной планы проекта, распределены участники проекта по задачам. Все эти документы составляют так называе мый базовый план. К нему нужно стре миться при выполнении проекта, с ним сравнивать действительное поло жение дел. Теперь можно легко посчитать стои мость с учётом разумной прибыли. Чтобы не промахнуться и случайно не взять лишних денег, предлагаю воспользоваться рекомендациями Минпрома России. Для этого сущест вует «Справочник базовых цен на разработку технической документа ции на автоматизированные системы управления технологическими процес сами (АСУ ТП)», разработанный НПЦ «ВНИПИ САУ 40» и ГП «ЦЕНТР ИНВЕСТпроект» Минстроя России. Произведённый расчёт по отечествен ному справочнику дал в моём случае разницу менее 10%, значит, расчёт про изведён верно. На этом этапе я склонен в большей степени доверять отечественному спра вочнику, так как оценка по стоимост ному плану сильно за висит от опыта авто ра, а справочник более объективен. Более того, если результаты расчёта стоимости по двум ме тодам серьезно различа ются, то рекомендую искать промах именно в стоимостном плане. Подготовим технико коммерческое предло жение и отправим. В моём случае ответ не за ставил себя долго ждать. Формально проект начинается с мо мента подписания договора. Взяли ти повой шаблон договора, заполнили пустые места и… Но не тут то было! Договор был запущен в долгий круг согласования. Хождение по кабинетам заняло у меня более 3 дней, и почти две недели ушло на различных согласо вателей. Ну, теперь, когда самое страшное позади, началась работа над проек том. Для ведения проекта существует множество бесплатных, как например OpenProj, и коммерческих программ (рис. 2). PMBOK ® предоставляет ряд удобных инструментов для контроля за ходом реализации проекта и за рас ходованием денежных средств, но в маленьком проекте полезны только не которые из них. Надо особо отметить качество подго товки специалистов в Учебном центре ПРОСОФТ. Буквально за неделю (бы стрее, чем ожидалось) все работы по созданию программного обеспечения ими были выполнены. Следовательно, риск использования «новобранцев» был оправдан и теперь может быть удалён из рассмотрения. Видеокадры пользовательского интерфейса были направлены на согласование. К концу следующей недели и за три дня до отгрузки мы получили от заказ чика одобрение вида пользовательско го интерфейса и первые изменения технического задания. Изменения в техническом задании коснулись как количества сигналов, так и их назва ния, разбиения на группы и даже функционального назначения. Столь масштабные изменения означали пол ную переделку написанного программ ного обеспечения. Таким образом, сработал один из пунктов «Реестра рисков», за ним сра зу же последовал второй — задержка поставки. Стало понятно, что сроки С ТАНДА Р Т ИЗАЦИЯ И С Е Р Т ИФИКАЦИЯ 81 СТА 1/2009 www.cta.ru Рис. 2. Так могут выглядеть календарный план и отображение текущего состояния проекта © СТА-ПРЕСС