Проектное управление: план игры

Логотип компании
Проектное управление: план игры
В российской действительности можно отметить невосприимчивость проектных систем к инцидентам, их обнаружению и быстрому устранению

Будущее — это тщательно обезвреженное настоящее.

Аркадий и Борис Стругацкие

 

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

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

Как известно, все идет от головы... Вот уже года три, как даже государственные чиновники обратили внимание на технологии проектного управления. Раньше существовали попытки разной степени успешности внедрять проектную технологию в бизнес-среде, а сейчас машина проектного подхода набирает обороты по всей стране. Достаточно вспомнить выступление Президента РФ на первом заседании Совета по стратегическому развитию и приоритетным проектам. Тогда Владимир Путин подчеркнул, что без проектного подхода решить стоящие перед страной задачи невозможно[1]. И все закрутилось...

Казалось бы, мы и раньше знали, что проектное управление это «клево», да и Президент указал явное направление куда идти... и мы пошли, только вот результаты наши весьма скромные, если не сказать больше. Местами деятельность по внедрению проектной технологии напоминает потемкинские деревни. Почему хочется как лучше, а выходит как всегда? Давайте подумаем вместе.

Нет технологии без культуры

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

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

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

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

Посмотрим на некоторые особенности национальных систем управления через призму их отношения к негативному незапланированному событию, то есть к инциденту. Для тех, кто захочет глубже погрузиться в эту тему, рекомендую обраться к опубликованным материалам Владимира Ананьева и, в частности, к статье «Особенности национального управления»[2].

Русская модель управления

Если рассмотреть эволюцию инцидента на временной шкале, она будет выглядеть так, как показано на рис. 1.

  Проектное управление: план игры. Рис. 1

Рис. 1. Временная шкала  эволюции инцидента

 

Основные реперные точки эволюции инцидента:

  • Время возникновения причины, которая обусловливает или предшествует инциденту. Причин может быть несколько, но всегда можно выделить главную.

  • Время обнаружения инцидента, когда инцидент стал заметен.

  • Время устранения инцидента, то есть время устранения последствий или их принятия, с последующей корректировкой действий.

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

В зависимости от реакции системы на инцидент различают несколько обобщенных моделей управления:

  • Японская модель — не допускать инциденты.

  • Американская модель — быстро устранять инциденты.

  • Российская модель — устранять чрезвычайные ситуации.

Для большей наглядности разместим области применения этих моделей на временной шкале с инцидентами (рис. 2) и дадим краткое их описание.


Рис. 2. Модели управления инцидентами

Модели управления инцидентами

Японская модель. Суть ее заключается в создании ситуации, при которой возникновение известных инцидентов невозможно. Каждый новый инцидент тщательно разбирается на причины и следствия, на основе которых формируется набор мероприятий, препятствующий возникновению подобных случаев в будущем. Для функционирования такой модели необходимы стабильные внешние условия и наличие жестких правил, хорошее планирование и спокойная (свободная от авралов) реализация проекта. Модель ориентирована на профилактику возникновения инцидентов и минимизацию их количества.

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

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

Читайте также
Почему даже системные администраторы должны работать в строго контролируемых рамках? IT-World разбирался, как PAM поможет защитить и администратора и всю компанию от неприятных сюрпризов.

Это значит, что специфика российской модели управления заключается в том, что она имеет маятниковый[3] характер. Другими словами, в каждый момент времени система управления пребывает в одном из двух состояний: либо стабильном, либо кризисном (либо все спокойно, и никто ничего не делает; либо у нас пожар, и все бегут в разные стороны). Я думаю, что не вызывает сомнения, что управление такими разными состояниями системы требует различных подходов и разных инструментов управления.

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

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

Методы и инструменты

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

С точки зрения методов управления проектами они описаны в соответствующих технологиях или стандартах той или иной страны (PMBoK, PRINCE2, P2M, AFW, IPMA, SCRUM и прочие). В чем отличие? Несмотря на то что каждый из этих методов описывает одну и ту же предметную область, все они имеют национальные особенности, поскольку появились в разных странах. Например, PMBoK склонен к управлению ресурсами. Вы представляете русского человека, которым можно управлять как ресурсом? Догадываюсь, что улыбаетесь. Вы пробовали использовать HR-подход AFW не на немцах, а на русских? Вы же не думаете, что без крепкого словца и указания на чью-то матерь у нас что-то будет делаться? Вот оно, проявление культуры в методе управления. Надеюсь, уже все понятно и про японский P2M можно не говорить.

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

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

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


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

Во-вторых, сообразно вашей культуре следует подобрать наиболее приемлемую методологию управления проектами. Например, для меня это PRINCE2.

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

 Немного патриотизма

Думаю, что у вас, дорогой читатель, должен возникнуть законный вопрос: почему я перечислил только иностранные методологии, разве у нас нет своих? В нашей большой и сильной стране, которая имеет наглость спорить с США, нет своей технологии?

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

Водоизмещение – 18 640 тонн

Дальность плавания ~ 12 000 км

Максимальная скорость ~ 65 км/час

Размерения ~ 210/23/7,3 метра

Экипаж ~ 1200 чел

Если подняться на борт, становится понятно, что это плавучий город со всеми атрибутами и инфраструктурой. Но самое интересное, что корабль был заложен в 1951 году, а сдан в эксплуатацию в 1954-м! Только подумайте, крейсер заложили лишь через пять лет после окончания Великой Отечественной войны и закончили всего за три года. Это значит, что к моменту начала строительства была разработана вся необходимая документация и конструкторские решения, определены подрядчики и требуемый на верфи персонал. В СССР в 1951 году были не только директора, инженеры, конструкторы и высококвалифицированные рабочие разных специальностей, но и ТЕХНОЛОГИЯ, позволяющая планировать и контролировать ход выполнения работ.

Такой технологией в 50-е годы прошлого столетия была технология сетевого планирования и управления (СПУ). Данный предмет преподавался во всех технических вузах СССР. Так что, у нас все было... и было неоправданно потеряно.

Читайте также
Как грамотно подойти к модели «нулевого доверия» (Zero Trust Network Access), как адаптироваться к ней, а также о многом другом IT-World рассказал Виталий Даровских, менеджер по продукту UserGate Client компании UserGate.

Вместо резюме

Для работы в российской действительности необходим набор инструментов, эффективный для наших типичных состояний проектной системы (стабильной и кризисной). Набор инструментов, апробированный на практике и точно работающий в наших условиях в настоящее время, формируется в «Российской инструментальной модели RIM-III[4]», авторство которой принадлежит Павлу Алферову. Одним из таких универсальных инструментов, вошедших в RIM-III, является технология управления проектом по контрольным точкам. И хотя данная технология пришла к нам из-за рубежа, можно констатировать, что в основе ее лежит наша СПУ, только очищенная от сложного математического аппарата. Так что не вешать нос — у нас все есть!

 [1] https://rg.ru/2016/07/13/putin-prizval-primeniat-proektnyj-podhod-dlia-resheniia-vazhnejshih-zadach.html

 [2] http://upr.ru/author/163

[3] А. Прохоров. «Русская модель управления».

[4] http://rim-iii.postach.io/

 

Проектное управление: план игры. Рис. 2

Опубликовано 18.06.2017

Похожие статьи