Академический и инженерный разбор
После инцидента команда может построить валидный аргумент на неполных данных,
потому что память легче извлекает яркие подтверждения любимой гипотезы.
Исправление формы не исправляет сбор свидетельств. И наоборот, наличие bias не
доказывает ложность конкретного вывода.
flowchart LR
A["Ожидание"] --> B["Направляет внимание"]
B --> C["Меняет сбор данных"]
C --> D["Формирует интерпретацию"]
D --> E["Решение"]
E --> F["Избирательная обратная связь"]
F --> A
G["Независимая оценка"] -. разрывает цикл .-> C
H["Заранее заданный критерий"] -. разрывает цикл .-> E
Правило главы
Не диагностируйте человека по названию bias. Проектируйте процесс, в
котором конкурирующие гипотезы, независимые оценки и обратная связь становятся
дешевле.
1. Bias, fallacy и noise
| Понятие |
Уровень |
Пример |
| Fallacy |
структура аргумента или диалога |
утверждение следствия |
| Bias |
систематическое направление ошибки оценки |
якорение |
| Noise |
случайный разброс суждений |
разные оценки одинакового кейса |
Один bias может порождать разные ошибки. Подтверждающее искажение ведёт к
cherry-picking, подавлению альтернатив и асимметричному стандарту доказательств.
2. Осторожно с моделью «быстрой и медленной системы»
Различие быстрых автоматических и медленных контролируемых процессов полезно,
но не является картой двух буквальных отделов мозга. Экспертная интуиция может
быть быстрой и точной в стабильной среде с частой обратной связью; долгое
рассуждение может рационализировать желаемый вывод.
Вопрос не «думали ли мы медленно?», а:
- среда предсказуема?
- была качественная обратная связь?
- есть внешний критерий?
- процедура допускает опровержение?
3. Подтверждающее искажение
Мы легче:
- ищем подтверждения;
- интерпретируем неоднозначное в пользу позиции;
- запоминаем согласующееся;
- строже проверяем чужую гипотезу.
Инженерный пример:
Решив, что причина инцидента — сеть, команда ищет timeout и игнорирует
сообщения о schema mismatch.
Противодействие
Для каждой гипотезы:
что мы ожидаем увидеть, если она верна?
что ожидаем, если неверна?
какой результат заставит отказаться?
Лучший тест различает гипотезы, а не просто совместим с любимой.
4. Мотивированное рассуждение
Желаемое решение влияет на стандарт доказательства:
- для выгодного вывода достаточно одного кейса;
- для неприятного требуют идеального RCT;
- неоднозначность трактуют асимметрично.
Признак:
Какое свидетельство мы потребовали бы, если бы вывод был противоположным?
Дебайасинг: заранее зафиксировать критерий решения и владельца проверки.
5. Bias blind spot
Мы видим искажения у других и считаем собственную интроспекцию доказательством
объективности.
Я выбрал архитектуру по фактам; несогласные просто боятся нового.
Намерение быть объективным не заменяет процедуры. Нужны ADR, альтернативы,
предсказания и последующий review решения.
6. Доступность
Вероятность оценивают по лёгкости вспоминания.
После громкой утечки переоценивают именно её сценарий; тихие, частые ошибки
прав доступа остаются без внимания.
Ремонт
- базовые частоты;
- реестр инцидентов;
- threat model;
- reference class;
- данные вместо медийной яркости.
Эвристика доступности иногда полезна: легко вспоминаемое событие может быть
частым. Ошибка — не проверить, почему оно доступно.
7. Якорение
Первая цифра или рамка смещает последующие оценки:
«Проект займёт год». Независимые оценки после этого группируются вокруг года.
Ремонт
- Собрать независимые оценки до обсуждения.
- Оценивать компоненты и reference class.
- Раскрывать предпосылки, не усреднять числа без модели.
- Использовать диапазоны и распределения.
Показывать якорь и затем просить «не учитывать» — слабая защита.
8. Репрезентативность
Случай кажется похожим на прототип, и сходство подменяет вероятность.
Кандидат говорит как сильный архитектор.
Следовательно, вероятно, он сильный архитектор.
Нужны базовая частота, валидность признаков и структурированная проверка.
Ошибка конъюнкции и пренебрежение базовой частотой часто вырастают отсюда.
9. Framing
Одинаковые исходы вызывают разные решения в зависимости от описания:
90% релизов без инцидента
10% релизов с инцидентом
Ремонт
Показывайте:
- gain и loss frame;
- абсолютные числа;
- единый горизонт;
- альтернативу по умолчанию;
- последствия действия и бездействия.
Фрейм неизбежен. Задача — сделать выбор устойчивым к разумным переформулировкам.
10. Неприятие потерь
Потеря существующего ощущается сильнее равного приобретения. Это может
поддерживать legacy даже при выгодной миграции или, наоборот, чрезмерно
ускорять меры после недавнего ущерба.
Не сводите решение к эмоции:
expected value
tail risk
необратимость
ликвидность ресурсов
распределение ущерба между людьми
11. Status quo и default effect
Текущий вариант кажется нейтральным, хотя продолжение — тоже действие.
Мы не решили хранить данные бессрочно; просто не добавили удаление.
Отсутствие механизма удаления фактически выбирает бессрочное хранение.
Делайте default явным и обосновывайте его.
12. Endowment effect
Собственное решение ценится выше альтернативы из-за владения:
Наш самописный scheduler гибче.
Спросите:
Если бы сегодня его не было, выбрали бы мы построить его при текущих
требованиях и стоимости?
13. Sunk cost
Уже понесённые невозвратные затраты используют как основание продолжать:
Мы потратили два года, поэтому обязаны завершить.
Решение должно сравнивать будущие варианты:
будущая ценность - будущая стоимость - риск
Прошлые затраты важны только там, где создали будущий актив, обязательство,
обучение или цену выхода.
14. Эскалация обязательств
После публичного решения человеку трудно признать ошибку; он инвестирует ещё,
чтобы оправдать прошлое.
Процесс:
- заранее задать stop conditions;
- разделить автора гипотезы и владельца continuation decision;
- вознаграждать раннее прекращение плохого эксперимента;
- проводить kill review по расписанию.
15. Hindsight bias
После события оно кажется предсказуемым:
Было очевидно, что база не выдержит.
Это разрушает обучение: реальная неопределённость прошлого исчезает.
Храните:
- прогнозы до решения;
- диапазоны;
- известные на тот момент данные;
- альтернативы;
- confidence.
Postmortem сравнивает решение с доступной тогда информацией, а не только с
исходом.
16. Outcome bias
Качество решения оценивают по одному результату:
Рискованный deploy прошёл — решение было хорошим.
Осторожный deploy упал — решение было плохим.
Хорошее решение может дать плохой исход в вероятностном мире. Проверяйте
процесс, калибровку и повторяемость.
17. Overconfidence
Проявления:
- слишком узкие интервалы;
- завышенная точность;
- низкая вероятность собственному провалу;
- вера, что понимаем больше механизма, чем можем объяснить.
Калибровка
Соберите много прогнозов с вероятностями. Среди событий с оценкой 70% примерно
70% должны происходить. Без обратной связи уверенность не обучается.
18. Иллюзия глубины объяснения
Кажется, что понимаем систему, пока не надо пошагово объяснить:
Как именно браузер получает страницу после ввода URL?
Техника:
- попросить оценить понимание;
- объяснить механизм по шагам;
- указать пробелы;
- снова оценить.
В архитектуре требуйте sequence diagram и failure path, а не только знакомые
слова.
19. Planning fallacy
Срок оценивают по внутреннему идеальному сценарию и игнорируют распределение
похожих проектов.
Inside view
список задач + оптимистичные длительности
Outside view
как распределялись сроки у похожих инициатив?
Используйте reference class forecasting, Monte Carlo по cycle time, буферы и
явные зависимости.
20. Fundamental attribution error
Поведение другого объясняют характером, своё — обстоятельствами:
Он опоздал, потому что безответственный.
Я опоздал, потому что dependency задержала ответ.
В организациях системные ограничения легко превращаются в моральную оценку
человека.
Ремонт:
- одинаковый набор вопросов к себе и другим;
- данные по системе;
- возможность объяснить контекст;
- разделение поведения, эффекта и личности.
21. Halo и horns effect
Одна сильная черта окрашивает остальные:
Кандидат блестяще решил алгоритм → вероятно, хороший лидер.
Один плохой ответ → слабый инженер вообще.
Структурированное интервью использует независимые критерии и отдельные оценки
до общего обсуждения.
22. Authority bias и социальное доказательство
Позиция старшего участника становится якорем; остальные не предъявляют
альтернативы.
Процесс:
- лидер говорит последним;
- письменные pre-reads;
- независимое голосование;
- назначенный challenger;
- анонимный сбор рисков, когда нужна психологическая безопасность.
23. Groupthink
Стремление к согласованности подавляет сомнения:
- иллюзия единодушия;
- самоцензура;
- давление на несогласных;
- рационализация;
- информационные «сторожа».
Не всякое согласие — groupthink. Диагноз требует процесса, блокирующего
критическую проверку.
24. Availability cascade и информационный каскад
Люди повторяют позицию, считая публичное повторение независимым подтверждением.
На деле все ссылаются на один источник.
Стройте граф provenance:
10 статей → 2 обзора → 1 исходный неподтверждённый отчёт
Количество ссылок не равно числу независимых свидетельств.
25. Эффект повторения
Знакомое утверждение кажется правдивее. Повтор полезен для обучения и опасен,
если источник низкого качества.
Защита:
- видимые источники;
- отметка уже проверенного;
- не повторять миф в заголовке без немедленного исправления;
- отделять узнаваемость от evidence.
26. Dunning–Kruger: аккуратная оговорка
Популярная версия «глупые всегда уверены, умные сомневаются» — карикатура.
Исходный эффект связан с тем, что низкий навык ухудшает и выполнение, и
самооценку, а статистическая картина чувствительна к измерению и регрессии к
среднему.
Практический вывод не «диагностировать коллегу», а:
- давать внешний критерий;
- обучать самопроверке;
- обеспечивать частую обратную связь;
- калибровать уверенность на серии задач.
27. Curse of knowledge
Знающий недооценивает, сколько контекста отсутствует у новичка:
«Просто подними окружение обычным способом».
Решения:
- usability test документации;
- onboarding новым человеком;
- glossary;
- явные prerequisites;
- проверка «можно ли выполнить без автора».
28. Дизайн среды сильнее памятки
Список из 200 biases мало помогает в момент решения. Эффективнее встроенные
ограничения:
| Риск |
Процесс |
| Якорение |
независимые оценки до обсуждения |
| Confirmation |
конкурирующие гипотезы и falsification test |
| Hindsight |
decision log с прогнозом до события |
| Sunk cost |
заранее заданные stop conditions |
| Groupthink |
лидер говорит последним, challenger |
| Planning fallacy |
reference class и Monte Carlo |
| Outcome bias |
review процесса отдельно от исхода |
| Availability |
базовые частоты и реестр |
| Halo |
независимые scorecard-критерии |
| Framing |
симметричные формулировки gain/loss |
29. Premortem
Представьте, что решение провалилось через год:
Что именно произошло?
Какой ранний сигнал мы проигнорировали?
Какая предпосылка оказалась ложной?
Какой контроль отсутствовал?
Premortem легализует критику до публичного обязательства. Но он тоже может
создать доступность страшных сценариев; после генерации оцените вероятности.
30. Adversarial collaboration
Стороны с разными убеждениями заранее согласуют:
- точный вопрос;
- данные;
- критерий;
- модель;
- возможные результаты;
- что изменит мнение каждой стороны.
Это лучше бесконечного обмена статьями после результата.
31. Чек-лист
- Не перепутан ли механизм формирования убеждения с ошибкой аргумента?
- Ищем ли мы данные, способные опровергнуть любимую гипотезу?
- Стандарт одинаков для удобного и неудобного вывода?
- Есть base rate и reference class?
- Оценки сделаны независимо до якоря?
- Показаны gain и loss frames?
- Будущие затраты отделены от sunk cost?
- Качество решения отделено от одного исхода?
- Сохранились прогнозы, сделанные до события?
- Есть внешняя калибровка уверенности?
- Человек не заменяет системное объяснение?
- Повторяющиеся источники действительно независимы?
- Процесс позволяет безопасно не соглашаться?
32. Задания
- После одного тяжёлого инцидента команда покупает дорогую защиту именно от
него. Какие данные нужны?
- Архитектор первым называет срок «три месяца», затем команда оценивает в
10–14 недель. Как изменить процесс?
- Эксперимент дал плохой исход, хотя decision rule был выполнен. Как провести
review без outcome bias?
- Команда продолжает продукт после трёх неудачных пилотов, потому что вложила
год. Какие будущие параметры сравнить?
- На интервью один блестящий system design перекрыл слабые данные по
сотрудничеству. Как redesign scorecard?
- Все десять статей ссылаются на один отчёт. Нарисуйте provenance и
пересчитайте независимые свидетельства.
Источники
- Daniel Kahneman. Thinking, Fast and Slow — полезная карта с учётом
последующих репликационных и методологических дискуссий.
- Daniel Kahneman, Olivier Sibony, Cass Sunstein. Noise.
- Philip Tetlock, Dan Gardner. Superforecasting.
- Richard Thaler, Cass Sunstein. Nudge.
- Gary Klein. Sources of Power — условия качественной экспертной интуиции.
- NIST.
Towards a Standard for Identifying and Managing Bias in Artificial
Intelligence.
Что дальше
Мы собрали ошибки формы, языка, данных и процесса мышления. Следующая глава
соединяет их в научный и инженерный метод: гипотезы, индукция, абдукция,
эксперимент, методы Милля, SDD, RFC и расследование инцидента.
Научная и инженерная аргументация
