Алексей Таченков - Живые команды. Управление стрессом в проектах

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

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

Если у проекта не будут определены моменты начала и окончания, то мы рискуем не получить результат никогда или существенно позже, чем нам этот результат нужен. Именно в постоянной гонке за бегущим временем разворачивается стрессовое напряжение. Постоянные дедлайны заставляют человека работать по 12‒14 часов на пределе своих возможностей.

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

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

Чтобы в этом выжить, упорядочить работу и достичь успеха, еще с середины прошлого века проектный подход, в том числе в части психологии управления, исследуется многими проектными институтами по всему миру: Project Management Institute (PMI) в США, International Project Management Association (IPMA) в Евросоюзе (Совнет в России), Project and Program Management for Enterprise Innovation (P2M) в Японии и другими организациями из многих стран. Они создают свои стандарты и платформы для полноценного управления проектами.

М. – Можешь простыми словами объяснить, зачем эти стандарты нужны?

А. – Все просто. Волонтеры, формирующие тот или иной стандарт, собирают работающие практики в проектном управлении. Работа по единому стандарту позволяет договориться о том, на каком языке будут общаться участники проекта, по каким правилам выстроят процессы и как будут определены критерии успешности.

– Так по идее в разных сферах деятельности должны быть разные стандарты?

– Не совсем. Универсальные стандарты не зависят от типа проекта – создается ли программный продукт, конструируются ли вертолеты или возводятся здания. Если компания работает по единому стандарту, участники проектной деятельности смогут хорошо понимать друг друга. Кроме того, вместо «кусочного» фрагментарного управления стандарты дают единый управленческий подход.

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

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

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

Рисунок 8. Варианты дизайна жизненного цикла проекта

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