Есть типовой выход или дорабатывать?

Вопрос, который задают каждый день

В профессиональных чатах внедренцев ERP и УХ один и тот же вопрос повторяется в разных формах. Меняются подсистема и версия, суть остаётся прежней:

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

Почему ошибка дорого стоит в обе стороны

Лишняя доработка. Задачу закрыли кодом, хотя типовой механизм был. Теперь этот код нужно переносить при каждом обновлении, проверять на конфликты с новым релизом и объяснять каждому новому человеку в команде. Через пару лет никто не помнит, зачем его писали, а убрать его страшно.

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

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

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

Как ответ ищут обычно

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

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

Как этот выбор устроен в 1Yes Аналитик

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

Два варианта и сравнение по критериям

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

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

Подсказки по упрощению: что заменить типовым и что при этом потеряется

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

В подсказке три части:

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

Третья часть самая важная. Упрощение почти всегда оказывается компромиссом, и решать, приемлем ли он, должен человек, который знает заказчика.

История версий: можно попробовать и вернуться

Применённая подсказка пересобирает решение, но прежний вариант не пропадает. У каждого решения есть история версий: исходные варианты, выбор, каждая доработка.

Это меняет сам способ работы. Упрощённый вариант можно собрать, показать заказчику и разработчику, а если компромисс не устроил, вернуться к предыдущей версии. Сравнивать приходится не идеи на словах, а два проработанных документа.

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

Система не выбирает за человека. Она не знает, что для этого заказчика важнее: гибкость сейчас или стоимость сопровождения потом. Она не знает, что согласование счёта в компании появилось после конкретного инцидента и трогать его нельзя.

За аналитиком остаются три вещи:

• ответить на уточняющие вопросы по требованию, потому что бизнес-контекст есть только у него;
• выбрать вариант и принять или отклонить подсказки;
• проверить решение перед передачей в разработку.

Меняется исходная точка: он начинает не с чистого листа и чужих советов, а с вариантов, собранных по фактам своей конфигурации.

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

• Конфигурация не проиндексирована. Без индексации система отвечает на уровне типовой логики. Про ваши доработки она в этом случае ничего не знает, и ответ будет не точнее совета из чата.
• Требование неполное, а спросить некого. Система задаст уточняющие вопросы, но отвечать на них должен человек, который знает процесс.
• Вопрос на самом деле про ошибку в типовой. Если поведение выглядит как дефект, это вопрос к поддержке вендора. Мы покажем, как устроен механизм, но исправление типовой остаётся за её разработчиком.
• Проверка всё равно нужна. Система может ошибаться, особенно на сложной нестандартной логике. Финальную проверку выполняет специалист.

С чего начать

Обычно начинают с малого: одна конфигурация и одно рабочее место аналитика.

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

На разговоре достаточно одной задачи, по которой вы сейчас решаете, настраивать или дорабатывать. На ней и посмотрим.