Как (не) осознаётся разрыв между эпистемами и реальностью
Итак, мозг постоянно измеряет разницу между картинами мира/представлениями/эпистемами в голове и получаемыми из среды данными и отмечает, где произошёл разрыв между эпистемой и реальностью. Однако этот механизм адаптации к реальности не всегда срабатывает.
Иногда мозг не может заметить/зарегистрировать разницу/разрыв, потому что мы вообще не умеем выделять из фона нужные объекты и правильно их называть. Соответственно, в субъективной реальности/реконструкции агента эти объекты, присутствующие в мире, отсутствуют. Например, инженеры обычно плохо выделяют вниманием работы, плохо оценивают сроки выполнения работ, забывают о необходимых ресурсах. В итоге прогнозировать сроки выполнения работ становится крайне сложным занятием, сходным с гаданием на костях животных в Древнем Китае. Менеджеры, напротив, игнорируют метод/способ выполнения работы, в их картине мира/реконструкции такой объект не выделяется вниманием и не присутствует как важный. В итоге метод/способ выполнения работ выбирается неоптимально или вовсе толком не выбирается, нет понимания, кого назначить на выполнение работ, рассчитать и предоставить нужные ресурсы вовремя невозможно, сроки выполнения работ опять-таки страдают. Этой проблеме посвящено много внимания в разделе 3 «Различать метод и работу». Не менее часто встречается и другой тип ошибки: например, когда данные Machine Learning (ML) модели или ИИ-модели выдаются за реальность: «если модель рассчитала, что экономический агент примет вот такое решение, то агент такое решение и примет (или уже принял)». Не различают физический объект/объект реального мира (агента и его решения) и их реконструкции/представления/representations внутри модели.
Иногда мы просто забываем выделить важные объекты. Такое часто происходит, когда вы только учитесь новому и/или попадаете в новую ситуацию/контекст. Например, вы получили повышение, и теперь по должности вам надо руководить командой. Значит, вам придётся исполнять роль лидера и применять методы/способы/практики лидера: уговаривать членов команды сотрудничать, разрешать конфликты, периодически проводить встречи 1-1 с членами команды для обсуждения их карьерного пути, и так далее. Но пока вы только привыкаете, вы можете забывать об исполнении роли лидера, не выделять вниманием «конфликт» между членами команды как что-то важное и считать, что «само как-то разрулится», не думать о встречах, и так далее. Из-за этого ухудшается взаимодействие между членами команды, члены команды поздно информируют о возникших проблемах (для их решения придётся сотрудничать с неприятными людьми!), решения начинают приниматься в последний момент.
Бывает, что мы неправильно выделили объект и неправильно определили тип объекта. Например, завод производит ленточные конвейеры для шахт:
Ленточный конвейер. В реальном проекте лучше иметь фото реального конвейера вашей компании
Но продажники завода считают, что продают не «ленточные конвейеры для шахт», а некоторое абстрактное «оборудование». Соответственно, на вопросы клиентов «а можно ли привезти ваше «оборудование» на другой конец России и смонтировать его на месте за пару дней?» отвечают «да». Ведь абстрактное «оборудование» действительно можно привезти и установить за пару дней. А вот ленточный конвейер для шахт, много тонн стали, привезти и установить нельзя. Продажники слабо понимают, что именно продают, неверно определяют тип объекта – а возможно, и неверно выделяют сам объект. Поэтому и не могут ответить, какие действия с объектом такого типа возможны, а какие нет.
Другой пример: у агента есть такое свойство/характеристика, как способность выполнять работы/capability (U.Capability в FPF). Это принципиальная потенциальная способность выполнять работы. «Я могу спеть», «Вася может составить отчёт о выполненных работах». Мы ничего не знаем о том, что делаю или Вася; мы не знаем, назначены ли я или Вася выполнять соответствующую работу; мы только мы только знаем, какую именно работу я и Вася можем потенциально выполнить.
Агентская способность выполнять работы/capability вообще означает следующее:
- у агента есть квалификация в соответствующем мастерстве, которое требуется для написания этого конкретного отчёта (выполнения этой конкретной работы), или иначе – агент знает метод/способ выполнения работы и может его применить;
- агент может выполнить работу в обсуждаемых условиях. То есть, Вася может составить отчёт с имеющимися под рукой данными или в условиях ограниченного времени;
- можно измерить процесс выполнения работы, а также результат выполнения работ. То есть, можно оценить, сколько времени понадобилось Васе, чтобы написать отчёт; какие инструменты ему понадобились; насколько результат устраивает заказчика отчёта. Можно оценить качество выполненной работы.
Но когда начальник даёт задание подчинённому, часто он подразумевает под «способностью выполнять работу» что-то другое, что-то своё. Например, что Вася один раз подготовил подобный отчёт, а значит, способен и в этот раз повторить. На самом деле этот факт лишь означает, что Вася в принципе знаком с тем, как составлять такие отчёты (вероятно, имеет некоторую квалификацию и может что-то подобное сделать). Но не факт, что Вася сможет повторить: например, у Васи может не быть времени выполнить этот отчёт (есть другие, более важные задачи), нет нужных данных для отчёта, и собрать их Вася не сумеет. «Способность выполнять работу» в словах начальника на самом деле отсылает нас не к способности выполнять работы/capability (U.Capability в FPF), а к утверждению/гипотезе/предположению вида «ну раз Вася один раз смог, то (наверно) и ещё раз сможет» (утверждение только о квалификации агента). Разница между этим утверждением о способности и тем, что реально понимается под «способностью выполнять работу» в операционном менеджменте не осознаётся, утверждение о способности в реконструкции начальника путается с совершенно другим объектом (реальной характеристикой агента). При попытке относиться к утверждению о способности выполнять работу как к реальной характеристике агента обычно начинаются проблемы, потому что выясняется, что реально способности в данный момент у Васи нет: есть квалификация, но нет времени; может сделать в принципе, но не может получить результат нужного качества, и так далее.
Иногда разрыв между эпистемами и реальностью всё-таки осознаётся, но очень медленно и мучительно. Например, в проекте (и в сложных задачах) последние 10-20% до завершения обычно самые психологически сложные. В этот момент опускаются руки, кажется, что проект не завершится никогда, возникает соблазн бросить его, не доведя до завершения. Часть людей воспринимает происходящее как сигнал о том, что от проекта надо отказываться. Потом сталкиваются с этой проблемой во втором, третьем и так далее проектах. Лишь позже приходит осознание, что происходящее не случайность и не проблема одного-единственного человека: это общая закономерность. И действительно: большинство не раз сталкивалось с этой проблемой. Осознание, что происходящее в рамках нормы, помогает снизить тревогу и рационально подойти к завершению проекта: поменять свои действия, если работа над проектом начинает подчиняться закону убывающей отдачи[1]. Что это означает: если видите или ощущаете, что вместо полезной сфокусированной работы начинается какая-то «тягомотина», каждый следующий час просто приносит ощущение бессмысленности и полного непонимания происходящего, то лучше всего выполнить следующее:
- пойти и отдохнуть и/или переключиться на другой проект. Мысли о незавершённом проекте всё равно будут «вариться» в голове фоном. Такое «проваривание» иногда помогает упорядочить мысли и найти ту идею, которая позволит вам продвинуться дальше и решить текущую задачу (или завершить проект);
- запросить обратную связь. Ставьте точку, считайте текущую версию рабочего продукта/артефакта (результата выполнения задачи) 0, 1, 2, ..., n-ной версией рабочего продукта или промежуточным рабочим продуктом. Отправляйте его на проверку заказчику проекта и/или задачи вместе с описанием ваших затруднений и планом решения затруднений. Как раз реализуете принципы «поставок мелкими партиями» и «быстрой обратной связи». Самую быструю обратную связь можно получить от LLM, усиленной FPF. Напишите ей запрос вместе с описанием задачи, ваших затруднений, вашими мыслями по поводу решения, и попросите прокритиковать. Возможно, уже после этого действия вы поймёте, что делать дальше. Если не поймёте, то по крайней мере LLM подскажет вам идеи, которые вы можете описать в письме заказчику (или на встрече).
- наконец, можно скомбинировать два предыдущих способа.
Но пока осознание закономерности и способов справиться с происходящим приходит, вы можете успеть совершить немало ошибок: бросать раз за разом проекты, погружаться в негатив по поводу происходящего, и так далее. Это происходит из-за длинного цикла обратной связи. В некоторых областях цикл обратной связи очень короткий. Например, если вы нарушите законы/первые принципы физики, вы либо не получите нужный результат очень быстро, либо умрёте. То есть, информация о том, что первые принципы нарушать нельзя, приходит очень быстро. Однако во многих областях цикл обратной связи более длинный, что приводит нас к иллюзии, что первые принципы можно нарушить без последствий для себя. На самом деле последствия будут, просто они отложены во времени, и когда они наступят, без знания закономерностей вы даже не поймёте, почему с вами происходит что-то не то. Если вы получаете обратную связь неоднократно, то рано или поздно задумаетесь, что не так в ваших реконструкциях/картинах мира/эпистемах. Но если цикл обратной связи достаточно длинный и накопленная инерция велика, задумаетесь вы не сразу. Мы надеемся, что при изучении наших руководств и прохождении резидентур вы будете постепенно учиться мышлению из первых принципов и начнёте искать подобные закономерности в ваших предметных областях.
Пример длинного цикла обратной связи: медленно осознаётся тот факт, что в режиме многозадачности/мультитаскинга/multitasking лучше не работать. Представление «мы работаем в режиме многозадачности, и это неизбежно (или даже хорошо)» коварна тем, что обычно не формализована, не описана текстом, не обсуждается явно на совещаниях/встречах. Просто многие члены коллектива (от линейных сотрудников и до топов) берут в работу как можно больше задач и проектов, обращая внимание на «вход» задач и проектов в конвейер/рабочую систему, но забывая обратить внимание на «выход»: скорость выпуска/Throughput результатов. Если спросить их, то сотрудники скажут что-то вроде «Многозадачность – это плохо, но иначе нельзя. У нас 40 задач и все приоритет!». Но объяснить рационально, почему иначе никак нельзя, вряд ли смогут. Скорее всего, при попытке запустить такое обсуждение вы наткнетесь на отмазки («мы всегда так работали», «все так работают в отрасли») или вовсе непонимание («да зачем это обсуждать? Бежать делать все 40 задач надо!»). Чего вы не увидите и не услышите – так это расчетов на основе реальных данных: «вот у нас было 10 проектов в работе, добавили еще 10 и ускорились, вот расчет на основе данных трекера задач/, вот как это повлияло на наши финансовые показатели». Скорее всего, никто ничего даже не пробовал считать. Представление о многозадачности как «неизбежном зле» просто как-то существует распределенно в коллективе и толком никем из этого «коллективного бессознательного» не извлекалось.
Некоторые представления могли быть когда-то полезны, но их «срок годности» истёк. Например, когда вы запускаете новый проект и создаёте минимальный продукт/MVP продукта, стратегия «виражировать быстрее» действенная: вы быстро проверяете гипотезы, быстро отбрасываете неработающее, быстро перебегаете от одной идеи к другой. Но когда MVP найден и/или рост вашей компании замедлился, от подхода «бежать быстрее» надо переходить к подходу «действовать точнее». Вам нужно глубже, чем раньше, изучать клиентский опыт, хорошо сегментировать клиентов, чтобы понимать, куда дальше развивать продукт и под нужды какого сегмента его затачивать. Также нужно не бросать текущий продукт, а постепенно доделывать и улучшать его (быстрые поставки мелкими партиями) под вашу целевую аудиторию. Кроме того, надо упорядочивать работу команды. Вы больше не можете позволить себе резко бросать одну идею и бежать за другой, не доводя дело до конца. Для создания продукта вы используете один подход («виражировать быстрее»), но для его развития используется другой подход («действовать точнее»). Это один из ключевых принципов эволюции: на старте эволюции важнее скорость преобразований/мутаций/эволюционных изменений, выигрывают те, кто меняется быстрее. Но когда ключевые мутации, обеспечивающие приспособленность к среде, уже найдены, вперёд вырываются те формы жизни, которые меняются медленнее, но находят более подходящие мутации. Быстрые бегуны после преодоления этого порога начинают быстро накапливать ошибки и в итоге проигрывают. В момент, когда рост компании замедляется (например, выручка колеблется в одном и том же диапазоне и не растёт), подход «виражировать (бежать) быстрее» перестаёт работать. Срок годности этой эпистемы истёк, для дальнейшего развития этой компании требуется эпистема/подход «действовать точнее». Требуется упорядочить работу сотрудников, описать методы работы, оформить их в виде регламентов, контролировать работу сотрудников, заниматься их развитием, и так далее. Но это может быть сложно: для того, чтобы быстро запускать новые компании и для того, чтобы развивать имеющиеся компании, буквально нужно по-разному смотреть на мир (с разных точек зрения/viewpoints): бизнесмена-стартапера и менеджера. Требуется научиться смотреть на мир с другой точки зрения, сменить подход к развитию бизнеса, и/или передать управление со-основателю, который как раз умеет смотреть на бизнес как менеджер, сфокусированный на развитии.