Известный тренер в области ИТ — Слава Панкратов — опубликовал у себя в блоге интересную статью о том, как протолкнуть свое решение, не вызывая защитной реакции собеседника, и в том числе привел специфичные для ИТ примеры. С разрешения автора привожу ее здесь — удовольствие и польза от прочтения гарантированы.
Мы часто спорим. По делу и не по делу. Умело и не умело. Тратим нервы там, где надо просто договориться. Когда ставим задачу мы спорим с подчиненным как ему ее лучше делать. Когда приходим к коллеге или шефу разобраться с проблемой, то часто приносим свое решение и тут же пытаемся его продать как единственно правильное.
Давайте вместе представим следующую ситуацию: вы пришли в гости к друзьям, молодая семейная пара, у которых есть ребенок. Вы заметили, что у ребенка искривлен позвоночник, а вы знаете, что плавание очень помогает при сколиозе. И что вы делаете? Вы выдаете решение.
— Родители, вы что не видите, что у ребенка проблема с позвоночником? По рукам же видно, что одно плечо выше другого, куда вы смотрите? Ребенка надо срочно отдать в бассейн… (это если вы успеваете это договорить, конечно, а папа ребенка тут же не исправляет вам диоптрии на очках или в более мягком варианте развития событий, родители начинают вам объяснять откуда у ребенка сколиоз).Что не так? Вы пришли продавать решение проблемы (вас кто-то об этом просил?) и при этом нарушили очень важную штуку — правило, которое называется «Не атаковать прошлое». Это простое правило открытое несколько веков назад, его часто вспоминают в разных книгах, но почему-то еще чаще мы его нарушаем в спорах и даже обычных житейских ситуациях. Можем быть нас так воспитывали, не знаю. Что не так с прошлым? Его нельзя изменить. А если я говорю вам о чем-то, что вы сделали не так в прошлом и вы не можете это изменить, что вам остается? Защищать его, потому что признавать совсем непросто. Приведу пример из нашей области. Новый ведущий разработчик, который вошел в проект на позицию архитектора, провел аудит проектной архитектуры и рассказывает об этом на очередном командном митинге:
— Говоря простыми словами, архитектура проекта полное г..но! Эти пять костылей, на которые навешан основной функционал и трогать которые никто не рискнет, чтобы ничего не развалилось, назвать архитектурой не решится даже начинающий программист. И вообще…Что он сейчас сказал команде?
- Вы сделали неправильно (и вы сделали это давно, поэтому мы не можете этого изменить)
- Вы не умные, потому что не поняли этого сами (снова атака в прошлое)
- Вы столько времени делали поверх одной глупости (архитектуры) кучу других глупостей (наворачивали функционал)
Что делать?
Помимо простого правила «Не атаковать прошлое», нужно понять еще одну штуку. С кем никто не спорит? У вас и у меня есть один человек, с которым вы или я никогда не будем спорить. Подумайте минутку не торопясь. Правда, не спешите читать дальше, подумайте. Наверное, это вы сами. Конечно, если у вас в голове не живет несколько людей, которые периодически устраивают продолжительные дискуссии Чьи решения всегда будут для вас самыми лучшими? Тоже верно — ваши решения. Попробуем применить понимание как устроен этот механизм принятия решений на практике. Возьмем первый пример с молодой семьей.— Ребята, я вам рассказывал, что мои знакомые отдали ребенка в бассейн? (с этим никто не спорит, вы правда еще не рассказывали об этом) — Ребенок два раза в неделю по 30 минут «кипятит бассейн», сбрасывает кучу энергии, домой приходит спокойным, хорошо засыпает. (мама и папа, которые устают от ребенка под вечер уже слушают вас очень внимательно) — Девочка стала меньше болеть. (извечная головная боль любой мамы, а когда у мамы про что-то важное болит голова, папе тоже прилетает)[тут первый очень сложный момент для любого человека, который знает правильные ответ на эту загадку — тут надо заткнуться и дать возможному будущему прорисоваться в головах родителей и стать для них тем вариантом будущего, в котором они захотят оказаться — тогда они не будут с вами спорить] Если тут родители еще не готовы сказать «У нас тут, кстати, есть бассейн недалеко», вы продолжаете помогать им нарисовать вариант будущего в котором он есть и захотеть там оказаться. Очень важно не говорить чего-то, за что может зацепиться внутренний механизм защиты, который есть в любом человеке.
— Они говорили, что бассейн это совсем не дорого, каких-то 50 баксов в месяц (конкретика, за которую можно цепляться, смотрите что может произойти дальше) — Хм… каких-то 50 баксов в месяц, это 600 долларов в год, которые еще надо суметь заработать! (веско замечает папа и смотрит на маму, которая должна поддержать мужа, чтобы при госте его мнение не подвергалось сомнению в этом доме)И сейчас вы можете начать обсуждать «стоимость денег» или уйдете в пространство рассуждений «на что на самом деле умные люди тратят деньги». Вы сейчас в том направлении двигаетесь? Или просто решили научить ваших друзей как им жить по уму? А если звучит:
— Да мы вот тоже думали какой-то бассейн или секцию гимнастики найти рядом с домом. (оказывается ваши друзья не глупые люди и знают о том, что есть задача как-то изменить ситуацию с ребенком, заметим, в прошлом сценарии вы это как-то не учитывали)То вы вежливо киваете (я например, абажаю, когда со мной кто-то согласен, а вы?) и продолжаете эту мысль в голове ваших друзей.
— Угу, тоже отличная тема: а что у вас тут есть неподалеку? (погодите продавать бассейн, может его просто нет рядом или есть причина, по которой он недоступен? вы ведь не бассейн продаете, а решение вопроса с позвоночником у ребенка, помним это. сейчас важно, чтобы люди говорили сами, тогда это будет их решение)[тут второй очень сложный момент для любого человека, который пришел продать свое решение — иногда надо согласиться, что решение, к которому пришел человек, может быть хоть и не вашим, но более хорошим и работающим для того человека, который его придумал. если это решение тоже решает задачу или проблему,с которой вы пришли, может лучше дать ему сделать его способом?]
— Есть бассейн в 10 минутах езды и секция гимнастики буквально напротив, через дорогу (гимнастика специально поставлена ближе, чтобы усложнить нам с вами задачу, но мы же сейчас учимся, коллеги) — Так вообще супер! (ваша оценка ситуации, которая читается родителями как хорошее подтверждение «у вас все хорошо») И то и то вообще рядышком. (у нас есть выбор, а это важно, иметь выбор. оба варианта хорошие, давайте выбирать из хороших вариантов, это всегда приятнее, чем выбирать из двух плохих вариантов) Понятно, что это ваше время, у вас работа… (даем родителям что-то все-таки опровергнуть, вдруг им сейчас это надо?) — Ну, времени у всех не хватает! Для детей-то надо находить. (веско добавляет папа, которому вы предыдущей фразой дали возможность так красиво выступить на тему жизненных ценностей. у вас появился союзник, между прочим). — Согласен. (вы снова-таки согласны с родителями. вы не спорите, они не спорят, вы спокойно идете к какому-то варианту решения и ваши очки и дружеские отношения по прежнему целы) Кстати, гимнастика может быть в этом возрасте и не самое полезное дело, ребенок растет, а это нагрузки. (вы согласились, теперь очередь родителей согласиться с вами, хотя и не обязательно) — Может и так, кстати. Жена, давай прикинем как можно водить мелкую в бассейн? (обратите внимание, то что бассейн или гимнастика нужны уже в общем-то и не обсуждается, обсуждает как это реализовать).Конечно, вариант этот «пластиковый», то есть придуманный, но механизм, думаю, иллюстрирует. Рассматривая вариант с архитектурой новый разработчик тоже может вести себя придерживаясь этой, несколько «обратной», логики.
— Мужики, привет. Я тут померял нагрузку на сотне пользователей, наша архитектура показала вот такие цифры: А, В, С. (факт, с которым пока никто не спорит) или Я тут попробовал вкрутить новый модуль, оказалось, что надо прописывать зависимости в 14-ти местах и я не уверен, что вы мне не подскажете еще пару мест, о которых я просто не в курсе. (еще один факт, с которым тоже никто не спорит, а возможно тут же кто-то подскажет те самые «еще пару мест», тем самым подтверждая то, что вы говорите). — Думаю, что вы ту тему уже обсуждали и какие-то варианты пробовали. (вы говорите «Я могу что-то не знать» и это нормально, вы адекватный человек и вы правда можете что-то не знать) Мы можем придумать какой-то вариант, чтобы модуль А держал нагрузку Х? (вы знаете правильный ответ, мы помним, но нам нужно обойти защиту, которая возникнет тут же, как только вы выстрелите своим вариантом). — Ну фиг знает… Мы уже пробовали, не вышло… (вы с этого и начали, они не просто сидели и тупо ждали пока кто-то им скажет об этом, они умные люди и они пробовали) Менеджмент не согласился,.. Заказчик не понял,.. (слушайте, а еще лучше записывайте — люди любят когда их слушают). — Угу, а какие варианты рассматривались? (вы признаете их предыдущий опыт, а признаете значит принимаете и не будете на него нападать: защищать нечего) Слушайте, а если бы наша система/модуль была спроектирована вот так […], она бы держала нагрузку / в нее было бы удобнее интегрировать новый функционал. (аккуратно, на уровне идеи, которую вы предлагаете обсудить).Аналогичный подход, кстати, работает при обсуждении технического вопроса с исполнителем, который приходит с проблемой:
— У меня не получается. (а вы точно знаете как сделать или как можно попробовать, ваш мозг буквально выталкивает несколько решений сразу) — А что ты уже попробовал? (выясняем варианты, которые были испробованы + непрямо договариваемся, что приходить надо попробовав решить задачу) — Я вот так и вот так, а оно все равно никак. (сейчас, между прочим, ваш коллега сделал героическое усилие и признался себе и вам, что у него что-то не получилось — если хотите раз и навсегда замкнуть его и узнавать о проблемах в самый последний момент, валяйте, рубите ему в ответ готовые варианты в формате «Это же очевидно!» и научите его спорить с любым вашим мнением на будущее)[третий важный момент: если это не горящая проблема или тикающая бомба — прикусите язык! для вас принципиально важно, чтобы ваш подчиненный решал эти вопросы самостоятельно, иначе вы не вырастаете из инженера в менеджеры в принципе]
— Да-а-а-а, задачка. (соглашаетесь с тем, что он пришел не просто так, это важно, иначе может больше не прийти пока не завалится совсем) И что ты думаешь делать? (для многих инженеров, которые пришли с гордостью спихнуть проблему на голову менеджера, этот поворот поначалу будет очень и очень удивителен, как же так, менеджер или тех.лид не взял привычно к себе на плечи еще и эту проблему и не побежал ее героически решать…) — Ну, ваще-то есть вариант… (киваете, поддакиваете, можете аккуратно «на уровне идеи в общий пул вариантов» подбросить идею решения, но не готовый сценарий).Есть вариант, когда инженер тут же уходит в защиту «Если бы знал, не пришел!» Тут важно спокойно пояснить, что ты без наезда на то, что оно не вышло сразу правильно и быстро, просто задача это инженерная и решать ее должен он как инженер, а если в инженерном поле она не решается, то будем ее вытаскивать на уровень архитектуры или управления проектом (что-то делать с требованием, задачей, сроками и т.д.). Или просто предложить спокойно подумать, посоветоваться с кем-то, но не забирать задачку в свою зону ответственности. Оговорюсь, сразу ничего не бывает, этот формат работы нужно спокойно и планомерно внедрять. Вы же со своими друзьями тоже не сразу стали доверять друг-другу и нормально открыто говорить о проблемах. Если попытаться собрать этот подход в простые правила, то получается следующее:
- Не атаковать прошлое, потому что его нельзя исправить.
- Говорить и думать в терминах настоящего и будущего.
- Говорить и думать не в модели «Надо менять потому, что…» (от плохого), а в модели «Для того чтобы стало вот так…, нам нужно» (к хорошему). Тем самым мы избегаем проблемы отрабатывать защиту прошлого.
- Пробовать больше спрашивать, а не говорить.
- В идеальном сценарии, нужно спроектировать хороший вариант будущего, перенести обсуждение в это будущее и уже из будущего вместе думать как в него попасть.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.