"Кому надо - тот поймёт".
Знакомая фраза?
Особенно в инженерной среде.
"Я же всё написал".
"Мы это на совещании обсуждали".
"Он сам должен был спросить".
"Там и так всё очевидно".
А потом выясняется, что один человек понял одно, второй - другое, а третий вообще решил, что речь шла о следующем этапе.
И начинается:
- Я думал, Вы уже сделали.
- А я думал, Вы только проверяете.
- Но я же писал!
- А что именно Вы хотели от нас?
Проблема не всегда в невнимательности коллег.
Автор сообщения знает контекст, который получатель не видит.
И чем выше цена ошибки, тем опаснее рассчитывать на то, что "кому надо - тот поймёт".
В новой статье разбираю на конкретных примерах:
Потому что иногда между фразами "Кому надо - тот поймёт" и "Я думал, Вы имели в виду другое" стоят несколько дней работы, переделка и деньги.
А Вы сталкивались с ситуацией, когда все участники одного совещания потом совершенно по-разному понимали, о чём договорились?
Я не раз слышала эту фразу от технических специалистов. И каждый раз понимаю, откуда она берётся.
Когда человек двадцать лет работает в одной профессии, знает производство изнутри и с коллегами разговаривает почти на профессиональном языке жестов, ему действительно бывает достаточно двух слов.
- Ну там надо немного поправить.
- Что именно?
- Ну, как обычно.
И коллега понимает.
Потому что у них за этими двумя словами - общий опыт, десятки похожих ситуаций, одни и те же чертежи, оборудование, технологические процессы и прошлые ошибки.
Но однажды в эту цепочку попадает человек, который не знает всего этого контекста.
Новый сотрудник.
Коллега из соседнего подразделения.
Руководитель, который не погружён в технические детали.
Подрядчик.
Заказчик.
И вот тогда выясняется: "как обычно" для каждого означает что-то своё.
А дальше появляются очень знакомые производственные фразы:
- Я имел в виду другое.
- Я думал, вы уже сделали.
- Мы это на совещании обсуждали.
- А что тут непонятного?
Мне вообще кажется, что большая часть проблем инженерной коммуникации возникает не потому, что люди не умеют разговаривать.
Они слишком хорошо понимают друг друга - но только внутри своего контекста.
И это довольно коварная ловушка.
"Я же всё написал"
Представим вполне обычную рабочую ситуацию.
Инженер отправляет коллеге письмо:
"Прошу учесть изменения по узлу согласно последней версии документации".
С точки зрения автора всё очевидно.
Он знает, о каком узле речь.
Знает, что именно изменилось.
Помнит, какую версию они обсуждали вчера.
Знает, что коллега должен сделать дальше.
Но получатель видит только одну фразу.
Какие изменения?
Какая последняя версия?
Что именно нужно сделать?
Старую работу остановить?
Нужно только принять информацию или уже вносить изменения?
И здесь возникает интересный парадокс.
Автор письма действительно всё написал.
Но получатель всё равно может ничего не понять.
Почему?
Потому что информация и контекст - не одно и то же.
Контекст находится в голове автора.
А получателю достаётся только сообщение.
Однажды я специально стала обращать внимание на слово «понятно»
Оно очень часто появляется в профессиональных разговорах.
- Всё понятно?
- Да.
И люди расходятся.
Но что именно означает это "да"?
Иногда:
"Я понял, что вы сказали".
"Я примерно представляю, о чём речь".
"Я понял, что от меня что-то хотят, но пока не знаю что".
А иногда человек просто не хочет продолжать обсуждение.
Особенно если перед ним более опытный специалист или руководитель.
Поэтому в важных рабочих ситуациях вопрос:
"Всё понятно?"
я считаю почти бесполезным.
На него очень легко ответить "да".
Гораздо полезнее спросить:
"Правильно ли я понял, что до пятницы нужно проверить возможность изменения конструкции, а решение пока не принимаем?"
Вот здесь уже появляется предмет разговора.
Если человек понял иначе, ошибка обнаружится до того, как начнётся работа.
Самая дорогая часть коммуникации - та, которую приходится переделывать
На производстве плохая коммуникация редко выглядит как красивая ссора двух людей.
Чаще она выглядит очень буднично.
Кто-то сделал не то.
Потом обнаружилось.
Потом нашли письмо.
Потом выяснили, что формально каждый действовал вполне логично.
И начинается поиск виноватого.
- Почему вы изготовили эту деталь?
- Потому что получили вот этот чертёж.
- Но я же говорил, что это старая версия!
- Где?
- Ну, на совещании.
- Я на том совещании не был.
Вот здесь особенно хорошо видно, почему фраза «мы же это обсуждали» не всегда является аргументом.
Обсудили - не значит зафиксировали.
Зафиксировали - не значит поняли одинаково.
Поняли одинаково - не значит определили, кто и что делает.
Совещание - ещё не договорённость
Я вообще очень осторожно отношусь к фразе:
"Мы это на совещании решили".
На совещании можно обсудить десять вариантов и разойтись с десятью разными представлениями о результате.
Например.
Конструктор говорит:
- Теоретически крепление можно перенести.
Технолог слышит:
- Крепление будем переносить.
Производство слышит:
- Пока ничего не меняем.
Руководитель слышит:
- Есть техническая возможность, решение будет позже.
И каждый потом действует исходя из того, что услышал.
Никто не врёт.
Никто специально не саботирует работу.
Просто решение не было сформулировано.
Поэтому после обсуждения я бы всегда задавала четыре вопроса:
Что решили?
Кто делает?
К какому сроку?
Что должно появиться в результате?
Причём последний вопрос очень важен.
Потому что "проверить вопрос" - это не результат.
Результат может выглядеть так:
"Заключение о возможности изменения конструкции с оценкой влияния на прочность и срок изготовления".
Теперь понятно, что должно быть сделано.
"Кому надо - тот спросит"
С этой фразой тоже всё не так просто.
Представьте нового инженера.
Он получил задание, но не понял один момент.
У него два варианта.
Спросить.
Или попробовать догадаться.
Если в подразделении нормально относятся к вопросам, он спросит.
Если принято считать, что хороший специалист «должен сам разобраться», он, скорее всего, сначала попробует разобраться самостоятельно.
И это совершенно естественная человеческая реакция.
Особенно у новичка.
Ему хочется показать:
"Я справляюсь".
Поэтому иногда руководитель удивляется:
- Почему ты не спросил?
А сотрудник честно отвечает:
- Я думал, что должен был сам разобраться.
Получается странная ситуация.
Мы хотим самостоятельных сотрудников.
Но одновременно создаём среду, в которой вопрос воспринимается как признак слабости.
А потом удивляемся ошибкам.
Что я бы изменила в такой ситуации
Не говорить:
"Если что-то непонятно - спрашивай".
Это звучит хорошо, но слишком абстрактно.
Лучше заранее обозначить:
"Если у тебя возникнет сомнение по размеру, последовательности операции или исходным данным - не додумывай. Приостанови работу и спроси".
Вот это уже рабочее правило.
Особенно для новичков.
Мы фактически даём человеку разрешение не угадывать.
А в производстве это очень полезное разрешение.
Есть ещё одна проблема: специалист не всегда знает, что именно непонятно другому человеку
Это особенно заметно в работе между подразделениями.
Допустим, инженер отправляет руководителю расчёт.
Для инженера документ понятен.
Формулы есть.
Исходные данные есть.
Результат есть.
А руководитель хочет получить ответ на совершенно другой вопрос:
"Мы можем это делать или нет?"
Инженер дал расчёт.
Руководитель ждал решения.
Оба получили то, что формально просили.
Но задача не решилась.
Поэтому мне нравится перед важным сообщением задавать себе один вопрос:
"Какое решение человек должен принять после того, как прочитает это?"
Если я отправляю руководителю пять страниц расчётов, но не говорю, к какому выводу пришла, я перекладываю на него ещё одну работу:
самому разобраться в моём материале и найти ответ.
Иногда это необходимо.
Но иногда можно написать в начале:
Вывод: предлагаемое изменение возможно. Дополнительных рисков для прочности не выявлено. Для реализации потребуется изменить чертёж и технологическую карту.
А уже ниже - расчёт.
Это не упрощение инженерной работы.
Это нормальная упаковка результата для конкретного адресата.
Почему инженер может говорить сложно - и это не всегда плохо
Здесь я бы не стала обвинять технических специалистов в «сложном языке».
У профессионального языка есть своя функция.
Если два инженера обсуждают конкретный узел, им совершенно не нужно каждый раз объяснять базовые понятия.
Проблема начинается тогда, когда тот же язык используется с человеком, который находится за пределами профессионального контекста.
Например:
"Необходимо выполнить корректировку КД с учётом замечаний по сопряжению".
Для конструктора это может быть нормальная фраза.
Для руководителя другого подразделения вопрос может остаться:
"И что конкретно происходит?"
Можно сказать иначе:
"В чертеже нужно изменить место соединения двух деталей. Сейчас это решение не соответствует требованиям производства. Конструктору нужно внести изменения и повторно выпустить документ".
Смысл тот же.
Но теперь человеку не нужно переводить сообщение с профессионального языка.
Я часто предлагаю простой приём: сначала смысл, потом детали
Например, вместо:
"В результате проведённого расчёта с учётом коэффициента запаса…"
начать:
"Предложенный вариант использовать нельзя: деталь не проходит по прочности".
А потом уже объяснить почему.
Или:
"Изменение возможно, но увеличит срок изготовления примерно на два дня".
И дальше - техническое обоснование.
Такой порядок очень помогает руководителям.
Сначала они получают ответ на вопрос:
"Что мне важно знать?"
А потом могут разобраться в технической части.
Но есть и обратная сторона
Иногда гуманитарно настроенные специалисты, наоборот, начинают чрезмерно упрощать техническую информацию.
И это тоже плохо.
Нельзя заменить инженерное содержание красивыми словами.
Фраза:
"Нужно немного оптимизировать конструкцию"
может звучать прекрасно.
Но инженер должен понимать:
что изменить, где изменить и в каких пределах.
Поэтому задача хорошей коммуникации не в том, чтобы сделать технический текст «простым».
Задача - сделать его однозначным для конкретного адресата.
Это разные вещи.
Я бы проверяла важные сообщения вот так
Не по принципу:
"Я всё написал?"
А по принципу:
"Может ли человек после моего сообщения сделать не то, что я имел в виду?"
Если ответ "да" - сообщение стоит доработать.
"Подготовьте новую версию документа".
Что здесь может пойти не так?
Какую версию?
Что именно изменить?
Кто готовит?
Когда?
Кому отправить?
А теперь:
"Иванов, до 16:00 10 октября внесите в чертёж КД-27 изменения по пунктам 2 и 3 из замечаний от 8 октября. Остальные размеры не менять. Новую версию направьте мне и технологу Петрову".
Вот теперь значительно меньше вариантов для трактовки.
Да, предложение длиннее.
Но оно дешевле, чем переделка.
И всё-таки: когда "кому надо - тот поймёт" действительно работает?
Работает.
Если люди находятся в одном контексте.
Если они давно работают вместе.
Если задача простая.
Если цена ошибки невысока.
Если речь идёт о привычной операции.
Я не призываю превращать каждое рабочее сообщение в официальный документ на две страницы.
Наоборот.
Хорошая коммуникация часто очень короткая.
Просто в ней есть главное.
"Чертёж КД-27 - в работу. Используем версию от 8 октября. Изменения только по креплению. Старую версию не использовать".
Четыре коротких предложения.
И человеку понятно, что делать.
Самое полезное правило, которое я бы оставила инженерам
Перед отправкой важного сообщения спросите себя:
"Если человек поймёт меня неправильно - я смогу доказать, что написал однозначно?"
Если да - отлично.
Если нет - лучше добавить ещё одно предложение.
Иногда именно эти десять лишних секунд экономят несколько часов работы.
А бывает, что и несколько дней.
И здесь я возвращаюсь к началу
Мне нравится эта фраза как описание профессиональной интуиции.
Когда люди много лет работают рядом, они действительно могут понимать друг друга с полуслова.
Но организация не может строить работу только на этом.
Потому что сотрудники меняются.
Проекты меняются.
Подразделения меняются.
В работу приходят новые люди.
А техническая информация остаётся.
И если она передаётся только вместе с "контекстом в голове" конкретного специалиста, организация становится зависимой от этого человека.
Для меня зрелая инженерная коммуникация - это не когда все научились писать красивые письма.
И даже не когда все перестали использовать профессиональные термины.
Это когда важная информация может пройти от одного человека к другому без потери смысла.
И человек на другом конце цепочки не обязан угадывать:
что именно произошло, что от него хотят и какой результат считается правильным.
Потому что хорошая коммуникация - это не когда автору всё понятно.
Это когда понятно тому, кто должен после этого что-то сделать.
Отправляя данные вы подтверждаете пользовательское соглашение