Rambler's Top100
Статьи ИКС № 12 2010
Александр МАРТЫНЮК  08 декабря 2010

Эффективное командообразование в проекте ЦОДа

О том, насколько значимы в проектах создания/модернизации ЦОДов вопросы правильного проектирования и подбора технических решений, на страницах «ИКС» сказано немало. Не осталась без внимания и тема грамотной эксплуатации. Пришло время поговорить о кадрах – о человеческом факторе, который был, есть и всегда будет определяющим фактором успеха любого технологического проекта.

Александр МАРТЫНЮК, генеральный директор, «Ди Си квадрат»Есть смысл начать разговор с повторения азбучных истин: дата-центр – многогранная сфера приложения специализированных знаний, в которой нет места мелочам. Энергетика, климатика, информационная и техническая безопасность, противопожарное обеспечение, ИКТ-системы и оборудование, слаботочные системы, СКС, строительство – каждая из этих предметных областей имеет свои «границы компетентности», свои подходы и специфику, свой профессиональный сленг, наконец. Неудивительно, что, оказавшись в одной проектной команде, представители каждой из этих профессиональных групп порой с трудом понимают друг друга, что, естественно, затрудняет принятие согласованных решений.

В чем суть проблемы?

Думаю, любой читатель этой статьи может в подробностях представить себе диалог между, скажем, главным энергетиком компании и представителем службы безопасности. Абсолютно разные аргументы, терминология, регламенты и документы – и каждый по-своему прав. Как в такой ситуации не уподобиться героям известной басни Крылова? Как в оптимально короткие сроки выработать единое видение проектной задачи, подготовить качественное ТЗ и обеспечить квалифицированный подбор исполнителей проекта?

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

Поэтапное командообразование

Этап первый

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

Этап второй

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

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

Этап третий

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

То же самое относится к подбору остальных представителей команды управления проектом, которая должна:

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

Кто будет входить в состав этой команды – решать заказчику. Вариантов не так уж много: представители генподрядчика (как это по старинке еще любят делать в России); собственные сотрудники (пока наиболее популярная форма проектного управления); профессиональная управляющая компания (которой отдают предпочтение на Западе). Давайте рассмотрим плюсы и минусы каждого варианта с позиции эффективности конечного результата.

Но прежде – определим основные роли участников проекта (см. рисунок).  

Кто у руля ?
Генподрядчик

Такой подход – дань традициям советского времени, когда в отсутствие рынка в стране довольно успешно работала модель единого генподрядчика. В те времена в этой роли выступала большая организация, в которой действовала четко встроенная проектная иерархия. Эта организация и проектировала, и строила, и определяла исполнителей субподрядных работ на местах. В составе этой организации было также подразделение, отвечающее за координацию разделов проекта и взаимодействие исполнителей. Именно это подразделение, по сути, и осуществляло то, что мы теперь называем проектным менеджментом (PM). Для тех условий такая модель была логичной и оправданной, учитывая, что все работы выполнялись, как правило, в пределах одной структуры и в соответствии с общегосударственными стандартами. Даже если в интересах проекта требовалось взаимодействие с другими компаниями, этих компаний было отнюдь не так много, как теперь. Это, кстати, одна из причин, почему в современных реалиях описанный подход уже не может претендовать на статус единственно правильного. К тому же, как известно, многие отечественные стандарты морально устарели и каждая организация пытается разрешить ситуацию по своему.

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

Штатные сотрудники заказчика

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

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

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

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

Внешняя компания

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

К примеру, убедитесь в том, что PM-команда имеет опыт разработки проектной документации с учетом отраслевых регламентов по комплексной защите объектов заказчика, и в соответствующий момент проекта (а не когда уже все построено) службы ИТ-безопасности, противопожарной безопасности, технической безопасности и главного энергетика не предъявят претензии в связи с несоблюдением важного, с их точки зрения, параграфа инструкции/корпоративной политики/отраслевого регламента. Обижаться на этих людей бессмысленно: они просто делают свою работу и, как правило, делают ее хорошо.

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

Персональный отбор исполнителей

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

Кадры решают все…

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Поделиться: