Тревожные расстройства. Часть 1. Введение в тревоги в профсистемах

Разберем в этой статье, что такое тревоги, какими они бывают и как их классифицируют.

Странно посвящать пару статей теме, которая стоит курса или нескольких книжек (и они есть), но я бы хотел начать делать выжимку общих аспектов тревог и проблем, связанных с проектированием систем тревог (alerts management) — или, как их зовут в российской традиции, систем аварийно-предупредительной сигнализации (АПС).

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

От масс-маркета до тревог

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

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

В общем, как часто бывает, механизмы похожие, но задачи, контекст и последствия их верного или неверного функционирования — другие.

Что такое тревоги

Вообще, тревога — это сигнализация о ненормальной ситуации или состоянии, требующих внимания оператора. Автоматизированная система постоянно анализирует в фоне ситуацию по самым разным критериям, и при их срабатывании генерирует тревогу. Разумеется, тревога может быть сгенерирована и самим оператором вручную — чтобы оповестить других людей.

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

Тревога ≠ событие

Итак. Начнём с того, что тревога — это не совсем событие. Далеко не всякое событие в системе или ситуации генерирует тревогу. Например, у нас есть внешний датчик GNSS, отправляющий позицию нашего автомобиля в систему с какой-то частотой, например, раз в секунду. При этом датчик этот по своей природе не самый надежный инструмент — он может переставать работать когда мы проезжаем под мостом, под кронами деревьев. Разумеется, он может сообщать о таких сбоях — но если каждый раз на событие сбоя мы будем генерировать тревогу, оператор быстро начнет ненавидеть систему. Поэтому тревога может генерироваться, если происходит несколько событий потери связи со спутниками подряд — или, иначе говоря, состояние потери длится достаточно долго. (конечно, можно сказать, что тревога — это отдельное метасобытие, но зачем усложнять?)

К тому же событие — это изменение ситуации в моменте, то есть точка на временной шкале. Тревога же — это продолжительная история, отрезок во времени, который может быть прекращен или пролонгирован другим событием. Например, когда судно вышло за границы разрешенной зоны — это событие, и оно запускает тревогу о выходе за границы. И эта тревога будет действовать всё время, пока не сработает новый триггер о возвращении за границу — а в некоторых случаях даже событие об устранении причины является поводом для отмены тревоги, но, опять же, не будем уходить здесь в эти детали.

Тревога ≠ уведомление

Также тревога — не уведомление о ней! Если тревога — это про смысл (содержимое), то уведомление — это форма, способ доставки тревоги пользователю/оператору. Иными словами, одна и та же тревога может быть передана различными механизмами уведомления оператора — звуком, вибрацией, визуальными уведомлениями в интерфейсе и т.п. При этом же одна и та же тревога может оповещаться несколькими разными уведомлениями во времени  — ровно как будильник в телефоне, который будет звонить, потом затихать на несколько минут, а потом снова звонить (что интересно, в английском языке слово будильник не про задачу будить, а именно про задачу генерации тревоги через какое-то время — alarm clock. То есть само его название предполагает более универсальную и абстрактную функцию).

И да, тревога без уведомлений не имеет смысла. Но всё равно это разные вещи.

Тревога ≠ индикатор

Ну и, наконец, тревога — не индикатор. Индикация о тревоге важна, но не всякий индикатор связан с тревогой. То есть индикатор — в каком-то роде более пассивный элемент, который может загореться в связи с тревогой, а может и просто ждать внимания пользователя, чтобы сообщить что-то относительно важное.

Плюс индикаторы часто выполняют функцию сообщения оператору, что всё хорошо (те самые зеленые лампочки) — в тревоги же эта задача не входит, хотя и может быть отдельное визуальное или звуковое уведомление о том, что действие тревоги закончилось.

Задачи тревог

Хоть задачи мы уже упомянули кратко выше, всё же потрачу немного больше вашего времени.

Основная задача тревоги — не просто сообщить пользователю об опасной или потенциально опасной ситуации, а заставить его реагировать на её возникновение, даже если вся реакция сводится к повышенному вниманию и росту когнитивной нагрузки. Тревоги ради тревог — верный шаг к ключевой проблеме, описанной в следующем разделе статьи.

Если говорить о частных задачах, то тревога — инструмент коммуникации, и не только между операторами и машиной, но и между операторами. Как выше говорилось, один оператор может сгенерировать общую тревогу («аварийная посадка!»), и другие участники экипажа/команды начинают реагировать согласно своим ролям и обязанностям.

Другой частный случай — тревоги помогают сообщить о проблемах у оператора. Здесь может использоваться один из механизмов эскалации тревог, о которых мы поговорим в другой части — например, если у системы есть подозрение, что оператор не реагирует на сработавшую тревогу, она может начать «распространять» тревогу другим членам команды — в результате чего они могут пойти к прозевавшему/проспавшему тревогу оператору на помощь. Так устроены, например, системы контроля за сном на рабочем месте (например, BNWAS на судах).

Особо отмечу, что тревога — это сущность, значимая юридически. Часто пользователь несет прямую ответственность за реакцию на тревогу — в том числе уголовную, если она не была должным образом. Но, опять же, это слишком глубокая тема для данного обзора.

Ключевая проблема тревог

Если бы это была не статья, а презентация или видеоролик, то это был бы очень яркий, тревожный слайд.

Прорабатывая механизм тревог, мы всегда должны держать в уме ключевую (и античную) проблему их эффективности, известную нам с детства в виде сказки Эзопа про мальчика и волков. Перечитайте её и используйте в рабочих коммуникациях — более того, она интернациональна.

Если мы слишком часто выдаём тревоги, которые громко дают о себе знать относительно реальной обстановки — оператор начинает меньше обращать внимания и может пропустить реальную проблему. С другой стороны, если мы закрутили все гайки и фильтры, и выдаем слишком мало тревог относительно ситуации, она может быть упущена оператором и это приведёт к катастрофическим последствиям (к слову, это одна из косвенных причин аварии Чернобыльской АЭС или крушения Costa Concordia — хотя там некоторые механизмы, генерирующие тревоги, были отключены намеренно).

Иными словами, любая тревога по форме (подаче) и по содержанию (сути) должна быть релевантной ситуации реального мира, объекта автоматизации. А ситуация должна адекватно обрабатываться системой и, в случае необходимости, генерировать тревогу даже если развитие проблемы не так однозначно — либо использовать другие средства, например, индикаторы.

В общем-то, многие описанные ниже механизмы классификации тревог (по приоритетам, источникам) а также, в будущих публикациях, способы уведомления и возможные действия с тревогами используются для этого — чтобы балансировать между потенциальной критичностью и потенциальной ошибочностью тревоги.

Хотя это всё больше про форму, дизайн тревог. Конечно, важно и само содержание тревог — но это уже больше про вопросы анализа предметной области и проработки кейсов/алгоритмов (а если я это не говорил ещё явно — я абсолютно уверен, что это точно так же относится к вопросам UX-дизайна, и игнорировать их фразой «это не моя сфера ответственности» не стоит, простите за душность).

Классификация тревог

Тревоги всякие нужны, тревоги всякие важны. Или менее важны — см проблему выше. Поэтому немного разберем способы их классификации.

Приоритетность

Тревоги отличаются по важности для пользователя, критичности возможных последствий и так далее. Для этого каждая система тревог классифицирует их по приоритету — и, в зависимости от приоритета, конкретная тревога может отображаться по-своему, звучать другим образом (или не звучать вовсе) и т.п.

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

Например, в морских системах используется система приоритетов, завязанная на доступное время, имеющееся на ответную реакцию (сами приоритеты переводить не буду даже пытаться, чтобы не позориться — с удовольствием бы помучил филологов):

• Alarm — тревога наивысшего приоритета, требующая немедленной реакции экипажа для того, чтобы не допустить аварийной ситуации. Например, предупреждение о возможности столкновения с другим судном.
• Warning — тревога, требующая немедленного внимания оператора, но не требующая немедленного действия. Эти тревоги генерируются чтобы предупредить экипаж о серьезном изменении обстановки, которая не обязательно становится опасной, но может стать таковой, если не предпринимать никаких действий. Примером тревоги может служить потеря информации о положении (координатах) судна.
• Caution — наименьший приоритет, обозначает ситуацию, которая не обязательно приведет к возникновению alarm или caution, но все же требует повышенного внимания относительно обычной обстановки. В каком-то роде с помощью caution сообщается всё, что может быть более-менее важным пользователю, но не относится к первым двум приоритетам. Например, информация о прохождении мимо запретной для движения зоны (военной, природного заповедника и т.п.) или отказе второстепенного прибора.

К слову, есть еще emergency alert — по идее самая критическая тревога о том, что произошла авария, но она, как ни странно, не всегда используется системами — ибо если авария случилась, все эти рутинные системы быстро теряют актуальность и экипаж должен заниматься устранением причин и последствий аварии (например, борьбой за живучесть судна) используя совсем другие, аварийные системы.

Другой подход используется в авиации — там исходят из степени критичности последствий (ущерба) возникшей ситуации:

• Warning — ситуация, неверная реакция на которую может привести к ранениям или потере жизни человека.
• Caution — ситуация, при которой отсутствие должной реакции приведет к ущербу/разрушению оборудования.

Понятно, что в менее требовательных к безопасности системах подход может быть совсем другим и менее формальным, например все тревоги могут делиться на «приоритетные» (primary alert), «второстепенные» (secondary alert) и «информационные» (information note, по сути уже даже не тревога). Но помним про мальчика и волков — если мы добавим в приоритетные то, что важно нам, но не важно пользователю, то пользователь вообще перестанет обращать внимание на тревоги вообще, даже если несёт за это ответственность. К слову, привет масс-маркетным банковским приложениям — я вас ненавижу за одинаковые уведомления о новых фичах и уведомлениях о списаниях/зачислениях средств.

Категории и источники тревог

Опущу излишние подробности, но отмечу, что приоритеты — далеко (и часто) не единственный способ классификации тревог.

Часто тревоги делят на смысловые категории, например, таким образом:

• тревоги, связанные с состоянием объекта автоматизации, типа того же опасного сближения судов или самолётов в центрах управлением движением;
• тревоги, связанные с окружающей средой — например, если ожидается ухудшение погоды;
• тревоги, связанные с техническими средствами — отказы сенсоров, соединений, серверов и т.п.

Забегая вперед, это часто отражается иконкой, тогда как приоритет отражается её цветом. Но это, опять же, больше про системы, не завязанные на безопасность.

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

Что дальше и что почитать?

Далее я перейду к практике (и картинкам) и расскажу о реализации механизмов тревог, доступных с ними действиях и связанных сущностях — например, журналах тревог, дэшбордах как сигнальных табло в цифровую эпоху и т.п.

Если, вдруг, вам некогда ждать от меня продолжения, советую почитать следующие книги на тему тревог:

• Neville A. Stanton — Human Factors in Alarm Design
• Bill R. Hollifield и другие — The High Performance HMI Handbook