Пользователю изменили права, но нужная возможность у него не появилась. Открываются знакомые настройки в 1С. Подобные обращения уже встречались, поэтому понятно, с чего начинать.
Первая версия - не хватает одной из ролей. Проверка быстро находит расхождение. Оно реальное, хорошо объясняет симптомы и уже не раз оказывалось причиной похожих обращений.
Позже, после длительного копания, выясняется, что роль здесь почти ни при чём. Пользователь работал с дополнительной организацией, которая не попала в ограничение доступа. Параметр находился на виду, но привычная последовательность его не затрагивала.
Первоначальное объяснение не было глупым. Специалист действительно нашёл ошибку. Просто она не определяла результат.
Нельзя сказать, что это была невнимательность. Она объясняет итог и почти ничего не говорит о том, как человек к нему пришёл.
Решение стало очевидным слишком быстро и именно этот условный и простой пример мы возьмем за основу.
Опыт сокращает путь
Сильный специалист не разбирает каждое обращение как совершенно новое. Он узнаёт сочетание признаков, отбрасывает маловероятные причины и начинает с версии, которая чаще всего помогала раньше.
В этом и состоит практическая ценность опыта. Работа идёт быстрее, лишних действий становится меньше, а существенные детали лучше выделяются. Если каждый раз возвращать человека к полной процедуре с нуля, вместе с частью риска исчезнет и часть скорости, ради которой его ценят.
Гэри Кляйн, изучавший принятие решений в реальной профессиональной среде, описывал, как опытные люди распознают тип ситуации и мысленно проверяют первый подходящий вариант, не перебирая все альтернативы. В знакомых условиях это экономит время и обычно даёт хороший результат. Поэтому быстрый переход к привычной версии сам по себе не является ошибкой. Риск появляется, когда текущая ситуация лишь кажется полностью знакомой, а одно важное условие изменилось.
Новичок, возможно, дольше сверялся бы с описанием и позже перешёл к решению. Нельзя сказать, что его результат работы будет надёжнее. У него просто ещё нет устойчивого маршрута, который запускается при первых знакомых признаках.
У опытного сотрудника часть анализа уже происходит почти без отдельного усилия. Он быстрее понимает, куда смотреть. Обычно именно это и нужно. Ошибка возникает тогда, когда привычный маршрут не учитывает изменившееся условие.
Хорошая версия может оказаться неполной
Особенно убедительно действует объяснение, для которого уже нашлось подтверждение. В начальной сцене роль действительно отсутствовала. После такой находки естественно продолжить проверку в том же направлении.
Мерим Билалич, Питер Маклауд и Фернан Гобе исследовали похожий механизм на шахматных задачах. Когда в позиции присутствовал знакомый, но не лучший ход, он мешал части опытных игроков увидеть более сильное решение. В другой работе исследователи отслеживали движения глаз. Участники говорили, что ищут альтернативу, но продолжали чаще смотреть на элементы, связанные с уже найденным вариантом.
Шахматная позиция не повторяет диагностику прав доступа. Здесь важен более узкий вывод: первая рабочая версия влияет не только на ответ, но и на дальнейший поиск.
Причину предполагают искать в роли. Затем сравниваются роли, профили и связанные настройки. Обнаруженное расхождение укрепляет гипотезу. Проверка становится тщательнее, но остаётся на том же участке.
Дополнительная организация не скрыта. Она просто не входит в вопрос, который сейчас задаёт себе человек.
В сложной системе частично правильное объяснение встречается часто. Отсутствующая роль действительно является дефектом. Она просто не объясняет, почему доступ не появился. Исправление такого дефекта создаёт ощущение, что причина найдена, хотя поведение системы не меняется.
После первой находки стоит посмотреть, какие наблюдаемые признаки она всё ещё не объясняет. Это не требование начинать диагностику заново. Скорее способ не принять хорошую рабочую версию за окончательный ответ раньше времени.
У найденного расхождения есть ещё одно следствие. Пока причина неизвестна, человек продолжает искать. Как только появляется правдоподобное объяснение, внимание переключается на исправление.
Если версия верна, это экономит время. Если она объясняет только часть картины, оставшиеся признаки легко отходят на второй план. После исправления роли проверяют уже не все исходные симптомы, а в первую очередь саму роль.
Почти знакомая система
В правах и настройках один параметр иногда влияет сразу на несколько связанных условий. Организация меняет доступ к данным, профиль задаёт набор ролей, расширение влияет на поведение формы.
Поэтому привычные элементы могут оставаться на своих местах, а общий результат уже формируется иначе. Так бывает после обновления, при появлении нового маршрута обмена или при переносе настройки в другую базу.
Полностью новая система обычно вызывает осторожность. Человек медленнее читает экран, чаще сверяется с описанием, задаёт больше вопросов. Почти знакомая система такой реакции не вызывает.
Дени Беснар и Люсиль Качитти исследовали отрицательный перенос после изменений интерфейса управляющей системы. Новая среда сохраняла достаточно знакомых признаков, чтобы запускать прежние действия, хотя их результат уже изменился. Поэтому почти знакомая система иногда опаснее полностью новой: человек не начинает разбираться с нуля и продолжает следовать порядку, который раньше работал.
Поэтому после изменения процесса повтор всей инструкции не обязательно поможет. Опытный сотрудник всё равно будет опираться на прежний порядок. Ему важнее увидеть места, где этот порядок больше не приводит к прежнему результату.
Фраза «я это сто раз делал» описывает прошлый опыт, но не проверяет текущие условия.
Одинаковый результат ещё не объясняет причину
Раз права настроили неверно, сотруднику ещё раз показывают правильный порядок действий. Возможно это и принесет пользу, но один и тот же результат может возникнуть по-разному.
Человек мог не знать, что доступ зависит от организации. Мог знать это правило, но отнести обращение к привычной проблеме с ролью. Мог правильно понять ситуацию и изменить настройку в другой базе. Наконец, мог отвлечься после изменения и не вернуться к проверке результата.
Джеймс Ризон различал ошибки понимания и планирования, ошибки исполнения, пропуски памяти и сознательные нарушения. Внешне они могут приводить к одному результату, но требуют разных решений. Если человек не знал правило, поможет обучение. Если он выбрал неверную версию, нужно разбирать ход диагностики. Если потерял шаг после переключения - условия выполнения работы. Поэтому фраза «надо быть внимательнее» обычно слишком мало объясняет.
Это не снимает личной ответственности. Человек отвечает за соблюдение критичных ограничений и за сознательно принятые решения. Но ответственность не заменяет объяснение механизма. Без него команда рискует снова назначить не ту меру.
Рутинная работа редко идёт без помех
В спокойной знакомой работе операция требует меньше осознанного контроля, и редкое отличие получает меньше внимания. Во время инцидента происходит другое: внимание стягивается к одной срочной версии. Человек может быть предельно собран, но вся его собранность направлена на слишком узкий участок.
Есть и более будничная причина. Настройка доступа редко выполняется без переключений. Нужно дождаться обновления, ответить пользователю, открыть другую базу, уточнить данные у коллеги.
Дж. Грегори Трафтон, Эрик Альтман и их коллеги изучали, как люди возвращаются к задаче после прерывания. Если перед переключением участники успевали удержать следующий шаг, возобновить работу было легче. Для привычной операции это важное различие: человек может хорошо помнить сам порядок действий, но после сообщения или звонка потерять место, на котором остановился. Поэтому повторное объяснение процедуры не всегда предотвращает такой пропуск.
Специалист изменил настройку и собирался проверить результат под нужным пользователем. В этот момент пришло сообщение по другой задаче. После ответа он вернулся в ту же форму, увидел уже выполненную часть работы и закрыл обращение. Сам порядок проверки он помнил, но уже не помнил, на каком шаге остановился.
Особенно уязвимы действия, которые должны произойти чуть позже. Они уже запланированы, но ещё не выполнены. После переключения на экране может не остаться ничего, что напомнит о них.
Трафтон Дрю, Мелисса Во и Джереми Вулф предложили 24 рентгенологам искать лёгочные узелки на компьютерных томограммах. В изображения добавили крупный неожиданный объект, который не отметили 20 специалистов. Отслеживание взгляда показало, что многие из них смотрели в соответствующую область. Это не значит, что эксперты менее внимательны: они выполняли профессиональную задачу и искали признаки определённого типа. Исследование показывает другое - параметр может находиться перед глазами, но не попасть в анализ, если текущая проверка направлена на иной класс ошибок. При настройке прав специалист может видеть выбранную организацию, но не рассматривать её как причину, пока занят сравнением ролей и профилей.
В знакомой операции такой пропуск иногда труднее заметить, чем в новой. Общая последовательность кажется завершённой, потому что большая её часть действительно завершена.
Когда менять маршрут работы
После ошибки обычно усиливают контроль, повторяют инструктаж или подключают второго специалиста. Иногда это помогает. Иногда только удлиняет прежний порядок работы.
Повторное обучение полезно тому, кто не знал правила. Если человек знал его, но не распознал момент применения, дополнительное объяснение почти ничего не меняет.
Со вторым взглядом похожая проблема. Если новому участнику сразу сообщить предполагаемую причину и показать найденное расхождение, он начнёт проверять уже заданную версию. Другой ход рассуждения появляется только тогда, когда исходные условия рассматриваются отдельно от готового решения.
Такой разбор требует времени, поэтому использовать его для каждой настройки бессмысленно. Он оправдан там, где цена ошибки высока, последствия трудно обратимы или один и тот же механизм уже повторялся.
Иногда причина находится в рабочей среде. В одной форме плохо различаются базы, в другой не видно выбранную организацию, в третьей результат изменения нельзя проверить без повторного входа. Человек может знать порядок и хотеть выполнить его правильно, но интерфейс постоянно подталкивает к одному и тому же пропуску.
Иногда всё проще: обязательную проверку сознательно пропустили, хотя риск был понятен. В таком случае разговор об устройстве процесса не заменяет разговор об ответственности.
Длинный новый регламент легко создаёт ощущение, что причина устранена. Но если в нём по-прежнему нет условия, которое изменило результат, количество пунктов ничего не решает.
После случая с правами команда, вероятно, начнёт чаще проверять организацию. Это разумно. Но следующий инцидент может отличаться уже другим параметром.
Поэтому полезно запомнить не только конкретную причину, но и момент, когда обычная проверка пошла по слишком знакомому пути. Иначе вчерашнее исключение быстро превратится в ещё одно правило, которое тоже начнут применять автоматически.
Что изменилось в этот раз
В случае с правами не требовалось заново разбирать весь механизм доступа. Достаточно было вернуться к исходному результату и заметить, что от предыдущих обращений этот случай отличала организация.
Опыт по-прежнему помогал: роли и профили были проверены быстро, типовой дефект найден. Ошибка возникла не из-за самого быстрого решения, а потому, что после него поиск фактически закончился.
Знакомую задачу не нужно каждый раз выполнять как новую. Но перед тем как закрыть её, стоит убедиться, что найденная причина объясняет именно тот результат, с которого всё началось.
