Живые команды. Управление стрессом в проектах

1.2. Идея проектного управления

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

М.: Алексей, а есть какие-то исследования по трендам проектного управления?

А.: Насколько я знаю, в 2019 году Московская бизнес-школа Сколково провела исследование среди руководителей российских компаний. Они задали вопрос: «Какие необходимые компетенции и навыки нужны для реализации стратегии?» Понятно, что много было ответов про операционную эффективность, но интересно, что фокусными стали идеи, связанные с работой в командах. Вот какие навыки назвали большинство: навыки проектного управления, управления командой и кросс-функционального взаимодействия.

М.: А в мире как обстоят дела?

А.: Разные компании проводят исследования регулярно. PMI, например, выпускает периодический «Пульс профессии». Совсем недавно узнал, что компания Microsoft на основании статистики и изменений в мире сделала очень смелое допущение, что в горизонте 7 лет потребность будет расти не в разы, а в десятки раз. Под сто миллионов проектных менеджеров будет!

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

Давайте для начала определимся, что же такое проект.

Согласно стандарту 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. Живые команды

Проектная команда – это, как правило, временная организационная структура, которая создается целевым образом на период выполнения проекта. Она объединяет отдельных специалистов, группы и/или организации, привлеченных к выполнению работ и ответственных перед руководителем проекта за их выполнение. Это могут быть как внутренние, так и внешние исполнители и консультанты. Каждый из них обладает знаниями и набором навыков в конкретной предметной области.

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

В соответствии с классической моделью проектного управления в команде проекта есть четыре звена принятия решения:

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

Руководитель проекта – управленец, на котором лежит вся полнота ответственности за результаты проекта. Тот, кто должен принимать управленческие решения в проекте.

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

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

Каждый сотрудник проекта выполняет свои функции, роли и контролирует свою зону ответственности. Каждый понимает свой объем работ и ориентируется на требования к результатам своей деятельности.

В разных подходах приняты разные способы организации структуры команды.

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

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

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

небольшие кросс-функциональные команды (7±2 человека) добиваются лучших результатов;

делают короткие итерации;

автономны и полностью вовлечены в работы над проектом; мотивированы общими командными целями и показателями эффективности;

достигают мастерства, обогащая работу друг друга.

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

М.: Недавно услышала мнение коллеги, что Брюс Такман был не прав и нет подтверждений, что команды проходят именно эти стадии.

А.: Я еще не встречал команду, которая бы не проходила.

М.: Согласна. Кто-то более выраженно, кто-то менее, в разном темпе. Но каждый раз я восхищаюсь, насколько это понятная и ясная модель и как красиво разворачиваются эти групповые процессы. В общем, я не стала спорить с коллегой. Верит, что Такман не прав, и ладно.

Давайте посмотрим в целом на психодинамику применительно к проектным командам в рамках этого подхода.

Рис. 9. Стадии развития команды по модели Б. Такмана

1-я стадия: формирование (Forming).

Как только люди собрались вместе, им кажется, что у них есть сплоченность. Они еще не до конца понимают, куда попали, но уже готовы идти к цели. Здесь они знакомятся друг с другом и со своими формальными и неформальными ролями. Каждый представляет группе свою лучшую версию себя. Люди обычно рады быть частью команды, стремятся к дальнейшей работе и имеют высокие положительные ожидания. В то же время они беспокоятся, задаваясь вопросами, как они вписываются в команду, как дальше пойдут дела и по каким правилам все будет происходить. Главная задача первой стадии – прояснить ожидания людей, определить цели и наметить четкий план действий.

2-я стадия: бурление (Storming).

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

3-я стадия: стабилизация (Norming).

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

4-я стадия: выполнение (Performing).

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

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