Согласно стандарту PMI PMBOK, «проект – это ограниченная временем деятельность по созданию уникальных услуг, продуктов или результатов».
В определении важна каждая фраза.
Если деятельность постоянная и не уникальная, то это чистый операционный подход: техническая поддержка, обслуживание клиентов в супермаркете или любая другая деятельность по поддержанию текущих процессов. Разумеется, когда компания сдает бухгалтерский баланс, эта деятельность имеет начало и конец, но она довольно жестко определена регламентами.
Рис. 5. Отличия проекта от операционной деятельности
В работе автозавода каждый автомобиль относительно уникален (не хочется расстраивать ничей автопром, но в случае некоторых компаний никогда не знаешь, какой сюрприз тебя ждет в новом автомобиле), но сама деятельность постоянная и, если не брать во внимание форс-мажоры, непрерывная. Поэтому ее правильнее относить к операционной.
То есть к проектам мы можем относить все, что является той самой временной деятельностью с уникальным результатом и множеством стрессовых факторов по его достижению. Теперь плавно переходим к критериям успешности проекта.
Есть три ключевых аспекта, на которые нужно ориентироваться при определении успешности.
Проект успешен, если он совершен в изначально установленные сроки.
Проект завершен в рамках выделенного бюджета (и здесь речь в первую очередь идет именно о себестоимости, а не о маржинальности или выгоде, получаемых от реализации этого проекта).
Удовлетворенность заказчика. Причем под этим следует понимать реализацию его задокументированных потребностей и пожеланий.
Эти три параметра подводят нас к проектным ограничениям или идее проектного треугольника. Мы полагаем, что про треугольник знает подавляющее большинство менеджеров, в том числе и те, кто не работает в проектной среде. Расхожая фраза «любую работу можно сделать быстро, дешево, качественно – выберите два параметра, третьим придется пренебречь», как раз и определяет проектный треугольник.
Рис. 6. Проектный треугольник
Как работает проектный треугольник? Все относительно просто: в проекте есть содержание, то есть то, что команда должна реализовать в конечном итоге. Разделяют содержание продукта – свойства и функции итогового результата, продукта, услуги и содержание проекта – работы, которые необходимо выполнить, чтобы получился продукт с этими характеристиками. У команды есть сроки, в которые нужно уложиться при выполнении работы. И есть стоимость: в каких бюджетных объемах мы должны это реализовать.
Семья из четырех человек собирается в отпуск в другую страну. В их планах прилететь на побережье, несколько дней там отдохнуть, затем взять в аренду машину, проехать по прибрежным городкам, протестировать местные аквапарки, национальную кухню, пообщаться с жителями (ради практики в языке, например). Это содержание проекта. В качестве времени проекта берется как само путешествие, так и время подготовки к нему: бронь отелей и транспорта, исследование маршрута и все, что с этим связано. В бюджет входят и затраты на времяпрепровождение в отпуске, и стоимость подготовительных мероприятий: получить визы, пристроить любимых котов в хорошую гостиницу и так далее. Все это относится к себестоимости проекта.
И вот буквально в первый день отпуска на побережье из-за скачка курса валют семья понимает, что бюджета в рублях, который выделен на отпуск, никак не хватит на реализацию всех планов. Тут и вступает в действие проектный треугольник.
Можно изменить содержание проекта, например, отказаться от аренды машины и поехать на автобусе. Можно сократить сроки, если обратный билет планировалось купить позже. А можно привлечь дополнительное финансирование, используя незапланированные траты с кредитной карточки главных героев.
В любом случае проектный треугольник поменяется, если поменялась одна из его сторон.
Чем занимаются проектный менеджер и команда в проекте? Первоначально, на этапе планирования, они определяют уже упомянутые проектные ограничения (содержание, сроки, бюджет). А вот дальше на проектный треугольник начинают воздействовать разнообразные риски и буквально растаскивать его в разные стороны, меняя любую из сторон. А это автоматически приводит к изменению любой другой стороны треугольника. Впрочем, само изменение этого треугольника является обязательным следствием неопределенности, в которой работает проектная команда.
Работа над проектом от А до Я требует от людей постоянной вовлеченности в процесс, что порой буквально сжигает людей на рабочем месте в огне постоянного стрессового напряжения. Проявления стресса могут быть весьма разнообразными. Однако стресс имеет свойство накапливаться, и это связано с интенсивностью и длительностью работы в проекте. Очень многие устают, выгорают, и их продуктивность падает. Некоторые сходят с дистанции.
Где-то год назад я тащилась из проектного офиса по заваленной снегом Москве после очередной порции пистонов на оперативном совещании у клиента, неся домой ноутбук и зная, что до 23 нужно наваять протокол совещания и отправить проджекту, чтобы с правками он ушел на согласование клиенту до полуночи. И мне стало непонятно почему плохо, голову сдавило, я обняла столб и думала – ждать ли автобус по вечерним пробкам или пройти остановку до Павелецкой и там заскочить в аптеку. Начинала уже идти, но побоялась упасть и таки дождалась автобуса. В аптеке мне дали стул, таблетки, воды, распаковали тонометр – 180 на 120. Тетеньки удивились, дали валидолу. И я очень четко запомнила то ощущение: а ведь если я сдохну тут прям на остановке – в проекте об этом забудут послезавтра. Зачем мне это? Чего на самом деле-то хочется? Я лучше буду лепить пельмени в Исландии. Потом после больничного я уволилась.
Юлия Г., менеджер IT-проектов
Организм несколько лет пытался адаптироваться, но, когда в одной точке сошлись запредельная для него нагрузка и невозможность с ней справиться, это отразилось на физическом и психологическом здоровье.
Чем же так сложна работа в проектах? Почему все без исключения люди, работающие на результат в командах, в той или иной степени испытывают постоянное напряжение и стресс? Ответ заложен в самом понятии проекта. В его временном характере и уникальности.
Если у проекта не будут определены моменты начала и окончания, то мы рискуем не получить результат никогда или существенно позже, чем нам этот результат нужен. Именно в постоянной гонке за бегущим временем разворачивается стрессовое напряжение. Постоянные дедлайны заставляют человека работать по 12–14 часов, на пределе своих возможностей.
Из-за уникальности проекта команда, как мы писали чуть раньше, часто работает в условиях жесткой неопределенности. Ни у нее, ни у менеджера проекта почти никогда до финала нет окончательного, целостного понимания маршрута и итогового результата, который устроит заказчика. Кроме того, новизна и уникальность подразумевают большое количество рисков, которые могут произойти в процессе. Дополнительно команда от проекта к проекту меняется, что добавляет руководителю определенной «головной боли».
Для большинства людей такие вводные данные в принципе неприятны. И с этой нагрузкой необходимо справиться в условиях ограниченных ресурсов (а по-другому почти никогда не бывает) и в четко определенные сроки, которые, будем честны, не всегда адекватны.
Чтобы в этом выжить, упорядочить работу и достичь успеха, еще с середины прошлого века проектный подход, в том числе в части психологии управления, исследуется многими проектными институтами по всему миру: Project Management Institute (PMI) в США, International Project Management Association (IPMA) в Евросоюзе (Совнет в России), Project and Program Management for Enterprise Innovation (P2M) в Японии и другими организациями из многих стран. Они создают свои стандарты и платформы для полноценного управления проектами.
М.: Можешь простыми словами объяснить, зачем эти стандарты нужны?
А.: Все просто. Волонтеры, формирующие тот или иной стандарт, собирают работающие практики в проектном управлении. Работа по единому стандарту позволяет договориться о том, на каком языке будут общаться участники проекта, по каким правилам выстроят процессы и как будут определены критерии успешности.
М.: Так, по идее, в разных сферах деятельности должны быть разные стандарты?
А.: Не совсем. Универсальные стандарты не зависят от типа проекта – создается ли программный продукт, конструируются ли вертолеты или возводятся здания. Если компания работает по единому стандарту, участники проектной деятельности смогут хорошо понимать друг друга. Кроме того, вместо «кусочного», фрагментарного управления стандарты дают единый управленческий подход.
Обычно в стандартах уделяется большое внимание формальному распределению ролей в команде: руководитель проекта, администратор, риск-менеджер, заказчик, куратор проекта и другие роли. Но, как правило, психологический и социально-психологический аспекты такого распределения выражены, к сожалению, слабо.
Любой проект описывается его жизненным циклом, маршрутом перехода из точки запуска в точку получения продукта или результирующей услуги. Жизненный цикл разбивается на фазы (этапы, итерации), каждый из которых имеет свое функциональное назначение и конкретный проверяемый результат на выходе.
На текущий момент принято разделять жизненный цикл в классическом понимании и в набирающих популярность гибких подходах, известных под зонтичным брендом Agile.
Рисунок 7. Варианты дизайна жизненного цикла проекта
В классическом проектном управлении для описания жизненного цикла проекта используется каскадный подход, который выглядит как поток, последовательно переходящий из одной фазы в другую. Здесь вы четко понимаете, что должно быть результатом всей работы, и, исходя из этого знания, заранее планируете процесс. В таком случае появляется вполне понятная структура, которая может быть сведена к последовательности: инициация (запуск проекта, определение целей), планирование (определение того, как именно будет реализован проект), реализация, проверка или тестирование результата, закрытие проекта и передача продукта заказчику.
В гибком подходе Agile есть те же самые активности – от инициации до закрытия проекта, но есть и отличия. Предполагается, что продукт проекта может меняться в процессе создания, так же, как и вариант его использования бизнесом. Поэтому двигаться нужно небольшими по времени (от недели до месяца) шагами – итерациями, выдавая промежуточные результаты для получения обратной связи от заказчика.
В Agile первичны видение продукта, простота управленческих практик, адаптивность. Основой работы становятся кросс-функциональные (состоящие из специалистов различных функций или отделов) команды, каждая из которых связана со своей частью конечного результата. И команда сама выбирает инструменты и методы, при помощи которых, будет идти к цели.
Каждый из подходов, стандартов, методов формулирует свой набор ценностей. Например, практики Agile исходят из идеи, максимально близкой VUCA-миру, известной как Agile-манифест:
1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с клиентом важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
О чем этот набор установок? Часто в жестких иерархичных организациях (да и не только в них) самыми важными приоритетами являлись следование процессам, использование предопределенных инструментов, документирование всех процессов, догмат единожды и навсегда сформированного плана.
Однако мир стал меняться быстрее, чем все ожидали, и обнаружилось, что процессы без людей просто набор никому не нужных регламентов, документация без наличия итогового продукта – фикция. Условия контракта важны, но если нет сотрудничества, то контракт становится однократным. Поэтому и появился манифест, который подразумевает важность всего: людей, процессов, продукта, документации, сотрудничества и контракта. Но люди, продукт и сотрудничество – важнее.
Мы не будем фокусироваться на типе подхода, который работает в организации. В конечном итоге проблемы и задачи везде схожи. Нас больше интересует то, что происходит с людьми в процессе работы над проектом и какие внутренние драйверы их мотивируют на достижение результата.
Однако мы не случайно упомянули про систему установок и ценностей, связанную с разными методологиями и практиками проектного управления.
Про ценности на разных уровнях корпоративной культуры говорят уже лет 20, а то и больше. Стены наиболее продвинутых компаний пестрят этими ценностями, сайты, брошюры, описывающие их, кричат: «Наша компания вот такая, у нас есть видение!» К сожалению, сплошь и рядом многое является бутафорией. Особенно это видно для специалистов внутри компании.
Сложно верить в ценность «безопасность», когда собственное руководство экономит деньги на этой самой безопасности. Сложно верить в ценность, если где-то в теплой стране собрались топ-менеджеры, «поштурмили» и выдали «на-гора» несколько лозунгов, которые теперь должны стать основой мышления компании.
– Ценности? Ха! Да, я тебе расскажу, как у нас с ценностями работают!
– Так, судя по началу, продолжение будет интересное.
– У нас ценности – это то, что нужно зазубрить и четко по номерам на тестировании рассказать. А не расскажешь и не вспомнишь – сам понимаешь…
Из беседы со знакомым руководителем проекта
Настоящие, а не декларируемые ценности – это то, что исповедуют живые люди, как они себя ведут, что делают, как принимают решения. И, если хочется понять реальные ценности в компании, стоит посмотреть на базовую проектную единицу проекта – проектную команду.
1.3. Живые команды
Проектная команда – это, как правило, временная организационная структура, которая создается целевым образом на период выполнения проекта. Она объединяет отдельных специалистов, группы и/или организации, привлеченных к выполнению работ и ответственных перед руководителем проекта за их выполнение. Это могут быть как внутренние, так и внешние исполнители и консультанты. Каждый из них обладает знаниями и набором навыков в конкретной предметной области.
Тут нужно сделать отступление. В этой книге речь пойдет фактически про любую команду, которая собирается для реализации той или иной задачи. Однако в первую очередь мы будем фокусироваться именно на проектных командах.
В соответствии с классической моделью проектного управления в команде проекта есть четыре звена принятия решения:
Куратор проекта – как правило, высокопоставленный человек в организации, к которому обращаются в случае дефицита ресурсов. Отслеживает связь результатов проекта со стратегией компании и оказывает проекту поддержку: административную, финансовую, в зависимости от задач проекта.
Руководитель проекта – управленец, на котором лежит вся полнота ответственности за результаты проекта. Тот, кто должен принимать управленческие решения в проекте.
Команда управления проекта – специалисты, которые помогают руководителю осуществлять управление (планирование, анализ рисков, взаимодействие с заказчиком и т. д.). Команда исполнения проекта – специалисты, которые непосредственно задействованы в исполнении планов проекта, обладающие профильными знаниями и навыками.
Успех всего проекта во многом зависит от эффективности работы всех частей этой структуры. От умения менеджера проекта определить и привлечь к работе необходимых специалистов зависит снижение рисков проекта и потенциальных проблем. Важно с самого начала использовать опыт всех членов команды для решения возможных проблем проекта. В крупных проектах менеджер может управлять относительно небольшой командой ключевых сотрудников, каждый из которых отвечает за собственный подпроект и свою часть команды.
Каждый сотрудник проекта выполняет свои функции, роли и контролирует свою зону ответственности. Каждый понимает свой объем работ и ориентируется на требования к результатам своей деятельности.
