Код от агента хорош ровно настолько, насколько хорошо требование

Спор, в котором правы обе стороны

В чатах 1С-разработчиков спорят, что на самом деле дают агенты. Позиции примерно такие:

Хорошо написанное требование — и агент выдаёт годный код. Раньше на такую задачу уходили часы, теперь минуты.

Чем дольше возишься с постановкой, тем меньше выигрыш. Проще написать самому.

Обе стороны описывают одно и то же с разных концов. Код теперь пишется быстро. Требование прорабатывается так же долго, как раньше. Узкое место сместилось из разработки в постановку, и выигрыш от агента упирается в неё.

Что теряется в требовании

От бизнеса требование приходит одной-двумя фразами: «нужно автоматизировать печать накладных при отгрузке». Человек, который давно в проекте, достраивает остальное сам. Агент не достраивает, он аккуратно выполняет то, что написано. По дороге теряется вот что:

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

Проработать всё это руками — значит написать хорошее требование. На это и уходит время, которое сэкономил агент.

Что с требованием делает 1Yes Аналитик

1Yes Аналитик работает на этапе между фразой от бизнеса и задачей для разработчика. Он работает по проиндексированной конфигурации, поэтому его вопросы и варианты относятся к вашей системе, а не к 1С вообще.

Читает то, что приложили

К требованию можно приложить регламент, выгрузку, фрагмент ТЗ или скриншот. Система читает их вместе с текстом: вложения попадают в разбор и влияют на вопросы, которые она задаст.

Требование с приложенными регламентом и фрагментом ТЗ — Регламент и фрагмент ТЗ заказчика приложены к требованию и читаются вместе с ним.

Задаёт вопросы по вашей конфигурации

Это главное отличие от универсального помощника. Вопросы строятся от того, что есть в системе.

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

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

Раскрывает сокращения заказчика

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

Помнит договорённости проекта

Когда аналитик правит решение комментарием, система предлагает сохранить правку как принцип проекта: формулировку и причину. В следующих требованиях этого проекта принцип учитывается сам.

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

Так уходит самая обидная часть работы: одни и те же поправки, которые приходилось писать к каждому новому решению.

Отдаёт спецификацию, с которой можно идти в разработку

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

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

Это и есть «хорошо написанное требование», с которого начался спор. Только собирается оно не вручную с чистого листа, а за проход, в котором аналитик отвечает на вопросы и выбирает вариант.

Что остаётся за аналитиком

Отвечать на вопросы. Какой документ считать накладной, знает только тот, кто знает бизнес заказчика.
Выбирать вариант. Система показывает плюсы и минусы, решение принимает человек.
Проверять результат. Спецификация — основа для работы, а не истина. Перед разработкой её читает специалист.

Меняется то, на что уходит его время: на решения, а не на сбор контекста.

Когда это не сработает

На вопросы некому ответить. Если заказчик сам не знает, как должен идти процесс, система покажет пробелы, но не заполнит их.
Конфигурация не проиндексирована. Без индекса вопросы и варианты будут на уровне типовой логики, а ваши доработки останутся за кадром.
Ожидание готового кода. Результат этапа — спецификация. Код по ней пишет разработчик или агент, и этот код проходит ревью и тесты как обычно.
Согласования. Проработка требования ускоряется, согласование с бизнесом и приёмка — нет. Они по-прежнему занимают столько, сколько занимают.
Сложные случаи с первого раза. Иногда решение приходится уточнять в два-три прохода. Для непростых задач это нормальный режим работы.

С чего начать

Замер конфигурации. Передаём скрипт-отчёт 1С, по нему считается объём индексации.
Индексация. Система разбирает метаданные, связи, код и доработки.
Пилот на ваших требованиях. Берём настоящие, в том виде, в каком они приходят от бизнеса.