Иногда решения в ИТ принимаются не головой, а… мозгом. А мозг любит экономить батарейку и ошибается по шаблону. Эти «шаблонные ошибки» и называются когнитивными искажениями. Ниже — 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), чтобы отличать «тогдашние знания» от «сегодняшней мудрости». Также не скрывайте своих сомнений - активно пишите в почту и в рабочие чаты. В дальнейшем когда все пойдет не так как планировалось - вам будет легче доказать, что конкретно вы это предвидели.
Читайте мою серию: Усталый Босс
