Что может помешать видеть реальность
Выполнить заземление по алгоритму – это достаточно просто технически. Обычно проблемы с заземлением возникают по причинам психологическим. Например, люди могут отказываться заземляться, потому что это больно: после заземления станет очевидным разрыв между текущей эпистемой о себе и реальностью. Инженер-менеджер может считать, что он может/способен реализовать 5 инициатив/проектов за месяц. В реальности происходит следующее: он планирует выполнить 5 инициатив, но регулярно/систематически выполняет за месяц только 2. Но если инженер-менеджер признает это, то для него это может стать ударом по самооценке: он думал, что хорош в планировании и выполнении работ, а оказалось, что не очень. Поэтому в моменте инженер-менеджер может применять стратегию «замести проблему под ковёр и не признавать её». В чуть более долгосрочном периоде такая стратегия страуса приведёт к ухудшению проблемы: инженер-менеджер будет косячить, но даже не понимать, почему. Кроме того, если задачи и инициативы/проекты начнут усложняться и/или их количество будет увеличиваться, то пропускная способность этого инженера-менеджера начнёт падать нелинейно.
Что на самом деле следует делать в такой ситуации: во-первых, разделить эпистемы «я хороший» и «я могу выполнить 5 инициатив в месяц», не ставить одно в зависимость от другого. «Я хороший» – это характеристика вас как личности, а «я могу выполнить 5 инициатив в месяц» – это характеристика пропускной способности/Throughput/Operational Throughput инженера-менеджера в проекте, т.е. вас как «рабочей станции» в рамках проекта, а не вас как личности. Напрямую они вообще не связаны. Это разные характеристики объектов (разные described_entity), выделенных по-разному (разные точки зрения/viewpoints) и в разных контекстах/context! «Вы как личность» =/ «вы как рабочая станция»! «Рабочая станция» задействует какую-то часть вашей личности, но не всю целиком, поэтому характеристики рабочей станции из предметной области операционного менеджмента никак нельзя переносить на характеристики личности в целом.
Во-вторых, если вы регулярно получаете замечания по поводу невыполненных инициатив, следует заземлиться и проверить, а насколько верно представление «я могу выполнить 5 инициатив в месяц». Вероятно, ваше представление о вашей реальной пропускной способности/Throughput/Operational Throughput как рабочей станции/workstation неверное. Замечание – это не атака на вас как на личность, а сигнал о том, что эпистема о ваших характеристиках как рабочей станции может быть неверна.
Далее нужно будет записать предположение/гипотезу: «возможно, я неверно оцениваю свою пропускную способность/Throughput как рабочей станции в проекте». Пропускная способность в операционном менеджменте – это характеристика рабочей станции, отражающая выпуск станции за указанный период. Внутри предприятия выпуск часто измеряется не в штуках деталей станка, выпущенных за период, а в штуках задач и проектов (инициатив), завершённых за период времени. В нашем примере 5 завершённых инициатив – это ожидаемый месячный выпуск конкретной рабочей станции. Но реальный выпуск – 2 завершённые инициативы. Ещё 2 инициативы из 5 – это «незавершёнка»/Work-In-Progress/WIP, а к одной инициативе даже не прикасались. Можно ли в этом случае увеличить реальный выпуск? Можно. Для этого надо в первую очередь ограничить число инициатив, которые рабочая станция берёт на месяц (ограничить входящий поток работ) и вместо 5 брать 3 инициативы на месяц. Во-первых, мы знаем, что 2 инициативы к концу месяца завершаются, а ещё две в процессе. Значит, брать 4 нет смысла – они тоже не будут выполнены. А вот если взять 3, то всё может получиться: под конец месяца рабочая станция не будет разрываться между двумя незавершёнными инициативами, а сфокусирует все усилия на одной. В итоге реальный выпуск составит 3 инициативы в месяц вместо прежних двух. Это реальный случай, и в компании, которая начала ограничивать входящий поток работ с учётом реальной пропускной способности/Throughput рабочих станций, выпуск увеличился в 1,5 раза. С точки зрения операционного менеджмента это успех.
Во-вторых, признавать реальность может быть напряжно. Вы понимаете, что после того, как признаете и опишете проблему, вам придётся её как-то решать, а для этого – напрягаться. Более того, если вы опишете проблему хорошо, скорее всего, вы выясните, что нужно будет выполнить куда больше разных работ. В примере с «мониторингом сервиса подписки» инженерам, получившим от менеджера эпистему «нужен мониторинг сервиса подписки», удобно не уточнять, что на самом деле имел в виду менеджер, а предположить своё. Опытные инженеры вполне могут в глубине души понимать, что менеджеру не дашборд в Grafana нужен, а что-то другое. Но если они сами уточнят/заземлятся, то выяснится, что нужно будет выполнить больше задач, например, помимо дашборда настроить уведомления о сбое в сервисе, прописать процедуры восстановления, назначить ответственных и так далее. Инженеры по-человечески не хотят напрягаться и предпочитают свалить ответственность на менеджера: «он неправильно сформулировал нам задачу и не уточнил, не проверил, мы не так поняли». В целом, они не так уж неправы: менеджер должен был вместо хотелки/чистой эпистемы дать описание задачи и убедиться, что исполнители поняли задачу правильно. Но и исполнитель должен убедиться, что сам правильно понимает задачу и не будет делать ненужную работу (или нужную, но не до конца). Требуется перекрёстная проверка: заказчик решения должен убедиться, что исполнитель понял задачу правильно и может её выполнить в нужные сроки (у него есть такая способность/U.Capability в FPF), исполнитель тоже должен убедиться, что понял задачу правильно, а ещё – что договорился с заказчиком о необходимых для выполнения задачи ресурсах.
Что делать в этой ситуации? Обычно в данном случае нужны полномочия, чтобы поменять правила игры. В данном случае нужно менять методы постановки задач и методы контроля исполнения задач. Допустим, вы как руководитель по должности[1] обладаете необходимыми полномочиями. Тогда вы планируете организационное изменение: описываете, как ситуация выглядит сейчас/as is (с примерами) и как ситуация должна выглядеть после завершения оргизменения/to be (тоже с примерами). Например, описываете: «у нас в компании есть процесс постановки и исполнения задач. Выглядит он так: есть заказчики, которые ставят задачи, есть исполнители, которые выполняют поставленную задачу. Заказчики описывают, что нужно будет сделать, и полученное описание работы кладут в виде задачи в корпоративный планировщик/таск-трекер. Исполнители принимают задачу и начинают её выполнять, в установленный срок показывают результаты (рабочие продукты) заказчику. К сожалению, в ходе этого процесса регулярно случаются недопонимания: заказчики неясно описывают задачу и не проверяют, поняли ли их исполнители. Исполнители, в свою очередь, не понимают заказчика, но не уточняют, что он имел в виду («не сверяют часы»). В итоге к моменту первой проверки оказывается, что ресурсы исполнителей потрачены на выполнение ненужной работы – или что работа выполнена не до конца. Например, вместо того чтобы быстро восстанавливать сервис подписок после того, как он упал, по согласованной процедуре, и не допускать слишком частых падений сервиса, исполнители просто сделали дашборд, который показывает, почему сервис упал».
В будущем ситуация должна выглядеть иначе: «Заказчик формулирует своё представление о том, какую задачу надо выполнить, а потом описывает её способом, записанном в регламенте постановки задач. Затем идёт обсуждение с исполнителем, в ходе которого заказчик убеждается, что исполнитель понимает задачу. Заказчик и исполнитель обсуждают и выбирают метод решения задачи, договариваются о необходимых для решения задачи ресурсах и о сроках завершения задачи с учётом всех прочих задач исполнителя. Исполнитель уходит решать задачу. Если возникли какие-то затруднения, с которыми исполнитель не может справиться самостоятельно, то он немедленно сообщает об этом заказчику, и далее совместно вырабатывается решение». Дополнительно можно указать, сколько ресурсов сэкономит компания, если проведёт это оргизменение, и насколько ускорит выпуск результатов.
С подобным (только более подробным) описанием вы идёте к руководству, чтобы согласовать оргизменение. После чего можно будет прописать подробный план проведения оргизменения и начать воплощать его в реальность.
Ещё одна причина, по которой мы не видим реальность – это наличие привычных, устоявшихся представлений о мире, которые перестали работать – или никогда не работали. Например, некоторые начальности по должности могут считать, что если как следует наорать на косинус, то он может быть равен 5[2]. Или – что можно «включить режим форсажа» и добить полугодовой объем работ за неделю[3]. Операция заземления игнорируется, реальные причинно-следственные связи не видны. Поставленные в условия, когда от них требуется невозможное, сотрудники в реальности чаще начинают искать возможность отделаться «бумажками» и «показательными выступлениями» вместо того, чтобы сделать нужную работу. Если им это удается, начальник может быть даже счастлив, хотя в реальности для компании не изменилось ничего: проход/выпуск систем не ускорился, количество полученных денег не выросло. Польза от работы равна 0 (как в физике: «перемещения физического объекта нет – выполненная работа равна 0»). Но начальник получил возможность сказать себе, что «он старался, просто работники такие», а сотрудники – «что сделали все возможное». Социальные ритуалы исполнены, физическая реальность компании все та же. Подобные эпистемы обычно впитываются из культуры.
Некоторые привычные представления о мире появились у нас, возможно, не только и не столько из культуры, а из-за особенностей работы мозга. Например, люди склонны бросать выполнение предыдущих задач и переключаться на вновь полученную. Почему? Потому что мозг в первую очередь «заточен» под выживание. Старые задачи – «старые вводные» – нас уже не убили, с ними можно жить. А вот новые еще убить могут, так что надо переключиться. Когда мы убегаем в лесу от хищников, это выгодная стратегия, но в бизнесе подобное поведение очень вредит. Его нужно специально корректировать, помня о том, что по умолчанию человек будет поддаваться соблазну немедленно реагировать на «новенькое» вне зависимости от того, нужно это было или нет.
Иногда непривычным является выполнение самой операции заземления. В школах и университетах нас учат обратной операции – абстрагированию, чтобы мы могли видеть более общие закономерности (например, могли понять, что законы Ньютона – приближение теории относительности). Операция абстрагирования нужная и полезная, но она нужна не одна! Нужно уметь выполнять и операцию в другую сторону – «заземляться». Этому специально не учат. Представители некоторых профессий научаются заземлению неявно. Например, физики-экспериментаторы или инженеры, создающие «железные» системы вроде автомобилей и трансформаторов, чаще привыкают заземляться и оценивать, насколько реально воплотить в жизнь гениальные идеи. Если они будут игнорировать реальность, у них вообще ничего не получится. Но для многих других профессионалов постоянное заземление не является абсолютно необходимым условием, невыполнение которого блокирует деятельность. Поэтому некоторые менеджеры и разработчики ПО периодически забывают заземляться, им нужно специально напоминать себе и окружающим это делать.
Некоторые представления появляются из-за поиска социального одобрения. Например, менеджер спрашивает инженера о сроках выполнения работы. Как нужно было бы ответить, если бы инженер опирался на свое реальное расписание/график работ и оценки трудоемкости: «Выполнение этой задачи занимает 6 часов непрерывного/потокового времени/Flow Time. Сегодня я доделываю другую задачу, поэтому новая в работу пойдет только завтра. Но завтра у меня еще 2 встречи, к которым нужно подготовить информацию. Поэтому реально задача пойдет в работу наверняка только вечером, и я успею поработать над ней 2 часа. Послезавтра у меня только 1 встреча, но она утром, поэтому задача будет выполнена послезавтра лишь к концу дня – при условии, что не возникнет форс-мажоров». Но в реальности инженеры часто говорят что-то вроде «ну 6 часов надо, завтра сделаю». При этом он может понимать, что завтра сдать не получится – но ему важно сейчас получить одобрение от начальства, а там хоть трава не расти. А во многих случаях инженер еще и не рассчитал сам для себя реальное время работы, и сам в общении с менеджером полагается на свое смутное представление о том, что 6 часов должно хватить (при этом нет четкого понимания, когда и как будут выделены эти 6 часов времени). Далее оба начинают полагаться на озвученную оценку, основанную лишь на представлении, «якорятся» на нее. Завтра к концу дня оба будут недовольны: менеджер – потому что не увидит результат в нужный срок; инженер – потому что будет работать до полуночи, чтобы выдать результат, и чувствовать себя глубоко несчастным (и недооцененным). Возможно, между ними возникнет конфликт – явный или не очень. При этом ключевая причина – неверное представление о реалистичных сроках работ – так и останется «невидимой» и потому неисправимой.
Аналогично начальник, который скомандовал сотрудникам «включать режим форсажа», может не желать признавать реальность (приказ не работает), потому что тогда, получается, он ранее был не прав. Значит, он не молодец в своих глазах – а ещё в глазах окружающих (для многих второе страшнее). Проще сделать лицо кирпичом и изображать из себя сурового менеджера с директивным стилем управления, чем признать ошибку. Если вы такой начальник, имейте в виду: вы делаете хуже лишь себе. Окружающие видят, что ваши методы не работают, и думают плохо о вас в любом случае. Плюс вы ещё и не поставляете классный результат компании, не можете как следует реализоваться. Если вы признаете реальность, то заплатите неприятными ощущениями «в моменте» за улучшение результатов в будущем. После заземления вы впервые увидите настоящий объём работ/Workload. Он, как правило, куда больше, чем думают все члены команды (см пример с «нужен мониторинг сервиса подписок»). При этом, если вы увидите этот объём работ после заземления (самостоятельного или с LLM), вы будете лучше понимать, что, когда и как вы можете требовать от команды, а что нет. Вы начнёте быстрее договариваться с командой, сотрудники будут делать то, что нужно. Вы увидите ускорение выпуска достаточно быстро. Многие наши инженеры-менеджеры ускоряют выпуск результатов в 1,5 раза в течение нескольких недель – нескольких месяцев.
Если вы подчинённый такого начальника, то не стоит ему возражать. Дождитесь момента, когда наступит более-менее спокойный период на работе. Он обычно наступает даже в самых хаотичных компаниях. После чего принесите начальнику проект оргизменений, в котором будет описана проблема (с цифрами), предложено решение (примерно как предложено выше), расписаны выгоды от решения (ускорение выпуска в 1,5 раза) и необходимое количество ресурсов. Обязательно подчеркните, что идея вам пришла в голову благодаря вашему начальнику. Зацепитесь за какую-то из фраз, которую он будет произносить во время аврала, напомните ему об этой фразе («Вы тогда сказали вот то и то о нашей команде, и я понял, чего нам не хватает, чтобы мы вас не подводили»). Подчеркните, что разработанный вами проект – заслуга вашего начальника. Если он захочет предоставить этот проект своему начальству как собственную разработку, не оспаривайте это решение. Напротив, помогите вашему начальнику – и тогда он одобрит ваше предложение об изменениях в команде, выделит необходимые ресурсы и даст вам полномочия. И когда он получит повышение, он подтянет вас за собой как полезный актив.
Это не «пустой подхалимаж», как любят заявлять гордые, но бедные рядовые сотрудники, которые не продвигаются в карьере. Это стратегия поведения, основанная на знании законов человеческой природы. Люди не любят признавать свои ошибки и будут защищать представление о себе как о хорошем человеке, компетентном управленце и так далее до последнего. В том числе они будут готовы проигнорировать хорошие предложения, уволить дающих результат сотрудников и даже повредить себе, лишь бы оставаться о себе хорошего мнения и сохранять/поддерживать репутацию в глазах окружающих. По сути, сам начальник в этот момент тоже находится в сложной ситуации. Он понимает краешком сознания, что не вполне прав. Но он не может признать свою ошибку и уронить тем самым свой авторитет перед подчинёнными, и кроме того, может не видеть выхода из этой ситуации. Если вы предоставите ему выход и укажете, что этот выход нашли с его подачи, тем самым вы обеспечите безопасность коммуникации. Вы не член коллектива, который оспаривает его власть и пытается занять его должность – вы его помощник, вы на его стороне. В таком случае почему бы и не принять ваше предложение, если оно выглядит неплохо?
В целом, лечение всех видов «мотивационной слепоты», перечисленных в данном подразделе, начинается с обеспечения безопасности коммуникации: с самим собой и окружающими. Когда вы сами заземляетесь, то первым делом скажите себе (напишите, проговорите вслух): «Я не стану плохим человеком, если признаю реальность». Договоритесь с окружающими, что когда вы заземляетесь, вы не ищете виноватых, а пытаетесь понять, что вообще происходит или происходило, и больше такого не допускать. Можете привести в пример расследования авиакатастроф и авиационных инцидентов, которые проводит Межгосударственный авиационный комитет (МАК). Цель каждого такого расследования – не поиск виновных, а установление всех обстоятельств инцидента, чтобы устранить причины, которые привели его возникновению. Только если вы установите это правило (подкреплённое вашими полномочиями), нужно будет тщательно следить за его выполнением: поначалу вы будете скатываться в привычные модели поведения (старые эпистемы изживают себя не так быстро). Если вы общаетесь с начальством и понимаете, что решения начальства уже привели к негативным последствиям, но начальники не торопятся сменить курс – обеспечьте им возможность безопасно поменять решение, не поступившись их представлениями о себе в их глазах и глазах окружающих. Тогда вам будет гораздо легче договариваться. Подробнее об этом можно прочитать в книге «Психологическое айкидо» психолога Михаила Литвака.
По итогу можно дополнить алгоритм заземления важным пунктом:
- Обеспечьте безопасность общения: признавать реальность должно быть безопасно для вас и окружающих. Это предварительное условие, без которого заземление невозможно. Проверьте, что люди, с которыми вы общаетесь, высказывают свои сомнения вслух, не демонстрируют сигналы уклонения от беседы или сомнения в ваших словах (покачивания головой и т.п.)
- Опишите, что должно измениться в физическом мире после того, как задача будет сделана. Явно пропишите: с точки зрения какой роли вы будете смотреть на ситуацию. Альтернативно: опишите, что вас смущает, что у вас «дребезжит», то есть, распишите ситуацию/контекст с выбранной точки зрения.
- Выделите в описании агентов, которые начали действовать иначе. Назовите эти иные действия. Назовите результаты этих действий: какие объекты сменили состояния (с точки зрения выбранной роли), назовите артефакты. Опишите последствия.
- Распишите, каким образом/способом/методом вы будете проверять, что в физическом мире произошли нужные вам изменения. Какие замеры вы будете делать, чтобы увидеть, что изменения реальны? Что вы будете измерять?
- При каких условиях результат возможно получить? А при каких невозможно?
- Какие сигналы могут вам указать заранее на то, что делается что-то не то?
Разница между должностью и ролью объясняется в разделе 2 ↩︎
Допустимые значения косинуса в пределах от [-1, 1] ↩︎
https://tenchat.ru/media/1455022-vklyuchay-rezhim-forsazha ↩︎