Портал №1 по управлению цифровыми
и информационными технологиями

Вторжение, набег, нашествие… Кого воспитывать – пользователей или программы?

Много лет назад, когда я работал в отделе разработки программного обеспечения, мы пытались приспособить кассиров в магазинах к отлову ошибочно зарегистрированного, неверно промаркированного и иным образом некорректно учитываемого товара. Было придумано несколько контролей, призванных обратить внимание кассира на продаваемый товар и инициировать эскалацию, обычно – вызов менеджера или старшего кассира. При сканировании товара, отвечающего заранее установленным условиям, на экран выводилось сообщение вроде "продажа запрещена. позовите администратора" или подобное. Абсолютное большинство кассиров в ответ предпринимало разнообразные усилия, направленные на скорейшее удаление сообщения с глаз долой. Проявлялись чудеса изобретательности и упорства, вплоть до физического выключения кассы. Никто не звал администратора. 


Прошли годы. 


 

Сегодня в магазине наблюдал попытки кассира провести оплату кредитной картой. Терминал выглядел практически так же, как на картинке, только надписи McDonalds там не было. Но на нём большими буквами было написано "Alert irruption!!!". Кассир игнорировала незнакомые слова, жала на кнопки, вставляла и вынимала карту, и лишь после трех неудачных попыток сдалась и принесла резервный мобильный терминал, с помощью которого успешно провела оплату. По ходу этих экспериментов взволнованный покупатель пытался обратить внимание кассира на тревожную надпись, на что кассир отвечала, что "она сегодня уже по карте пробивала". 

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

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

О данном конкретном случае известно вот что. Поисковый запрос "alert irruption" довольно популярен, и ведет, среди прочего, к инструкции по работе с такими терминалами. И там есть такой пункт: 

В соответствии с требованиями PCI DSS и PCI PED все терминалы содержат большое количество датчиков, которые предотвращают возможность получения доступа к информации внутри терминала. Срабатывание защиты может произойти при ударах по корпусу, от воздействия сильных магнитных полей, скачков напряжения, разряде внутренней батареи или при попытке вскрыть терминал.
При срабатывании защиты терминал при загрузке будет выводить грустный смайл « 🙁 », а на экране будет выводиться одно из сообщений:

  • UNAUTHORIZED
  • ALERT IRRUPTION
  • ERROR ххххх

В таких случаях терминал нужно отправлять в отдел ремонта для проверки и повторной активации на специальном оборудовании.

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


Что говорит ваш опыт? Можно ли надеяться научить массовых рядовых сотрудников менять модель поведения в ответ на определенные сообщения информационных систем? Как повысить успешность такого обучения? Как учесть описанные особенности поведения пользователей при разработке интерфейса и правил бизнес-логики?

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 13

  • Pavel Solopov

    Да, интересный вопрос…
    Как часто мы с вами (достаточно эрудированные в ИТ люди) не задумываясь жмём на Ок в каком-нибудь окне алерта, и только на 3 или 5-ый раз решаем почитать, чтож там нам система говорит.
    Вообще алерты это как дорожные указатели, надо над их разработкой тщательно подумать. Чтобы они не были перегружены текстом. И в тоже время было понятно, что произошло и что делать дальше. Не всегда это возможно, конечно.
    Ну и лучше конечно из цепочки человека устранить по максимуму.
    Такое моё мнение.

    Ну и ещё есть такой фактор привычки. Известный факт про пилотов. Есть такая проблема, пилоты забывают выпустить шасси при посадке. Чтобы не забывали, в кабине при сближении с землёй включается сирена. И всё равно они садятся на брюхо. А когда их спрашивают, почему они не выпустили шасси, ведь сирена же выла, они удивляются “Какая сирена?”. Они к ней привыкли и не замечают.

    • Вадим

      О, боже, Павел, Вы прямо подрываете основы безопасности полетов! ))))

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

      IMHO надо не сирену включать (это реакции прошлого индустриального века), а “встроить” выпуск шасси, закрылков и тп. в некую обязательную предпосадочную последовательность включений/переключений, которая прописывается в руководствах по пилотированию, так чтобы ее нельзя было обойти. Ведь ручек и переключателей на современных лайнерах ого-го сколько!

      • Pavel Solopov

        Сирена в истребителях, не беспокойтесь. В современных лайнерах даже посадка часто на автопилоте совершается, поэтому там с этим проще.

        Прописать в руководстве по пилотированию не достаточно, как показывает практика. Вы думаете там не прописано выпустить шасси? Прописано, всё равно забывают…

      • Pavel Solopov

        Хотя нет, Вадим, лучше всё же бояться:
        http://shpls.org/labour-2/safe-aviation/599-avstralijskij-pilot-zabyl-vypustit-shassi-iz-za-smski

        • Вадим

          Всё, решено! В Австралию теперь ни ногой! ))))

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

          • Pavel Solopov

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

            • Вадим

              и какой смысл это сейчас обсуждать???
              есть только один способ – берешь солдатские сапоги, надеваешь и пи…шь, пока не дойдет! после чего выгоняешь с работы с волчьим билетом. и то если посадка все-таки была совершена без жертв.
              а если с жертвами или не дай бог не так и не была совершена – то срок или аминь.

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

              • Pavel Solopov

                И что? Поможет думаете? Думаете у них там что халва с мёдом и сахаром присыпана? В том то и дело, что их и сапогами, и рублями, и билетами, и даже сирену поставили. А они всё равно забывают… Ну привыкает человек ко всему, расслабляется, устаёт…

  • Dmitry Melnikov

    Сегодня как раз обсуждали вопрос – как заставить пользователей (сотрудников магазина) реагировать на сообщение ИС класса SD. На предложение “Давайте запретим им делать новую заявку, пока не ответят на вопрос по предыдущей”, появился ответ, действительно по типовой модели поведения пользователей:

    “Если не будет работать прием заявок в ЛК, они используют другой пункт по инструкции – позвонят в CALL-центр и скажут, что не работает система SD”

    Вот так…

    Предположу, на основании своего небольшого опыта работы в рознице, что “научить массовых рядовых сотрудников менять модель поведения в ответ на определенные сообщения информационных систем” можно в основном только только через живое общение – через сотрудников CALL-центров. И сообщения ИС должны быть типа “позвоните в CALL-центр”. В нашем случае это работает гораздо эффективнее, чем административные распоряжения о реагировании на сообщения ИС.

  • Grigory Kornilov

    Для чего разнообразие ошибок терминалу? Чтобы ремонтникам было проще диагностировать и ремонтировать – пользователь аппарата и ремонтник тоже :), а ролевая модель не определена, не понимает аппарат кто перед ним.
    С аппаратом более менее ясно – он технический объект, создан давно и малопрограммируем. Вы внедрили технический объект с понятным техническим UserGuide в бизнес систему as_is.

    Но в мире есть и тупее ситуации : разработчики часто грешат тем, что выплевывают на бедных пользователей технические термины, описывающие проблемы\ошибку, причем as_is копипастом.

    • Марина Капнулина

       Но в мире есть и тупее ситуации : разработчики часто грешат тем, что выплевывают на бедных пользователей технические термины, описывающие проблемы\ошибку, причем as_is копипастом.

      Вот это реальная проблема, которая есть в софтверных решениях не первый год. И она никуда не девается! Сидит бедный пользователь, ничтоже сумняшеся вносит заявку, жмет ОК, а софт плюет в него ошибкой SQL запроса. Первая реакция, увидев этот ужас, закрыть окно, чтоб никто не видел! Вторая – перезапустить софт. И почему тогда удивляться, что пользователь хочет закрыть окно??

  • Вадим

    Думаю, все проще.
    Рядовой персонал в подобных точках обслуживания обычно ориентирован (и мотивирован) на число транзакций, т.е. обслужить больше покупателей. То, что этому мешает, по мере возможности игнорируется. А вопросы вызова старшего, замены агрегата (а то и просто его отключение) снижают “производительность” сотрудника (в его понимании производительности). Грубо говоря, за разбирательство с железкой ему не платят. Поэтому никакой заинтересованности в изучении непонятных надписей у них нет.

    Я, кстати, уже давно стараюсь игнорировать “особо технологичные” агрегаты в пользу “юзерфрендли” не потому, что не в состоянии разобраться (а иногда и так бывает), а потому что не хочу тратить на это свое время

    • Марина Капнулина

      Ну так а что мешает прописать последовательность необременяющих рядовой персонал действий? Типа : нажал на кнопку, вызвал администратора. Отложил неработающий терминал, взял запасной – продолжил работать. Пришел администратор, забрал терминал. Все!


Добавить комментарий для ВадимОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM