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

Этот же прием работает и при подготовке к рабочим встречам.
Предположим, вы хотите согласовать свое будущее внедрение. Не важно, в виде распоряжения или плана проекта или даже слайда с целями на ближайший отчетный квартал/полгода/год.
И вот вы готовитесь к встрече.
Представьте себе, проиграйте в голове, как отреагирует на ваше предложение тот, с кем вы будете его обсуждать.

⬆️ А как представить на шаг вперед ход вашего контрагента, если вы человека почти не знаете или он не в вашей иерархии?

На самом деле 80% позиции контрагента по переговорам, будет зависеть от его номинальных KPI (КПЭ). Если по-простому, то от того, за что он получит квартальный/годовой бонус или, наоборот, люлей.

⏺ Руководителю от ИТ-сопровождения важно, чтобы ваш проект или продукт не принесли больше дефектов на ПРОДе. Он в 90% случаев не услышит спасибо за ваше внедрение, но с 90% вероятностью больно получит за рост инцидентов в его зоне ответственности.

⏺ Представителю от Data Protection Office важно, чтобы вы не нарушили регламенты или законы, связанные с распространением данных.

⏺ Ответственному от кибербезопасности - что вы не увеличите риск утечки данных или внешнего проникновения.

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

Совсем хорошо, если вы помимо номинальных KPI(КПЭ), знаете еще и конкретные, это сильно упростит и вашу подготовку к встрече и сами переговоры - но, не всегда точные KPI вам могут быть известны. Впрочем, вы в случае если установилось продуктивное общение, можете про них в явном виде спросить.

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

Ситуативочка с назначением Андрея Рэмовича Белоусова - Министром Обороны.

Если ты - топ-менеджер, то зона ответственности у тебя - бесконечная. Всегда появляются задачи за рамками привычных компетенций, которую просто больше некому делать, т.к. ты и есть топ.
У успешного топ-менеджера всегда есть среди подчиненных 1-2 менеджера, которым бесконечно доверяешь и которым можно поручить самую сложную задачу. Не знаешь кому - поручи ему.
Вот Андрей Рэмович - и есть такой менеджер у В.В.П.

По поводу того, что А.Р. Б. - не военный человек.
Значит, от министра обороны требуется решение менеджерских задач, а не военных.
Войсковые операции должен планировать военный человек.
А, например, внедрение цикла производства, скажем, беспилотников, или выделение необходимого и достаточно бюджета на год - лучше поручать профильному менеджеру.

Сергей Кужугетович Шойгу, до некоторого момента, тоже был таким же доверенным менеджером. Он ведь не только МО и МЧС, он и Московскую область возглавлял.

Лифт-тест.
Сможете ли вы прорешать вопрос с менеджером более высокого звена пока едет лифт?

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

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

Представим, что здание - высотное, кто-то заходит/выходит на промежуточных этажах, итого у вас есть примерно минута.
Как потратить это время эффективно?

На самом деле, ваш занятый высокопоставленный коллега и сам с радостью вам поможет, при обязательном выполнении условий:
▪️Босс точно понял, что это - его решение (а не кого-то еще);
▪️Он вашу проблему может решить быстро (клик, тап, подпись на бумаге, форвард, ок и т.д.);
▪️Это - правильное решение, т.е. он от этого экспресс-решения в лифте не пострадает, а, наоборот, выиграет;
▪️Чел сэкономит свои ресурсы и время, и поможет своим и вашим задачам.

Поэтому и конструкция вашего обращения в лифте должна быть примерно такая:

- Здравствуйте Семен Аристархович
- (опционально, если не знакомы) Я - Олег Олегов, руководитель задачи такой-то/подразделения такого-то
- У вас на согласовании распоряжение/проект решения
- Ваши подчиненные все согласовали, от вас только кнопку нажать
- Вопрос срочный, т.к. завтра фиксируется конкурсная документация на сайте или подрядчик ждет денег или истекает поручение Председателя Правления (или что-то еще важное, почему надо вопрос решить прямо сейчас в лифте)
- Вот бумага и ручка / вот ссылка / вот письмо, могу переслать -
{т.е. абсолютная минимизация усилий занятого босса }

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

С другой стороны, если вы научитесь так выражать свои мысли в общении с важными лицами, то для вас и переменная "лифт" становится не обязательной :)

Сегодня все и везде репостят замечательную цитату А.Р.Б.:

ошибаться можно, врать нельзя

а я хотел бы предположить, почему этот принцип вообще был озвучен в публичном пространстве.

Дело в том, что у нашего с вами культурного кода есть несколько свойств:

🤫У нас принято не говорить о своих ошибках руководителю /менеджеру

Каждый, кто ошибается и об этом молчит, обычно руководствуется одним или несколькими соображениями из списка:
- Не хочется выглядеть некомпетентным в глазах руководителя
- Боится получить тех или иных люлей, словесных или материальных
- Ему и так на душе тяжело, и не хочется, чтобы стало тяжелее по итогам обсуждения с боссом
- Верит, что негатив от разговора получить можно запросто, а пользы от этого - никакой. Все равно ошибку исправлять, только с дополнительным поручением и чрезмерным контролем руководства.
- Считает, что он быстрее эту ошибку исправит, чем руководство заметит, а значит негатива можно и избежать
- иное

🤐 У нас не принято еще и доносить наверх негатив, будь то отставание по срокам от плана, критические дефекты качества, иные неприятности.

Все те же аргументы, что и выше.
Разве что еще может от руководителя прилететь что-нибудь вида:
"А тебе погоны не жмут, часом?"
или
"Я нанимал высокооплачиваемого сотрудника, чтобы он решал такие проблемы, а не порождал их мне. Если ты их не можешь решить - ищи работу, я найду себе другого, который сможет такие задачи решать".

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

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

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

У всех этих сценариев есть два неприятных следствия, и вовсе не то, что виновный не понес наказание, и даже не сдвиг по срокам как таковой, а:

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

А нельзя решить системную проблему, если не знаешь даже о точечной.
⬇️

Ок.
А делать-то что, если это - культурный код ? Нельзя же изменить культурный код общества в рамках отдельно взятого проекта.

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

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

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

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

Так вот, есть некое ощущение, что А.Р.Б. своим заявлением хотел сказать своим новым подчиненным и контрагентам примерно то же самое.

Мультик Кордебалет от Смешариков - для меня лучший мультик про руководителя проекта и одновременно курс молодого бойца для начинающих РП

Значит плохо "продавал"

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

ИТ-Директор одной из крупных корпораций выявил, что у крайне важной для поддержки бизнеса старой ИТ-системы нет серверов и системы для резервирования. А значит, если система рухнет, то восстанавливать ее будет не откуда, и будут те или иные потери.
Осознав, что эти сервера с системой срочно надо купить, он отправился утверждать финансирование закупки, как полагается, на коллегиальном органе (комитете), принимающем важные решения в корпорации.
Сумма закупки была значительной, предположим, >1 миллиона долларов.

Пришел, выступил, рассказал зачем, почему так дорого...
Комитет посовещался и в финансировании отказал.

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

И в третий раз закинул старик в море невод пришел ИТ-Босс на комитет, снова попросил финансирование и снова решение не приняли.

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

Шум, гам, волна эскалаций...
Вызывают ИТ-директора на ковер на самый высший уровень, все друг друга перебивая задают вопросы: "Как допустил?", "Почему не предусмотрел?" и т.д. в разных выражениях.
Руководитель ИТ и отвечает: "ну как же не предусмотрел? Вот я к вам на комитет приходил за резервным сервером раз - отказали, два - отказали, три - отказали"
Ему и ответили:

значит плохо "продавал".

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

Такой подход верен абсолютно на любом уровне принятия решения.
Даже в семье.

#быль

Ремонт квартиры как проект

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

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

Или вы - бригадир = РП,
у вас есть бригада ремонтников, которая вас слушается,
и есть хозяин квартиры = заказчик, которому нужно всегда знать:
- когда ремонт закончится;
- во сколько ему обойдется его новая хотелка "ой, а можно еще в ванной комнате кафель поменять";
и с которым надо согласовать всякие внезапно обнаруженные в ходе проекта-ремонта чудеса (ой, у вас тут электрокабели у розетки совсем сгоревшие, может хороший кабель поставим, а то может пожар случиться?).

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

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

Вот и в ИТ-проектах все ровно так же.

Добавлю еще, что у меня не было еще ни разу проектной ситуации, которую я не смог бы описать в виде аналогии ситуации с ремонтом квартиры :)

Важность контекста

Когда вам от руководителя или руководителю от вас по вашей задаче нужна помощь, начинать надо с введения в контекст.
Как кратко ввести в контекст зависит, безусловно, от того, когда последний раз и насколько плотно вы обсуждали задачу. Но как бы вы плотно ни общались, в текущий момент времени руководитель сфокусирован на своих проблемах, а не на ваших. А может, у него проблем сейчас и вовсе нет, и он спокойно делает свою запланированную работу и о вашем проекте вообще не думает.
Один мой знакомый зам. Руководитель блока ИТ, к сожалению, он ныне не с нами, легендарно учил одного из моих коллег.

- Вот представьте себе, я – генерал, сейчас ночь и я сплю. Вдруг раздаются взрывы, выстрелы, шум, гам...
Вбегаете вы, начинаете запыхавшись рассказывать, что у Иванова заклинило ружье и он стрелять не может, Петрову не хватает патронов, Сидоров – обделался…
🙉
…
Да вы хоть скажите мне, кто на нас напал?
...
Армия какого государства стреляет под моими окнами?
...
Ах это наша армия?! И сейчас учения идут?! Ааа, ну так бы сразу и сказали.
Адъютант! Соедините, пожалуйста, с полковником Смирновым, который за проведение учений отвечает

​​Инструмент для установления авторитета

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

Авторитет - не дают, его - берут.

Как же его взять, если команда новая, и менеджера еще не знают?

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

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

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

👉 И тогда, это становится инструментом для управления проектной командой, причем в обе стороны.
С одной стороны, можно рассказать главному заказчику, что со стороны проектной команды вот здесь стоит что-то улучшить (вовлеченность, ресурсы, приоритеты и т.д.).
А с другой стороны, можно решение, необходимое для проекта и проектной команды быстрее принять, правильно "продав" его главному заказчику.

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

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

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

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

Если мультфильм, который полезно посмотреть, РП - это Смешарики "Кордебалет", то какой тогда фильм?

Мое мнение - Оппенгеймер.

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

P.S. Упоминать Криминальное чтиво и Уинстона Вульфа я не стал, т.к. этому примеру около 20 лет.

Деперсонификация как первый шаг разрешения проектного конфликта.

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

🤵‍♂️ Есть заказчик, назовем его (чтобы имя случайно не совпало) Уолтер, который настаивает на сроке внедрения, уверенно говорит, какая катастрофа случится, если этот срок не выдержать даже на день (миллионы жалоб, отзыв лицензии, миллиардные убытки, банкротство и увольнение всех, нужное подчеркнуть...).
Доработать нужно 5 ИТ-систем, руководители разработки 4-х систем из 5 подтвердили, что к концу текущего квартала завершат разработку и выйдут на интеграционное тестирование, а к концу следующего - доведут свои системы до внедрения;

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

🧑‍🏫 Есть руководитель проекта, Джон, от которого и требуется завершить проект в желаемый Уолтером 🤵‍♂️ срок.

Я неоднократно слышал, от людей в роли РП-Джона 🧑‍🏫 предложения, как эту задачу решить, а именно:

🤜 Попробовать еще раз договориться со Стивеном 🧑‍💻 , указав дедлайн (некоторые, к слову, этот шаг пропускают и начинают сразу со следующего)

🤜🤜 Эскалировать вопрос на руководителя Стивена 🧑‍💻 и настоять на желаемом сроке

⛈️Эскалировать вопрос на Уолтера 🤵‍♂️, а то и на его руководителей, направив его гнев/аргументы на Стивена 🧑‍💻 . В формате (все согласны, один ты - такой-сякой)
И так до победного конца.
Успехом считается продавливание Стивена 🧑‍💻 на желаемый срок.

Лично на мой взгляд, данный сценарий имеет ряд не очень приятных свойств:
- не зная расклада, я бы оценил вероятность успеха в 50%: продавит Джон 🧑‍🏫 (+ помощь) или нет;

- победа в данном вопросе может стать для Джона 🧑‍🏫 одноразовой. В следующий раз Стивен 🧑‍💻 лучше подготовится и сможет запрос отбить. Более того, он может "обидеться", и отбить даже запрос, который смог бы своими ресурсами реализовать;

- часто бывает, что в результате такого сценария Джон 🧑‍🏫 , скажем деликатно, сильно усложнит будущее взаимодействие со Стивеном 🧑‍💻 совершенно без каких-либо плюсов, потому что окажется, что Уолтеру-то 🤵‍♂️ и не настолько этот срок - дедлайн. 🫤
Я сам лично слышал, как заказчик, который рассказывал мне и окружающим, какая катастрофа наступит на следующий день после дедлайна, если не завершить работы, он же потом целый квартал рассказывал всем как он без этого результата спокойно проживет.

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

А как тогда действовать?

Читать далее

#деперсонификация

По ситуативочке могу сказать только одно.
Стартовая позиция менеджера, если он хочет достичь договоренности,

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

Чем сложнее и важнее переговоры и сильнее оппонент - тем более верно это утверждение.

Когда еще работает деперсонификация конфликта.

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

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

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

🚦 А может быть он из тех, кто просто считает своей должностной обязанностью предотвратить нарушение/риск/катастрофу.
Как турникет в метро.
Турникет же не волнует ваша жизненная ситуация, куда вы опаздываете и как драматически изменится ваша жизнь, если вы опоздаете.
Билет не приложили - барьер закрылся. В некоторых случаях больно для частей вашего тела.
С вашей точки зрения турникет вступил с вами в конфликт, но точно ли целесообразно тратить нервы на войну или объяснение своей позиции ?

☝️ Для меня деперсонификация конфликта - это и есть выведение конкретного человека и эмоций по отношению к конкретному человеку - за скобки конфликта.
Я либо невольно оказался в конфликте с ролью, играющую по заданному сценарию - и тогда моя задача, чтобы мы сыграли вместе и в общих интересах. А их всегда можно найти.
Либо я конфликтую с "турникетом", и тогда мне нужно просто купить билет и приложить, чтобы "турникет открылся".

Нет человека - нет и конфликта.

#деперсонификация

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

Умение видеть за деревьями лес - одно из важнейших качеств сильного менеджера проекта.

Менеджер всегда должен быть в контексте своего проекта и его окружения - без этого он не сможет ни проектом управлять, ни ожиданиями всех сторон.

📍Точно ли истинные мысли заказчика до буквы совпадают с тем, что он говорит на проектных встречах?
📍Если заказчик или смежник принимает "нелогичные" решения или предлагает "нелогичные" шаги, а ваши «логичные» предложения отвергает - точно ли вы правильно понимаете его логику?
📍Если прилетело распоряжение на всю корпорацию или на весь ваш блок, вы оценили его влияние на ваш проект? точно ли совсем никак не влияет?
📍Понимаете ли вы генеральную линию вашей корпорации и, в частности, чем ваш стейкхолдер дышит в контексте генеральной линии?

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

#контекст #окружение

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

🦻👀 Послушайте внимательно, кто что говорит.
Попробуйте обратить внимание на невербальные признаки.
Сопоставьте услышанное с ролью, с позицией, с должностью.
А потом с тем, что вы ожидали услышать.
Если вы ожидали услышать совсем не это - забудьте то, что ожидали. Важно то, что услышали.

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

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

💪 Упражнение повторять до того момента, как оно не войдет в привычку.