Сергей Таратута
Мне приходилось наблюдать много вариантов внедрения методики проектного управления в различных российских организациях. При этом можно выделить ряд вполне конкретных методических проблем, с которыми приходится иметь дело, и которые не упоминаются ни в литературе, ни в разрабатываемых под заказ стандартах проектного управления. Более того, даже в тех случаях, когда существование таких проблем становится осознанным, способы их решения остаются «устным народным творчеством» и не отражаются в регламентах. Отсутствие упоминания о них в литературе играет злую шутку и переносится всеми в раздел «искусства». Не думаю, что это станет откровением для практиков проектного управления, поскольку говорить я буду о сугубо прикладных вещах, с которыми многие из нас сталкиваются. Но надеюсь, что обсуждение их для многих будет интересно.
Немного предыстории (о терминах):
Проектное управление как методика появилась не так давно и выросло из желания навести порядок в слабо формализуемой деятельности, связанной с созданием чего-то нового и уникального в рамках ограниченного времени и средств. И действительно, если что-либо делается впервые, то говорить о какой-то методике бессмысленно. Но если выполнение таких уникальных задач является регулярной деятельностью для организации (научные исследования, разработка новых продуктов, строительство), то необходимость создания каких-то правил становится актуальной. И такую организацию называют проектной или проектно-ориентированной.
В «рафинированном» виде проектный менеджмент ориентирован на описание менеджмента во временном коллективе, созданном для достижения конкретного результата в течение ограниченного, заранее предопределенного времени. Классический пример проектного предприятия – бывший широко популярным некоторое время назад в Штатах метод разработки заказного программного обеспечения путем набора временного коллектива разработчиков на контрактной основе. Закончили работу - сдали – разбежались.
Проектный тип управления, в отличие от обычного «функционального», обладает рядом как достоинств, так и недостатков. Главным его достоинством, пожалуй, можно назвать то, что такая схема обеспечивает наибольшую мотивацию сотрудников. И действительно, именно в проекте сотрудники в полной мере осознают, что они не «кирпичи кладут», а «дом строят».
В то же время, главным недостатком проектной организации является проблема занятости сотрудников в межпроектное время. Чем заняты головы сотрудников в чисто проектной организации, когда проект подходит к концу? Поиском следующего места работы. Естественно, это сказывается на эффективности труда в наиболее ответственный для проекта момент. Кроме того, после выполнения проекта остается сплоченная проектная команда, которую хочется сохранить для новых проектов.
Подобные размышления привели к появлению так называемых «матричных» типов организации, в которых делались попытки объединить преимущества «функционального» и «проектного» типов управления. Но и матричные организации не являются панацеей. Главной и все еще не решенной проблемой всех типов «матриц» является двойное подчинение сотрудников: руководителю проекта и функциональному менеджеру (начальнику функционального отдела, распорядителю ресурсов). Даже в наиболее проектно ориентированных ИТ-компаниях, занимающихся разработкой ПО или системной интеграцией, двойное подчинение является нормой. Даже если руководитель один, то участие сотрудника в нескольких проектах одновременно – в порядке вещей.
С точки зрения проектного менеджмента это нормальная ситуация и почти все используемое в проектном управлении программное обеспечение позволяет автоматизировать процедуру перепланирования ресурсов и сроков выполнения задач на стадии выполнения проекта. Но в жизни все не так просто. Проблема в том, что не все осознают, что ресурсное планирование без адекватной методики «управления изменениями» становится сложной задачей, часто не отражающей реальное положение дел в проекте.
Попытка примерить
Все это развивалось на Западе постепенно. Т.е. постепенно внедрялось, адаптировалось под специфику бизнеса, меняло мировоззрение менеджеров и рядовых сотрудников. Появлялось понимание ключевых принципов: личная ответственность, делегирование полномочий, управление рисками и т.д. Результатом стало то, что определения этих терминов в западной литературе приводятся в предположении об их интуитивной понятности и заведомом существовании описываемых ими явлений в организации.
Попытка внедрения западного проектного менеджмента в буквальном переводе часто сталкивается с широтой русского размаха «все разрушить и построить заново». Здесь трудно не провести исторические параллели с реформами Петра Великого: всем сбрить бороды, носить европейское платье, есть щи вилками…
В результате, периодически приходится слышать скептические замечания о том, что в российской действительности вся эта западная наука не работает. Дескать, пробовали мы – знаем! Часто при этом ссылаются на особые российские условия: менталитет чиновников, пережитки эпохи развитого социализма, загадочность русской души и т.п.
Неужели все так уж бесперспективно? Ведь научились же есть вилками, железную дорогу построили, джинсы одели… Думаю, что и внедрение проектного менеджмента в России является лишь делом времени. Дело именно в том, что не хочется ждать сто лет, но и бежать впереди паровоза не стоит. Итак, о проблемах.
- Двойная отчетность
Признайтесь, господа, а кто из нас не писал отчетов как прямому начальнику, так одновременно и вышестоящему? Для чего это нужно?! Почему Исполнители (рядовые сотрудники) должны отчитываться перед кем-то еще кроме Руководителя проекта? Ведь именно его прямой обязанностью является сбор и консолидация такой информации в форме удобных для руководства сводных отчетов, отражающих суть происходящего. Зачем вышестоящему начальству тратить свое дорогостоящее (хотя бы по зарплате) время на дублирование такой работы?
Возможно, это связано с недоверием к руководителю проектов. Может быть, в таком случае правильным решением будет его замена? Проблема ведь не только в «неэффективном» расходовании высокооплачиваемого времени Руководства, но и в том, что для подготовки «вторых отчетов» требуется дополнительное время Исполнителей. А это стоит вдвойне дороже ввиду того, что их много и все они отрываются для этого от решения проектных задач. Не думаю, что целесообразно нагружать Исполнителей дополнительной рутиной – они же не кирпичи кладут, они дом строят!
- Определение ответственности Исполнителя
За что отвечает Исполнитель в проекте?
(Здесь хочется сделать пару пустых страниц, чтобы уважаемый читатель, перед тем как прочитать ответ, задумался над этим вопросом)
В несколько упрощенной форме можно сказать, что Исполнитель отвечает за то, чтобы выполнить свою работу хорошо и вовремя.
Интересно, для кого из читателей это определение не кажется очевидным? Мой университетский преподаватель по алгебре как-то сказал: «Очевидно – это не то, что Вам, товарищ студент, кажется понятным, а то, что легко доказать!» Давайте немного расшифруем определение:
Хорошо и вовремя это означает - так, как отражено в плане проекта. Например, на диаграмме Ганта в виде отдельного прямоугольника, где указано, что и когда должно быть сделано. Стало быть, если сделано именно ТО и именно ТОГДА, то все Ok? Не совсем.
Во-первых, там, как правило, указано, что является ожиданием Руководителя проекта, а не то, что конкретно должен сделать Исполнитель. А если мы говорим о Проекте (т.е. согласно теории о каком-то новом, уникальном предприятии), то ожидаемый результат вполне может и не быть очевиден как для Исполнителя, так и для самого Руководителя проекта. Разные люди под одним и тем же могут понимать разные вещи. Я думаю, что большинство читателей согласится с тем, что это нормально - такова природа человека.
В таком случае, остается только одно: договариваться. Руководитель проекта должен вразумительно донести до Исполнителя ожидаемый результат его работы, а Исполнитель должен уточнить все непонятные ему детали. Причем все это должно быть сделано перед началом выполнения задачи, а не в момент ее выполнения.
Во-вторых, то же самое относится и к срокам выполнения работ. Что именно мы имеем в виду:
- дату окончания работы Исполнителя,
- дату приемки его результата (например, после проведения испытания)
- или дату приемки работы Заказчиком, которому тоже далеко не всегда очевидно, что это «то самое, что ему нужно»?
Где же в таком случае взять объективный критерий завершения работы? Думаю, что в каждом конкретном случае и каждом конкретном бизнесе это может быть сформулировано по-разному, но Руководитель проектов должен твердо знать и четко понимать этот критерий. А еще он должен учесть его в своем календарном плане и не сваливать вину на нерадивость Исполнителя или капризность Заказчика. Вот тогда, как говорил Шарапов, «у нас будет полная любовь и взаимопонимание». :-)
- Контроль исполнительской дисциплины в проекте.
Всем, кто работал в обычной функциональной организации, знакомо понятие «табеля с восьмерками». Это такая таблица, в которой отмечается, сколько рабочих часов было потрачено сотрудником в каждый конкретный рабочий день. В более изощренной форме эти «восьмерки» еще и расписываются по категориям работ:
- участие в проекте;
- хозяйственные работы;
- тех. поддержка пользователей
- и т.д.
В чем смысл сбора такой информации? В идеале в конце месяца мы получаем «объективную» информацию о занятости сотрудников и можем корректировать рабочие нормы. С точки зрения научного менеджмента занятие это архиважное! Почему же у меня слово «объективную» в кавычках? Потому что, как правило, эту информацию вносят сами Исполнители и, как правило, в конце недели, тщательно высасывая из пальца правдоподобность.
Неужели у кого-то в Табеле есть графа «Веб-серфинг» или «Перекур»? Даже если их и ввести, то вряд ли кто-то поставят туда хотя бы час. А есть ли у кого-то сотрудники, которые не тратят на это время? Хорошо, а нужно ли Руководителю проектов это знать и что мы сможем с этим сделать, если узнаем?
Мое мнение, что знать это незачем. И не потому, что я не знаю, как с этим поступить, а потому, что меня не интересует, чем занимается мой сотрудник, если он выполняет свою работу хорошо и вовремя. Иначе говоря, если сотрудник закончил свою работу – я с чистой совестью ставлю галку «100% completed» не вспоминая, сколько раз я его видел за чтением новостей в Интернет.
А как же быть с «веб-серфингом» и «перекуром»? Можете со мной не согласиться, но я считаю, что без этого нельзя. В Интернете есть не только игры, но и обзоры нового оборудования, а на форумах обсуждают не только анекдоты, но и самые серьезные проблемы, решение которых зачастую не знает даже производитель того, с чем нам приходится работать. Что касается перекуров, то при всем очевидном вреде этого занятия, я много раз видел, как в этом коллективном чаду рождаются блестящие и оригинальные идеи. В конце концов, насколько полезно человек тратит собственное время – его личное дело и это напрямую сказывается на темпах его развития и заработной плате. Те, кто этого не понимает после первого внушения, обычно переходят из проектной на более спокойную работу, где достаточно заполнять табель.
- Проектный героизм.
Еще одно требование к Исполнителям по выполнению проектных задач, которое не встречается в литературе, но является одним из ключевых:
ругать подчиненных нужно не за то, что они не выполнили задачу вовремя, а за то, что они своевременно об этом не сообщили.
Удивительно, что применение этого правила сильно упрощает взаимоотношение с подчиненными и снижает проектные риски. Дело в том, что крайне редко бывают случаи, когда нельзя было бы что-то исправить, ускорить или перенести сроки, если об этом договориться заранее. Но умение предвидеть такие ситуации приходит только с опытом. Добившись такого «раннего оповещения» от Исполнителей, Вы как бы увеличиваете радиус действия своего радара. При этом вы создаете у них чувство уверенности в Вашей «отеческой» поддержке.
Жаль, что добиться этого от российских сотрудников очень нелегко. Связано это, по-видимому, с воспитанием, основанным на многочисленных героических примерах от Ильи Муромца до Матросова. Проявляется это воспитание у всех по-разному, но в той или иной форме почти у всех: студенты учатся только на сессии, депутаты работают в период предвыборной кампании..., а в проектной деятельности так: Исполнители и Руководители часто склонны переоценивать свои возможности и до последнего момента надеяться, что они справятся сами. И более того, некоторые такую ситуацию создают искусственно в надежде на то, что проявленный ими «героизм» будет по достоинству оценен. А если что - приходят с повинной головой, которую, как известно, и меч не сечет.
Бороться с этим можно и нужно. Каким образом – тема для отдельного рассказа.
- За что отвечает Руководитель проекта?
После всего вышеизложенного, думаю, становится понятно:
Руководитель проекта отвечает за то, чтобы проект был выполнен хорошо и вовремя.
Хотя это и не очевидно. :-)
Продолжение следует?
