BoatmansHome: Проект ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Введение в проектное управление


Оглавление

Предисловие к разделу


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


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


Перечислю лишь некоторые упущения в части знаний, навыков и умений у коллег, приступающих к изучению (в частности) проектного управления:


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


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

Что такое проект


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


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


Все дело в том, что перед стартом проекта мы собираемся (в любых сочетаниях):


Чтобы лучше запоминалось, разделим отличия проекта на три части:


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


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


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


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


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


Еще раз повторю: Менеджер проекта, ты тратишь деньги спонсора и основная твоя задача – бережное к ним отношение, которое заключается

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

Пункт 2 создает органический конфликт интересов менеджера проектов, так как фиксация убытков лишает менеджера проектов рабочего места (как минимум в этом проекте).


Отсюда следует один скандальный вывод: управление проектами не предназначено для менеджеров проектов. Точнее, менеджер проекта, как роль, чаще всего не в состоянии без искажений применять базовые постулаты управления проектами.


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


И последнее, что необходимо упомянуть в этом разделе. Для кого-то это само собой разумеется, но для некоторых становится открытием на заре изучения управления проектами (и хорошо, если на заре).
Так вот, в проекте все параметры присутствуют как минимум в трех состояниях:

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

Место проекта в других системах отношений


С точки зрения товарно-денежных отношений проект находится в ряду других видов отношений:


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

Роли и отношения


Сначала список:


Роль Может (рычаги) Должен (отвечает за) Хочет (интересы)
Спонсор вне проекта монетизирует или оценивает эффект; для проекта может обеспечить поступление денег с оговоренной скоростью и/или выдачу ресурсов в натуральных единицах измерения для проекта своевременное финансирование; вне проекта за прямой или косвенный возврат вложений получить прямой или косвенный возврат вложений на основе достигаемого эффекта и (обычно) как можно дешевле
Заказчик вне проекта может обеспечить получение эффекта на основе созданного результата; для проекта обладает информацией о процессе использования и нанесения эффекта вне проекта получение эффекта; для проекта полноту и качество информации о критериях приемки результата, о желаемом конечном эффекте, о связи между ними вовремя получить эффективный результат
Исполнитель может выполнять определенные виды работ сдачу промежуточного/окончательного результата в оговоренном объеме, качестве, в обещанные сроки и с оговоренными затратами максимизация фактического часового тарифа одним из из двух путей: или максимальная оплата за фиксированный объем, или максимальный запас производительности (минимальный объем) при фиксированной оплате (на самом деле здесь все чуть сложнее, но пока это не так существенно)
Поставщик может поставлять определенные виды ресурсов/инструментов/материалов поставку ресурсов/материалов/инструментов в оговоренном объеме, качестве, в обещанные сроки и с оговоренными затратами реализовать максимальное отношение затраты*сроки/объем/качество, то есть поставлять долго, дорого, мало и в соответствии с собственными представлениями о качестве
Менеджер проекта может вести переговоры со всеми сторонами и достигать контрактирования взаимных обязательств (включая свои) для организации работ поставку эффективного результата в оговоренных ограничениях по времени и ресурсам ИЛИ минимизацию потерь в случае отсутствия эффективного результата ???

Теперь про отношения:



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


Казалось бы все не так уж сложно, но не тут-то было.


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


Но это еще не все. Теперь поговорим о проектных решениях и ответственности.

Проектные решения и ответственность


Будущего не знает никто, и любые проектные решения сопряжены с риском потерять деньги спонсора. Это с одной стороны.
С другой стороны кто-то должен принимать проектные решения в условиях неопределенности (а это трудно и неприятно) и нести за них какую-то ответственность.
С третьей до конца не ясно, а чем отвечают люди, принимающие проектные решения.
Самые главные решения, касающиеся проекта – это связь эффекта с результатом, точные формальные критерии приемки результата и способ получения результата, иногда еще затрагивается связь эффекта с отдачей.


Ответственность в товарно-денежных отношениях (а они на работе у нас именно такие) подразумевает прямые или косвенные финансовые последствия принятых решений. Например, не сделал работу – лишили премии; три раза не сделал – уволили.
Теперь давайте посмотрим на это глазами менеджера проектов и исполнителей: наемный работник, за исключением редких случаев, не может понести ответственность, превышающую размер оклада, умноженный на число месяцев в поисках следующей работы (премию для простоты не учитываем). Да и то такие случаи единичны. Какого размера бюджет можно доверить такому сотруднику?
Это зависит от того, как мы считаем. Если равенство ущерба по номиналу, то никакого проектного управления с наемными сотрудниками быть не может. Если же считать в пропорции от годового оборота (потерял 2% от оборота компании – срежем 2% от годового дохода, что как раз примерно соответствует лишению премии), то наоборот, никакой ответственности быть не может при нормальном состоянии рынка труда (имеются ввиду нормальные размеры окладов, позволяющие не зависеть критично от премии).


В итоге приходится подключать множество других факторов как (условно) объективных

так и субъективных


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

Немного об искажениях


Частые варианты ущемления интересов сторон:

Уточнение ролевой модели


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

Как быть с искажениями


В целом, для всех проблем, описанных выше, есть инструменты их полного или частичного решения с разными побочными эффектами и вариантами сочетания.
Я условно поделил эти инструменты по направлениям:

Практика выделения ключевых параметров проекта

Эффект


Не-эффект – деньги
Не-эффект – результат, как вещь в себе

Результат


то, что можно приемо-сдать и закрыть проект

Ключевые ограничения


Сроки, бюджет – при каких условиях теряется интерес целиком или существенно
Объем, качество – при каких условиях обеспечивается эффект, то есть сохраняется интерес

Ролевые позиции


Кто кем заходит в проект

Ключевые принципы проектного управления

Конус неопределенности и финансовые потоки

Проект, как финансовый актив

Жизненный цикл проекта

Связь эффект-результат

Проработка ограничений проекта

Проектный цикл, системно-аналитический цикл

Ступенчатое проектирование и требования

Планирование и оценка

Управление ресурсами и активами

Риски

Ключевые механизмы проектного управления

Устав

Требования

План проекта

Внешний контур управления

Внутренний контур управления


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]