Казалось бы, о когнитивных искажениях в разработке и архитектуре уже написано достаточно. В профессиональных блогах и даже в научных публикациях этот вопрос поднимался неоднократно. Но, как показывают мои наблюдения, тема когнитивных искажений и их влияния на принятие решений все еще остается актуальной.
На основе личного опыта, обсуждений на конференциях и историй крупных компаний можно утверждать, что задачи меняются, технологии обновляются, но поведение команд и лидеров остается удивительно стабильным: предубеждения (bias) все так же заставляют нас наращивать усилия там, где правильнее было бы остановиться.
И раз уж эта тема дает о себе знать с регулярной периодичностью, мы предлагаем еще раз вернуться к ней — в формате размышлений и попытки описать нескольких способов снижения влияния когнитивных искажений на принятие решений.
Александр Якунин
Lead Architect в MWS Tech Governance (департамент управления технологиями).
Более 15 лет опыта в ИТ-индустрии, включая компании из Fortune Global 500. Работал над проектами разного масштаба и сложности в разных доменах — от банкинга до модернизации мейнфреймов.
Сейчас вместе с коллегами выстраивает системный подход к управлению архитектурой практикой в MWS: от единых стандартов и процессов принятия решений до инструментов контроля изменений. Это позволяет синхронизировать стратегию и технологии в масштабах всей компании.
Как благие намерения заходят в тупик
Я не раз наблюдал одну и ту же картину в разных компаниях. Команда вкладывает месяцы — а иногда и годы — в новое решение или продукт, который должен прийти на замену старому. Все выглядит вдохновляюще: современные паттерны, модные технологии, масштабные планы. Но через какое-то время становится очевидно: система работает хуже, чем старая. Издержки растут, изменения даются тяжелее, а команда уже «слишком много вложила, чтобы остановиться».
В такие моменты я вспоминаю проекты, где здравый смысл уступал место когнитивным искажениям. Решения принимались не потому, что они были оптимальными, а потому, что «так уже решили раньше», «так делают все» или «мы верим, что в этот раз получится лучше».
От Knight Capital, потерявшей сотни миллионов долларов за считаные минуты, до компаний вроде eBay, которые несколько раз переписывали собственную систему с нуля, — в истории ИТ много примеров того, как предубеждения определяют судьбу архитектуры.
Со временем я понял: архитекторы редко ошибаются из-за недостатка знаний. Чаще всего они становятся заложниками невидимых психологических сил, которые искажают восприятие реальности и заставляют наращивать усилия там, где уже давно пора остановиться.
Какие искажения встречаются чаще всего
Эффект якоря (anchoring): первая предложенная идея становится «точкой отсчета». Например, выбор NoSQL ради масштабируемости, даже если транзакции бизнес-критичны (HBR, Wikipedia).
Искажение подтверждения (confirmation bias): мы видим только факты, которые поддерживают уже принятое решение (HBR, The Decision Lab).
Искажение оптимизма (optimism bias): мы систематически недооцениваем сложность интеграции и расходы на сопровождение (NAO UK, Wikipedia).
Ошибка невозвратных затрат (sunk cost fallacy): «мы слишком много вложили, чтобы остановиться» (McKinsey, Wikipedia).
Обычно они работают не изолированно, а каскадом: якорь задает направление, подтверждение укрепляет выбор, а оптимизм маскирует проблемы до тех пор, пока становится слишком поздно.
Цена ошибок: деньги, время и люди
Эффект от когнитивных искажений измеряется сразу в нескольких плоскостях:
Финансовой: исследование McKinsey и Oxford показало, что крупные ИТ-проекты в среднем превышают бюджет на 45%, сроки — на 7%, а создают ценности на 56% меньше, чем планировалось. Об этом же можно почитать в исследовании от BBC.
Технической: архитектурный техдолг напрямую связан с искажениями. По данным IEEE и этого исследования с arXiv, до 60–70% архитекторов признают, что когнитивные искажения напрямую ведут к росту архитектурного долга и увеличению стоимости поддержки систем.
Человеческой: разработчики тратят время на «латание дыр», а не на создание ценности. По данным Gallup и Deloitte, до 70% сотрудников ИТ-команд указывают на хронический стресс, а у 30% есть признаки выгорания. Это напрямую связано с постоянной работой над устранением эффектов от архитектурных ошибок и ведет к падению мотивации.
Примеры из мировой практики хорошо иллюстрируют эти последствия:
Knight Capital (2012) — американская трейдинговая компания потеряла 440 млн долларов всего за 45 минут из-за ошибки в программном обеспечении. В системе остался старый код, который случайно активировался при обновлении. В тот день трейдеры буквально в панике выдергивали кабели из серверов, пытаясь остановить неконтролируемые сделки. Это яркий пример ошибки невозвратных затрат (sunk cost fallacy).
Challenger (1986) — катастрофа шаттла, унесшая жизни семи астронавтов. Инженеры компании-подрядчика Morton Thiokol предупреждали о рисках при низких температурах, но их рекомендации были отвергнуты руководством из-за поджимаюших сроков. Запуск транслировался в прямом эфире, а миллионы школьников ждали, когда в космосе побывает обычный учитель. Увы, дедлайны оказались сильнее здравого смысла. Это трагический пример искажения подтверждения (confirmation bias) и искажения оптимизма (optimism bias).
В противовес им можно привести пример eBay (1995–2019). Компания начинала с небольшого монолита на Perl. Первую версию основатель написал буквально за выходные, чтобы проверить идею онлайн-аукциона. Но вскоре сайт начал падать под нагрузкой каждую неделю. Тогда команда решилась на переписывание — шаг, который в других компаниях назвали бы безумием. В дальнейшем eBay несколько раз радикально меняла архитектуру: от монолита к сервисам, затем к микросервисам и к управлению тысячами кластеров. Именно эта готовность отказываться от устаревших подходов спасала компанию от коллапса. Это пример преодоления эффекта якоря (anchoring) и искажения подтверждения (confirmation bias).
Что помогает снизить влияние искажений
Вот несколько действенных практик:
Pre-mortem: метод описан в HBR, краткое объяснение доступно на Wikipedia. Сценарий заключается в том, чтобы представить провал проекта заранее и выявить все возможные причины. Это позволяет снизить чрезмерный оптимизм и показать скрытые риски до начала работы.
Правило трех альтернатив: его детальное описание есть в исследовании Debiasing Architectural Decision-Making: An Experiment With Students and Practitioners. Суть метода — требовать хотя бы три разных варианта архитектурного решения, включая максимально простое. Это помогает избежать эффекта якоря и увидеть реальный диапазон возможных подходов.
Kill-switch для архитектуры: обсуждение можно найти в McKinsey Digital, практическое объяснение — в Reluctant blog. По сути, это заранее согласованный стоп-механизм: если проект не достиг ключевых показателей к определенному моменту, его закрывают или пересматривают.
Red Team или Devil's Advocate: классика в Harvard Kennedy School, адаптированная в Semantic Scholar. Это практика назначения оппонента или группы, которые намеренно ищут слабые места в аргументации и проверяют устойчивость решений.
Архитектурные ретроспективы: упоминаются в IEEE Software, практические советы — ServerlessFirst blog. Суть в том, чтобы обсуждать не только технические ошибки, но и процесс принятия решений: какие гипотезы проверили, какие отвергли слишком быстро и почему.
Какие метрики видят лидеры
Чтобы разговор об архитектуре был понятен бизнесу, нужны цифры. Можно использовать три набора.
DORA-метрики
Подробно описаны в Google DORA reports, краткое объяснение есть в Wikipedia. С их помощью лидеры видят, насколько быстро команда поставляет ценность и насколько устойчива ее архитектура. Они включают:
частоту релизов (Deployment Frequency) — например, ежедневные или еженедельные релизы вместо ежеквартальных;
время доставки изменений (Lead Time for Changes) — сокращение цикла от коммита до продакшена с месяцев до дней;
процент неудачных релизов (Change Failure Rate) — допустим, снижение с 30 до 5%;
время восстановления (Mean Time to Recovery) — уменьшение MTTR с нескольких часов до минут.
Cost of Delay (CoD)
Определение и детали можно найти в Black Swan Farming, а также в Wikipedia. Эта метрика показывает, сколько денег или ценности бизнес теряет за каждый месяц задержки. Например, сдвиг запуска новой платежной функции в банке на три месяца может стоить десятки миллионов недополученной комиссии. CoD помогает приоритизировать инициативы и решать, какие архитектурные задачи откладывать нельзя.
Risk-Adjusted ROI
Базовый принцип работы с этими метриками описан в HBR, а простое объяснение есть в Wikipedia. Суть подхода — умножать ожидаемую выгоду от проекта на вероятность успеха. Например, если ожидаемая экономия составляет 1 млн долларов, но возможность достижения цели оценивается в 50%, то фактический Risk-Adjusted ROI равен 0,5 млн долларов. Это позволяет оценивать архитектурные инвестиции реалистично и избегать переоценки оптимистичных сценариев.
Эти метрики позволяют обсуждать архитектуру не в категориях «красиво — некрасиво», а в терминах стоимости, скорости и риска.
Заключение: зрелость — это умение вовремя остановиться
За годы работы я убедился: компании редко проигрывают из-за того, что выбрали «не ту архитектуру». Они идут ко дну, потому что слишком долго удерживаются за решения, переставшие работать.
Лучшие действуют по другому. Они строят процессы так, чтобы регулярно проверять свои гипотезы, вовремя останавливаться и менять курс. Они воспринимают когнитивные искажения не как индивидуальные ошибки, а как управляемый риск.
Pre-mortem, правило трех альтернатив, kill-switch — это не академические концепции, а инструменты, которые работают и помогают компаниям экономить миллионы и ускорять выход продуктов на рынок.
В конечном счете зрелость архитектора и лидера проявляется не в том, чтобы всегда угадывать правильное решение, а в том, чтобы вовремя сказать «стоп». Это умение и есть настоящее конкурентное преимущество.
Next steps: проверьте себя на непредвзятость мышления
Чтобы проверить, насколько когнитивные искажения влияют на ваши архитектурные решения, проведите небольшой эксперимент:
Выберите одну инициативу, которая уже идет или только стартует (например, миграция сервиса или внедрение нового решения).
Соберите команду и проведите короткий pre-mortem-разбор (HBR, Wikipedia): «Представьте, что проект провалился. Почему?». Запишите все версии.
Задайте правило трех альтернатив: попросите команду на следующей встрече предложить три возможных архитектурных решения (включая самое простое). Сравните их TCO и Time-to-Market.
Определите kill-switch-критерий (McKinsey, Reluctant blog): например: «Если к концу квартала мы не сократим MTTR хотя бы на 20%, эксперимент закрывается».
Отслеживайте результат через DORA-метрики (DORA.dev, Wikipedia): сравните показатели «до» и «после».
Что вы получите
Прозрачную картину скрытых рисков, которые обычно не обсуждаются.
Осознанное сравнение нескольких вариантов вместо «эффекта якоря».
Четкий стоп-механизм, снимающий эмоциональное давление от слов и мыслей «мы уже вложили слишком много».
Первое измерение, показывающее, как архитектурные практики влияют на скорость и стабильность бизнеса.
Такой эксперимент можно провести за 2–3 недели, не меняя процессы радикально. Его результат — доказательство того, что борьба с когнитивными искажениями — это не «абстрактная психология», а конкретные улучшения метрик.