ДОЛЖЕН ЛИ РУКОВОДИТЕЛЬ IT-ПРОЕКТОВ ПОНИМАТЬ В ПРЕДМЕТНОЙ ОБЛАСТИ?
Тема для новой статьи о профессиях ИТ пришла совершенно естественным путем. Дело в том, что 30 сентября в доме журналистов состоялась презентация нового стандарта по управлению проектами под длинным названием «Performance Based Competency Standards for Global Level 1 and 2 Project Managers», что можно несколько вольно перевести как «Стандарты компетенции по результату для руководителей проектов 1-ого и 2-ого уровня».
Удовлетворяя ваше естественное любопытство, отмечу, что рассказывал про стандарт Вильям Дункан — культовая личность в управлении проектами, человек, который написал большую часть PMBok. В создании стандарта кроме него принимали участие многие выдающиеся специалисты из разных стран мира и разных организаций. Основной особенностью стандарта является то, что руководителей проектов предлагается оценивать не по их теоретическим знаниям, а по зрелости и грамотности возглавляемых ими проектов.
Как обычно и бывает, в процессе обсуждения разговор коснулся одного из камней преткновения управления проектами — должен ли руководитель проекта понимать в предметной области. Дункан привел пример лучшего с его точки зрения руководителя проектов — женщины, которая возглавляла несколько крупных проектов по разработке ПО, ничего не понимая ни в ПО, ни в его разработке. Поскольку эти проекты были неведомы аудитории, на том дискуссия и увяла.
Размышляя над примером Дункана, тем более, что он был из области ИТ, я, честно говоря, подумала, что это именно то исключение, которое подтверждает правило. Помните, когда мы говорили про Менеджера Центра поддержки мы уже пришли к выводу, что гениальный руководитель может и не понимать в предмете руководства. Так и здесь: я вполне поверю в то, что отдельные выдающиеся руководители проектов, обладая незаурядным чутьем и волшебной интуицией, могут и не разбираться в сути проекта. Но ведь проектов так много, и для них надо так много руководителей. Откуда взять столько гениев?
Приведу еще пару причин, почему именно руководитель проектов оказался следующим в череде героев нашего сериала ИТ-шных профессий. Пару лет назад нам удалось пригласить Дункана в финансовый холдинг, в котором я тогда работала, для того, чтобы он рассказал ИТ-специалистам об управлении проектами «из первых рук». Вильям в течение полутора часов делился с нами интереснейшей информацией по поводу особенностей управления проектами в области ИТ. И мне кажется справедливым поделиться тем, что он нам тогда рассказал с более широкой аудиторией.
В то же время для крупного проекта внедрения в Холдинге CRM-системы, мы искали руководителя проекта. И непростой опыт поиска заставил меня задуматься о многих аспектах этой профессии в применении, конечно же, к области ИТ. Вот на все вышеперечисленное, а также на опыт моих друзей и коллег, книги, стандарты и статьи, я и буду опираться в дальнейшем. Не стану отвлекать ваше внимание на определения. В конце статьи приведен краткий словарик.
ЧТО ТАКОЕ ПРОЕКТ В ИТ?
А мы с вами давайте сразу погрузимся вместе с руководителем проектов в пучины ИТ. Что такое проект в ИТ? Не правда ли сразу на ум приходят проекты внедрения корпоративных систем или проекты по разработке ПО? Но ведь есть еще проекты прокладки СКС или построения VPN. А подготовка и проведение тендера — это проект? Или только подпроект для общего проекта, например, выбора, установки и внедрения корпоративной системы?
Мне приходилось участвовать в проекте создания стратегии ИТ. Можно ли считать это проектом? Ведь все вышеперечисленное имеет начало, конец и результат, который добавляет к образу ИТ организации нечто уникально новое. Давайте попробуем грубыми мазками изобразить классификацию проектов ИТ.
1. СПЕЦИАЛЬНЫЕ, сугубо «ИТ»-шные проекты
Их, в свою очередь можно разделить на 3 типа:
a. Разработка ПО
b. Внедрение ПО
c. Инфраструктурные проекты, в частности, построение СКС
2. ВНУТРЕННИЕ, относящиеся к качеству ИТ-процессов. .
Схожие проекты могут проходить в соседних подразделениях или во всей компании. Например, это проекты реинжиринга ИТ-процессов. Здесь же можно обнаружить проект внедрения стандартов ITIL, или сертификацию по СММ или ISO. К этой же группе относится проект построения Центра поддержки, столь часто упоминаемый нами в предыдущих статьях.
3. СТРАТЕГИЧЕСКИЕ проекты.
Это проекты разработки стратегических документов и корпоративных стандартов (в частности, разработка стратегии ИТ, построение архитектурной модели, разработка модели эффективности ИТ). Сюда же я бы отнесла проекты выбора: тендеры, выбор технологической платформы.
Чаще всего, упоминая руководителя ИТ-проекта, имеют в виду два первых типа проектов: проекты разработки и внедрения (в случае, когда ПО разрабатывается под заказ эти два типа обычно объединяются в один проект — разработки и внедрения.) Поэтому далее в наше рассмотрение попадут руководители именно таких проектов.
Рынок труда ощущает просто волчий голод на руководителей проектов внедрения корпоративных систем. Не далее как вчера, одна знакомая жаловалась: «Да мы готовы взять первого встречного, который не побоится этого гиблого проекта». Причем оплачивается эта позиция совсем неплохо. Я уже упоминала, что и мне знакомы долгие и тяжелые поиски руководителя проекта по внедрению CRM-системы, которые, к счастью, увенчались успехом.
Анализируя причины такой ситуации, я поняла, что корни ее кроются в катастрофическом непонимании между работодателями и кандидатами. Работодатели ищут козла отпущения, обычно, для проблемных проектов, а кандидаты — руководящую позицию, для которой, как им кажется сгодится тот винегрет знаний и умений, которым они обладают. Меня как работодателя обычно отпугивала именно эта мешанина обрывочных сведений, а также полное отсутствие интереса к предмету проекта, к тому результату, для которого собственно он и затевается.
ТЕОРЕТИЧЕСКОЕ БОГАТСТВО
Подобное положение тем более удивительно, что в теории управлении проектами все обстоит неплохо: есть PMI, есть IРМA, СОВНЕТ. Недостатка в литературе не наблюдается. Незнание английского здесь не помеха — PMBok переведен на русский язык, есть множество книг на русском языке, в том числе и по проектам в области ИТ. Появился журнал «Управление проектами», тема управления проектами регулярно оказывается в центре внимания конференций и прессы.
Множество фирм предлагает обучение, причем, насколько мне известно, в том числе и из собственного опыта, очень высокого качества. Управлению проектами даже учат в институтах. С инструментами тоже все неплохо: кроме MS Project есть масса ПО разной стоимости и качества.
Так что ситуация сложилась парадоксальная: наработан огромный питательный теоретический пласт по управлению проектами, но качество проектов внедрения и разработки остается устрашающе низким. Боюсь, что это тот случай, когда теория опережает практику, и этот разрыв пока не собирается сокращаться. Возможно также, что это логический результат излишне механистического, теоретического подхода к такой творческой области как управление проектами.
Попытаюсь развить эту мысль. Мне кажется, что в данном случае теоретическое богатство играет с руководителями проектов злую шутку. Освоив теорию, они рвутся в бой, оставаясь не вполне подготовленными к таким сторонам деятельности руководителя проекта, как психология, гибкость, интуиция. А уж если у человека один раз получилось выполнить проект успешно, он, простите, как попка-дурак, будет повторять те приемы, которые привели его к цели. Но как проект, так и среда, в которой он выполняется, скорей всего будут совершенно другими. Поэтому привычные приемы могут, да просто обязаны, не сработать.
Есть, конечно, и объективные причины того, что проекты в ИТ так редко бывают успешными. Это большая неопределенность, высокие риски, подвижность современных предприятий, для которых выполняется проект, а значит и изменение требований к продукту проекта «на лету», по мере выполнения проекта. Именно по последней причине классическая схема: сбор требований, выполнение работ, сдача заказчику, — здесь работает плохо.
Нельзя просто взять требования к системе и спокойно заниматься ее разработкой или настройкой. Когда Вы вернетесь к Заказчику с готовым решением, Вы вполне возможно обнаружите, что его потребности кардинально изменились. Поэтому в классический треугольник сроки-бюджет-качество продукта, в котором вынужден вертеться руководитель любого проекта, прибавляется еще один важнейший четвертый элемент — потребности заинтересованных лиц. Именно об этом и рассказывал нам Вильям Дункан несколько лет назад.
С другой стороны, эти потребности можно рассматривать как важнейший элемент качества продукта — третьей вершины треугольника ограничений проекта, которая, в этом случае, становится динамической и слабо поддается влиянию руководителя проекта. Последнему остается только балансировать на тонкой грани между изменчивостью потребностей, сроками и затратами, постоянно напряженно прислушиваясь к дыханию Заказчика. А не потерял ли уже проект для него всякий смысл?
Постоянная череда изменений требований постепенно приближает ИТ-проект к процессу. Не доводилось ли Вам слышать, как несчастные CIO жалуются: » Это внедрение никогда не кончится. Проект превратился в нескончаемый процесс!». Это тоже искусство руководителя проекта — выбрать точку останова. Что никоим образом не означает, что надо остановить процесс развития внедренной системы. Рецепт прост и всем известен — если не получается съесть проект целиком, то надо отправлять в рот по кусочку. Так и прогресс будет нагляднее, и заказчик — довольнее.
ОТКУДА БРАТЬ РУКОВОДИТЕЛЕЙ ИТ — ПРОЕКТОВ?
Следующий вопрос, который неоднократно приходится обсуждать: откуда брать руководителей ИТ — проектов. Я знаю три возможных инкубатора.
Проектный офис. Если в компании управление проектами поставлено на широкую ногу, то проект ИТ, как и все прочие проекты получает руководителя проекта отсюда. Преимущества заключаются в том, что такой руководитель станет рассматривать проект в общем портфеле проектов компании, в рамках корпоративных стандартов по управлению проектами.
Он скорей всего будет обладать высокой квалификацией в управлении проектами и хорошим знанием стратегических и оперативных задач всей компании и ее подразделений. Он будет знаком с ключевыми сотрудниками и вопросы взаимодействия не должны представлять для него особых трудностей. Недостаток все тот же, о котором мы уже говорили — слабое владение ИТ и отсюда нечеткое представление, что же должно получиться в результате проекта.
Внешняя компания. Приглашенный руководитель проекта приносит в компанию опыт (как успешный, так и неуспешный — а за битого двух небитых дают) управления схожими проектами, знание методологий. Во всяком случае, именно такого надо искать. С другой стороны гастролер не знает особенностей Вашей компании, ее стандартов и привычек, ее клиентов и сотрудников. Руководимый им проект может развиваться где-то на задворках жизни компании, что обязательно скажется на его качестве (я имею в виду как качество процесса проекта, так и качество его результата).
Подразделение ИТ. В больших организациях под сенью управления или департамента ИТ вполне может созреть отдел управления проектами, в котором (о, чудо!) специально подготовленные руководители проектов ИТ будут с нетерпением ожидать нового проекта. Такие руководители проектов имеют огромное преимущество перед выше рассмотренными вариантами. Они и в теории подкованы, и свою компанию знают, и в ИТ не новички. Однако далеко не каждая компания может позволить себе такую роскошь.
Нельзя забывать, что поток ИТ-проектов должен быть достаточно полноводным, чтобы руководители проектов во-первых не были дармоедами, во-вторых не теряли квалификации. Эти соображения обычно приводят к тому, что руководители ИТ-проектов смещаются из подразделения ИТ в проектный офис, и мы с вами имеем картину №1. А это позволяет полностью избавиться от первой неприятности, но существенно выпячивает вторую. (Наверное, надо будет отдельно написать про «интерфейсные» профессии ИТ, то есть те профессии, которые находятся на стыке подразделений. Кроме руководителя ИТ-проектов сюда явно относится специалист по ИТ-безопасности.) Для дела не очень важно, в каком подразделении находятся такие специалисты. Важно, чтобы использовались они максимально эффективно.
Небольшая организация, конечно, не может позволить себе держать выделенного руководителя ИТ-проекта. Да и никакого проектного офиса в ней скорей всего нет. При необходимости коллектив выдвигает смельчака, который входит в клетку проекта (уж, не в тот ли магический треугольник, который я упоминала выше) и становится дрессировщиком (возлагает на себя его руководство).
Чаще всего это программисты, которым кажется, что опыт разработки собственных программ, которые ведь тоже проекты, вполне подготовил их к этой деятельности. Нет, я не воскликну: «Как же они заблуждаются!» Прежде всего, потому, что знаю многих грамотных и успешных руководителей проектов, вышедших из программистов. Но причину этого вижу не в том, что разработку программ они осуществляли в строгом соответствии с законами проектного менеджмента, а в присущем им системном мышлении, понимании предмета и острой заинтересованности в успехе. Большинству программистов присуща эта здоровая нотка — вынянчить результат.
Вот эта вера, помноженная на энтузиазм да сложенная со знаниями методологии управления проектами, только и способна привести к успеху проекта. Может быть не совсем в срок, выйдя за границы бюджета, ИТ-проект завершится получением достойного результата.
После этого наступает самое сложное. Что делать руководителю и что делать компании, его вырастившей? Как Элиза Дулитл, побывав герцогиней, не могла вернуться в цветочницы, так и не всякий руководитель проекта может вернуться в программисты (это совсем не означает, что программистом быть хуже, чем руководителем проекта; впрочем, цветочницей, по-моему, быть намного веселее, чем герцогиней).
Увы, большинство специалистов, оставшись без проекта, уходят из компании. И компания теряет не только программиста, но и обученного ею же руководителя проекта. Впрочем, если взглянуть на ситуацию без лишней сентиментальности, для компании это выгоднее, чем платить за приглашенного руководителя проекта. Кроме того, успех проекта окупает эту неприятность. А сам руководитель проекта приобрел новую специальность.
Если же он и компания не хотят расставаться, то можно, например, сделать руководителя проекта ответственным за модернизацию и поддержку внедренной системы. Выполнив проект, пусть теперь налаживает процесс развития его продукта.
Мы перечислили три типа руководителей проекта ИТ. А возможно ли объединение этих вариантов. Можно ли, например, поручить управление проектом сотруднику ИТ-подразделения, который понимает в предметной области, и сотруднику проектного офиса? Или объединить усилия последнего и приглашенного консультанта? Второй вариант мне представляется вполне многообещающим. В первом же случае практически неизбежно возникнет дележка простыни ответственности. Впрочем, все зависит от конкретных людей и умелого руководства.
Один из самых острых вопросов, которые задавали Дункану при обсуждении нового стандарта, звучал так: «А как определить долю руководителя проекта в его качестве? Ведь есть команда проекта, есть внешние условия». Добавлю, есть еще и политика, и везение, и много чего другого. Можно ли это померить?
Перефразируя заключение моей любимой сказки, отвечу так: «Если не всегда у хорошего руководителя проекта, проект успешен, то у плохого он не успешен всегда». А поскольку именно проекты есть тот двигатель, который везет компанию в светлое будущее, то без руководителя проекта далеко не уедешь. Что же можно сказать о руководителе ИТ-проектов, ведь ИТ сами мощный двигатель развития компании?
МАЛЕНЬКИЙ СЛОВАРИК
Проект — это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов.
Руководитель проекта — это лицо, ответственное за управление проектом. В управление проектом входит:
— Определение требований
— Установка четких и достижимых целей
— Уравновешивание противоречащих требований по качеству, содержанию, времени и стоимости
— Коррекция характеристик, планов и подхода в соответствии с мнением и ожиданиями различных участников проекта.
Продукт проекта — ключевой выход проекта (продукт, услуга, результат), достигаемый по завершению проекта
Границы продукта — особенности и характеристики продукта проекта.
Границы проекта- работы, необходимые для создания продукта проекта
PMI — Project Management Institute, Институт Управления проектами
IРМA — International Project Management Association, Международная Ассоциация Проектного Менеджмента
СОВНЕТ — Российская ассоциация управления проектами
PMBok — A Guide to the Project Management Body of Knowledge (3 издание, 2004 г.)
Автор: Марина Аншина.