При взаимодействии заказчиков и подрядчиков в работе над ИТ­проектами возникает немало трудностей и подводных камней. Об особенностях управления проектами этого типа и о наиболее характерных проблемах рассказывает Дмитрий Фомичев, заместитель генерального директора компании «Оптима­интеграция».

Intelligent Enterprise: Давайте начнём разговор с организации предпроектных работ. Как правило, именно на этом этапе выясняются особенности проекта, а также его временны’е и финансовые рамки. С какими проблемами вы сталкивались в ходе подготовки к проектированию?

Дмитрий Фомичев: Основная и наиболее часто встречающаяся проблема — это непонимание со стороны заказчика, чего же он хочет на самом деле. То есть стоит некая задача, которую по его мнению можно решить внедрением системы автоматизации. Но при этом совершенно ничего не говорится о промежуточных целях. А это особенно важно в крупных и сложных проектах. Например, если предполагается, что создаваемая система автоматизации будет эксплуатироваться несколькими службами заказчика, то в идеальном варианте было бы неплохо уточнить, какие выгоды от внедрения должна получить каждая из этих служб. Немаловажно также знать, будет ли новое решение интегрировано с уже установленными системами, и если да, то на каком уровне. Иными словами, основная цель проекта должна быть максимально детализирована, конечно же в разумной степени. Главное на этом этапе — как можно точнее определить предмет работ.

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

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

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

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

Кто и как работает на этапе обследования? В каких случаях создаются опросные листы, а в каких проводятся интервью с группой специалистов заказчика?

Самый простой и надежный способ провести предпроектное обследование — это съездить на объект и осмотреть будущую площадку автоматизации своими глазами. Другой весьма распространенный способ — анкетирование заказчика и заполнение соответствующих опросных листов. При этом крайне желательно побеседовать как с руководителями компании, так и со специалистами более низкого уровня — зачастую их ви’дение задач проекта существенно различается.

Решение, на каком способе остановиться, зависит от специфики проекта и от принципов работы ИТ­компании. Мы уже почти три года работаем с СО­ЦДУ ЕЭС по реконструкции региональных диспетчерских управлений. За это время выполнили 16 похожих друг на друга проектов. В такой ситуации было бы неправильно каждый раз выезжать на объект и проводить там обследование, так что здесь уместно воспользоваться анкетированием. Этот же способ придется использовать при внедрении системы автоматизации на режимных объектах, например на АЭС, куда доступ посторонним лицам строго ограничен.

А вот если заказчик планирует серьезные изменения в инфраструктуре, то без личного присутствия на объекте не обойтись. Например, в рамках создания резервного ЦОДа на «Сильвините» сильно менялась сетевая инфраструктура предприятия. Поэтому нами было проведено объемное обследование, на которое в общей сложности ушло примерно полгода. Причём мы постарались обеспечить постоянное присутствие наших специалистов на объекте.

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

Как в условиях задействованности людей в других проектах формируется рабочая группа? И как при этом решаются проблемы разделения ресурсов — времени, специалистов, оборудования?

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

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

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

Часто весь процесс проектирования разбивается на несколько этапов; тем самым получается календарный план­график проекта, фиксируемый документально. Во всех ли случаях это необходимо и что может этому препятствовать?

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

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

Используете ли вы формальные методики планирования проектов и управления их реализацией, и если да, то на каком этапе и какие (скажем, «планирование работ по методу критического пути» или его модификации)?

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

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

Насколько формализовано создание проектной документации? Готовится ли документация и в ходе проектирования, какая и в каком формате?

Проектная документация обязана быть формализованной, поскольку это официальный документ, регламентирующий все работы. Она обязательно нами готовится и соответствует как минимум двум сериям ГОСТ: 21­й — ГОСТ на системы проектной документации в строительстве и 34­й — ГОСТ на автоматизированные системы.

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

Как ведётся управление субподрядчиками в проекте и какие при этом возникают проблемы?

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

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

Как контролируется исполнение графика? Проводится ли корректировка проектирования или проекта и сколько итераций она обычно занимает?

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

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

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

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

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