Проектный менеджмент – объемная разноплановая управленческая дисциплина. Особенно много приходится слышать разговоров о проектном менеджменте в ИТ. Когда возникает очередная необходимость поговорить об этом, хочется, чтобы собеседник не только был хорошо теоретически подкован, но и мог поделиться практическим опытом работы. Предполагая, что уж в девелоперской компании, проектной по своей природе, проектный менеджмент не может быть слабым и оторванным о жизни, мы решили побеседовать с ИТ-директором ОАО «Группа компаний ПИК» Сергеем Потаповым.
Intelligent Enterprise: Давайте поговорим об особенностях ИТ в проектной организации. Существует ли взаимовлияние проектного управления в основной деятельности компании и проектного управления в ИТ?
Сергей Потапов: ОАО «Группа компаний ПИК» действительно может служить наглядным примером проектной организации. Наши продукты – многоэтажные дома, которые создаются в ходе проекта. Строительство отдельного дома представляет собой и отдельный проект, и часть более широкого инвестиционно-девелоперского проекта. Проектный характер работы, безусловно, налагает некоторый отпечаток и на специфику работы ИТ. Нам не нужно лишний раз объяснять коллегам, что такое проект и что такое проектное управление. Но напрямую инвестиционно-девелоперский блок компании не влияет на культуру проектного управления, принятого в департамент ИТ, а мы напрямую не влияем на культуру проектного управления инвестиционно-девелоперской деятельности. При этом я хотел бы подчеркнуть, что сам по себе подход к проектному управлению в этих разных направлениях деятельности принципиально не отличается. Методология проектного управления во многом схожа. И это упрощает нашу работу в области ИТ. С другой стороны, хотя проектная специфика компании не влияет существенно на ИТ (и наоборот), в проектах по автоматизации мы непосредственно участвуем в упорядочивании и оптимизации процессов – а раз мы в этом участвуем, значит, так или иначе влияем на процессы, образующие один из ключевых видов деятельности компании.
Общие положения проектного менеджмента, наверное, действительно универсальны для любого вида деятельности. Но поставщики информационных технологий предпочитают приходить со своей «фирменной» методологией, которую можно принимать или не принимать. И нередко заказчики говорят о необходимости модифицировать методологию «под себя». Значит, и у этой универсальности есть предел, а «бренд методологии» так или иначе оказывает влияние на проектную деятельность именно в ИТ.
Правильно, каждый подрядчик имеет собственные, именные методологии. Это очень важно и для ИТ-вендоров, и для серьезных поставщиков проектного управления – авторитетных консалтинговых компаний. У компаний PricewaterhouseCoopers, Deloitte, Accenture, Ernst&Young свои методологии, у компаний SAP AG, Oracle, Microsoft – свои методологии, и у отечественных компаний, таких как «1С», конечно, тоже могут быть свои методологии. И методология получает звучное название, соответствующее бренду. Но в основе всех этих методологий лежат одни и те же принципы, которые базируются на здравом смысле и на большом опыте. Каждая компания многократно вела подобные проекты, делала ошибки, набивала шишки, извлекала из этого уроки, формируя, таким образом, свою методологию. И если абстрагироваться от названий и говорить о сути, то все эти методологии более или менее похожи. Как бренды методологий влияют на ИТ? Да почти никак. Вендоры могут быть разные. А наша задача – внедрить систему, и другого пути нет. А внедряются системы приблизительно одинаково с точки зрения методологии. Вопрос в другом: если мы собрались работать с конкретным вендором, то хорошо бы научиться говорить с ним на одном языке.
Поэтому при запуске проекта мы всегда «сверяем часы» на предмет понимания конкретной методологии и использования конкретной терминологии. Потому что у кого-то есть понятие «техническое задание». А у другого то же самое может называться «техническим проектом», а у кого-то – еще иначе. Терминология разная, но суть за этим стоит одна. Очень важно зафиксировать ключевую терминологию в уставе проекта, который может также являться частью договора. В уставе также прописываются другие методологические вопросы управления конкретным проектом, а именно: структура управления, описание ролей в этом управлении, способов взаимодействия внутри проектной команды и т. д.
Таким образом, именно здравый смысл лежит в основе проектного управления?
Есть выражение: все в этом мире рождается дважды – сначала в виде плана на бумаге, а затем уже «в кирпиче и бетоне». В этом, в частности, и заключается здравый смысл – прежде чем начинать реализацию проекта, необходимо добиться четкого понимания, чего мы хотим добиться на выходе, сначала выраженного в функциональных требованиях заказчика, а затем и в детальном описании технического задания. Сначала планирование ресурсов, денежных и временнЫх, и только потом – реализация. Нельзя сделать что-либо качественное, не понимая, чего именно хочет заказчик. Ведь «качество» – это во многом соответствие ожиданиям, ожиданиям заказчика. Мы обязаны понимать заказчика, говорить с ним на одном языке. Мы обязаны оформить это понимание в виде адекватного документа, который понятен и заказчику, и исполнителю. И это прописано в методологии. Методология дает каркас, принципы работы. Ингредиенты, как в приготовлении супа, могут быть разные. Но есть обязательный порядок действий: налить воды в кастрюлю, поставить на плиту и т. д. Еще нужен рецепт, в котором сказано, в какой последовательности добавлять продукты. Методология как раз дает правильную последовательность. Она нужна для того, чтобы не пересолить и не переварить. Если мы действуем в полном соответствии с методологией, которая основана на предыдущем опыте «набивания шишек», то не должны потерпеть неудачу. Если же это случилось, то любая методология вам предложит сделать шаг назад и повторить попытку.
Проектные команды состоят часто из множества людей, у каждого из которых свой почерк в работе, привычка работать в определенных условиях и определенном режиме. Какое влияние, по-вашему, это оказывает на ход проекта? И как предлагает с этим работать методология?
В работе всегда сталкиваешься с так называемым субъективным подходом. Каждый человек уникален по своим способностям, опыту, возможностям. Все, кто вовлечен в проект, – разные люди. Чем выше руководитель, участвующий в проекте, тем сильнее он влияет на проект с точки зрения его управленческого стиля, взглядов, привычек. Мы уже говорили, что любая проектная методология стремится исходить прежде всего из здравого смысла. Это одновременно и плюс, и минус. Поскольку здравый смысл вроде бы доступен всем, многие люди не считают проектный менеджмент отдельной дисциплиной, думая: «Я и так понимаю, как действовать: сначала это, а потом вот это… Это же очевидно!» Люди, которые, по сути, занимаются проектным менеджментом, – будь то антикризисные управляющие или генеральные директора, создающие уникальный продукт с ограниченными ресурсами в заданное время, – всегда делают это исходя из собственного понимания и опыта, но не всегда основываясь на какой-либо сформулированной методологии. Все делают в целом похожие вещи, но делают по-разному, привнося в это свою индивидуальность. Кто-то лучше убеждает людей и заражает их своими идеями, кто-то хуже… Методология же как раз и предназначена для того, чтобы объединить всех участников проекта в единой системе понятий и ценностей. Кто-то заказчик, кто-то спонсор, кто-то исполнитель, кто-то участник рабочей группы в отдельной функциональной области. Проектная методология позволяет привести всех этих людей к единому пониманию конкретного проекта – как он должен идти, на какие должен разделяться фазы, какие роли должны быть у каждого участника проекта. Всех этих людей с их индивидуальным опытом методология направляет в единое русло. Понятно, что у каждого человека свой стиль. Но чтобы все работали более или менее слаженно, понимали распределение обязанностей и цели проекта, нужна методология, которую необходимо постоянно проговаривать, фиксировать и, возможно, адаптировать под конкретный проект.
Проектный менеджмент – дисциплина объемная, со сложной структурой, с множеством направлений. Соответственно в современной компании есть несколько областей приложения проектного менеджмента. Очевидно, это финансы, маркетинг, кадровый менеджмент, продажи и, конечно, ИТ. Можно ли выделить в проектном менеджменте (или хотя бы в одном из его направлений) «системообразующее» ядро?
Я, пожалуй, не буду касаться маркетинга и финансов, а буду говорить пока только об ИТ-менеджменте. И здесь я как раз считаю проектное управление ядром и связующим звеном ИТ-менеджмента. Потому что очень многое, что мы выстраиваем в компании с точки зрения ИТ, мы выстраиваем в ходе проектов. Прежде чем система заработает, ее нужно внедрить, а это проект. Любой проект в ИТ – это консолидация всех основных сил ИТ-департамента. С точки зрения ресурсов ИТ есть функциональные специалисты, которые знают предметную область внедряемой системы, есть системные администраторы, отвечающие за сетевую и серверную инфраструктуру, бизнес-аналитики, которые перекладывают задачи с языка бизнеса на язык ИТ, есть тестировщики и специалисты поддержки и др. При внедрении мы зачастую приглашаем внешние компании, поскольку на этот период нам нужно больше ресурсов, а потом необходимость в таком количестве ресурсов отпадает.
Практически все основные силы департамента подключаются в нужном порядке, исходя именно из той методологии, которая подразумевает планирование, роли, распределение ресурсов. Поэтому проектное управление и является тем ядром, которое объединяет работу ИТ-департамента. И хотя Группа компании ПИК – это организация со зрелой проектной культурой, наши ИТ-специалисты вполне достойно выглядят на общем фоне с точки зрения их квалификации в области проектного управления. Каждый год у нас в работе два-три крупных проекта по внедрению. Была внедрена серьезная ERP-система на одном из домостроительных комбинатов. На уровне Группы компаний были автоматизированы функции казначейства, функции проектного управления в инвестиционно-девелоперской деятельности, функции документооборота и service-desk. Кроме того, в настоящий момент мы внедряем систему CRM, приступили к внедрению системы консолидированной отчетности.
В классическом подходе считается, что руководить проектом внедрения крупной бизнес-системы должен человек от бизнеса. У нас же руководителями таких проектов были как раз представители департамента ИТ. Потому что наши специалисты, во-первых, понимают задачи бизнеса и, во-вторых, понимают, как правильно организовать работу в проекте. А со стороны бизнеса у нас возникает роль руководителя службы заказчика, который не руководит проектом напрямую, не составляет график работ, не планирует ресурсы, не ведет протоколы и не отслеживает статусы выполнения работ, а обеспечивает постановку задач и мобилизацию ресурсов заказчика тогда и в том объеме, как необходимо в рамках проекта. И у нас получается такая связка: ИТ-специалист – руководитель проекта, который планирует и координирует всю работу, и руководитель службы заказчика, который обеспечивает постановку задачи, обеспечивает необходимые ресурсы заказчика и принимает работу исполнителей. В частности, мы руководили проектом внедрения системы Primavera. Это большая система для управления как индивидуальными, так и целыми программами инвестиционно-девелоперских проектов. В ней ведутся все наши инвестиционно-девелоперские проекты, отслеживаются их сроки и бюджеты.
Ею пользуются и менеджеры проектов, и руководство компании для принятия стратегических решений. Если говорить об инвестиционно-девелоперских проектах, то у нас есть внутреннее положение о работе проектных команд, где четко прописана роль ИТ-специалиста, выделяемого в проект от ДИТ. Как правило, ИТ-специалист, например системный администратор, оказывает ИТ-услуги, участвуя сразу в нескольких проектах. Мы осуществляем также поддержку проектной команды как обычных пользователей. У них у всех есть компьютеры, которые необходимо обслуживать, обеспечивать удаленный доступ и т. д. Это делают инженеры поддержки службы service-desk или системные администраторы.
Какого рода проектным опытом должен обладать ИТ-специалист, руководящий бизнес-проектом, и где он его может получить?
Основное требование к квалификации руководителя проекта по внедрению бизнес-приложений – знание проектной методологии внедрения систем. На момент начала проекта он, как правило, может знать специфику предметной области не очень хорошо, но постепенно в ходе проекта ее осваивает. Есть такая фраза: «я сам не знаю, но знаю, кто знает». В принципе это характеризует хорошего руководителя проекта. Он человек, который понимает, как должен строиться проект, и вовремя «подтаскивает» нужные ресурсы. Он не обязан знать какие-то вещи, которые знает заказчик. Но он должен в нужный момент пригласить нужных специалистов, которые сделают необходимую работу, чтобы проект оказался успешным.
Кроме перечня методологий и продуктов, есть еще и квалификации по управлению проектами, которые могут как способствовать взаимопониманию и эффективному взаимодействию участников проекта, так и наоборот – разобщать. Есть ли необходимость в наличии квалификаций, что они дают и какие из них предпочтительны?
Я лично руководил многими проектами, и хотя у меня нет формальной сертификации по проектному управлению, но есть большой опыт. Свой опыт я приобретал, работая в разных компаниях, в том числе в одной из компаний «большой четверки», а впоследствии сотрудничая с ними в качестве представителя заказчика. Когда я знакомился с проектными методологиями, которые у них используются, то понимал для себя, что в них нет ничего принципиально нового, что позволило бы мне по-другому взглянуть на проект.
Но это моя личная история. Тем более что я все-таки в последнее время не специализируюсь непосредственно в управлении проектами. А тем людям, которые постоянно занимаются проектным управлением, сертификация нужна. Она нужна для того, чтобы тот здравый смысл и практический опыт, который есть за плечами у каждого, как-то систематизировать и говорить всем на одном языке. Если компания хочет, чтобы в рамках проектного управления ее специалисты нормально взаимодействовали, желательно, чтобы все они прошли какую-то одну сертификацию, например ту, что дает PMI (Project Management Institute). Это качественно построенная и признанная во всем мире система знаний в области проектного управления, и организация, объединяющая профессионалов в разных отраслях. Я бы выбрал ее. Понятно, где ее получать и как обучаться. По большому счету там есть все то, что и в других подходах и «брендированных» методологиях. Причем в PMI это отлично структурировано. Очень важно, чтобы человек, помимо своего опыта, вооружался структурированной методологией, с тем чтобы допускать как можно меньше ошибок.
