Дмитрий Лукьянов

"Т": Расскажите о процессах управления проектами (УП). Какие инструменты и методики Вы используете в обучении?

Если исходить из того, что проект – это временное предприятие для создания уникальных продуктов, и услуг, то становится понятно, что главное – это уникальность прежде всего замысла, и на ранних стадиях создания плана проекта, а также при разработке самой идеи, присутствует много креативности и элементов творчества. Вот дальше – переходя уже к выполнению проекта, все становися гораздо более "суше" и "стандартней". Для УП существуют достаточно жесткие рамки стандартов, прежде всего это свод знаний по УП – Project Management Body of Knowledge (PMBOK), стандарт американского Project Management Institute, а также сборник требований к компетенциям проектных менеджеров Международной Ассоциации Управления Проектами (IPMA ICB). Во время работы с клиентами, мы используем различные подходы, и, в первую очередь, учим думать "правильно" с точки зрения умения ставить нужные вопросы и систематизировать ответы на них, и учим прежде всего, делать это без помощи компьютера. В УП есть четкая пошаговая процедура планирования через девять областей знаний стандартов: управление интеграцией, содержанием, временем, стоимостью, качеством, людьми, коммуникациями, рисками и контрактами. Во время мозгового штурма мы используем технику, которая в дальнейшем, позволяет участникам тренинга работать без модератора – команда проходит стадию генерирования идей, после чего переходит к обсуждению этих идей, а после формализует и структурирует "сухой остаток" сессии – так рождается первое самое общее изложение содержания проекта, с которым в дальнейшем и идет вся остальная работа по более детальному планированию. По управлению рисками, применяем метод "карточек Кроуфорда" (этот метод уже требует модератора). Иногда, вначале тренинга группу бывает сложно "раскачать", но после – участников сложно остановить.

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

"Т": В одном из своих тренингов Вы рассказываете о модели технологической зрелости предприятия. Насколько важна такая модель в области УП для организации?

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

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

"Т": Какие функции возлагаются на проектных менеджеров?

Проектные менеджеры отвечают за достижение цели проектов в компании. Шутя, их можно назвать "Хоттабычами". Проектному менеджеру необходимо представить план проекта с запросом на ресурсное обеспечение, взять ответственность за его выполнение и соответственно, свершить "чудо" - чтобы все в проекте произошло вовремя, в рамках утвержденного бюджета, в соответствии с ожидаемыми параметрами содержания и качества. Например, если взять ролевую модель Международной Ассоциации Управления Проектами, то там присутствует четыре уровня ответственности проектного менеджера. На первом уровне, ответственность за "чудо" несет директор проекта (уровень А). Он, как правило, появляется на крупных комплексных проектах, и в его полномочия входит управление совокупностью подпроектов, являющихся частью крупного проекта или управление целиком программой проектов, которые ведет организация. На втором уровне - ведущий менеджер проекта (уровень В), который отвечает либо за то или иное направление деятельности, либо за ведение комплексного проекта внутри компании, либо за ее клиентов, либо за программу однотипных проектов. На следующем уровне находится менеджер проекта, который выполняет небольшой подпроект большого проекта, или стандартный проект (фактически именно тот, кто реально все и выполняет). Последний уровень – уровень D - замыкает так называемый ассистент менеджера проекта. В целом менеджером проекта является человек, который, получая полное задание, выполняет действия с декомпозицией задач и распределяя ответственность за их выполнение, впоследствии интегрируя сбор результатов в единый результат проекта.

"Т": Какие наиболее распространенные ошибки допускаются области УП и как с ними бороться?

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

Если в организации нет стратегии, она становится подобна электрической мясорубке, которая настолько быстро преобразовывает входы в выходы, что не успеваешь остановиться. И когда нет стратегического плана развития, и понимания того, что действительно нужно компании, возникает большая вероятность быстро отпилить себе палец, то есть быстро выполнить ненужную работу. Еже существует "Главный миф" проектного управления – это то, что программное обеспечение нам поможет. Вначале должна быть методология, а уже после программное обеспечение. Те, кто поставил ПО на первое место, часто вынуждены заходить "на второй круг", а поднять людей в организации на повторное внедрение однажды провалившейся технологии бывает очень сложно.

"Т": Но говорят, что в условиях современного бизнеса без программного обеспечения управление проектами невозможно. Так ли это?

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

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

"Т": Но все же если брать программное обеспечение, то какую бы программу Вы посоветовали использовать?

Это зависит от того кто, где, на каком уровне и для каких целей использует программу. Например, такой "монстр", как Primavera реализует все возможные функции проектного управления. Но далеко не всегда возникает потребность в использовании подобного программного обеспечения, а также не все умеют этим пользоваться. Если говорить о более доступных средствах, то среди них безусловно лидирует Microsoft Project, как интуитивно понятное и распространенное средство, чтобы заняться сетевым планированием. Вообще, в мире насчитывается несколько сотен программных продуктов с более-менее однотипными функциями. Но, самое главное, что "тормозит" развитие проекта, это нечеткие коммуникации и невозможность вовремя передавать результаты своего труда от одного участника проекта к другому. Важно иметь скорее хорошую систему документооборота, учета и контроля распоряжений, который включает в себя участников проекта, а саму модель проекта иметь и работать с нею в "штабе" проекта – проектном офисе..

"Т": Какие перспективы развития рынка УП Вы видите в ближайшем будущем?

Если оценивать этот рынок по косвенным показателям (количество специалистов, проходящим в год специализированное обучение и сертификацию), то он является недостаточно развитым. Также на сегодня в Украине есть крайне мало провайдеров обучения, которые действительно готовят проектных менеджеров по международным стандартам УП. В тоже время потребность в сертифицированных специалистах велика. Большое количество специалистов, владея определенным набором компетенций, называют себя проектными менеджерами. Но, к сожалению, "сухих" знаний иногда бывает недостаточно. Важно не только иметь определенный набор компетенций и понимать суть международных стандартов, но и применять это на практике. И системы сертификации проектных менеджеров сегодня все больше и больше учитывают именно практический опыт и успешность проектного менеджера, а некоторые системы сертификации построены исключительно на этом!

"Т": Какие основные типы задач Вам приходится решать в рамках проектов, реализуемых для заказчиков?

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

"Т": Назовите наиболее сложные и интересные проекты в Вашей практике?

В УП осмысленно я попал в 1999 году. Тогда я работал в белоруско-британском предприятии СП "БелАВМ" – тогда, пожалуй это был крупнейший системный интегратор Республики Беларусь. В то время я возглавлял техническое подразделение – руководил проектами, связанными с созданием сетей передачи данных, локальных вычислительных сетей и установке сетевого оборудования. Количество контрактов, которые подписали наши менеджеры по продажам в преддверии наступления "проблемы 2000-года" – известной как Y2K, перевалило все мыслимые пределы. В том числе было задание в сжатые сроки подготовить технически новое здание, в которое переезжало главное подразделение "Белорусь-Банка". Тогда пришлось из своих сотрудников делать "офицерский полк", который был "приставлен" к субподрядчикам. Это был крупный, но не такой уж и комплексный проект, каким он мне казался тогда. Еще один интересный проект - запуск нового Интернет-провайдера в Минске, который существует и сегодня. Цели были амбициозные - сделать провайдера номер 1 в Белоруссии. И сегодня это крупнейший коммерческий интернет-провайдер в стране – "Атлант-Телеком". С этим проектом я связан до сих пор, провожу стратегические сессии, моделирую сессии по разработке проектов. Я запускал крупнейшие автоцентры в разных городах и странах – мой вклад был в построении ИТ-инфраструктуры новых предприятий и интеграции в единую систему управления холдинговй компании, которая ими владела и управляла. Запускал крупнейшие на тот момент автоцентры Фольксваген в Восточной Европе - в Белоруссии, Украине, России. Также был такой проект, как крупнейший автоцентр компании Дженерал-моторс в СНГ – "Атлант-М Балтика" в Петербурге. Но самый сложный и интересный проект – как всегда – впереди.