Ошибка появляется только при некоторых условиях

«У коллеги проходит, а у меня нет» — важная подсказка: результат зависит от условий. Но она не называет условие. Им может быть роль, состояние данных, настройка, версия, порядок действий или сочетание факторов. Аналитику полезно не назначать виновника по первому совпадению, а сравнить две ситуации так, чтобы отличалось по возможности что-то одно.

Зафиксируйте пару случаев

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

Используем сквозную синтетическую модель «Заявка на выплату»: операции «Оплата услуг» и «Возврат средств»; назначение обязательно только для услуг; ниже 100000 рублей нужен один согласующий, начиная с 100000 — два. Если заявка чуть ниже порога проходит, а на границе нет, это повод проверить настройку или правило согласования. Если один сотрудник видит назначение, а другой нет, это повод сравнить контекст и сохранённые данные. Ни то ни другое само по себе не устанавливает причину.

Сначала найдите, что различается

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

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

Сопоставь два учебных случая «Заявки на выплату»: один проходит согласование, другой получает ошибку при отправке. Изучи доступные правила операций, обязательных полей и согласования; покажи, какие факты подтверждены источниками, а какие факторы пока только кандидаты. Не делай вывод, что причина в роли, пока это не подтверждено.

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

Проверяйте факторы по отдельности

Разделите кандидаты на группы. Роль и права: есть ли документально подтверждённое различие, влияет ли оно на чтение, изменение или отправку? Данные: совпадают ли операция, сумма, заполненность полей и состояние связанных объектов? Настройки: отличаются ли параметры процесса или организации? Версия: находятся ли участники на одном выпуске системы? Порядок действий: возникла ли ошибка после редактирования, сохранения или переключения операции?

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

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

Учитывайте границы наблюдения

Наблюдаемый результат относится к конкретным данным, пользователю и среде. Уточните версию; не делайте вывод о правах по похожим названиям ролей и сверьте, относится ли настройка к той же организации и процессу. Источники LEM помогают исследовать связи, а фактическое поведение проверяют отдельно в разрешённой тестовой среде. Общий маршрут диагностики описан в статье «Как искать причину ошибки», различие правила и наблюдения — в соответствующем разборе.

Запишите, что сравнили

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

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

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