Когнитивные искажения в ИТ: коротко, по-человечески и с примерами⁠⁠

Иногда решения в ИТ принимаются не головой, а… мозгом. А мозг любит экономить батарейку и ошибается по шаблону. Эти «шаблонные ошибки» и называются когнитивными искажениями. Ниже — 10 самых частых ловушек для ИТ менеджеров и команд

🧠 Подтверждающее искажение (Confirmation Bias)

Что это:

Замечаем то, что подтверждает наши прежние убеждения, и пропускаем остальное.

Пример:

Приложение «тормозит» — application support сразу винит DBA: месяц назад после оптимизации базы данных «всё висело», значит и сейчас наверняка виноваты снова они, симптомы похожи на те что были месяц назад. Варианты то что проблемы могут быть в прочих компонентах  приложения (инфраструктура, сеть и пр.) даже не рассматриваются.

Что делать:

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

⚓ Эффект привязки (Anchoring)

Что это:

Первое число/факт которое попадает в наше поле зрения задаёт «якорь» для дальнейших решений — всё остальное подгоняем к нему.

Пример:

Выбирая вендора для новой системы мониторинга, берём первого из выдачи Google — остальные варианты уже не воспринимаются всерьёз.

Что делать:

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

💸 Ошибка невозвратных затрат (Sunk Cost Fallacy)

Что это:

Тянем проект/технологию «потому что уже столько вложили», вместо того чтобы смотреть на будущие выгоды.

Пример:

Есть дорогие Enterprise-perpetual-лицензии на Oracle Database — держимся за неё, хотя можно перейти на бесплатную open-source-альтернативу или более экономичный managed-сервис. Решение диктуют прошлые траты.

Что делать:

Делаем новый расчёт с учётом перехода на свежие технологии — вероятные выгоды могут перекрыть потери. Считаем не только деньги, но и будущие «возможности»: скорость вывода фич, гибкость архитектуры, снижение vendor lock-in. Улучшение климата в коллективе и мотивации — тоже бенефит.

📅 Ошибка планирования (Planning Fallacy)

Что это:

Систематически недооцениваем сроки и усилия: в голове — «идеальный мир», в жизни — зависимости, очереди и внезапные «а сертификат то истёк».

Пример:

Задачу планировали сделать за 5 часов, но по ходу всплыли неучтённые сложности — в итоге ушло 10 часов, а ещё пришлось завести пару тикетов в technical debt.

Что делать:

Человек, который окончательно решит задачу точного планирования, получит Нобелевскую премию. А пока используем базовые стратегии: трёхточечные (или шеститочечные) оценки/PERT, «покер планирования» для независимых прикидок и буферы как на уровне задач, так и на уровне проекта.

🧑‍💼Эффект авторитета (Authority Bias)

Что это:

Мнение «большого начальника» автоматически кажется верным: даже если кто-то в команде не согласен, спорить «не принято», и точку зрения руководителя принимают — пусть и с сомнениями.

Пример:

Большой босс говорит: «В прошлой компании мы внедряли этот продукт — выгоды не получили, значит и здесь внедрять не будем». Детали того внедрения (цели, масштаб, настройки, метрики) не раскрываются, но решение фактически принимается «по весу» спикера.

Что делать:

Конструктивно спорить с боссами и «звёздными» коллегами — нормально: опирайтесь на метрики, результаты пилота, TCO/ROI и чёткие критерии. Если убедить руководителя не удалось, заранее зафиксируйте риски и последствия выбранного курса (краткий one-pager/decision record), договоритесь о метриках успеха и триггерах для пересмотра решения.

🐑 Эффект стадности (Bandwagon Effect)

Что это:

«Все так делают — и мы сделаем»: популярность решения подменяет его пригодность именно для нас.

Пример:

Внедряем Prometheus + Grafana для time-series-мониторинга, потому что «это у всех». Хотя у нас монолит на ~200 пользователей, нужен мониторинг здесь и сейчас, и текущий вендорский мониторинг уже закрывает потребности. В итоге получаем лишнюю инфраструктуру и лишнюю точку сбоя — без реальной выгоды.

Что делать:

Когда тянет идти за трендом, сначала выписываем свои use cases и критерии успеха: зачем нам это и какие метрики улучшатся.  Отвечаем на вопросы, кто будет это поддерживать? Не превратится ли это через год в кладбище ненужных технологий? Сравниваем с базовой альтернативой («оставить как есть»/вендорское решение) и принимаем решение по пользе, а не по моде.

🔢 Закон малых чисел (Law of Small Numbers)

Что это:

В малых выборках велик шанс случайных «крайностей» в нетипичных местах: разброс высок, закономерности ещё не проявились — поэтому мы склонны делать большие выводы по маленьким данным.

Примеры:

• Фидбэк. Получили три отзыва: два нейтрально-негативных и один сильно позитивный. По двум «минусам» делаем вывод, что «всё плохо», хотя выборка слишком мала и легко искажена.

• Интервью. Пять бесед с «любимыми» клиентами → «фича нужна всем», а реальное использование потом — всего 7%.

Что делать:

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

💀Ошибка выжившего (Survivorship Bias)

Что это:

Видим истории успеха, а «кладбище неудач» — нет. Делаем выводы по тем, кто выжил, а не по полной картине.

Пример:

Выбираем платформу observability по витрине «успешных внедрений» и логотипам на сайте вендора. Не спрашиваем, сколько PoC провалилось и в каких условиях те кейсы взлетели — и повторяем чужой путь вне нашего контекста.

Что делать:

Требуем «знаменатель»: сколько компаний пробовало и каков процент успеха/отказов для нашего масштаба и домена. Запрашиваем негативные кейсы и контакты референсов; запускаем короткий пилот с чёткими метриками успеха/остановки и сравниваем с базовой альтернативой (status quo) — решаем по данным, а не по красивым историям.

🎓 Эффект Даннинга–Крюгера (Dunning–Kruger Effect)

Что это:

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

Пример:

Молодой менеджер после 2–3 удачных внедрений воодушевляется, берёт завышенные обязательства на следующий крупный проект — и проваливается. Параллельно мнение опытного менеджера, который трезво оценивал сроки и риски, игнорируется: уверенный новичок «кажется опытнее».

Что делать:

Отделяйте уверенность от компетенций: оценивайте аргументы и данные, а не тон. Учитывайте мнение обеих сторон, просчитывайте риски (допущения, зависимости, план B). Следуйте проверенным процессам и критериям, а не личной симпатии.

🔍 Знание задним числом (Hindsight Bias)

Что это:

После события кажется, что «и так было ясно» — и мы переоцениваем предсказуемость прошлого.

Пример:

На ретро: «Очевидно было, что интеграция сложная!» — хотя в рисках этого не было, а тесты не ловили. Память дорисовала причинность.

Что делать:

Ведите лог предположений до релиза (какие риски и ожидания были), на ретро сравнивайте с записью, а не с памятью. Фиксируйте решения и их основания (decision record), чтобы отличать «тогдашние знания» от «сегодняшней мудрости». Также не скрывайте своих сомнений - активно пишите в почту и в рабочие чаты. В дальнейшем когда все пойдет не так как планировалось - вам будет легче доказать, что конкретно вы это предвидели.

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Вариант ретроспективы для ИТ команд (postmortem)

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент