Диалог, который знает каждый аналитик
Аналитик приходит на проект сопровождения или готовит переход на новую версию. Конфигурация живёт много лет, её дорабатывали несколько команд. Он задаёт первые вопросы и слышит примерно следующее:
Никто здесь не виноват. Документацию не пишут не из лени: бизнесу нужна работающая функция, а не её описание, и бюджет на описание закладывают редко. В результате знание о системе хранится в самой системе и в головах двух-трёх человек.
Что на самом деле отнимает время
Понять найденный код обычно несложно. Долго — найти, где смотреть. Типичные вопросы первых недель:
| Вопрос | Что нужно знать для ответа |
|---|---|
| Откуда в документе берётся это значение? | Обработчики формы, модуль объекта, подписки на события, общие модули |
| Что запишет документ при проведении? | Все регистры и условия, при которых движения формируются |
| Что сломается, если убрать реквизит? | Все места, где он читается: отчёты, обработки, обмены, права |
| Это типовое поведение или доработка? | Где проходит граница между кодом вендора и своим |
| Кто вообще видит эти данные? | Роли и ограничения доступа на уровне записей |
Человек, который давно работает с этой конфигурацией, отвечает на такие вопросы по памяти. Новому приходится каждый раз идти в код, и он не уверен, что нашёл всё.
Почему обычные способы не спасают
Документация. Если она есть, то устарела: её писали к запуску, а доработки шли после.
Глобальный поиск в конфигураторе. Он находит строки, а не связи. Подписка на событие, которая меняет поведение документа, в поиске по имени реквизита не всплывёт.
Спросить автора. Автор уволился или занят, и каждый вопрос к нему отнимает время у обоих.
Загрузить код в универсальный чат-бот. Для небольшого фрагмента это работает. Но конфигурация уровня ERP целиком в него не помещается, а по фрагменту нельзя сказать, кто ещё обращается к этому регистру.
Общая причина одна: у вопроса нет адресата, который знает всю конфигурацию сразу.
Как это выглядит с проиндексированной конфигурацией
Индексация разбирает конфигурацию один раз: объекты метаданных, связи между ними, код, роли и права. После этого конфигурации можно задать вопрос обычными словами. Этим занимается чат-эксперт: вы выбираете конфигурацию и пишете вопрос так, как спросили бы коллегу.
Мы проверили это на типовой ERP 2.6 и нарочно задали вопрос с ошибкой в условии: спросили, откуда в документе реализации берётся статья расходов.
В этом ответе видно три вещи, ради которых всё и делается.
- Ответ начинается с факта о конфигурации, а не с общих слов. Реквизита
СтатьяРасходовнет ни в шапке, ни в табличных частях, и на форме такого поля тоже нет. Новый аналитик выяснял бы это сам, открывая документ и форму по очереди. - Названы конкретные объекты.
РеализацияТоваровУслуг,ФормаДокумента,ИсточникГФУНоменклатуры— это имена из конфигурации, по ним можно открыть объект и проверить. - У утверждений есть источники. Значки после предложений показывают, на что опирается ответ. Его не нужно принимать на веру.
Отдельно про скорость: такой ответ готовится несколько минут. Система не достаёт готовый текст, а проходит по объектам и коду. Это медленнее поисковой строки, но искать по конфигуратору самому при этом не нужно.
С каких вопросов начинают
- Откуда при проведении документа заполняется конкретное поле?
- Какие документы пишут в этот регистр и при каких условиях?
- Какие объекты затронет удаление или изменение реквизита?
- Как устроено согласование, закрытие месяца, расчёт себестоимости именно в этой базе?
- Какие роли видят этот документ и что ограничивает доступ?
Попробовать на типовой
Чат по типовой ERP открыт на chat.1yes.pro: первый вопрос можно задать без регистрации и увидеть начало ответа, полный ответ и следующие вопросы доступны после регистрации.
Типовая показывает принцип. Настоящая польза появляется на вашей конфигурации с её доработками, потому что именно про них спросить некого.
Что остаётся за человеком
Чат отвечает, как система устроена. Он не отвечает, как она должна быть устроена.
- Ошибка это или так задумано. Система покажет, что документ делает и почему. Правильно ли это, решает тот, кто знает учёт и договорённости с бизнесом.
- Что с этим делать. Найти места, где используется реквизит, теперь недолго. Решить, убирать его или нет, должен человек.
- Разговор с бизнесом. Он никуда не девается, но начинается с фактов, а не с просьбы «расскажите, как оно у вас работает».
Когда это не сработает
- Конфигурация не проиндексирована или индекс устарел. Чат знает то состояние, которое разобрали при индексации. Если конфигурацию активно дорабатывают, индекс нужно обновлять, иначе ответы будут про вчерашнюю систему.
- Вопрос про данные, а не про устройство. «Почему в этом документе такая сумма» — вопрос к базе, а для индексации нужны структура и код, но не продуктивные данные. На вопрос «как эта сумма считается» чат ответит, на вопрос «почему она такая у этого контрагента» — нет.
- Объекта нет в индексе. Мы отдельно следим за тем, чтобы пустой результат поиска не превращался в ответ «такого механизма нет»: это разные утверждения, и система их различает.
- Сложная нестандартная логика. Система может ошибаться. Для этого в ответе и нужны источники: спорное утверждение проверяется по объекту, на который оно ссылается.
С чего начать
- Замер конфигурации. Передаём скрипт-отчёт 1С, по нему считается объём индексации.
- Индексация. Система разбирает структуру метаданных, связи объектов и доработки. Продуктивные данные для этого не нужны.
- Вопросы от вашей команды. Лучше всего работают те, на которые сейчас может ответить только один человек.