Социальный роли и проблемы с ними: Смешение ролей

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

• от глагола “мешать”, а не “смешить” :-)

Давайте представим себе ситуацию

Planning meeting и вдруг Product Owner (или Заказчик) начинает рассказывать, как нужно сделать работу. Причем рассказывает в деталях, на уровне “пиши это – вот так, а это – таким способом” и, параллельно, расставляя эстимейты – “вы с этой задачей за 3 часа справитесь”. Часто это встречается, когда у Заказчика роль разработчика уже присутствует (сам был девелопером, пока не стал заказчиком).

Что собственно происходит?

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

• Это как если бы при постановке “Ромео и Джульетты” Джульетта возьмет шпагу и попытается помочь Ромео в дуэли. Это будет выглядеть, мягко говоря, странно… и уж точно это не Шекспир. Зрители будут волноваться и возмущаться.
• Айтишный пример “в другую сторону”: программисты начинают решать, какие фичи нужны, а какие нет, и молча делать. При этом программисты берут на себя роль Заказчика. Т.е. вместо “оценил трудоемкость и передал Заказчику для расстановки приоритетов” получается “оценил востребованность фичи на рынке и расставил приоритеты”

Смешение ролей в стандартных ситуациях часто создает больше проблем, чем решает

Как правило проблем становиться больше даже если человек, который смешивает роли, думает, что он “помогает”. Если генерал выйдет из штаба и возглавит рядовую операцию, это может не столько воодушевить, сколько дезорганизовать солдат – “неужели все у нас так плохо?”. Коллеги-психологи часто шутят, что самые сложные клиенты – это коллеги. Слышал подобное и от врачей. Что происходит? Человек просто путает свою роль: он сейчас Заказчик, а не исполнитель, он сейчас пациент/клиент, а не врач/психотерапевт и т.д.

Роль и ситуация

Роль диктует стереотип поведения. При этом роль всягда связана с ситуацией в которой эта роль актуальная. И всегда будет ситуация, когда эта роль не актуальная. На этом, кстати, построено много анекдотов.

«Участник команды” – это роль человека, РО – это тоже роль. Но это не единственные роли. РО может быть и менеджером проекта, и программистом (может, в прошлом) или “большим начальником”. Ролей много.

Но давайте эти роли смешаем, перепутаем ситуации, где роли актуальны. И что мы получим?
Большой Босс, не выходя из своей рабочей роли, общается с женой, как с подчиненным. Охранник в магазине, входя в роль “пацана с района” матом кроет клиента. РО, вспоминая роль специалиста, начинает давать оценки “Да что тут делать-то, на 3 часа задача”.

Смешение ролей вызывает недопонимание, растерянность, тормозит общение и часто является причиной конфликтов.

Выводы:

• Выходя с работы – выходите из рабочей роли
• В стандартной рабочей ситуации лучше всего действовать из своей роли (программист, менеджер, заказчик, и т.д.)
• Если Заказчик (или менеджер, не программирующий непосредственно) выходит из своей роли – ставит эстимейты, говорит, как реализовывать, то можно использовать “Сократический диалог”. Через технику следует дать понять, чего мы ожидаем от него, как от Заказчика, и закрепить это техникой “Договор”.
• Если Программисты выходят из своей роли, а мы знаем, как лучше – то тут лучше не самому разбираться, а обратиться к другим программистам для проверки, либо воспользоваться техниками “Сократический диалог”, “Конструктивный ультиматум”, “Ратификация” и опять же лучше закреплять “Договором”.