Разделение проблем

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

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

Есть формулировка, которая называется "выйти из зоны комфорта", и это стало маркетинговым лозунгом. Выход из зоны комфорта действительно является стимулом изменений, и это действительно очень неприятное ощущение. Ещё один вариант, когда основной заказчик сам созрел до этого, ощущает этот дискомфорт в себе в виде кризисного состояния организации как живого организма, с которым он связан, или себя самого как лидера организации. Это практически идеальная ситуация, такой лидер может и остальным транслировать это состояние.

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

Есть один косвенный признак здорового отношения заказчика к проекту и здорового взаимодействия внутри команды. Это использование слов "наш" и "мы" вместо "их". Конечно, это можно довести до абсурда, то есть до потери идентичности и переваливанию крайне неприятных проблем на команду. Например, наличие балласта (лишних некомпетентных людей) в команде – это явная ошибка того, кто этот балласт нанял, и команда тут не при чём. "Их" также появляется при попытке ввести иерархические взаимоотношения в команде, это тоже ничем хорошим не заканчивается. Если эти проблемы решены, люди говорят "мы" и верят в это "мы", и в решение возникающих проблем впрягаются сообща.

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

Теперь посмотрим из целевой ситуации, долгосрочных отношений, в конкретный проект. Что нужно сделать на конкретном проекте, чтобы в итоге обеим сторонам захотелось сделать той же командой ещё не один проект? Разделять радости и горести. Одной из базовых потребностей всех людей является потребность в справедливости. Как минимум, когда не сваливают общие ошибки на одного. А ещё есть потребность признания совместных достижений и вклада каждого в эти достижения. Это оно и есть – разделение радости и горести.

@Константин Овчинников
Теги: #управление изменениями

Комментарии