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

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

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

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

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

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

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

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

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

Согласно стандарту PMI PMBOK, «проект – это ограниченная временем деятельность по созданию уникальных услуг, продуктов или результатов». В этом определении важна каждая фраза.

Рисунок 6. Отличия проекта от операционной деятельности

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

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

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

Теперь плавно переходим к критериям успешности проекта.

Есть три ключевых аспекта, на которые нужно ориентироваться при определении успешности.

• Первый указывает на то, что проект успешен, если он совершен в установленные изначально сроки.

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

• И последнее – удовлетворенность заказчика. Причем под этим следует понимать реализацию его задокументированных потребностей и пожеланий.

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

Рисунок 7. Проектный треугольник

Как работает проектный треугольник? Все относительно просто: в проекте есть содержание, то есть то, что команда должна реализовать в конечном итоге. Разделяют содержание продукта – свойства и функции итогового результата, продукта, услуги и содержание проекта – работы, которые необходимо выполнить, чтобы получился продукт с этими характеристиками. У команды есть сроки, в которые нужно уложиться при выполнении работы. И есть стоимость: в каких бюджетных объемах мы должны это реализовать.

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

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

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

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

Работа над проектом от А до Я требует от людей постоянной вовлеченности в процесс, что порой буквально сжигает людей на рабочем месте в огне постоянного стрессового напряжения. Проявления стресса могут быть весьма разнообразными. Однако стресс имеет свойство накапливаться, и это связано с интенсивностью и длительностью работы в проекте. Очень многие устают, выгорают, и их продуктивность падает. Некоторые сходят с дистанции.

Где-то год назад я тащилась из проектного офиса по заваленной снегом Москве после очередной порции пистонов на оперативном совещании у клиента, неся домой ноутбук и зная, что до 23 нужно наваять протокол совещания и отправить проджекту, чтобы с правками он ушел на согласование клиенту до полуночи. И мне стало непонятно почему плохо, голову сдавило, я обняла столб и думала – ждать ли автобус по вечерним пробкам или пройти остановку до Павелецкой и там заскочить в аптеку. Начинала уже идти, но побоялась упасть и таки дождалась автобуса. В аптеке мне дали стул, таблетки, воды, распаковали тонометр – 180 на 120. Тетеньки удивились, дали валидолу. И я очень четко запомнила то ощущение: а ведь если я сдохну тут прям на остановке – в проекте об этом забудут послезавтра. Зачем мне это? Что на самом деле-то хочется? Я лучше буду лепить пельмени в Исландии. Потом после больничного я уволилась.

Юлия Г., менеджер IT-проектов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый из подходов, стандартов, методов формулирует свой набор ценностей. Например, практики Agile исходят из подхода, максимально близкого VUCA-миру. Их основой является Agile-манифест:

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с клиентом важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

О чем этот набор установок? Часто в жестких иерархичных организациях (да и не только в них) самыми важными приоритетами являлись следование процессам, использование предопределенных инструментов, документирование всех процессов, догмат единожды и навсегда сформированного плана.

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

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

Однако мы не случайно упомянули про систему установок и ценностей, связанную с разными методологиями и практиками проектного управления.

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

Сложно верить в ценность «безопасность», когда собственное руководство экономит деньги на этой самой безопасности. Сложно верить в ценность, если где-то в теплой стране собрались топ-менеджеры, «поштурмили» и выдали «на-гора» несколько лозунгов, которые теперь должны стать основой мышления компании.

– Ценности? Ха! Да, я тебе расскажу, как у нас с ценностями работают!

– Так, судя по началу, продолжение будет интересное.

– Ценности у нас – это то, что нужно зазубрить и на тестировании, четко по номерам их рассказать. А не расскажешь и не вспомнишь, какой номер у нее, ну сам понимаешь…

Из беседы со знакомым руководителем проекта

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

1.3. Живые команды

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

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

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

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

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

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

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

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

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

Руководитель проекта, человек старой закалки, решил управлять всеми процессами по исторически сложившемуся каскадному методу, но автоматизацию разбить на функциональные блоки. Так, чтобы в каждой команде работало не более чем 10‒12 специалистов. При этом каждая мини-команда имела свободу выбора подхода для работы – (PMBOK, SCRUM, Kanban и т. д.). Главным требованием к командам было наличие общих промежуточных результатов в четко определенные моменты времени.

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

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

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

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

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

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

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

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

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

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

• автономны и полностью вовлечены в работы над проектом;

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

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

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

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

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

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

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

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

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

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

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

Главная задача первой стадии – прояснить ожидания людей, определить цели и наметить четкий план действий.

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

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

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

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

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

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

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

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

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

Это главная стадия для того, чтобы слаженно и эффективно выполнить основную работу по проекту. Чего бы это ни стоило.

5-я стадия: расформирование (Closing)

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

Здесь самое важное – завершить проект и поставить качественную точку в командной работе.

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

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

1. Размер и половозрастной состав команды.

2. Стиль и методы руководства.

3. Степень развития эмоционального интеллекта у руководителя и людей его команды.

4. Личностные и социальные различия между людьми.

5. Тип офиса и формат работы: открытый, кабинетный или дистанционный.

6. Сроки, в которые необходимо завершить проект.

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

Какие же ключевые моменты позволяют команде стать по-настоящему эффективной? Команда Google в течение двух лет проводила исследование, изучая секреты этой темы[6]6
  Проект «Аристотель» (https://rework.withgoogle.com/print/guides/5721312655835136/).


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

Рисунок 11. Факторы, влияющие на динамику команды

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

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

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

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

5. Влияние. Людям в командах необходимо чувствовать, что их деятельность имеет значение, и способствует достижению общих целей компании.

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

Рисунок 12. Соотношение важности и доступности ценностей[7]7
  По результатам исследования, проведенного авторами книги в одной из компаний г. Москвы в мае 2020 года


[Закрыть]

Глядя на рисунок 12, мы ясно понимаем, что и в новом мире, как и многие столетия назад, людям важны человечность, определенность и справедливость. Но жизнь фокусирует их на результативности, самостоятельности и возможности развиваться. Страдают значимые ценности, и люди испытывают высокую степень дискомфорта.

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