Джедайские техники конструктивного общения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IV. Контроль.

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

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

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

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

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

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

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

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

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

— Да.

— Что решили?

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

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

— Конечно.

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