itSMF Russia :: Ассоциации организаций и специалистов в сфере управления информационными технологиями «ИТ сервис-менеджмент форум» баннер
НОВОСТИ УЧАСТИЕ В АССОЦИАЦИИ ОБ АССОЦИАЦИИ БИБЛИОТЕКА СОБЫТИЯ ДЛЯ УЧАСТНИКОВ NEW ТРЕБУЮТСЯ СПЕЦИАЛИСТЫ БЛОГИ NEW НАБЛЮДАТЕЛЬНЫЙ СОВЕТ

 

поделиться

Присоединиться к ITSM сообществу


Состав itSMF Russia


баннер

 

 


книжный магазин itSMF



Подпишитесь на новости ITSM-сообщества

* обязательные поля
Архив рассылок >>>



facebook linkedin баннер twitter



Реестр аккредитованных учебных центров, работающих в Российской Федерации и имеющих право проводить обучение по утвержденному списку курсов ITIL®


Manager’s Certificate in IT Service Management Список ITIL Expert'ов и сервис-менеджеров России и стран СНГ



Список российских профессионалов сервис-менеджмента, обладателей сертификатов priSM




Работа для Вас: актуальные вакансии


Управление ИТ-проектами: а как правильно?
Untitled Document

Опубликовано 15.02.2010
Солопов Павел

Сергей Хайрук
11.02.2010 13:03

Крупные ИТ-проекты, как, впрочем, любая бизнес-деятельность, имеют две стороны – парадную, с победными реляциями пресс-служб, и кулуарную, не предназначенную для чужих глаз. Проекты не бывают гладкими, случаются ошибки, просчеты, но об этом публично говорить не принято. Мы задали практикующим специалистам несколько вопросов о том, каков нынешний уровень проектного управления в России, с их точки зрения. При этом рассчитывали, что особый формат нашего сообщества позволит экспертам высказываться более открыто, а читателю, в свою очередь, увидеть объективную картину.

Ответы получились совершенно разными, при этом кивать на российскую специфику специалисты не стали. «На мой взгляд, какой-либо особенной практики, присущей исключительно российским компаниям, попросту не существует – заявил Евгений Грибов, начальник отдела управления корпоративными проектами компании «Инфосистемы Джет». — В нашем случае уместнее говорить о методологии управления проектами в той или иной российской компании. Если такая методология существует, то в ее основе, как правило, лежат апробированные, общепризнанные стандарты и указания в области управления проектами. Другое дело, если корпоративная проектная методология отсутствует или, что наиболее часто встречается, не проработана или находится на этапе внедрения. Ровно в этом месте и начинается «специфическая» практика, однако называть ее отечественной, российской практикой нет ни каких оснований. В области управления проектами российскому менеджменту не хватает, прежде всего, зрелости».

Александр Зубрицкий, директор проектов копании ЛАНИТ, PMP, вице-президент московского отделения PMI, соглашается с коллегой. Большинство проектов выполняется компаниями с низшим уровнем проектной зрелости по стандарту OPM3. Сказывается и недостаток сертифицированных специалистов: «В нашей стране даже специальности «менеджер проекта» (или «руководитель проекта») нет. Проектом зачастую руководит специалист, который умеет решать технические задачи, но не имеет ни знаний, ни навыков управления. Такой специалист, как правило, не умеет управлять рисками, не может разработать бюджет проекта, мотивировать команду на достижение цели, делегировать полномочия и т. д., перечислять можно очень долго».

Интеграторы обращают внимание на «прижимистость» клиентов – отечественный заказчик предпочитает экономить на стадии предпроектной подготовки. Планирование, декомпозиция проекта, детальная оценка рисков – все это часто остается за скобками. «Поверхностное отношение к этапам инициации и планирования в будущем может привести к срыву сроков, увеличению бюджета, использованию дополнительных ресурсов, — предупреждает Роман Зейбот, заместитель директора департамента вычислительных систем компании КРОК. — В процессе проекта российский заказчик может потребовать изменения достигнутых ранее договоренностей, например, по времени завершения проекта. Нередко нас просят досрочно завершить проект к началу месяца, концу квартала или новому году. Еще одним «нашим» отличием, не всегда влияющим на проект позитивно, является политизация управления проектом. Помимо руководителя проекта, влияние на управление оказывает администрация заказчика, полномочная принимать соответствующие решения. Правилом российской действительности является упрямое нежелание применять на практике непререкаемый на западе постулат «plan-do-check-act».

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

Помимо сертифицированных специалистов, российскому проектному менеджменту не хватает единого подхода к стандартизации. «Большинство российских компаний знают о существовании международных ИТ-стандартов, методологий и моделей, таких как ITIL, PMBOK, CMMI, COBIT и др., и даже предпринимают попытки строить свою работу в соответствии с этими стандартами. Но далеко не каждая компания может реально продемонстрировать достигнутые результаты и показать экономическую эффективность их применения, — комментирует Станислав Калканов, руководитель центра качества компании Люксофт. Александр Зубицкий более категоричен – руководители проектов, которые должны, по идее, применять упомянутые методы и инструменты, часто даже не знают об их существовании: «Большинство наших менеджеров используют только один инструмент – «пинок ботинком» для ускорения работ».

С другой стороны, тот же PMBoK – это лишь набор кейсов, мешок, из которого при необходимости можно достать некое универсальное знание. Наверное, можно сказать, что своеобразный «локальный PMBoK» существует в каждой компании, накопившей собственный опыт старым добрым методом проб и ошибок. «У некоторых ИТ-компаний с устоявшейся технической культурой может в явном виде не декларироваться использование каких-либо стандартов управления проектами. Но опытные проектные команды, как правило, применяют некий адаптированный к их реальной практике «гибрид» из положений, распространенных в мире стандартов без ссылки на эти стандарты (например, подготовка иерархической структуры работ в каком-то виде присутствует во всех проектах, но при этом не называется WBS и не отсылает к стандарту PMBoK). Сейчас на практике широко используются их идеи PMBoK и ITIL, но они не рассматриваются как обязательные инструкции, а их положения и рекомендации в конкретных проектах используют в адаптированном виде», — отмечает Андрей Озеров, руководитель отдела управления проектами компании РДТЕХ.

Стоит ли в условиях «неявного» применения международных ИТ-стандартов что-либо менять? Нужен ли отрасли отечественный стандарт управления проектами? Здесь мнения наших экспертов разделились. Виктор Сдобнов, начальник отдела генподрядного управления департамента корпоративных информационных систем компании АйТи, сетует на недостаток внимания к этому вопросу со стороны государства: «Российскому управлению проектами не хватает опеки и покровительства федеральных структур (хотя бы одной). Международные стандарты применимы, но их надо «докручивать» под наш российский менталитет. Грамотный стандарт, «заточенный» на практическую реализацию способен значительно изменить ситуацию. Если в России смогли бы адаптировать стандарт Офиса управления проектами штата Нью-Йорк (изданный в октябре 2002 года) ему бы цены не было».

Очевидно, что стандарты, удовлетворяющие и подрядчика, и заказчика, способны снять множество противоречий, привнести единое видение проекта обеими сторонами. «Было бы крайне полезным наличие как общего подхода к выполнению проектов, так и общего подхода по оценке и выбору компаний-разработчиков, которые допускаются до участия в государственных тендерах, — отмечает Станислав Калканов. — В настоящее время мы периодически видим, как крупные государственные тендеры по разработке ИТ-систем выигрывают никому не известные компании, которые подобных проектов никогда не выполняли и совершенно не представляют, какие задачи им придется решать. Эти компании предлагают самую низкую цену и выигрывают тендер. Через год-полтора становится понятно, что бюджет потрачен, система сделана в лучшем случае наполовину, передать разработку системы другой компании крайне сложно из-за недостаточно качественной проектной документации. Но менять что-либо уже поздно, и либо проект начинается практически с самого начала, либо начинается внедрение недоделанной системы с последующей доделкой «на ходу» и возрастанием стоимости и сроков выполнения проекта в несколько раз. Во всем мире уже более четверти века применяются стандартизованные подходы по анализу и оценке компаний-разработчиков ПО. Самым известным и наиболее широко распространенным подходом в настоящее время является применение модели зрелости и качества CMMI. К сожалению, модель официально не переведена на русский язык, но ее перевод и использование даже в качестве неформального стандарта могло бы существенно повысить общую культуру выполнения ИТ-проектов, а создание на ее основе национального стандарта помогло бы вывести российскую индустрию разработки ПО на принципиально иной уровень».

Эксперты советуют не изобретать велосипед. Евгений Грибов: «Теоретическая база проектной деятельности, основанная на обобщении успешного опыта, достаточно детально изложена в различных руководствах к международным стандартам в области управления проектами. Стоит ли в нашем случае изобретать что-либо новое? Сомневаюсь. Сомневаюсь, что результатом труда будет некий «прорыв» или «откровение» в данной области. Полагаю, что более разумным приложением энергии будет деятельность, направленная на расширение применения на практике существующих методологий управления проектами».

Еще один фактор – уже упомянутая «скупость» клиента. «Заказчик часто не готов платить большие деньги за «пустой» документ, написанный в соответствии с требованиями, да и попросту подготовить такой документ в ряде случаев не позволяет специфика бизнеса заказчика – например, на этапе стартапов или постоянно меняющихся бизнес-процессов. Если же говорить об использовании ГОСТов при рассмотрении споров между заказчиком и исполнителем в суде, то тут тоже ничего кардинально не улучшится, поскольку, на мой взгляд, у многих сотрудников судебной системы зачастую просто не хватает специальных навыков и знаний для обстоятельного и грамотного рассмотрения дела», — пояснил Антон Шахлевич, руководитель практики Microsoft Dynamics компании «НОРБИТ»

Упомянутые ГОСТы – тема отдельная. Андрей Озеров, руководитель отдела управления проектами компании РДТЕХ: «Для подавляющего большинства «производственников» использование ГОСТ — это не «идея», а многолетняя и успешная практика. «Идея» была у тех, кто пытался и пытается отказаться от стандартизации и ГОСТ. Более того, ничего не мешает, взяв за основу ГОСТ, разработать и использовать, например, ведомственные стандарты или стандарты предприятия.

В соответствии с законом «О техническом регулировании» стандарты (кроме технических регламентов) теперь носят рекомендательный характер. Заказчик и исполнитель должны договариваться об их использовании. Идея стандартизации существовала и существует. Например, действует стандарт ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. СИСТЕМНАЯ ИНЖЕНЕРИЯ. Процессы жизненного цикла систем». В нем есть описание процессов проекта, как и в PMBoK, но терминология несколько другая. Выбор «как работать» осуществляется в каждом конкретном случае.

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

Безусловно, в пользу стандартов говорит уже тот факт, что наличие сертифицированных специалистов может рассматриваться как конкурентное преимущество компании. Конечно, при условии, что заказчик в состоянии это преимущество оценить. Важно, чтобы клиент и подрядчик говорили на одном языке, чтобы оценка управления проектом осуществлялась не по количеству отчетных встреч или затраченного руководством времени. Необходимы совсем иные критерии. Как правило, используются такие параметры, как достижение поставленных задач, использование бюджета, сроки. Александр Зубрицкий: «Встречаются заказчики, которых интересуют вопросы эффективности управления проектом. Но, в общей массе, их не так много. Правильнее было бы сказать: результат проекта – вот что волнует заказчика. А как этот результат будет достигнут – это проблемы подрядчика, которые мало волнуют заказчика».

Станислав Калканов подтверждает: «Для меня характерным критерием уровня зрелости отечественных заказчиков является то, что основными обсуждаемыми параметрами проектов, на которые обращают внимание заказчики, являются стоимость и сроки выполнения проекта. Существенно реже обсуждается уровень качества ИТ систем, их поддерживаемость и развиваемость, условия постпроектной поддержки и сопровождения. Практически никогда не обсуждается вопрос цены качества (cost of quality). Также для отечественного заказчика характерно отсутствие желания и практики в привлечении опытных консультантов, которые могли бы помочь в оценке эффективности выполнения ИТ-проектов».

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

Статья опубликована на
cio-world
Все права сохранены



Помогите своим коллегам быть в курсе интересных новостей! Поделитесь!
Документ без названия


 

Приглашаем принять участие
в воркшопе ITSM Labs
баннер


баннер


баннер


Партнеры itSMF России



 Директор информационной службы
 

Information Management

Открытые системы



Московское отделение ISACA

ABPMP Russian Chapter

GlobalCIO

СоДИТ

SPb CIO Club — партнер itSMF России

Высшая школа бизнес-информатики Государственного университета – Высшей школы экономики (ВШБИ)

МИИТ

ГУУ

Московский государственный университет экономики, статистики и информатики (МЭСИ)

Факультет ВМК МГУ имени М.В. Ломоносова

Московский институт электроники и математики (МИЭМ)

Институт информационных бизнес систем



Блоги: