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

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

В мире книги Гарри — приёмный сын учёного, воспитанный в духе рационализма. Он попадает в Хогвартс с мышлением исследователя, привыкшего ставить эксперименты и проверять гипотезы. В результате мы получаем не столько "ещё одну историю про магию", сколько курс рационального мышления в художественной форме.

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

Рациональное мышление

Рациональное мышление — это не про «быть умным» или «думать быстрее всех».
Это про умение:

• строить проверяемые модели реальности,

• принимать решения на основе фактов и логики, а не интуиции,

• корректно обновлять свои взгляды,

• видеть системные связи и последствия,

• учиться на ошибках.

Современные исследования показывают, что человеческое мышление изначально эволюционировало не для поиска истины, а для выживания. В результате мы все подвержены когнитивным искажениям и часто используем упрощённые эвристики вместо строгого анализа.

Рациональное мышление — это сознательная практика, позволяющая "перепрошить" некоторые из этих базовых паттернов.

Методы и принципы рационального мышления — как они применяются в практике ИТ, разработки, инженерии и управления

Байесовский подход

Байесовское мышление основано на теореме Байеса — формальной модели обновления вероятностей по мере поступления новых данных.

Формула Байеса позволяет вычислить, насколько вероятность гипотезы H изменилась, когда мы получили новые данные E:

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

Это базовый принцип в:

• машинном обучении (наивные байесовские классификаторы)

• научном методе (все прогностические модели строятся итеративно)

• оценке рисков (в бизнесе, медицине, авиации, IT‑инфраструктуре)

В инженерной работе этот подход стал для меня основным в диагностике инцидентов. Когда поступают новые логи или наблюдения, я сознательно пересматриваю вероятность "виновности" каждой подсистемы. Если изначально я думал, что проблема на стороне сети, но новые данные показывают, что задержки идут от базы — я не держусь за первую гипотезу, а корректирую модель.

Это же критично важно при A/B тестах. Часто первые 1–2 дня теста дают "красивый результат", но по мере роста выборки вероятность изменяется. Тут важно не зафиксировать успех по первому сигналу, а пересматривать гипотезу по мере накопления данных, вплоть до финального анализа.

Когнитивные искажения

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

В результате мы склонны:

• искать подтверждение своим убеждениям

• переоценивать вероятность недавних событий

• держаться за убыточные решения из-за уже вложенных усилий

• переоценивать общее впечатление о человеке/команде

В инженерной практике я регулярно вижу влияние этих искажений. Пример — внедрение новой технологии. Команда влюбляется в модный стек и начинает игнорировать риски и реальные ограничения проекта.

Чтобы бороться с этим можно внедрять в работу роль "адвоката дьявола": кто-то из команды сознательно ищет недостатки в предлагаемом решении. Это помогает снять "слепоту" и объективно оценить варианты.

Эвристики и системное мышление

Эвристики — это «короткие пути» мышления, позволяющие быстро принимать решения в условиях неопределённости или дефицита времени. Они крайне полезны в ИТ, где приходится действовать в высокоскоростной и постоянно меняющейся среде.

Примеры распространённых эвристик в ИТ:

• «Если система работает → не трогай»
  Часто спасает от ненужных изменений и багов. Но иногда мешает улучшениям, если «работает» означает лишь отсутствие явных сбоев, а не хорошую производительность или масштабируемость.

• «Никогда не деплой вечером в пятницу»
  Уменьшает риск инцидентов в период, когда меньше инженеров в доступе. Но иногда становится иррациональным запретом, если процесс деплоя автоматизирован и хорошо протестирован.

• «Оптимизируй узкое место»
  Звучит разумно, но без системного взгляда может привести к тому, что нагрузка переедет в другие части архитектуры, создавая новые «бутылочные горлышки».
  Эвристики — это не законы природы. Они срабатывают часто, но не всегда. Опасность возникает, если превращать их в догму и применять без осознания контекста.

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

Ключевые элементы системного мышления:

• Видеть взаимосвязи, а не только события.

• Искать петли обратной связи — как изменения в одной части влияют на другие.

• Учитывать отложенные эффекты — не всё ломается или улучшается мгновенно.

• Моделировать непрямые последствия .

Классический источник идей по системному мышлению — работы Донеллы Медоуз, особенно её книга Thinking in Systems.

В айтишной практике эвристики и системное мышление дополняют друг друга:

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

• Системное мышление позволяет избежать ловушек локальной оптимизации и проектировать изменения, которые улучшат устойчивость, масштабируемость и качество всей системы.

Очень частая ситуация в ИТ: команда решает снизить задержку в одном сервисе, например, ускорив работу базы данных или кэша.

Если смотреть локально, кажется, что всё отлично:

• запросы стали быстрее

• нагрузка на компонент упала

Но системно может произойти следующее:

• увеличивается число транзакций в секунду

• растёт нагрузка на API или соседние сервисы

• в бэкенде вырастают очереди сообщений

• другие команды начинают получать алерты по CPU или OOM

В итоге суммарная стабильность системы падает. То, что выглядело как улучшение, превращается в источник сбоев.

Научный метод, Бритва Оккама и принцип экспериментирования

Научный метод — это цикл:

1. Формулируем гипотезу

2. Проводим эксперимент

3. Анализируем результаты

4. Корректируем модель

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

Например: "Мы ожидаем, что новая версия микросервиса сократит время отклика на 20% для X% запросов". После этого — эксперимент на тестовом окружении, замеры, анализ. Без этого легко попасть в ловушку "улучшить" систему, которая в итоге деградирует из-за неучтённых побочных эффектов.

Бритва Оккама отлично работает при отладке. Часто сложные теории о причине бага оказываются ложными, а реальная причина намного проще.

Теория двух заключенных

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

Классическая дилемма двух заключённых: обе стороны выигрывают, если сотрудничают. Но каждая из них имеет стимул "предать", чтобы выиграть больше. Если оба "предают" → оба проигрывают.

В рабочей практике это проявляется в отношениях между командами.

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

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

Декомпозиция проблемы

Декомпозиция — это разделение сложной задачи на более простые и управляемые подзадачи.
Это базовый принцип системного мышления и основа любой инженерной работы. Сложные задачи "в лоб" не решаются.

Проблема Геттиера

Проблема Геттиера — философская концепция из области эпистемологии (теории познания), сформулированная Эдмундом Геттьером в 1963 году. Она ставит под вопрос классическое определение знания как оправданного истинного убеждения.

Согласно классической модели, знание есть тогда, когда:
• убеждение истинно
• есть обоснование (доказательства)
• человек в это верит

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

Простой пример: вы смотрите на работающие часы, видите время 12:00 и думаете "Сейчас полдень". Это истинно. Но часы сломаны и давно показывают 12:00. Ваше убеждение оправдано (вы посмотрели на часы), оно истинно (сейчас действительно полдень), но оно случайно оказалось верным, а значит, это не знание в строгом смысле.

В инженерной практике эта ловушка возникает чаще, чем кажется.

Например, команда устранила инцидент путём переконфигурации балансировщика. После этого система стабилизировалась. Но позже выясняется, что настоящая причина сбоя была на стороне сети, а конфиг не имел реального влияния. Просто совпали два события.

Если в такой ситуации считать "мы знаем, что помогло" — можно закрепить ложное представление о системе, что приведёт к новым сбоям в будущем. Чтобы этого избегать, важно не просто фиксировать "что сработало", а разбирать какая цепочка событий привела к восстановлению. Полезно задавать вопросы:

• Какие альтернативные факторы могли повлиять на исход?

• Могло ли совпасть несколько факторов?

• Каким образом можно подтвердить, что именно конкретное действие дало эффект?

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

Фундаментальная ошибка атрибуции

И, последний, пример, который я хочу рассмотреть - фундаментальная ошибка атрибуции. Это когнитивное искажение, при котором люди склонны объяснять поступки других людей их личными качествами («он ленивый», «она безответственная»), а свои собственные ошибки — внешними обстоятельствами («у меня времени не хватило», «не повезло»).

В команде это часто приводит к конфликтам и недопониманию.

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

Чтобы избегать этой ошибки в работе, полезно спрашивать себя:

• Что ещё могло повлиять на поведение человека?

• Были ли у него обстоятельства, о которых я не знаю?

• Мог ли я сам поступить так же на его месте?

Методы рационального мышления (МРМ) — это не просто академическая дисциплина или философская концепция. Это практический инструмент, который помогает принимать более точные и обоснованные решения в условиях неопределённости и высокой сложности.

В инженерной и управленческой практике эти методы особенно ценны. Работа с современными системами требует:

• умения строить и проверять гипотезы,

• способности корректно обновлять модель мира по мере поступления новых данных,

• осознанной борьбы с когнитивными искажениями,

• системного мышления и учёта побочных эффектов,

• тщательного анализа причинно-следственных связей,

• выстраивания эффективной коммуникации и аргументации.

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

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

Если вы хотите глубже понять, как применять Методы рационального мышления в реальной работе, книга Юдковского — хороший способ увидеть их на конкретных примерах и встроить в свою профессиональную практику.