Чем занимаются проектный менеджер и команда в проекте? Первоначально, на этапе планирования, они определяют уже упомянутые проектные ограничения (содержание, сроки, бюджет). А вот дальше на проектный треугольник начинают воздействовать разнообразные риски и буквально растаскивать его в разные стороны, меняя любую из сторон. А это автоматически приводит к изменению любой другой стороны треугольника. Впрочем, само изменение этого треугольника является обязательным следствием неопределенности, в которой работает проектная команда.
Работа над проектом от А до Я требует от людей постоянной вовлеченности в процесс, что порой буквально сжигает людей на рабочем месте в огне постоянного стрессового напряжения. Проявления стресса могут быть весьма разнообразными. Однако стресс имеет свойство накапливаться, и это связано с интенсивностью и длительностью работы в проекте. Очень многие устают, выгорают, и их продуктивность падает. Некоторые сходят с дистанции.
Где-то год назад я тащилась из проектного офиса по заваленной снегом Москве после очередной порции пистонов на оперативном совещании у клиента, неся домой ноутбук и зная, что до 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-манифест:
