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

Когда инфраструктура падает из‑за хакерской атаки, редко бывает так, что никто ничего не знал. Чаще картина одна: инженеры видели уязвимости, рассылали отчёты, предлагали заплатки, а решения принимались слишком поздно — или не принимались вовсе. И дело не в том, что кто‑то «не старался». Проблема в разобщённости: разные цели, разные языки, разные представления о срочности. А в кибербезопасности разобщённость — это и есть уязвимость.

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

Например, срочный релиз может ослабить периметр, а отсрочка патча — увеличить окно для атаки. Чтобы не выбирать «или/или», нужна совместная оценка: «Мы выпускаем фичу, но параллельно закрываем критические уязвимости и усиливаем мониторинг на 72 часа». Это и есть настоящая договорённость: не компромисс «хоть что‑то», а план, который учитывает и бизнес, и безопасность.

Почему люди не слышат друг друга: когда инженер говорит «будет плохо», а бизнес отвечает «ок, запишем» Фраза «я предупреждал» звучит как горькая победа. Особенно когда за ней — упавший сервис, потерянные данные и недели восстановления. В ИТ это случается пугающе часто: инженеры бьют тревогу, рассылают отчёты, устраивают встречи, а решения принимаются слишком поздно — уже после аварии. Почему так происходит? Дело не в «плохих людях». Чаще это сбой на стыке ролей, процессов и психологии.

Разные языки и разные метрики Инженер говорит на языке рисков: «вероятность отказа 80% при текущей нагрузке», «уязвимость в цепочке поставок», «срок жизни дисков истекает». Бизнес слышит это как «возможно, когда‑нибудь». Потому что у бизнеса свои метрики: выручка, сроки, NPS, бюджет. Риск без перевода на деньги — это абстракция. Когда инженер говорит «надо усилить защиту», бизнес слышит «надо потратить деньги». И если нет чёткой связки «если не потратим — потеряем X», решение откладывается.

Что помогает: переводить риски в понятные бизнесу последствия. Не «есть уязвимость», а «при атаке мы потеряем 3 дня работы и 5 млн рублей выручки».

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

Что помогает: регулярные «учёные аварии» (chaos engineering), отчёты по инцидентам и разбор «почти случившихся» проблем. Это делает невидимое видимым.

Перегрузка сигналами и «синдром мальчика, который кричал “волк”»** Если предупреждения сыплются каждый день, любое новое сообщение теряет вес. Инженеры видят сотни потенциальных проблем и честно о них говорят. Менеджмент привыкает к тону тревоги и перестаёт реагировать. В итоге, когда приходит реальная угроза, её уже не слышат: «Опять что-то про уязвимости, ладно, потом».

Что помогает: приоритизация по единому фреймворку (например, CVSS, MITRE ATT&CK, RICE), чёткие уровни инцидентов и понятные пороги эскалации. Тогда «красный» действительно означает «сейчас», а не «когда будет время».

Разрыв ролей и отсутствие общего контекста Инженер и менеджер часто живут в разных контекстах. Инженер знает, как устроена система изнутри. Менеджер знает, какие цели стоят перед компанией. Без общего понимания эти контексты не пересекаются. Получается диалог глухих: инженер говорит про архитектуру, менеджер — про дедлайны. Оба правы, но не слышат друг друга…

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