Сергей Таратута: Проектное управление. Чужая рубашка? Ближе к телу!

Сергей Таратута

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

Немного предыстории (о терминах):

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

В «рафинированном» виде проектный менеджмент ориентирован на описание менеджмента во временном коллективе, созданном для достижения конкретного результата в течение ограниченного, заранее предопределенного времени. Классический пример проектного предприятия – бывший широко популярным некоторое время назад в Штатах метод разработки заказного программного обеспечения путем набора временного коллектива разработчиков на контрактной основе. Закончили работу - сдали – разбежались.

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

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

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

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

Попытка примерить

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

Попытка внедрения западного проектного менеджмента в буквальном переводе часто сталкивается с широтой русского размаха «все разрушить и построить заново». Здесь трудно не провести исторические параллели с реформами Петра Великого: всем сбрить бороды, носить европейское платье, есть щи вилками…

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

Неужели все так уж бесперспективно? Ведь научились же есть вилками, железную дорогу построили, джинсы одели… Думаю, что и внедрение проектного менеджмента в России является лишь делом времени. Дело именно в том, что не хочется ждать сто лет, но и бежать впереди паровоза не стоит. Итак, о проблемах.

  1. Двойная отчетность

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

Возможно, это связано с недоверием к руководителю проектов. Может быть, в таком случае правильным решением будет его замена? Проблема ведь не только в «неэффективном» расходовании высокооплачиваемого времени Руководства, но и в том, что для подготовки «вторых отчетов» требуется дополнительное время Исполнителей. А это стоит вдвойне дороже ввиду того, что их много и все они отрываются для этого от решения проектных задач. Не думаю, что целесообразно нагружать Исполнителей дополнительной рутиной – они же не кирпичи кладут, они дом строят!

  1. Определение ответственности Исполнителя

За что отвечает Исполнитель в проекте?

(Здесь хочется сделать пару пустых страниц, чтобы уважаемый читатель, перед тем как прочитать ответ, задумался над этим вопросом)

В несколько упрощенной форме можно сказать, что Исполнитель отвечает за то, чтобы выполнить свою работу хорошо и вовремя.

Интересно, для кого из читателей это определение не кажется очевидным? Мой университетский преподаватель по алгебре как-то сказал: «Очевидно – это не то, что Вам, товарищ студент, кажется понятным, а то, что легко доказать!» Давайте немного расшифруем определение:

Хорошо и вовремя это означает - так, как отражено в плане проекта. Например, на диаграмме Ганта в виде отдельного прямоугольника, где указано, что и когда должно быть сделано. Стало быть, если сделано именно ТО и именно ТОГДА, то все Ok? Не совсем.

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

В таком случае, остается только одно: договариваться. Руководитель проекта должен вразумительно донести до Исполнителя ожидаемый результат его работы, а Исполнитель должен уточнить все непонятные ему детали. Причем все это должно быть сделано перед началом выполнения задачи, а не в момент ее выполнения.

Во-вторых, то же самое относится и к срокам выполнения работ. Что именно мы имеем в виду:

  • дату окончания работы Исполнителя,
  • дату приемки его результата (например, после проведения испытания)
  • или дату приемки работы Заказчиком, которому тоже далеко не всегда очевидно, что это «то самое, что ему нужно»?

Где же в таком случае взять объективный критерий завершения работы? Думаю, что в каждом конкретном случае и каждом конкретном бизнесе это может быть сформулировано по-разному, но Руководитель проектов должен твердо знать и четко понимать этот критерий. А еще он должен учесть его в своем календарном плане и не сваливать вину на нерадивость Исполнителя или капризность Заказчика. Вот тогда, как говорил Шарапов, «у нас будет полная любовь и взаимопонимание». :-)

  1. Контроль исполнительской дисциплины в проекте.

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

  • участие в проекте;
  • хозяйственные работы;
  • тех. поддержка пользователей
  • и т.д.

В чем смысл сбора такой информации? В идеале в конце месяца мы получаем «объективную» информацию о занятости сотрудников и можем корректировать рабочие нормы. С точки зрения научного менеджмента занятие это архиважное! Почему же у меня слово «объективную» в кавычках? Потому что, как правило, эту информацию вносят сами Исполнители и, как правило, в конце недели, тщательно высасывая из пальца правдоподобность.

Неужели у кого-то в Табеле есть графа «Веб-серфинг» или «Перекур»? Даже если их и ввести, то вряд ли кто-то поставят туда хотя бы час. А есть ли у кого-то сотрудники, которые не тратят на это время? Хорошо, а нужно ли Руководителю проектов это знать и что мы сможем с этим сделать, если узнаем?

Мое мнение, что знать это незачем. И не потому, что я не знаю, как с этим поступить, а потому, что меня не интересует, чем занимается мой сотрудник, если он выполняет свою работу хорошо и вовремя. Иначе говоря, если сотрудник закончил свою работу – я с чистой совестью ставлю галку «100% completed» не вспоминая, сколько раз я его видел за чтением новостей в Интернет.

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

  1. Проектный героизм.

Еще одно требование к Исполнителям по выполнению проектных задач, которое не встречается в литературе, но является одним из ключевых:

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

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

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

Бороться с этим можно и нужно. Каким образом – тема для отдельного рассказа.

  1. За что отвечает Руководитель проекта?

После всего вышеизложенного, думаю, становится понятно:

Руководитель проекта отвечает за то, чтобы проект был выполнен хорошо и вовремя.

Хотя это и не очевидно. :-)

Продолжение следует?

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Эрнст Мальцев
  На это просто напрашивается цитата из повести Хольма ван Зайчика "Дело жадного варвара" (комм...
Все дискуссии
HR-новости
Исследование: что доводит сотрудников до выгорания

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

Большинство россиян считают работу в креативной индустрии привлекательной

76% хотели бы попробовать себя в роли креативного продюсера, при этом у половины из них нет четкого представления, чем занимается этот специалист.

Средние зарплаты в отрасли туризма и гостеприимства выросли на 52% за год

Рост внутреннего туризма стимулирует спрос на кадры, а конкуренция за них меняет подходы работодателей.