Проектный менеджмент до сих пор является активно развивающейся дисциплиной корпоративного управления, чему способствует и сегодняшняя экономическая ситуация. В результате обсуждение многих практических нюансов в данной области представляется весьма актуальным, особенно когда мы говорим о компании, где проектный подход активно используется в различных направлениях, в том числе и при развитии ИТ-поддержки. Об этом мы беседуем с вице-президентом Deutsche Bank, руководителем направления Project Management в России Андреем Плужниковым.
Intelligent Enterprise: Насколько абсолютным или, наоборот, относительным можно считать термин «проектно ориентированная бизнес-компания»? Зависит ли сила акцента на проектной ориентации от отрасли бизнеса компании, от решаемых в настоящее время задач, от их масштаба, от стратегических приоритетов на тот или иной момент времени?
Андрей Плужников: Я не думаю, что есть однозначно верный ответ на этот вопрос. Вероятно, все явления в нашем мире носят как абсолютный, так и относительный характер. При этом я считаю, что природа бизнеса большинства компаний скорее лежит вне этих двойственных крайностей и способна принимать ту или иную форму в зависимости от специфики самого бизнеса, окружения компании, накопленного за время существования компании «бизнес-скарба». Чаще всего мы наблюдаем гибридные структуры: некоторые сбалансированы, некоторые — с ярко выраженным смещением фокуса в сторону проектного или процессного подхода к ведению бизнеса. Иными словами, насколько мы можем считать абсолютным термин «проектно ориентированный бизнес компании», настолько же мы его можем считать и относительным.
Однако важно понимать, что есть силы, которые подталкивают компанию двигаться в сторону проектно ориентированного бизнеса или же наоборот. Например, необходимость расширения бизнеса или же оптимизации текущего однозначно подталкивают компанию к проектному подходу. Скажем, некоторый банк решает расширить свою ритейл-сеть и двинуться из столицы в регионы. Хотя его сеть в столице и некоторых регионах, вероятно, уже сильно развита, освоение нового региона — задача определенно новая, уникальная, в чем-то рискованная. Компании, конечно же, потребуется проект, чтобы этот новый бизнес мог быть успешно запущен.
Другим примером может послужить некоторая компания, которая производит много ИТ-продуктов. В производстве задействовано значительное количество людей, которые приходят к десяти утра и уходят в семь вечера, честно отрабатывая свои зарплаты. Все бы ничего, да только никому не понятно, действительно ли разрабатываемые продукты приносят адекватную прибыль, развиваясь в правильном направлении, или большая часть персонала работает над низкоприоритетными продуктами/направлениями, некоторые из которых, вероятно, вообще можно остановить — и никто ничего не заметит. Более того, непонятно, что с качеством продуктов, как часто мы выпускаем нерабочий софт или же вообще не выпускаем по ряду объективных причин. В таком случае переход к проектно ориентированному бизнесу кажется очевидным. При этом сам переход должен осуществляться на проектной основе.
Я верю, что в условиях неблагоприятных экономических обстоятельств бизнес все больше и больше будет смотреть в сторону проектного подхода, поскольку этот подход отражает готовность к переменам и рискам, отражает готовность отвечать динамично растущим стандартам и требованиям к качеству. Не в последнюю очередь он отражает и необходимость делать выход продуктов на рынок предсказуемым и сокращать время этого выхода (time to market). Когда придется экономить и понимать, что каждый инвестированный доллар приносит компании прибыль, мы все чаще будем наблюдать проекты, направленные на оптимизацию самого бизнеса. думаю, что в ближайшее время понятие проектно ориентированного бизнеса будет принимать все более абсолютный характер.
Когда необходимо экономить ресурсы, все большее значение должна приобретать методика управления портфелем проектов. Ведь именно она призвана динамично и при этом оптимально распределять ресурсы между различными проектами. А значит, за счет ее использования предполагается достигать высокой эффективности в работе…
Это верно лишь отчасти. В известной мере PPM (Projects Portfolio Management) можно считать неким регулятором «тонкой настройки» эффективности, когда проектное управление у нас отлажено идеально или же очень близко к идеальному. При этом требуется смотреть на ситуацию «сверху» и с этой же позиции наблюдения ее контролировать. Однако на практике проблема проектного управления остро встает уже на нижнем уровне, то есть на уровне классического проектного менеджмента. Этот управленческий пласт сейчас во многих компаниях предельно упрощен, а зачастую и вовсе отсутствует. Некоторые компании совершают ошибку и фокусируются на PPM, не внедрив проектный подход на самом низком уровне, и это определяет неэффективность PPM. А объясняется это просто — PPM позволяет эффективно работать с бизнес-приоритетами и правильно распределять ресурсы, но неэффективность на самом низком уровне проектного управления не позволяет справляться с самим производством.
Хотелось бы понять, как вообще складывается культура проектного управления, откуда приходят в компании проектные методологии и на какой почве они в конце концов укореняются. Дисциплину Project Management не назовешь новой, но часто складывается впечатление, что, скажем, менеджер бизнес-проектов и сотрудник, ответственный за реализацию программной разработки, могут проповедовать несколько разную культуру проектного управления. А поскольку Deutsche Bank ведет в том числе и крупные программные разработки, этот вопрос хочется адресовать именно вам.
Не думаю, что буду оригинален, сказав, что проектная культура складывается под воздействием целого ряда факторов. Прежде всего потому, что проектные задачи бывают разными. В одном случае мы даже в нынешнем быстро меняющемся мире позволяем себе четко разделить проектные этапы анализа требований, постановки задачи, реализации и тестирования. Тогда мы можем применять водопадную (waterfall) модель управления проектом. И наоборот, в наших проектах, в ходе которых мы, например, создаем программное обеспечение для трейдеров, нам необходимо предельно гибко подходить к разработке, прислушиваясь к мнению заказчика ПО и пытаясь по возможности оперативно реализовать его требования в программном продукте. Причем даже если его пожелания поступают спонтанно, что в данном случае скорее нормально. Здесь явным образом становится востребованной небезызвестная agile-методология, основная цель которой — как раз возможность постоянно актуализировать требования заказчика в ходе выполнения проекта.
Что касается работы с вендорами, то в определенном смысле она проще, так как специфика их работы подразумевает проектную ориентацию и достаточно неплохую методологическую зрелость. Вендоры, работающие на ниве производства ПО, как правило, гибки и способны работать как по водопадной модели, так и следуя agile-методологиям. А интеграторы, конечно, более консервативны и менее гибки, что опять же объяснимо спецификой предоставляемого сервиса. Отчасти это связано с тем, что при внедрении готовых систем, опыт имплементации которых уже обобщен по результатам сотен или даже тысяч проектов, уже изначально сняты многие неопределенности, которые могут оказаться «сюрпризами» в проектах по разработке ПО. Но даже здесь кое-что меняется.
То, о чем вы сейчас сказали, может лишь послужить дополнительным стимулом для продолжения обсуждения заданного вопроса. Только что мы говорили о проектах разработки или внедрения ПО, употребляя такие термины, как waterfall и agile. Но есть основания полагать, что они произносятся только в кругу разработчиков ПО и почти не употребляются, когда бизнес-проекты не имеют значительной ИТ-составляющей. Действительно ли применение столь востребованных и перспективных принципов agile остается прерогативой ИТ-подразделений?
В том, что данные методы больше всего популярны в ИТ-проектах, есть доля истины. Однако замечу, что принципы agile стали популярны, в частности, как раз благодаря серии известных управленческих инноваций компании Toyota. Широко распространенные принципы lean, напротив, никогда особенно не связывались именно с ИТ. Одно это уже доказывает: применять данные наработки в том числе и в проектах, не имеющих прямого отношения к ИТ, можно и нужно. И это делается. У нас, в банковском бизнесе, например, хватает таких ситуаций, когда изменение требований в ходе проектов (в том числе дистанцированных от ИТ) — абсолютно штатная, даже практически неизбежная ситуациея. Чего стоят одни только требования регуляторов! Реализуя их, мы, конечно, вынуждены трансформировать и ИТ-системы (не только эксплуатируемые, но и создаваемые в данный момент), но и непосредственно бизнес-процессы банка тут затрагиваются далеко не в последнюю очередь.
Я думаю, что процесс становления agile как некой классики проектного управления уже идет. Для пояснения ситуации напомним, что неким универсальным руководством в сфере проектного менеджмента является небезызвестный стандарт PMBoK. Это руководство достаточно общего характера, которое не дает детальных описаний тех или иных действий, но зато декларирует все важнейшие принципы проектного управления, которые оказываются эффективными на практике (не только в ИТ). И под эти принципы могут быть подстроены более конкретные рекомендации в сфере Project Management. Надо сказать, что в некоторых кругах на протяжении нескольких лет шли дебаты относительно того, насколько agile-методология коррелирует с принципами PMBoK. Но год назад PMI-иститут подтвердил со своей стороны актуальность agile-подходов, запустив сертификацию и в этой области. Конечно же, это носило скорее формальный характер, так как сообщество профессионалов Project Management уже давно относится к agile со всей серьезностью.
В нашем банке, в частности, стремление применять agile-подходы сейчас явно двунаправленное. Оно исходит и от бизнеса, и от ИТ.
Насколько быстро и легко теоретические, научные разработки в области проектного менеджмента внедряются в практику работы коммерческих компаний? От чего это может зависеть?
Если мы посмотрим на развитие профессиональных стартапов, то увидим, что зачастую они изначально строятся на проектной основе. Тому есть несколько причин, и в первую очередь — небольшие размеры этих стартапов, а также огромнейшая степень неопределенности и нацеленности на результат. В подобных случаях все достаточно быстро и легко.
Можно обратиться к примеру компании, в которой работает, скажем, тысяча человек, которая всегда была далека от проектного управления и в таком виде существует уже много лет. Я бы не ожидал, что здесь внедрение будет проходить просто. Скорее наоборот. Тут будут мешать и корпоративная культура, и, может быть, образовательный уровень, и подходы к компенсации сотрудников, и многое другое. Внедрение методологической части и проектного управления в таких условиях — сверхсложная задача. Это должно решаться также на проектной основе.
И все-таки надо понимать, что и в изменившихся экономических условиях дисциплина project management по-прежнему продолжает претендовать на то, чтобы служить некой идеологией, объединяющих всех функциональных менеджеров компании, со своих позиций вносящих вклад в развитие ее бизнеса. Но поскольку эта дисциплина довольно объемна, хотелось бы понимать: какие ее компоненты в большей степени выступают в качестве этой объединяющей основы?
Очень важной я считаю правильную организацию работы со стейкхолдерами проекта. Конечно же, эта работа должна вестись непрерывно, а не срочно инициироваться в моменты постановки задач или сдачи результатов выполненных работ заказчику. В работе со стейкхолдерами требуется определенный структурный подход, актуальный для каждого конкретного случая. Все коммуникации должны быть хорошо продуманы и методологически обоснованы.
Чрезвычайно важен также этап планирования проекта, как бы банально это ни звучало. В российской практике дела с этим пока обстоят явно не лучшим образом. Однако именно на этапе планирования ведущихся в компании проектов консолидируется вклад отдельных подразделений и соответственно происходит тесная интеграция их работы. Хорошее планирование в значительной мере увеличивает шансы проектов на успех.
В качестве еще одного важного направления я бы отметил управление изменениями. Зрелость применения данной дисциплины прямо свидетельствует о том, насколько методически грамотно мы умеем управлять ситуацией при изменении самых разных параметров проекта — требований, сроков, людских или финансовых ресурсов и пр.
И наконец, никак нельзя не сказать о важности управления рисками (risk management). Опасность прежде всего в том, что этим очень часто занимаются поверхностно, просто ограничиваясь перечислением возможных рисков, в то время как менеджмент должен осуществляться на постоянной основе. Но, лишь перечисляя риски, многие почему-то считают, что risk management у них присутствует, а значит, бизнес уже достаточно защищен.
Каковы принципы формирования проектного офиса и проектной деятельности в компании в целом, принципы формального и неформального участия в нем ИТ-руководства и/или менеджеров проектов со стороны ИТ?
Чтобы начать формировать проектный офис, в первую очередь нужно обязательно заручиться поддержкой спонсора — «правильного человека» из топ-менеджмента компании. Во вторую — убедиться, что вы заручились поддержкой правильного человека и он сможет быть вашим спонсором и покровителем на протяжении всего формировния и последующего функционирования офиса.
Большинство неудач в процессе построения проектных офисов и внедрения проектного подхода заключается в том, что либо не было спонсора, либо он был выбран неправильно, либо он куда-то делся посреди пути. Не менее важно понимать и знать всех основных стейкхолдеров: как они относятся к этой инициативе, каково их влияние.
Далее, нужно понять, какой проектный офис нужен вашей компании. Иными словами, какой проектный офис реалистично построить в вашей компании? Зачастую компании ограничиваются «слабым» проектным офисом, который в большей степени отвечает за методологическую часть и занимается консалтингом. С моей точки зрения, «слабый» офис лучше, чем ничего, но объективно хуже. Что главное, он медленнее приводит компанию к проектному типу, чем «сильный», подразумевающий реализацию в компании сильной организационной матрицы или же полностью проектного подхода (project-based).
Ищите таланты (не только внутри компании). Нужна «свежая кровь» — люди, которые профессиональны с точки зрения руководства проектами, которые разделяют ваши цели и верят в них, люди, «не испорченные» культурой компании, в которой вы внедряете проектный офис. Работайте с сотрудниками: организуйте образовательные программы, объединяйте людей в communities of practice. Важно пилотировать подходы на небольших объемах. Это позволит вам проверить, как работает тот или иной подход в конкретно вашей компании, в ваших специфических условиях. Учитесь на ошибках и учитесь формировать истории успеха, на которые можно ссылаться. Если у вас уже давно нет историй успеха, вам все сложнее и сложнее будет доказывать, что вы строите что-то правильное и нужное. Не забывайте про методологическую часть, но не ударяйтесь в крайность стандартизации всего и вся. Чтобы переходить к стандартизации, нужно сначала убедиться, что все основные и необходимые методы и процедуры уже наличествуют. Чаще всего это не так, и тогда фокусируйтесь на содержании (методах), а не на форме (стандартах).
Все вышесказанное — хорошие практические рекомендации по построению проектного офиса.
Восприятие дисциплины project management в качестве одной из основных управленческих методик во многом зависит и от того, какие формальные квалификации присутствуют у сотрудников компании. Что вы могли бы сказать по этому поводу?
Я снова не буду оригинальным, если скажу, что широко известная квалификация PMP (Project Management Professional) института PMI является очень хорошей базой. Вообще любые сертификации и тренинг программы PMI можно считать очень полезными. Получаемые квалификации по меньшей мере позволяют людям ориентироваться в довольно объемном пространстве Project Management, дают возможность концентрировать усилия на наиболее важных задачах в практике проектного управления. Иными словами, это, как теперь говорят, некая карта-памятка, позволяющая ориентироваться на индустриальный опыт. К сожалению, российские вендоры, котоые готовы давать нам подобные тренинги, с моей точки зрения, слабоваты. Нам зачастую приходится приглашать западных трейнеров.
Но динамичность современного мира, как я уже говорил, проявляется сейчас буквально во всем. Она должна находить отражение в практике проектного управления вообще и в отношении получаемых сотрудниками квалификаций в частности. Поэтому в сфере разработки программного обеспечения в Deutsche Bank мы приходим к необходимости получения некоторыми специалистами сертификатов Certified Scrum Master и Certified Product Owner (от Scrum Alliance) в дополнение к традиционному образованию, предлагаемому институтом PMI.
Вообще получение разного рода сертификатов в сфере управления проектами — довольно развитая практика в бизнесе. Сертификаты в целом востребованы, поэтому многие специалисты тоже весьма мотивированы на то, чтобы их получить. Это нормальное следствие востребованности данной дисциплины как таковой, однако подобный ажиотаж таит в себе определенную опасность. Дело в том, что за этими гарантирующими должный уровень знаний документами мы часто забываем о личных качествах людей, которые получают те или иные полномочия по ведению проектов. Лично я не раз сталкивался с ситуацией, когда проектом занимается сотрудник, весьма грамотный с точки зрения образования в сфере PM. И наличие у него практического опыта при этом достоверно подтверждено. Но, наблюдая за его работой, приходишь к выводу, что успешной ее никак нельзя назвать. Причина этого, по крайней мере по моему личному убеждению, состоит в том, что на позицию назначен человек, личные качества которого явно препятствуют выполнению им обязанностей, этой позицией предусмотренных.
В этом смысле полезно обратиться к соционике и смежным дисциплинам. Например, к составлению так называемого MBTI-профайла. Не слишком сложная методика позволяет классифицировать человека в пространстве ряда бинарных характеристик. Например, понять, интроверт он или экстраверт, склонен ли он к детальной проработке фактов или больше доверяется интуиции, обязательно ли для него доводить любое дело до логического конца или он может легко увлечься новой идеей. Составив подобный профайл, можно гораздо объективнее оценить, сможет ли данный человек выполнять определенную работу, а уж потом соответственно смотреть на сертификаты и практический опыт сотрудника. Мы в Deutsche Bank так и поступаем.
