Управление проектами продолжает оставаться проблемной зоной. Их число и сложность постоянно увеличиваются. Казалось бы, за 10–15 лет развития ИТ-рынка в России должен был накопиться опыт, определенные практики в этой сфере. Но, к сожалению, пока этого не произошло. Возможно, потому, что реальная работа по проектному управлению лишь начинается. Более «зрелые» виды деятельности, прежде всего поставки оборудования, практически ни у кого из клиентов особых нареканий не вызывают. Самое распространенное мнение о них звучит уже весьма оптимистично: «Да какие проблемы, закажешь — привезут». С проектами дело обстоит совсем иначе.

Аноним 1 (ИТ-директор крупного металлургического холдинга): «Уровень проектного управления подрядчиков в большинстве случаев оставляет желать много лучшего. Есть компании, которые вполне адекватно к этому подходят, но большей частью ситуация иная. Подрядчики вроде бы следуют стандартной проектной методологии, но реально ситуацией на проекте они не владеют.

Алексей Герасимов, экс-CIO банка «Юникредит», а ныне его исполнительный директор, директор департамента банковских операций: «Я в банковских ИТ с 1994 г. Мне кажется, в проектном управлении ничего не меняется. Подрядчики пытаются что-то улучшить, выстраивают какие-то процессы, назначают аккаунт-менеджеров, читают PMBoK. Но прогресса особого не видно».

Марат Хайретдинов, вице-президент и директор департамента ИТ «Еврофинанс Моснарбанка» (Москва), и Юрий Тарасов, CIO угледобывающего холдинга «Белон» (Новосибирск), оценивают уровень зрелости подрядчиков как весьма низкий. Юрий Тарасов: «К сожалению, положительно опыт ведения проектов я оценить не могу: по пятибалльной системе это между 2 и 3, ближе к 3». Многие заказчики оценивают свой уровень управления проектами как более высокий по сравнению с подрядчиками. Юрий Тарасов: «Если сравнивать уровень подготовки наших специалистов и исполнителей, то должен констатировать, что наш уровень выше, ведь управление проектами осуществляется по нашей методике». Количественных данных нет, но судя по неформальному общению с ИТ-руководителями, это мнение многие разделяют и такая ситуация весьма распространена.

Сами подрядчики, естественно, видят положение дел иначе.

Игорь Рудый, директор управления программами проектов OXS (ГК «Оптима»): «Уровень управления растет прямо пропорционально общему количеству завершенных проектов в сфере ИТ. Разброс уровня зрелости в различных компаниях еще достаточно велик, но случаи, когда со стороны клиента в проекте участвуют не менее опытные руководители проектов (РП), чем со стороны исполнителя, уже не редкость. И это радует».

Владимир Мелдов, директор по качеству «Корус Консалтинг»: «Уровень зрелости нашей компании в области управления проектами выше уровня большинства клиентов: у нас большая проектная практика, это наш основной бизнес. Клиент не может учить нас управлять проектами, даже если он имеет более высокую квалификацию. Тогда, скорее всего, он бы нашел другого подрядчика».

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

Елена Новикова, генеральный директор группы компаний Polymedia: «Наша компания прошла долгий путь понимания, что такое системная интеграция и управление проектами. Интеграционное направление мы открыли восемь лет назад, три года назад получили ISO 9001, но по-прежнему активно обсуждаем на внутренних совещаниях, как вести проект, как должны распределяться роли между его участниками, то есть постоянно учимся. Уровень заказчиков разный, начиная от таких, которым бессмысленно даже говорить, что такое управление проектами, и заканчивая теми, у которых есть чему поучиться, — но таких немного».

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

Аноним 2 (ИТ-директор крупной сети розничных магазинов): «Мелкие проекты я не беру — их успех полностью зависит от профессиональных возможностей интегратора. Например, открытие магазина в Барнауле. Небольшая задача, где необходимо комплексное решение. Здесь имеет значение подход подрядчика к управлению проектами, выстроенность процессов интегратора, отлаженность его логистики. В крупных же проектах кроме профессионализма, в котором на таком уровне уже нет особых сомнений, значительно большую роль играют субьективные ощущения, взаимопонимание менеджеров заказчика и подрядчика.

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

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

Может быть и обратная ситуация, когда заказчик ориентирован на четкий проектный подход и требует того же от подрядчика, а тот отвечает: «Да зачем это все? Я и так все вам сделаю, как скажете». Вот на это несовпадение подходов, взглядов, как правило, тратятся время и силы. Нужно перейти в одну плоскость, на один уровень понимания, только тогда пойдет работа. Уровень этого понимания у всех разный. Если встречаются бизнес и подрядчик, которые сразу разговаривают на одном языке, все равно на каком, формальные вопросы решаются очень быстро и можно сразу переходить к делу. Уровень зрелости бизнес-процессов партнеров — вот что играет важную роль».

Мнения о том, насколько стоит опираться на формальности, а насколько — на сложившиеся отношения, различаются тоже весьма заметно.

Марат Хайретдинов: «Мне кажется, нужно нормально выстраивать отношения с партнерами, личные в том числе, тогда можешь решать вопросы неформально. Договоры, штрафные санкции — это все деструктивно. Это все равно что жениться и брачный договор подписывать. Кому-то это близко, а мне нет. Хочется верить своим партнерам, доверять. Купцы российские тоже ведь на слово верили, правда? Даже когда все идет очень плохо, мы пытаемся взаимодействовать с подрядчиком, что-то менять. У нас были такие случаи, когда со сроками у исполнителя были очень серьезные проблемы. Мы били в колокола, встречались с первыми лицами этих фирм, иногда период поиска общего языка был довольно долгим, но есть примеры, когда после этого подрядчики начинают работать более-менее адекватно. Процесс борьбы за качество, конечно, непрерывный, но результаты есть».

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

Вадим Полещиков, начальник управления информационных технологий Газинвестбанка (Москва): «Бюрократия — одно из величайших изобретений человечества. Формализация отношений, договоренностей крайне важна. Она позволяет снять массу проблем и в ходе проекта, и при последующей поддержке решения. Для нас очень важно документирование проекта, но не ради проформы. Если можно что-то пропустить, отклониться от требований методологии, — мы это делаем со спокойной душой, если уверены в подрядчике и знаем, что можно без вреда для дела так поступить.

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

Аноним 1: «В нашем департаменте много сотрудников с консалтинговым прошлым, включая меня самого. С технологией проектного управления мы были знакомы и привнесли ее в каждодневную жизнь компании. Причем проектный подход у нас строго формализован. Устав проекта, статусы, планы-графики — все выложено в сети, все можно смотреть. Это общая дисциплина работы, которую мы внедряем в коллективе. При этом от сотрудников требуется систематическое заполнение отчетных форм, которые мы тщательно анализируем. Это вроде бы несложно, но дает значительный эффект. От подрядчиков мы требуем следовать этой же методологии. И вот что удивительно: обычно они говорят: «Вы первые, кто требует этого, обычно наш подход оказывается более упорядоченным и строгим, чем подход клиентов».

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

«Языковая» проблема тесно связана с другой — методологической, а из нее вытекают и недостатки планирования.

Аноним 1: «Огорчает низкий уровень проектного управления, отсутствие практического опыта применения подрядчиками проектной методологии. При планировании никто не идет «от обратного», знание носит весьма «вероятностный» характер. «Будет поставка?» — «Наверное, будет. Рано или поздно» — такой чаще всего получаем расплывчатый ответ. Но проект надо завершить к определенному сроку. Отступая от этой даты назад, надо четко определить, когда нужно заключать контракт, когда размещать заказ на поставку техники, и все прочее. Есть подрядчики, к которым у нас вообще нет претензий по качеству работы, все отлично. Но сроки срываются всегда. Почему так? Просто плохо планируют».

Юрий Тарасов: «Понимания менеджерами, как организовать планирование, как организовать эффективную систему мониторинга реализации проекта и прочее, практически нет. В лучшем случае кто-либо из менеджеров знаком с PMBoK, но конкретно из них никто не применял его рекомендации на практике».

Игорь Рудый: «Большинство компаний, профессионально занимающихся выполнением проектов, разрабатывают свои процедуры и правила управления проектами, естественно, в большинстве случаев, с использованием рекомендаций PMBoK. По-другому и быть не может, проекты разные, различаются стиль управления, менталитет компаний и т. п. Все это обязано отразиться на управлении проектами.

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

Не умеешь — научим

Даниил Динцис, руководитель направления систем ДО и сертификации Центра компьютерного обучения «Специалист» при МГТУ им. Н.Э. Баумана, имеет семилетний практический опыт управления проектами и программами в сфере ИТ, сертификацию PM2005 университета Velociteach, кандидат наук по специальности «Управление в технических системах»: «Курсы по управлению проектами в ЦКО «Специалист» основаны на методологии PMBoK (Project Management Body of Knowledge) от PMI и IT Project Management, а также CompTIA. Подготовку по PMBoK проходят представители различных отраслей: строительство, телекоммуникации, государственные проектные организации и институты, ИТ-компании. На курсах по IT Project Management занимаются только представители ИТ, из них примерно треть — из ИТ-фирм. Уровень подготовки слушателей варьируется от опытных управленцев, которым необходимо структурировать свой богатый опыт, до новичков, осваивающих «азы». Такие слушатели прекрасно уживаются в одной группе и взаимно обогащают друг друга.

Количество обучающихся заметно растет. Если два года назад в группе было обычно 3–5 человек, то сейчас стабильно 10–12. Количество групп увеличилось примерно в 2 раза».

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

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

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

Управление людьми и передача знаний

Очень распространенная претензия к подрядчикам: нет передачи знаний внутри компании от одного менеджера проекта к другому ни в рамках одного проекта, ни от проекта к проекту с одним и тем же заказчиком. Юрий Тарасов: «Практически ни у кого из исполнителей нет ни методики передачи знаний, ни обмена опытом, ни наставничества. Поэтому велики потери времени, если произошла смена менеджера. Чтобы хоть как-то подстраховаться, мы в договор включаем пункт, по которому утвержденная нами команда (и менеджер в т. ч.) исполнителя не должна меняться до конца проекта».

Алексей Герасимов: «Конечно, нужно больше проектных менеджеров с опытом, но откуда подрядчики их возьмут? ИТ-фирмы очень плохо передают опыт внутри своей организации. Вот ведет человек проект. Через некоторое время, если он хороший специалист, он оказывается либо в банке, на стороне клиента, либо топ-менеджером ИТ-компании, и сам лично уже проектами не занимается. Вместо него приходят другие люди, но его опыт им не передается.

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

Вадим Полещиков: «Мы сверхъестественных требований к подрядчикам не предъявляем, но то, что нам положено, возьмем. Были случаи, когда с одной и той же фирмой один проект проходит «на ура», все довольны, следующий — совершенно провальный, в основном в результате смены менеджера со стороны исполнителя. Однако, так как у нас была уверенность в компетенции компании, удалось наладить отношения, и новый проект оказался удачным.

У подрядчиков высока текучесть кадров, и во многом поэтому знания внутри компании не передаются или передаются очень плохо. Отдельная проблема — внутренняя конкуренция. Подразделения подрядчика конкурируют между собой за клиентов и за внутренние ресурсы. Поэтому более 60% успеха проекта зависит от личности проджект-менеджера, от его умения обеспечить ресурсы, привлечь нужного инженера».

Юрий Саламонов: «Смена менеджера — это как минимум задержка в проекте. Пройдет время, пока он научится общаться с нами. Почти всегда это новое притирание, становление отношений. Каждый менеджер, приезжающий на проект, пытается вначале мыслить категориями формальных договоренностей. Он не хочет заниматься задачами прошедших этапов — ведь они уже закрыты. А как же о них не думать, если их результаты неизбежно повлияют на то, что делается сейчас? Это нужно непременно учитывать.

Со сменой консультантов и программистов подрядчика получается еще хуже. Новый исполнитель меняет код, не зная, как это повлияет на другие модули, и иногда вызывает этим совершенно непредсказуемые ситуации. Может быть, у них и есть какое-то общее архитектурное описание, но кто же в него полезет? Если у кодировщика есть два дня на поставленную задачу, он решает ее, как может, и обычно решает хорошо, но чтобы разобраться с документацией, со связями с другими блоками и приложениями, ему нужно дать месяца два, но об этом, конечно, и речи быть не может. И это плохо. Если бы разработчик не менялся, он помнил бы сам о тех связях, которые есть в системе, и не наносил бы вреда изменениями. Поэтому текучесть кадров консалтинговых компаний — больное место. Нам в большинстве случаев везло: удавалось провести проект не более чем с двумя менеджерами и только с одной передачей дел.

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

Подрядчики утверждают, что передачей знаний озабочены и адекватные методы применяют. Борис Полухин: «Знания и опыт в области управления проектами в рамках одного проекта (при наличии нескольких менеджеров) передаются путем оформления и доведения до менеджеров протоколов и резюме встреч, а также путем проведения личных встреч или совещаний. От проекта к проекту знания передаются в основном путем оформления итоговых отчетов и обеспечения доступов к ним. Кроме того, проектный опыт обобщается и распространяется на специальных обучающих тренингах и конференциях менеджеров». Игорь Рудый: «Если речь идет о передаче знаний в короткий промежуток времени при смене РП, то для того чтобы такая смена произошла безболезненно, информация о ходе проекта накапливается, систематизируется и подробно документируется. Задача преемственности опыта и передачи знаний может быть решена и при участии такой структуры, как проектный офис, где не только аккумулируется вся информация о проекте и проектная документация, но и формируется база знаний компании по всем реализованным проектам». Владимир Мелдов: «Для передачи знаний используются все известные и доступные средства. В ходе проекта: проектная документация (техническая и организационно-распорядительная) и личное взаимодействие, база данных системы управления проектами, записи по качеству. От проекта к проекту добавляется архив проектной документации, типовые проектные решения, встречи менеджеров по обмену опытом, курсы обучения.

Постановка формальных требований

Возможно, и единства языка, и общего понимания методологии можно было бы добиться, сразу выбирая «правильного» партнера. Но как это сделать эффективно? Может быть, помогут формальные требования, сертификации? Похоже, вряд ли.

Аноним 1: «Сертификация подрядчиков для нас не важна, ведь чаще всего сертификация по ISO делается легко и для галочки. Значительно важней методология, которую приносит исполнитель. Конечно, полностью быть уверенным в его квалификации, не начав работать, сложно, но многое говорит предварительное общение, те документы, которые уже имеются у подрядчика, его предыдущий опыт. В любом случае цена сама по себе для нас не является критерием принятия решения. Критерием является соотношение «качество/стоимость».

Марат Хайретдинов: «Сертификации, такие как ISO, CMMI, — не совсем ерунда, но часто это делается формально. Тогда в этом нет смысла. Важнее то, насколько доволен клиент твоей работой». Но есть и другое мнение.

Аноним 2: «Прямо поставить «уровень зрелости процессов» в условиях тендера нереально. Этот параметр плохо поддается простой численной оценке и проверке. Но чем точнее сформулированы не только сами задачи, но и подход к ее решению, требования к процедурам, причем уже на этапе RFP, на этапе коммерческих предложений, тем больше шансов выбрать подходящих, понимающих исполнителей. Можно прямо указать методики, согласно которым будет вестись проект. Нужно максимально детально отражать видение компании с самого начала, это может помочь избегать недоразумений. Тогда шанс увидеть среди участников конкурса больше единомышленников станет выше. А дальше это вопрос переговоров и максимальной формализации описания форм работы на этапе заключения контракта».

Юрий Тарасов: «К сожалению, оценить опыт проектной деятельности исполнителя зачастую очень сложно, даже если обратиться к заказчикам уже реализованных проектов, т. к. у каждого заказчика разное понимание стандартов управления и разные ожидания. Мы ставим и для себя, и для исполнителей достаточно высокие планки и используем следующую методику по оценке специалистов исполнителя (и не только по компетенции проектного управления, а и по знанию предметной области):

  1. Изучение резюме всех специалистов проектной группы и собеседование с отобранными кандидатами.
  2. Методики ведения проектов исполнителем.
  3. Наличие базы знаний (материалов, шаблонов, нормативов и пр.).

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

Игорь Рудый: «Как правило, клиенты просят представить руководителя проектов или же организовать референс-визит на предприятия, где компания выполнила аналогичные проекты. Я считаю более эффективным второй способ. Нельзя сказать, что от людей ничего не зависит, но люди могут меняться. Ориентироваться, по-моему, надо на экспертизу компании в целом, на оценки клиентов».

Владимир Мелдов: «Чем ответственнее и профессиональнее организация тендера, тем большее внимание уделяется каждому аспекту, не только вопросам управления проектом. Успешность подрядчика косвенно определяется историей успеха».

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

Немного статистики

Очередное, третье исследование «Практика применения ИТ на российских предприятиях» журнала Intelligent Enterprise, проведенное летом 2008 г., дало интересные результаты в области постановки проектного управления. В исследовании приняло участие около 150 ИТ-директоров российских компаний различного размера и отраслевой принадлежности.

Ответы на вопрос: «Удовлетворены ли вы текущим уровнем автоматизации нижеприведенных бизнес-процессов и собираетесь ли развивать ИТ-решение их поддержки в ближайшие 2–3 года?» — показывают весьма низкий уровень удовлетворенности (см. рис.). Удовлетворены имеющимися средствами только 14% опрошенных, и примечательно, что почти у трети нет планов развития. Хотя уровень организации проектного управления не связан прямо и непосредственно с качеством автоматизации этой деятельности, но косвенная связь все же есть.

Управление проектами в двух третях опрошенных компаний автоматизировано на основе Microsoft Project, одновременно другие продукты того же вендора для этих целей используют 40%.

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

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

Если нельзя решить вопросы формально, то как быть?

Марат Хайретдинов: «Формализация доверительному подходу не помеха. Я знаю достаточно много случаев, когда в договоре написано одно, на деле происходит другое, и ни одна сторона не предъявляет претензий. Наверно, если доходит до совсем уж серьезных осложнений, тогда надо судиться, но в моей практике такого, слава богу, не было. У тебя всегда должен быть запасной парашют, но лучше, чтобы им пользоваться не пришлось. Заказчик должен так строить отношения с партнером, чтобы тот чувствовал — если он начнет валять дурака, на него есть управа».

Итак, главные причины низкого уровня проектного управления в компаниях-исполнителях заключаются в следующем, считает Юрий Тарасов:

  1. Отсутствие эффективного, отработанного на различных проектах стандарта управления, который можно было бы применять не только внутри компании-исполнителя, но и совместной рабочей командой, т. е. и на стороне заказчика.
  2. Отсутствие базы знаний по проектам, приемлемой для последующего использования на других проектах (следствие первого обстоятельства).
  3. Поверхностный подход к формированию проектной команды и выбору менеджера проекта со стороны исполнителя. Как правило, специалисты исполнителя (которых назвали менеджерами проектов) не имеют представления, как управлять людскими ресурсами, как эффективно распределить роли и пр. Все сводится к предметной области, т. е. менеджер проекта — специалист, более технически продвинутый в вопросах автоматизации.

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

А пока действует еще одно, без преувеличения — фундаментальное, обстоятельство, о котором говорит Марат Хайретдинов: «В основном мы выбираем подрядчиков внедрения банковских продуктов по тому, какие системы они нам предлагают. Если мы выбрали систему ЦФТ, «Диасофт», мы вынуждены мириться с тем уровнем зрелости, который есть у этих компаний. Хочется надеяться, что он будет расти от года к году. «Диасофт», например, что-то меняет в области управления проектами. Я даже заметил определенные улучшения в их работе, прогресс есть».

Хайретдинов подчеркивает: чаще всего смена подрядчика означает и смену каких-то систем, оборудования, чего, конечно, хочется избежать. «В целом мы очень зависимы от решений и тех, кто их обслуживает, — говорит он. — Если нам для хранилища данных нужна какая-то информация для подготовки налоговой отчетности из определенной системы, а система эта закрытая, то у нас есть два варианта. Либо заменить систему на другую, а вместе с ней и подрядчиков, года полтора ее внедрять и в дальнейшем использовать из нее данные, либо пойти на компромисс и добиться от исполнителей выгрузки всех нужных данных из этой системы».

Что делать?

Юрий Саламонов: «Снижение рисков возможно за счет предварительного анализа, изучения технологии, максимального сужения области, где действительно необходимы консультанты.

Например, начальный этап внедрения ERP у нас делали консультанты БДО «Юникон Консалтинг». На этапе автоматизации финансов и первой фазы проекта управления производством тоже работали консультанты, но значительную часть доработок мы выполняли сами, а когда перешли к автоматизации всего основного производства, обходились только своими силами.

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

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

Необходимо организованно бороться с нехваткой кадров, причем с обеих сторон. Марат Хайретдинов подчеркивает: «Для бизнеса такая ситуация неприемлема: если мы зависим от разработчика, а он чего-то не делает, потому что у него ресурсов нет, то явно надо что-то менять, искать ресурсы. Это мешает развивать бизнес». Людей нужно не только искать, но и учить, и подрядчики стараются решить и эту проблему, правда, своими силами в основном. Владимир Мелдов: «Все менеджеры проходят внутреннюю аттестацию и обучение. Сертификация внешними органами поощряется, но необязательна. Компания организует и финансирует обучение перспективных менеджеров в наиболее авторитетных учебных заведениях». Борис Полухин: «Практически все проектные менеджеры «АйТи» проходили курсы и тренинги, но сертифицированных по международным стандартам менеджеров в компании немного. Такая сертификация нужна скорее для повышения «стоимости» менеджера при устройстве на работу. Компании это требуется лишь в особых случаях».

* * *

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

Хайретдинов четко формулирует точку зрения, разделяемую многими ИТ-директорами: «Подрядчик — как доктор, как мастер, как хороший слесарь, надо их найти и идти вместе по жизни. И прощать ошибки, ведь все мы люди».


Версия для печати (без изображений)