От просьбы к функциональному требованию

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

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

Сначала фиксируем просьбу и границы

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

Первый разговор можно провести почти дословно:

— Что должно помочь сделать телефон, почта и кабинет?

— Быстрее связаться с сотрудником и понять, куда к нему направить посетителя.

— Речь о рабочем контакте и текущем месте работы? Что считать текущим, если у сотрудника несколько вариантов?

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

Разведка отделяет данные от догадок

Попросите LEM исследовать доступные объекты и показать основания для каждого наблюдения: существующую форму карточки, список, источники контактов, связи, отображение и доступные права. Это статическая разведка. Если проект подключён и индекс актуален, поиск по коду и метаданным помогает найти контекст; точность и давность снимка проекта всё равно нужно сверить. Агент не должен выдавать предположение за подтверждённое поведение.

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

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

Мини-ТЗ начинается с вариантов, а не с ответа за заказчика

Предварительная карточка постановки может выглядеть так:

• Цель: облегчить связь с сотрудником и навигацию посетителей.
• Текущее поведение: требует подтверждения по форме и списку целевой конфигурации.
• Ожидаемое поведение: показать согласованное контактное значение и кабинет в карточке; кабинет также доступен в списке.
• Источники данных: сначала проверить типовой источник email и телефона у физического лица и существующие связи с местом работы.
• Неопределённости: показывать все контакты через разделитель или один выбранный; какой кабинет считать актуальным; что делать при пустых данных.
• Приёмка: карточка и список показывают согласованный результат с учётом прав, отсутствующих и множественных значений.

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

Вопросы, без которых нельзя фиксировать критерии

Согласуйте сценарии: один контакт; несколько; отсутствие контакта; несколько рабочих мест; смена места; нет кабинета; одновременно несколько действующих кабинетов. Выбор одного значения требует бизнес-правила. Последняя запись сама по себе не означает актуальность: запись могла остаться исторической или быть введена позже с другим смыслом.

Обсудите отображение. Список может быть ограничен по ширине; карточка — нет. Нужны ли все значения, короткое представление, подсказка или переход к полному списку? Как пользователь поймёт, что строка обрезана? Что делать, если у пользователя нет права на контактные данные: скрыть столбец, оставить пустое значение или сообщить об ограничении? Выбор зависит от политики учреждения и целевой формы.

Передаём задачу вместе с неизвестным

Исследуй в выбранном зарегистрированном проекте существующие формы карточки сотрудника и списка, источники email и телефона, связи сотрудника с физическим лицом и рабочими местами, а также доступные ограничения прав. Для каждого факта укажи источник и версию снимка. Ничего не меняй. Отдельно перечисли, что остаётся неизвестным. Не предлагай создавать дубли контактов; подготовь вопросы владельцу процесса про множественные контакты, актуальное рабочее место, пустые значения, видимость и длину списка.

После ответа аналитик обновляет мини-ТЗ: сведения снабжает источниками, гипотезы помечает, решения владельца фиксирует после явного ответа. Путь исследования описан в статье «Как аналитику работать с LEM», а пример требований — в разборе заявки на выплату. Практический результат — формулировка, которую пользователь может подтвердить или уточнить до разработки.