От бизнес-запроса к проверяемой задаче для ИИ и разработчика 1С

От «сделайте быстрее» к задаче, которую можно проверить: постановка для ИИ и разработчика 1С

«Ускорить согласование скидок» — понятная просьба, пока команда обсуждает неудобство. Но разработчику её недостаточно. Где начинается согласование? Кто вправе одобрить скидку? Что произойдёт, если после одобрения изменится сумма заказа? Как заказчик поймёт, что доработка работает?

ИИ быстро превращает такую просьбу в гладкое описание и даже предлагает код. Гладкость текста не подтверждает бизнес-правило и не доказывает, что предложенный объект есть в конкретной базе. Поэтому перед разработкой полезно собрать короткую постановку, в которой каждое существенное решение имеет владельца, а ожидаемый результат можно наблюдать.

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

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

Сначала выяснить результат, затем выбирать механизм

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

Спросите владельца процесса:

1. Кто сталкивается с проблемой и на каком действии?

2. Что должно измениться для этого человека?

3. Какой признак покажет улучшение: время до решения, доля заявок без ответа или видимость статуса?

4. Кто утверждает само правило согласования и спорные исключения?

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

Ограничить задачу одним сценарием

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

В этом описании сразу обнаруживаются вопросы. Запрос появляется при вводе скидки, записи документа или отдельной отправке? Какие значения входят в решение: процент, сумма, клиент, состав заказа? Где хранится решение? Что видит менеджер при отказе? Можно ли отправить запрос повторно? Без ответов два разработчика реализуют разные, но внешне правдоподобные варианты.

Границу сценария нужно проверить в текущей базе. Действие может проходить через форму, обмен или фоновую обработку. Это возможные пути для обследования, а не утверждение, что все они существуют в любом решении 1С. Разработчик устанавливает фактические точки входа по конкретной конфигурации и релизу, а владелец процесса подтверждает, где правило должно действовать одинаково.

Назвать то, что нельзя нарушить

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

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

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

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

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

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

Передать ИИ задачу на поиск пробелов

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

Пример запроса к модели:

Из приложенного согласованного описания выдели: (1) факты со ссылкой на фрагмент входного текста,
(2) предположения, (3) вопросы владельцу процесса. 
Предложи до трёх негативных случаев и способ наблюдать результат каждого.
Не придумывай пороги, роли и объекты конфигурации. 
Если исходных данных нет, верни вопрос вместо готового правила.

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

Собрать контракт задачи на одной странице

После обсуждения результат можно зафиксировать без большого документа:

• Цель: какую проблему решаем и по какому признаку оценим результат.

• Владелец: кто утверждает правило и исключения.

• Граница сценария: инициатор, событие, вход, решение и выход.

• Инварианты и ограничения 1С: какие данные, права и пути изменения нужно сохранить; что проверено в текущей базе.

• Примеры: основной, граничный и негативный случаи с ожидаемым состоянием.

• Приёмка: кто и где воспроизведёт примеры, что увидит пользователь и что будет записано в системе.

• Открытые вопросы: вопрос, ответственный и срок ответа; неизвестное нельзя скрывать за текстом ИИ.

Для небольшой настройки контракт будет коротким. Если есть обмены, учётные движения или несколько сторон согласования, его расширяют. Объём определяется числом рисков и развилок, а не стремлением заполнить шаблон.

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

Выводы

Проверяемая постановка начинается с бизнес-результата и владельца правила. Затем команда ограничивает один сценарий, записывает важные условия 1С и проверяет правило на обычном, граничном и негативном примерах. Приёмка описывает наблюдаемый результат в данных, правах и действиях пользователя.

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

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