Слышали ли вы когда-нибудь в свой адрес упреки в неконструктивности? Может быть, сами кого-то упрекали? Как вы понимаете, что вот это конкретное обсуждение не конструктивно, а вот это конструктивно?

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

Принципы простые, но объясняют довольно много рабочих и не только рабочих конфликтов. И разобравшись с ними вы:

• Поймете причины поведения своих коллег, руководства и заказчиков в некоторых ситуациях
• Занесете в свой арсенал несколько простых приемов, которые помогут вам легче договариваться по работе
• Сможете абсолютно точно объяснить любому коллеге, что он неконструктивен (и в чем именно), если он действительно неконструктивен

Здесь не будет полюбившихся нам матриц 2 на 2, но пару схем мы разберем.

Итак, поехали. Первый принцип — это:

1. Своевременность.

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

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

Ошибка №1. Атака в прошлое.

Прибегает, например, менеджер к своему сотруднику с сакраментальным вопросом: “ПОЧЕМУ ты вчера не прогнал тесты?!!” Что в этот момент сделать сотруднику? Сесть в машину времени, метнуться в прошлое, там прогнать тесты и вернуться с уже прогнанными тестами?

С прошлым есть ровно одна проблема — его нельзя изменить. Поэтому вопросы в прошлое люди зачастую воспринимают как атаку на них лично. Более того, на вопрос “Почему ты не сделал вчера вот это” человек начинает добросовестно отвечать, почему он вчера этого не сделал. Причин у умных людей всегда много: соседний отдел поздно прислал требования, потом другой отдел долго не мог сделать сборку, тут еще директор отвлек на важную задачу и т.д.

На самом деле, то, что тесты не были прогнаны, само по себе не хорошо и не плохо. Это некий факт. Я, вот например, тоже вчера тесты не прогнал. Более того, я их уже лет пять тесты не гоняю. И пока все довольны.

Но судя по накалу эмоций, этот факт создает какую-то проблему В НАСТОЯЩЕМ. Например, менеджер не может отправить сборку заказчику. Или не может рапортовать об успешном завершении работ наверх и т.д. И вот эту проблему и надо решать в настоящем.

А когда она решена — тут как раз можно заглянуть В БУДУЩЕЕ: как бы нам сделать так, чтобы таких ситуаций больше не повторялось. И вот здесь будет уместен анализ прошлого: почему тогда тесты-то не прогнали? Но в этой точке человек уже не воспринимает это атаку на него личного. Когда текущая проблема разрешилась, виноватых уже не ищут. Мы вообще теперь будущее обсуждаем.

То есть, правильная последовательность обсуждения:

1. Решаем проблему в настоящем. Здесь про прошлое не вспоминаем.
2. Думаем, как предотвратить (или отреагировать) проблему в будущем. И на это этапе:
3. Анализируем прошлое

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

— Приезжаю к заказчику. Что говорить — непонятно, потому что вчера не успели с Сергеем обсудить. Ну ладно, думаю, сейчас Сергей все равно подъедет и все будет под контролем. На всякий случай, набираю его — телефон вне зоны действия сети. 10 минут до встречи, Сергея нет. Набираю его еще раз — телефон не работает. Начинаю нервничать. 3 минуты до встречи — то же самое. У меня реальная паника. 1 минута — Сергей снимает трубку. Я ору:

— Почему ты не берешь трубку?!!!

— Вчера дома не нашел зарядку…

— Мне что, тебе зарядку подарить?!!!

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

Ошибка №2. Одну проблему решили, вторую забыли.

Начнем с примера.

Пример из жизни. На нашем недавнем московском тренинге один менеджер поделился своей проблемой с удаленным сотрудником:

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

— А дальше?

— А дальше ситуация повторяется с некой периодичностью.

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

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

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

— Я хотел бы научиться отказываться от проектов.

—?.. Расскажите нам больше…

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

— А что было, когда вам давали пятый проект?

— [после паузы] Я работал над четырьмя… Мне было очень тяжело… Я им говорил, что не потяну…А они сказали, что очень надо…

— Ну и как, вы потянули?

— Потянул…

— Тогда руководство знает, как дать вам и шестой проект…

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

Потому что как эта ситуация выглядит со стороны руководства / заказчика? Приходишь к ребятам, просишь что-то сделать. Они поначалу сопротивляются, говорят, что невозможно, но после аргумента “очень надо” — берут и делают, большие молодцы!

Или наоборот, руководство начинает подозревать, что когда вы говорите “невозможно”, то мягко говоря. лукавите. Значит, и дальше надо грузить.

Ни один реальный подвиг не должен оставаться не “проданным”. Любой подвиг — это повод для обсуждения с заказчиком подвига (после совершения, когда заказчик находится в приятственном расположении духа, хорошо к вам относится и готов вас слушать): “Как там, все нормально? Так вот, я поэтому и пришел. То, что произошло — это чудо, потому что… Как бы нам так сделать, чтобы это все предусмотреть и в следующий раз вас не подвести?”

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

2. Адресность.

Когда два сотрудника друг другу в курилке жалуются на начальство: “Блин, опять переезд в новый офис. Сколько можно? Третий раз за год!.. Заколебали уже…” — это не вполне конструктивно. Потому что, если есть проблема с переездами. то вряд ли они ее между собой у курилке решат.

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

Принцип адресности говорит о том, что проблему нужно решать с тем, с кем можно ее решить.

К нарушению принципа адресности очень часто относится и публичная критика кого бы то ни было. Любая публичная критика большинством людей воспринимается как атака на них лично. Что нужно сделать? Правильно — размазать источник критики. Тогда все зрители с попкорном немедленно увидят, кто прав, а кто нет. И дальше герои обсуждения расчехляют трофейные какашкометы и начинается др-р-рака!

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

К личной критике люди прислушиваются гораздо, гораздо лучше. И личная критика позволяет сохранять хорошие конструктивные отношения в долгосрочной перспективе.

3. Факты и данные.

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

Например, вы убежденный сторонник гибких методологий разработки. Соответственно, у вас в команде проходят утренние планерки (они же скрам митинги или standup митинги). И вот ваш новый коллега на них постоянно опаздывает. Почему?

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

“Это ухудшает командный дух” — отличный аргумент, но в чем это выражается? Что такое командный дух? Это когда заходишь в комнату, а там такой “сильный командный дух” витает в воздухе?!

“В чем это выражается?” — сильный вопрос, позволяющий понять, есть в аргументе факты или нет. Факты хороши тем, что с ними не поспоришь. Именно поэтому они убедительны, именно поэтому они и позволяют человеку увидеть и понять, в чем проблема.

Аргументы “это лучшие политики Agile”, “это правила нашей компании”, “так завещал Кен Швабер”, кстати говоря, хоть и являются фактами, но не сильно лучше. потому что не показывают, что конкретно не так из-за поведения человека.

А такие аргументы, как:

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

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

4. Намерение решить проблему, а не человека.

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

Если по ходу обсуждения возникает ощущение, что человек пытается доказать, что он не виноват, то очень неплохо работает прием ДИССОЦИАЦИИ: “Погоди, я не на тебя наезжаю, но сама ситуация…”

Пример из жизни. У меня двое детей — пацаны 8 и 10 лет. Первая фраза, когда приходишь к ним с конструктивной критикой, очень часто: “Я не виноват”.

Со временем, уже вошло в привычку выруливать: “Так я не про виноват, не виноват. Просто как теперь…” и дальше возможны варианты “пойдем играть в футбол, если ботинки мокрые”, “посмотрим фильм, если нам сейчас надо будет убираться” и т… д.

От принципов к практике…

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

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

А мы в следующей статье поговорим о 4-фазном алгоритме решения проблем, предложенном тем же Энди Гроувом. Потому что принципы — это хорошо, это правильно, но они не дают ответа на вопрос, с чего начать и как по шагам вести обсуждение проблем с людьми. А алгоритм — он как раз про это.

P.S. Предыдущие статьи серии:

• Управленческие инструменты: Как объяснить, когда чувствуешь одним местом?
• Советы практикующего андрагога: как мы учимся
• Управленческие инструменты: Как играть в нелинейные шахматы
• Управленческие инструменты: Почему заказчики требуют дурацкие отчеты?
• Управленческие инструменты: 5 вопросов для прояснения целей или для чего нужен BMW X5?

Автор: eagleson

Источник