Про управление проектами, или Project Management, слышали многие, но немногие способны внятно облечь в слова то, что же они на самом деле слышали. Парадокс? Несомненно. А между тем, без проектов, их менеджмента и, естественно, менеджера проектов, не обходится ни одно более-менее серьёзное начинание. Потому иметь представление об этом вопросе нужно буквально каждому. Давайте разбираться?

Мы будем говорить об управлении проектами просто и доступно. Птичий язык определений мы оставим учебникам. Кстати, во врезках-цитатах по всему тексту даны разные определения из официального учебника Project Management Insti tute, так что заинтересованный читатель может сам оценить всю сухость изложения. Как и у любого проекта, у этой статьи есть цель. И цель эта заключается в том, чтобы объяснить в меру подкованному читателю, что же это за зверь — менеджер управления проектами, и что это такое — управление проектами.

Развенчиваем мифы

Несмотря на то что в почти любой программе любого вуза есть предмет, который называется «Управление проектами», у большинства выпускников этих вузов (и молодых специалистов)
отсутствует чёткое представление о том, кто это такой — менеджер проекта и в чём заключается его работа.

Кто-то считает, что это такой руководитель среднего звена, стоящий в одном ряду с управленцем по кадрам или руководителем отдела. Он с важным видом присутствует на всех совещаниях и что-то там решает, и чем-то там управляет.

Кто-то полагает, что это человек-молния, который пыхтит, дымит и занимается преимущественно тем, что бегает и решает проблемы. Не успеваем по срокам? Вышли за рамки бюджета? Всё сломано и ничего не рабо-тает? Ну-ка, где там наш менеджер проектов? Сейчас он прибежит и всё решит, разрулит, спасёт!

У кого-то представление о менеджере проектов, как о педантичном человеке в костюме, который обходит офис с коммуникатором в руках и, проникновенно глядя в глаза, постоянно спрашивает у сотрудников: «ну как, успеваешь?». Ответы он, естественно, скрупулёзно заносит в свою электронную записную книжку, а потом полночи корпит над отчётом.

Многие же, наоборот, при словах «менеджер проектов» представляют себе известную карикатуру, на которой один человек копает яму, а вокруг стоят семеро и смотрят, как он это делает.

Наш герой у таких людей ассоциируется, естественно, не с трудягой, а с одним из наблюдателей.

Все эти представления ложны. Во многих из них есть своя доля правды, но ни одно не является исчерпывающим описанием того, что же такое на самом деле управление проектами, и
чем же занимается проект-менеджер.

И швец, и жнец…

Начать следует с определения проекта и его управления. Итак, проект — это временная задача по созданию чего-либо. У этой задачи есть чёткая цель. Управлять проектом — это сделать так, чтобы цель была достигнута точно в срок, проект не вышел за рамки бюджета, а клиент остался доволен.

Потому из всего этого логично вытекает, что менеджер проекта — это человек, который ответствен за то, чтобы проект закончился успешно. Ключевые моменты здесь вот какие. Проект — это сугубо временное явление. Даже если он длится пять лет, он всё равно конечен. Поэтому, например, поддержка ресурса Times.lv — это не проект, а операционная деятельность. А выпуск октябрьского номера журнала digital times — это проект, потому что у него есть цель, он ограничен временными рамками и конкретным бюджетом.

Из всего этого также можно подумать, что менеджер проекта, это такой специальный человек, который должен разбираться в очень многих вещах. Он должен уметь инициализировать проект, определить его содержание, сроки и стоимость. Он должен следить за качеством и человеческими ресурсами, заниматься коммуникациями участников проекта и риск-менеджментом … ведь так?

Так, да не совсем. Ко всему вышеперечисленному следует добавить слово «управление». Управление интеграцией, содержанием, сроками, стоимостью, качеством, человеческими ресурсами, коммуникациями, рисками и поставками. Разница небольшая, но на самом деле принципиальная, она говорит о том, что менеджер проектов не должен быть профессионалом во всех этих областях, он вполне может привлекать специалистов. Его дело: сделать так, чтобы всё это вместе заработало и получилась маленькая магия — успешный проект.

Отсюда следует, что управление проектами — очень специфическая область деятельности. Профессионал в этой сфере не только должен иметь очень хорошее представление обо всём вышеперечисленном, но и обладать отличными навыками общения, знанием психологии и многими другими «общими» вещами. Кроме того, очень желательно, чтобы он был профессионалом в той сфере, в которой управляет проектами.

Да, кстати — то, о чём мы говорим, необязательно относится исключительно к информационным технологиям. Дом построить — это тоже проект. Просто так сложилось исторически, что эта тема особенно актуальна именно для нашей области. Объясне-ние этому может быть только одно — в сфере IT особенно много задач, которые по сути своей являются проектами. А значит, именно для нас всё это наиболее актуально и полезно.

Трое в лодке, не считая…

Выше мы говорили о магии успешного проекта. Как эта магия возникает? А вот как — классическое определение говорит о том, что задача считается успешно выполненной, если команде удалось удержаться в рамках треугольника Cost — Times — Scope, то есть не выйти за рамки бюджета, уложиться в отведённое время и при этом выполнить все взятые на себя обязательства. Такая ситуация — мечта любого менеджера проектов, цель его работы и недостижимый идеал.

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

Неудача на неудаче и неудачей погоняет

Аналитики очень любят цифры статистики. «Только 30%* проектов в сфере X оказались удачными в прошлом году!», — заявляют они, и окружающие в ужасе хватаются за голову. Как же так? Почему столь маленький процент? А потому — наука управления проектами (а это именно наука) требует серьёзного подхода, который не всегда выдерживается.

Ведь зачастую как всё происходит в обычной организации… Придумали, скажем, усовершенствовать интернет-банк. Составили план, определили цели, выделили бюджет и ресурсы. В том числе и человеческие. Проект идёт себе и идёт, однако его ход никто особо не контролирует и ВДРУГ («вдруг» — штука коварная, наступает обычно за неделю до дедлайна) выясняется, что мы не успеваем. Что делать — просим ещё людей. То есть уже выходим за рамки стоимости.

Однако добавление людей в данном случае не помогло, причём для специалистов это было очевидно с самого начала — оно вообще редко когда помогает, если проект находится в завершающей стадии. Значит, мы встали перед выбором: или опоздать, или урезать функциональность. Упс, мы вышли за пределы треугольника.

Проект — провален.

Почему так произошло? Скорее всего, менеджером была допущена ошибка на этапе инициализации и планирования или неверно оценены временные затраты, а может быть, имело место быть давление со стороны начальства (сдадим «Южный мост» к 18 ноября любой ценой, м?). Причём в данном случае проект, скорее всего, был завершён — через два месяца или с 25% превышением бюджета — и новая версия интернет-банка увидела свет. Но это всё равно неудача.

И тут необходимо сделать одну важную оговорку — перераспределе-ние человеческих ресурсов (и вообще любых ресурсов) в рамках проекта является одним из инструментов менеджера. Потому в добавлении людей «на проект» как таковом нет ничего плохого… но не в этой ситуации.

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

А кому вы нужны, через два-то года? Но в действительности, возможно, самое умное в вышеописанном случае было — закрыть проект, списать убытки и направить людей на выполнение других задач. Почему? Да потому, что: создание новой версии интернет-банка могло либо опоздать настолько, что никому уже не нужно было; либо выйти за рамки бюджета настолько, что не окупилось бы и через пять лет; либо не обладать функциональностью, которая, возможно, есть у конкурентов.

Впрочем, мы вновь сознательно сгущаем краски — в данном случае, скорее всего, проект был бы не закрыт, а перезапущен — необходимость в интернет-банке так просто не отпадает. Были бы поставлены новые сроки, пересмотрена функциональность, снова выделены ресурсы и т. д. Но с большими, многофазовыми проектами нередко бывает так, что руководство задаётся вопросом: а стоит ли, опоздав, выпускать на свет версию 2.2 нашей программы, если другая команда уже почти доделала 2.5? Ведь запуск тоже чего-то стоит. А если мы и уложимся в срок, так ведь из-за неверного планирования и управления человеческими ресурсами наша версия никак не тянет на 2.2. Скорее, 2.15 какая-то. Нужна ли она нам, такая куцая?

Хорошо, может быть и нужна, а как насчёт наших пользователей, будут ли они довольны? Аспектов, которые следует учитывать — масса. И чем масштабнее проект, тем их больше. Возвращаясь к примеру журнала — автор может написать волшебную статью в номер, но если она сдана позже дедлайна, то она уже никому не нужна. Если затраты на её создание превысят гонорар, то она, возможно, не нужна автору (исключением может быть репутационная прибыль — возможно, в The New York Times стоит написать и бесплатно разок-другой).

Ну а если для того, чтобы успеть, автор сознательно пошёл на искажение фактов или работал вполсилы, то даже сданная в срок, выгодная по соотношению время/гонорар — она всё равно получилась ущербной и некачественной. А значит — провальной.

И читатель может найти такие маленькие «проекты» и в собственной жизни. Взять, например, ремонт — это ведь очень серьёзный проект. Если читатель покрасит стены в спальне масляной краской вместо запланированной поклейки обоев, то проект он провалит. «Как-то» комната будет отделана, но ведь цель ремонта наверняка была другой.

Позабыты, позаброшены?

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

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

Функциональных или «скорее, функциональных, чем проектных» гораздо больше, чем их антиподов. Такую организацию узнать очень легко — в них жёсткая иерархическая структура, существует множество конкретных отделов с явно функциональными названиями — «Отдел кадров», «Отдел маркетинга», «Отдел реализации» и т. д. Все решения проводятся «сверху вниз», и каждый работник знает, что у него в единицу времени есть только один начальник. И, сюрприз-сюрприз, этот начальник, конечно же, вовсе не проект-менеджер.

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

Между ними расположены матричные организации (те самые, которые «скорее…, чем…»). Их сила в совмещении подходов, а главная проблема состоит в сложном управлении. Как правило, матричные организации — это довольно крупные компании, в которых есть сильная сервисная часть или очень большое количество начинаний, требующих проектного подхода (разработка программного обеспечения, нефтедобыча и переработка и т. д.).

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

Это обусловлено как исторически, так и тем, что организация и управление подобными компаниями — дело сложное, а создание такой структуры далеко не всегда оправдано из чисто практических соображений. Нужна ли фирме, которая владеет парой лесопилок, проектная организация? Она пилит лес, все её проекты — модернизация производства, новая маркетинговая компания и т. д. — носят краткосрочный характер и, может быть, менее важны, чем её основная деятельность. Однако стоит ли при этом удивляться, если тот же проект по модернизации в такой компании будет провален, так как менеджер помимо собственно самого проекта должен заниматься своими прямыми обязанностями, а все остальные сотрудники ему напрямую не подчинены и слушают, скорее, своего непосредственного начальника? Но зато такая организация сильна в своём прямом бизнесе — она отлично пилит лес, и всё в ней работает как часы.

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

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

Позолоти ручку, а?

Ещё один бич успешных проектов — «слишком хорошие» человеческие отношения участников и пренебрежение «излишними формальностями». Нередко даже самые хорошие начинания губит то, что профессионалы называют gold plating. Что обозначают этим термином? Он описывает ситуацию, при которой изначальные требования к проекту были небольшими или неполными, а в процессе вдруг выясняется, что надо сделать больше или лучше — этого требует заказчик или даже наши собственные специалисты (все мы в душе немножко перфекционисты). Причём делаться за те же деньги и в те же сроки. Так вот — так делать нельзя. В любом случае, кто бы ни был инициатором подобных «надстроек», должен делаться запрос на изменения (Change Request), и он в проекте идёт отдельной статьей — заново оцениваются время, сроки, цена и т. д.

Возвращаясь к нашему примеру с ремонтом… Допустим, вы затеяли в квартире большой ремонт, нашли мастера, составили смету и определили уровень качества и поставили конкретные сроки окончания «проекта».

Но на стадии выполнения работ вдруг оказалось, что для новой сантехники необходимо поставить новые трубы на кухне. Тогда вы просите мастера поменять трубы и тот недолго думая соглашается и походя демонтирует старые. Что в этом такого? Пустяки, дело житейское? Казалось бы да… Но тут вдруг оказывается, что новые трубы стоят, как самолёт, для того, чтобы заменить их, потребуется неделя времени из-за хитрого изгиба и вообще надо приглашать ещё особых специалистов. Сроки летят ко всем чертям, из сметы мы серьёзно выбиваемся, а если на дату окончания ремонта были «завязаны» ещё какие-то важные события (переезд, праздник, выход на новую работу — что угодно), то и они оказываются под угрозой срыва. А всё
потому, что вы вместе с мастером изначально обсудили изменения за рюмочкой чая и порешили, что надо делать. А через пару недель нашли себя за тем же столом, только вместо чая перед вами был ворох чеков за трубы, вы отчитывали мастера за то, что он не успел подготовить квартиру к Новому году, а он требовал от вас не только расплатиться по чекам но и оплатить те несколько дней работы, в течение которых он возился с вашими драгоценными трубами.

Не правда ли, представляя себе идеального мастера, мы хотим, чтобы он уже при первой встрече произнес что-то вроде: «Можно ещё поменять трубы, так будет надёжнее, и я даже рекомендовал бы вам это сделать, но вам придется считаться с тем, что это как минимум дополнительные три дня на работу. Если желаете, то я могу это поставить как опцию в смету, которую я вам готовлю. Туда будут включены необходимые расходы на материалы, цена работы и, соответственно, расчёты по срокам».

Естественно, профессионалы отдают себе отчёт в том, что иногда любое правило можно нарушить. Однако Project Management Institute фактически требует от владельцев своих сертификатов соблюдать кодекс этики и играть «по правилам». Правила эти запрещают не только Gold Plating, но и любые неэтичные поступки. Например, дачу взяток, даже если специалист работает в стране, в которой по-другому дела не делаются.

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

Я бы в менеджеры пошёл, пусть меня научат

Кстати, а как становятся профессиональными менеджерами проектов? Очень хороший вопрос. Автор даже готов польстить себе и предположить, что некоторые наши молодые читатели прониклись статьёй и уже решили, что это как раз то, чем бы им хотелось заниматься. Спешим вылить на них ушат холодной воды — это работа не для всех. И вообще — от дипломированного выпускника вуза до реального менеджера проекта путь долгий.

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

Дальше — больше. Серьёзные организации или требуют, или «настоятельно рекомендуют» пройти сертификацию одной из стандартизирующих организаций. Самая влиятельная из них — уже упоминавшаяся в этой статье Project Management Institute.

Требуют они этого ещё и потому, что у очень многих внутренняя методология строится на базе терминологии и определений подобных стандартизирующих организаций. И в области управления проектами, как правило, такой организацией выступает именно Project Management Institute. То, что она делает — стандарт для индустрии. И её сертификаты являются самыми престижными.

Сертификат этот можно получить, отработав несколько лет в качестве менеджера проектов (это самое главное), прослушав курс и изучив специальную литературу. То есть начинать придётся в качестве «подмастерья» — в качестве участника проекта, затем как «тим-лида», потом менеджера небольших проектов или подпроектов… и так к самым вершинам.

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

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

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

Если читатель всерьёз заинтересовался этой темой, автор может порекомендовать найти PMBOK — учебник Project Management Institute. Эта книжка способна остудить самые горячие головы, рвущиеся в сферу управления проектами. Либо наоборот, лишь подстегнуть их. Но приятного чтива от учебника не ждите — цитаты в статье из него и их сухость вы уже должны были оценить.