Как аналитику работать с LEM

Когда на встрече звучит «в заявке должно быть понятно, кто и за что платит», это ещё не готовое требование. Неясно, где именно появляется назначение платежа, всегда ли оно обязательно, кто его проверяет и что происходит при возврате денег. Аналитику не нужно отвечать на эти вопросы по памяти или разбирать код 1С. Можно описать ситуацию обычными словами, а LEM поможет найти доступные сведения о форме, реквизитах, правилах и связях, чтобы превратить расплывчатое ожидание в предметный разговор.

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

Сначала опишите ситуацию

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

Полезно отдельно записать слова пользователя и ваши гипотезы. «Мне пришлось снова открыть заявку» — наблюдение со слов пользователя. «Вероятно, поле не сохраняется» — гипотеза, которую ещё предстоит проверить. Такое разделение не позволяет случайно превратить объяснение одного человека в подтверждённый факт.

Попросите LEM найти контекст

Сформулируйте запрос так, чтобы было ясно, какой вопрос вы исследуете и что нужно показать в ответе. Например:

В учебном примере «Заявка на выплату» выясни, при какой операции назначение платежа обязательно. Найди доступные сведения о форме, реквизитах и связях, которые подтверждают правило. Раздели найденные факты и предположения; объясни результат простыми словами и задай вопросы, без которых нельзя составить требование.

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

Если ответ опирается на конкретную форму или связь, попросите назвать источник и указать, что остаётся неясным. При недостатке данных сузьте вопрос: какая операция выбрана, кто вводит заявку, на каком шаге возникает ошибка, что пользователь сделал перед этим? Предметные уточнения обычно полезнее, чем просьба «посмотреть всю конфигурацию».

Переведите находки в решение для процесса

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

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

Именно так работает переход от исследования к требованию: найденные сведения дают основу, а желаемый процесс согласуют ответственные люди. Пошаговый разбор есть в статье «Разбираем заявку на выплату», а объяснение отдельной логики — в статье «Как объяснить работу функции».

Сделайте требование проверяемым

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

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

Проверьте поведение в подходящей среде

LEM помогает исследовать доступные статические источники и объяснять их человеческим языком. Чтобы проверить поведение, повторите сценарий в тестовой базе 1С; если используете Vanessa Automation MCP, он должен быть отдельно настроен для этой базы.

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