Еще в ноябре мы вместе со Славой Панкратовым написали статью по одной из “Игр в ИТ”. В декабре статью опубликовали в журнале “Профессия - директор”. Теперь публикуем ее здесь:
Александр Орлов
Независимый консультант, автор проекта «Клуб Успешных Менеджеров Программистов», соавтор проекта «Управленческие игры: психология и политика, в которые играют сотрудники, начальники, заказчики и компании»
«Игры» - часть теории транзакционного анализа, выдвинутой выдающимся американским психологом 20-го века Эриком Берном. В своей теории Берн рассматривал межличностные отношений с точки зрения человеческих транзакций или соглашений, сделок. Транзакции, имеющие в себе скрытую цель, он назвал «играми».
Любая игра подразумевает нескольких участников: я, ты, они. Например: я - руководитель, ты - сотрудник, они - остальные сотрудники. Или: я - сотрудник, ты - другой сотрудник, они - начальство. Для начала игры играющий человек должен считать каждого из этих трех участников либо плюсом, либо минусом.
Например, один сотрудник говорит другому: «Это начальство совсем оторвалось от жизни, совсем уже не видит, куда идет проект. А нам, инженерам, расхлебывать.» Это человек исходит из позиции «я+, ты+, они-».
Если же человек говорит: «Ну, конечно, у них все получается и у тебя получается. Вы-то тут уже два года работаете…», то это позиция «я-, ты+, они+».
Целью любой игры является получение ощущений - «купонов», которые могут быть как положительными (золотые купоны), так и отрицательными (коричневые купоны). Золотые купоны человек в будущем сможет обменять на определенные выгоды для себя (например, на повышение зарплаты). А коричневые он сможет использовать, например, чтобы обосновать свой уход: «Меня в этой компании никто не слушает». Также возможны фальшивые золотые купоны - например, человек, испытывает фальшивое чувство торжества над коллегами, но обменять это чувство на повышение он не сможет (потому что руководитель видит, что человек просто строит из себя «супер-звезду»).
Однажды, когда я руководил одной из команд в большом проекте (мы разрабатывали программное обеспечении), у нас случился казус. Инженеры в разных командах реализовали один и тот же модуль. Модуль был нужным, но существовал теперь в двух экземплярах. Обе реализации делали одно и то же, но внутреннее устройство у них немного отличалось.
Перед руководителем проекта встала задача - решить, какой модуль оставить. Обе команды, разработавшие свою версию модуля, такой вариант решения не устраивал: «Это что же,» - говорили они, «может так оказаться, что мы зря писали?..»
Руководитель, однако, считал, что нужно выбрать лучший модуль, а другой выбросить в корзину. Поэтому он попросил обе команды заполнить таблицу с плюсами и минусами обеих реализаций. Думаю, читатель может догадаться, что произошло. Естественно, каждая команда нашла больше плюсов в своей реализации, а больше минусов в чужой. Слова: «Вы понимаете, что мы не зря писали этот модуль?» все чаще звучали с обеих сторон.
Стало понятно, что ситуация становится взрывоопасной. Руководитель решил принять компромиссное решение. Инженерам из разных команд, авторам модулей, предлагалось сесть вместе и сделать совместный модуль, взяв лучшее из обеих реализаций. Поскольку команды находились в разных городах, то совместная работа проводилась по телефону и заняла около двух недель.
Говорит эксперт. Компромисс всегда бывает вынужденным. Он должен быть последним средством. Если два отдела или подразделения не могут решить проблему и приходят с ней к вам, выслушайте обе стороны и, не уподобляясь царю Соломону, выберите одну или другую. На победившего это накладывает огромную ответственность за выполнение работы.
Роберт Таунсенд «СЛОМАЙ СИСТЕМУ! Лекарство от управленческой изжоги»
Последние коментарии