В этой статье я начинаю раскрытие секретных сценариев на которых базировалась советская школа управления проектами. Я расскажу сначала о довольно простом во внедрении сценарии управления подрядчиками на примере Заказчика/Геподрядчика Строительства. В том числе расскажу о секретной методике «укрупненных норм», которую хорошо знали профессионалы работавшие в советских ТРЕСТах (по-сути проектных офисах строительных проектов СССР). Все методики я показываю на примере реализации в Turbo Project, но практически без изменений они могут быть применены пользователями Spider Project. Отличие составляют только коммуникационные сценарии американской школы управления проектами, которыми дополнена русская методология управления проектами в части коммуникации с подрядчиком по составам работ и интеграции с существующими в организации бюджетными моделями в Excel. Подробнее о различии русской и американской школ управления проектами я рассказал в этой популярной статье , которая, как вы можете увидеть по голосованию через Google даже побила новость о выходе публичной версии MS Project 2013 . Интерес к методологии сейчас больше чем просто к инструментам. Но еще раз отмечу, русская методология управления проектами требует даже для сравнительно простого сценария управления проектами с точки зрения заказчика дополнительного функционала такого как физические объемы, нормы, типовые фрагменты и коммуникационные формы. Этого вы не сможете сделать в «голом» MS Project. Вам потребуется расширить функционал MS Project с помощью Turbo Project или применить Spider Project.

Я расскажу в этой статье много интересного. Какой секрет содержится в старых советстких мануалах по проектированию атомных реакторов? Почему «волшебный дедушка» ранее работавший в советском ТРЕСТе наводит ужас на подрядчиков своей баночкой зеленки? Почему в СССР выкидывали на помойку толстые регламенты управления проектами? Знают ли даже строители, что в советском ТРЕСТе использовали еще один вид секретных норм, которых нет в современных сметах? Почему я навожу ужас на 1С:Франчайзи прося их решить простую задачу о проценте завершения проектов? И многое другое.

 Искусство регламентов управления проектами в СССР. Краткость и эффективность как у армейского Устава

Вероятно это единственный учебный материал, где вы можете сможете увидеть не имитацию регламентов путем copy/paste из PMBOK в расчете на некомпетентность заказчика, а реальный боевой регламент. Причем что интересно за основу взята модель регламентов СССР. Так называемые «карточки» ведения проектов. От меня спасибо дорожным строителям, которые меня познакомили с такой эффективной формой регламентов управления проектами.

Обратите внимание на важные детали:

• Регламент предельно краткий, «водяные регламенты» были вне закона . Это было требование советской школы. Фактически регламенты использовались также как «технологические карты» производства, поэтому во многих случаях главки регламентов больше... одной страницы A4 немедленно отправлялись в мусорный бак, т.к. это являлось признаком «воды» и некомпетентности составителя. Так же как технологическая карточка или как главка армейского Устава советский регламент УП был по спартански лаконичен. Лаконичность связана с тем, что исследование советских методологов показали, что с увеличением размера регламента резко падает процент его реального использования персоналом. Это верно и в наши дни.
  
   
• Центральная часть регламента — это пошаговое описание процессов планирования, отслеживания и составления отчетности для руководства. Фактически это Communication Plan в терминах PMBOK.
  
   
• В советских регламентах запрещалось нарушать принцип интеграции процессов планирования и отслеживания . Сейчас многие консультанты-мошенники сдают заказчикам под видом регламентов управления проектами просто скопированные разделы PMBOK, это видно потому, что в таких псевдорегламентах отдельно описывается управление поставками, управление рисками, управление стоимостью и т.п. Просто в PMBOK данные процессы Дункан описан отдельно, но он также указал,что нужно соблюдать принцип интеграции процессов управления проектом (Process Integration) . В советских карточках по управлению проектами этот принцип соблюдался строго. В составе интегрированного процесса планирования описывалось и управление стоимость и рисками и др., при этом подпроцессы не выделялись, но четко показывалось как шаги связаны между собой.

Планирование с использование библиотеки типовых фрагментов и нормативов сверху-вниз строителей и проектантов СССР

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

Технологические процессы описывались с помощью библиотеки типовых фрагментов, т.е. элементов иерархической структуры работ. В обычном MS Project такой методологией не воспользоваться, т.к. он понимает только шаблоны на проект целиком, а тут требуются шаблоны на фрагменты работ. Такая возможность есть в Turbo Project и Spider Project. Есть и различие. Spider Project является переделанной программой созданной первоначально в СССР для управления исключительно строительными проектами. Turbo Project имеет много клиентов в проектировании, поэтому тут повлияла русская школа НИОКР, которая отличается от строительной. Отличие в том, что проектант в СССР использовал эту методологию сложнее чем строитель: применялись вложенные в друг друга типовые фрагменты для описания технологии проектирования, а также применялся специальный вид нормативов распределения сроков «сверху-вниз». Эта методология поддерживается Turbo Project. В принципе в «методических рекомендациях по планированию» для строительных ТРЕСТов СССР также содержалась такая методика, но в Spider Project ее нет, т.к. эти рекомендации по нормам сверху-вниз разрабатывали специалисты в Москве, а нормы снизу-вверх разрабатывали в Одессе, которая родина Спайдера.

Запрос детализации работ

Весьма ценный сценарий планирования с запросом детализации работ. В советских регламентах применялся также, но был и у американских коллег. Мне больше нравиться именно американский вариант по удобству использования, он и реализован в Turbo Project. Лучшие традиции коммуникации и планирования в стиле Microsoft Office. На мой взгляд эффективна комбинация методологии типовых и методики запросов составов работ.

Интересное наблюдение. Один из проектных институтов Лукойла поставил фактически рекорд внедрения Microsoft Project Server запустив внедрение на 700 рабочих мест за считанные месяцы весьма незначительными ресурсами. Хитрость была в применении схемы бизнес-процессов через планировщика, который планировался путем массовых запросов детализации работ к ведущим специалистам в группах.

Планирование физических объемов работ. Тонкие моменты как не сломать Освоенный Объем при отслеживании дальше

Русская школа управления проектами является самой сильной в мире в ресурном плане, поэтому не удивительно, что физические объемы это базовый элемент планирования для строителей и производственников. Без физических объемов невозможно дальше привязывать ресурсы к задачам через нормы. Однако есть «военные хитрости». Даже если вы не планируете использовать нормирование ресурсов, вы должны аккуратно вводить расценки по физическим объемам и видам технологических операций, в противном случае вы уничтожите систему Освоенного Объема при дальнейшем отслеживании проектов. Типичная ошибка специалиста, который обучался только по американским методикам PMI и не ознакомлен с русскими хитростями использования комбинации физических и освоенных объемов.

 Укрупненные нормативы. Хитрая задача получения % завершения по проекту. Секрет «волшебного дедушки» с банкой зеленки

В последнее время когда я встречаю коллег из 1С уверяющих, что они что-то понимают в управлении проектами, я их убиваю наповал этой задачкой. Я просто быстро доказываю, что все поделки по управлению проектами в 1С не могут сообщить директору .... какой процент завершения проекта сейчас!!! :) На деле задача далеко непроста. Дело в том, что вы должны корректно сложить проценты завершения по разным задачам для выхода на проценты по суммарным задачам и всему проекту. Это можно сделать только используя понятия «веса» задач. В обычном MS Project как «вес» используется длительность задач, это подойдет для управления IT-проектом. Однако для производственных и строительных проектов полная глупость, т.к. короткая операция по монтажу металлоконструкции куда более значима, чем длительная операция по уборке строительной площадки гастробайтерами.

В реальности существуют два способа. Можно складывать проценты задач либо через деньги, либо через трудозатраты. В обоих случаях не получится обойтись без норм. Если использовать как вес деньги, то без стоимости единицы физического объема получаться некорректные значения Освоенного Объема. Но в реальности профессионалы знающие как работали в СССР используют чаще как вес трудозатраты. Дело в том, что тут все равно возится с нормами. Без разницы по организационной сложности эксплуатации решения вводить сколько денег или сколько часов на единицу физического объема. Однако метод через трудозатраты имеет преимущество. Дело в том, что через него не только легко выйти на корректный процент завершения проекта и его этапов, также можно ответить на ключевой вопрос для любого заказчика строительства: «сколько сейчас должно быть людей на площадке?». Я знаю одного «волшебного дедушку», который работал в советском ТРЕСТе, так он наводит ужас на подрядчиков своей баночкой зеленки. Он приезжает на площадку и помечает строителей из дружественных республик на площадке этой зеленкой, чтобы при пересчете дважды не подходили. Все подрядчики в шоке, как он догадался о нужном числе людей не имея даже полного комлекта смет. Секрет прост. «Волшебный дедушка» в Spider Project завел укрупненные нормы в разрезе «рабочий» (без специальностей), потом накинул директивные сроки и программа показала сколько в какое время должно быть людей.

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

Интересный момент,что коллеги в 1С во всех своих конфигурациях по управлению проектами сделали методологическую ошибку перешедшую в архитектурную и делающее ПО непригодным для реального использования. Хитрость вот в чем, поскольку нормы укрупненные, то они не могут быть точными для разных операций и там правятся в зависимость от условий или концевика сметы (если смета есть). Чтобы поддерживать такой сценарий Spider Project и Turbo Project поддерживают понятие «локальной нормы», т.е. на конкретной операции норма может быть отредактирована и отличаться от справочника.

 Сбор фактических данных по периодам на примере заказчика строительства

Сбор фактических объемов делается по периодам. Весьма похожа реализация в Turbo Project и Spider Project (модуль учет). Мы первыми предложили сбор факта через Обменные Формы Excel, метод оказался таким эффективным, что разработчики Spider Project скопировали его с нас. :)

Отметим, что Turbo Project управляет периодами учета также как MS Project Server через понятие закрытых и открытых периодов и их нумерации. Для пользователя MS Project Server поэтому не требуется переучиваться.

 «Переходный лист» как методика интеграции с существующей финансовой и ресурсной информацией

Интересная методика-дополнение. Сколько бы ERP не внедряли, все равно финансисты останутся в Excel. Просто Excel как и MS Project умеют показывать влияние факторов на модель в реальном времени, поэтому возможен подбор оптимального плана путем игры «а что если?». Масса оборудования также имеет нормы расчета, которые сложнее линейных норм Turbo Project и Spider Project. Например, не поверите, но нормативы для тепловоза считаются через интегралы. В таких частных расчетных задачах для финансов или ресурсов пользователь может решить свои проблемы путем создания модели на формулах Excel. Вопрос как импортировать в реальном времени эти финансовые и ресурсные модели в график MS Project, особенно если такие расчеты сделаны в аналитике не совпадающей с проектной системой?

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

Оригинал: http://www.microsoftproject.ru/articles.phtml?aid=452