Книга: Джедайские техники конструктивного общения
Назад: Глава 4. Принципы конструктива
Дальше: Глава 6. О подборе аргументов: «хотелки» → аргументы

ГЛАВА 5

Алгоритм конструктивной конфронтации

— Представляете, он программистов за опоздание даже на три минуты заставляет писать объяснительные от руки! Знаете, как аргументирует? «Им надоест писать, и они перестанут опаздывать!» А все идеи принимает только в виде докладных записок!

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

— Да нет, вот два года назад мы с ним ездили на выставку в Германию. Нормальный чувак был, мы с ним вместе по стрип-барам тусовали…

— А в какой момент он стал «неадекватным»?

— Гм…

Короче говоря, выяснилось, что года полтора назад они сорвали очень важный проект. Компания попала на крупные штрафы. Акционеры вызвали молодого директора (26 лет на тот момент) и, видимо, объяснили ему, что в следующий раз будет такое, что лучше до следующего раза не доводить. После чего директор начал наводить в компании порядок. Как умел.

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

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

Итак, в алгоритме четыре фазы. При этом обсуждение занимает две фазы: вторую и третью. А начинается все, конечно, с подготовки.

I. Подготовка

На этапе подготовки мы определяем несколько вещей.

1. В чем конкретно проблема?

Пример из жизни. На одном из тренингов встает слушатель:

— Ну это все понятно. А вот ситуация из реальной жизни. Я иду по коридору и вижу, как сотрудник соседнего отдела смотрит порнуху. Что делать?

— А в чем проблема?

— Ну…

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

Чтобы понять, надо ли решать проблему, задаем себе два вопроса:

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

2. Цель: чего хотим добиться обсуждением?

Периодически менеджеры приходят со странными проблемами. «У меня проблема: люди сидят “ВКонтакте”. Вот я думаю, сейчас мы им закроем доступ к соцсетям…»

Если в этом случае закрыть доступ к соцсетям, то получится как в анекдоте: «Много нового из жизни собак узнали ученые, прикрепив камеру на голову собаке. Оказывается, до 90% своего времени собака проводит за тем, что пытается содрать камеру с головы».

Все инженеры начнут решать интересную инженерную задачу, как обойти дурацкий запрет.

На самом деле в том, что люди сидят «ВКонтакте», нет проблемы. Сидят — и слава богу. Чем плохо-то? Плохо то, что работа не делается. А вот это должно быть целью обсуждения — чтобы работа делалась.

3. Почему человек так себя ведет?

Для любого поведения человека всегда есть причина. Даже для поведения, которое вам кажется неадекватным.

Анализируя точку зрения, хорошо бы подумать вот о чем.

В жизни масса разных вещей, которые переключают поведение людей, среди них следующие.

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

Хорошо бы попробовать для себя это все прояснить, потому что именно здесь решается, с чего мы начнем разговор:

(Для анализа точки зрения другого человека существует ряд инструментов. Если интересно познакомиться с ними подробнее, отошлем читателей к бесплатному курсу «Управленческие инструменты: системный менеджмент на пальцах» (). Там обо всем этом говорится де­тально.)

4. Факты и аргументы. Как мы писали в предыдущей главе, люди иногда абсолютно искренне не видят, в чем заключается проблема. «Ну не присылаю я отчеты, да и бог бы с ними. Зато работы успеваю больше сделать!»

На этапе подготовки к разговору, хорошо бы подумать:

Если заранее не подготовить факты, то в разговоре мы автоматически скатываемся к давлению:

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

Итак, допустим, этап подготовки пройден, мы готовы к обсуждению.

II. Обсуждение проблемы.

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

Общая схема разговора может быть такой.

— Я хотел бы обсудить вот такую ситуацию… Это не очень здорово, потому что [ФАКТ № 1] + [ПАУЗА]

— И че?

— Так вот… [ФАКТ № 2] + [ПАУЗА]

— И че?

— Я поэтому и пришел… [ФАКТ № 2] + [ПАУЗА]

Наша задача на этой фазе алгоритма — привести человека к точке согласия по проблеме. Чтобы он сказал что-то вроде:

— Да, как-то все это неправильно…

Пауза дает человеку возможность высказаться. Можно ее заменить уточняющими вопросами:

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

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

— А давайте внедрим $НОВАЯ_МОДНАЯ_ТЕМА (Kanban, Lean, TDD, FDD…)

И у людей в глазах немой вопрос: «ЗАЧЕМ? Ведь мы же до этого как-то работали без $НОВАЯ_МОДНАЯ_ТЕМА? Релизы релизили, билды билдовали, все было хорошо… ЗАЧЕМ?»

Что происходит? С точки зрения алгоритма — скачок к фазе «решение», минуя фазу «обсуждение проблемы». И это автоматически вызывает сопротивление.

Что делать, если факты закончились? Бывает так, что факты и аргументы заканчиваются, а человек все равно не согласен. Не видит, гад такой, проблему! Что делать?

Интуитивная модель поведения — надавить (авторитетом, политиками компании, лучшими практиками, силой…). Контр­интуитивная — выйти из разговора.

Пример из жизни. Несколько лет назад мы с коллегой Славой Панкратовым оказались на тренинге Блисс Браун, американской бабушки 60 лет и потрясающего коуча. Может быть, кто-то слово «коуч» воспринимает как отрицательное, но вот что я вам скажу. Блисс Браун — одна из самых мудрых людей, с которыми мне посчастливилось познакомиться. За время нашего трехдневного общения я кое-что переосмыслил в жизни. Хотя я не меньший скептик, чем вы.

Так вот, в ходе тренинга у моего коллеги возникло несогласие по какому-то поводу:

— Блисс, минуточку, я не согласен!

— Слава, давай я объясню по-другому (объясняет по-другому).

— Блисс, я все равно не согласен!

— Давай так (объясняет по-третьему).

— Все равно не согласен!

— … Слав, я сейчас, видимо, не могу подобрать нужные слова. Дай мне время подумать, как это лучше сформулировать и давай обсудим с тобой эту тему на кофе-брейке?

Дальше — со слов Славы:

— Мне в тот момент стало дико неловко. Елки-палки, думаю, тетенька 40 лет объясняет это разным людям. Неужели я такой тупой, что не могу этого понять?.. До кофе-брейка я только об этом и думал и сам дошел до того, что она имела в виду. На кофе-брейке подхожу к Блисс Браун: «Блисс, я правильно понимаю, что ты имела в виду вот это?» — «Именно так».

Закончились факты — выходите из разговора. Не со словами: «Чего ты такой тупой-то?!», а со словами: «Я, похоже, не могу донести проблему». Подумайте и вернитесь к разговору чуть позже, с новыми фактами и аргументами. Возможно, и собеседник дозреет.

Может так оказаться, что в ответ на ваши слова человек начнет озвучивать свои проблемы: «А чего ты хочешь, если ты такой хреновый менеджер?!»

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

Но, допустим, используя факты, аргументы и паузы вы все-таки привели человека к тому, что он сказал:

— Да, согласен, ситуация неловкая…

III. Обсуждение решения.

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

В противном случае лучше спросить человека: «Как решать-то будем?» Важно, чтобы человек предложил решение сам. За свое решение он чувствует большую ответственность.

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

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

Можно сказать: «Подожди, она же не выдержит нагрузки», но при этом вы рискуете услышать коммуникативную формулу ЗАТО: «Зато ее можно быстро реализовать!»

Поэтому лучше задать один из вопросов:

Утверждения включают в человеке желание поспорить. А что у человека включает мозг? Правильно, вопросы.

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

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

— Коллеги, есть идея: давайте писать юнит-тесты!

— Отличная идея!

— Вот! Ну тогда переходим к следующему вопросу…

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

Хорошая форма записи решений: WWW = Who, What, When (Кто, Что, Когда) — меньше шансов понять по-своему. А далее мы переходим к последнему этапу алгоритма, потому что, как говаривал бывший СЕО IBM Лу Герстнер, People do not do what you expect. They do what you inspect. («Люди не делают того, что вы ожидаете. Они делают то, что вы проверяете.)

IV. Контроль.

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

Если человек начал вести себя так, как вы с ним договорились, — это повод сказать ему: «Спасибо, вижу». Если этого не сказать, он может подумать, что вы не заметили: «А зачем тогда приходил мне мозг греть? Похоже, тема для него не так важна… Короче, в следующий раз, можно не напрягаться…»

Если человек ведет себя по-старому или не так, как вы договорились, это повод спросить его: «Как же так?» И окажется, что либо человек забыл / забил (в этом случае, вероятно, надо будет усилить контроль), либо окажется, что решение для него не работает. И придется вернуться на предыдущий этап и дорабатывать решение.

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

— Понимаете, у нас заказчик в середине итерации пропихивает новые «хотелки».

Какая неожиданность! Ни у кого такого не бывает! Начинаем разбираться:

— А чем это плохо? Вы же их реализуете, верно? Ну и слава богу, как говорится, сатисфачьте кастомера, и будет вам счастье…

— Ну, мы не успеваем сделать то, подо что подписались…

— Да, это проблема. Обсуждали ее с заказчиком?

— Да.

— Что решили?

— Решили, что он свои «хотелки» будет копить до начала следующей итерации, а там мы их будем обсуждать.

— Записали решение?

— Конечно.

— А что потом происходит?

— Он снова пропихивает «хотелки» в середине ите­рации…

— А вы что делаете?

— А мы их реализуем…

Так алгоритм не работает. Последняя фаза контроля столь же важна, как и три предыдущие.

(О типах контроля при фиксации решений подробнее поговорим в главе 7.)

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

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

Небольшое упражнение.

  1. Вспомните свой последний сложный рабочий разговор и попробуйте разложить его в соответствии с этим алгоритмом. На каком этапе сбойнуло и что сейчас вы сделали бы по-другому?
  2. Попробуйте подготовиться к ближайшему непростому разговору и провести его по этому алгоритму. Посмотрите, как пройдет.
Назад: Глава 4. Принципы конструктива
Дальше: Глава 6. О подборе аргументов: «хотелки» → аргументы