Когда правило в бизнес-системе стоит настраивать, а когда — дорабатывать?
Правило в бизнес-системе стоит настраивать, когда компания меняет допустимый вариант уже понятного процесса. Дорабатывать код нужно тогда, когда меняется сам смысл операции, ответственность или проверка результата. Если перепутать эти случаи, система либо превращается в набор ручных исключений, либо требует разработки по каждому рабочему вопросу.
Самый простой ориентир такой: настройка меняет параметры известного правила, а доработка создаёт или меняет правило. Разница кажется тонкой, но от неё зависят скорость работы, цена поддержки и безопасность изменений.
Что считать настройкой
Настройка отвечает на вопрос «какой из заранее предусмотренных вариантов выбрать?». Например, руководитель устанавливает лимит согласования для отдела, выбирает маршрут документа, добавляет группу пользователей или меняет срок напоминания. Система уже понимает эту операцию; ей нужно только указать допустимые значения.
Хорошая настройка имеет владельца в бизнесе. Ему не нужно просить разработчика заменить число в коде, но и он не должен иметь возможность нечаянно сломать расчёт или выдать себе чужие права. Поэтому у настройки есть границы: кто её меняет, как изменение фиксируется, когда начинает действовать и как откатить ошибку. О том, как определить такого владельца до запуска, я писал в материале «Как назначить владельца процесса перед автоматизацией».
Плохой признак — когда одну и ту же «настройку» никто не может объяснить без инструкции на несколько страниц. Обычно это значит, что под видом гибкости в систему вынесли сложную логику, которую пора назвать отдельным правилом и спроектировать заново.
Когда нужна доработка
Доработка нужна не потому, что запрос сложный или срочный. Она нужна, когда системе неизвестно, что считать правильным. Например, компания вводит новый способ расчёта бонуса, связывает этап заказа с юридическим обязательством или меняет логику списания запасов. Здесь недостаточно выбрать значение в форме: появилось новое условие, новая проверка или новый результат операции.
Полезно остановиться и описать изменение простыми словами: «Если произошло X, система должна сделать Y, но только при Z; исключение рассматривает роль N». Если такое предложение невозможно сформулировать, разработку начинать рано. Скорее всего, бизнес ещё не договорился о правиле.
Особое внимание стоит уделить изменениям, которые затрагивают деньги, доступы, обязательства перед клиентом или исторические данные. Их нельзя считать обычной настройкой только ради скорости. Здесь нужны тестовый сценарий, автор решения, дата вступления в силу и понятный путь назад.
Три вопроса для выбора
- Был ли такой вариант предусмотрен заранее? Если да, вероятно, это настройка. Если нет — нужно проектировать доработку.
- Меняется значение или смысл результата? Новый лимит — значение. Новый порядок расчёта и ответственности — смысл.
- Сможет ли владелец процесса безопасно объяснить и проверить изменение? Если нет, нельзя оставлять его скрытым переключателем.
Представим согласование скидки. Изменить порог с 10 до 15 процентов — настройка, если система уже умеет работать с порогами и журналом изменений. Добавить правило «для стратегического клиента разрешить скидку при условии предоплаты и отдельного согласования финансового директора» — доработка: система должна узнать новые факты, связать их и вести другой маршрут.
Сначала проверить правило на одном живом случае
До выбора между настройкой и доработкой я бы взял недавнюю операцию, в которой уже возник вопрос. Не воображаемый «типовой заказ», а реальную заявку, которую пришлось обсуждать. По ней быстро видно, что именно пытаются поменять: параметр, порядок действий или смысл результата.
Допустим, отдел просит «больше гибкости» в сроках поставки. На одном заказе выясняется: менеджер может менять дату сам, но если дата влияет на обещание клиенту и резервирование склада, требуется подтверждение. Значит, речь не просто о календарной настройке. Появляется правило о том, кто вправе менять обязательство и что должно произойти после изменения.
Один живой разбор лучше длинного списка пожеланий ещё и потому, что показывает исключения. Можно ли изменить параметр после начала операции? Что делать с уже созданными документами? Кто узнает о смене? Если эти вопросы не имеют ответа, нельзя прятать решение в форму настроек.
Почему опасна универсальная настройка
У разработчика часто возникает соблазн сделать «конструктор на все случаи». У заказчика — желание иметь поле для каждого будущего исключения. В результате появляются десятки флажков, формулы, условия и роли, смысл которых сохраняется только у человека, который всё это однажды настроил.
Такая гибкость похожа на пульт от незнакомого оборудования: кнопок много, но нажимать страшно. Новому сотруднику проще вести параллельный Excel, чем рисковать рабочей системой. А при ошибке никто не знает, было ли неверным правило, настройка или данные.
Лучше оставить пользователю небольшой набор решений, которые он действительно вправе принимать. Всё остальное вынести в прозрачную доработку с названием, описанием и проверкой. Это не замедляет бизнес: наоборот, снижает число случайных изменений и длинных поисков причины.
Как оформить изменение без лишней бюрократии
Для настройки достаточно короткой карточки: что меняем, кто владелец, для кого действует, с какого момента и как проверить. Если система хранит журнал, в нём должно быть видно старое и новое значение. Особенно полезны дата начала действия и возможность вернуть предыдущую конфигурацию.
Для доработки добавляются сценарий, исключения и тест. Не нужно писать роман на сто страниц. Достаточно провести один обычный случай, один пограничный и один ошибочный: что увидит пользователь, что запишется в историю, кто получит уведомление и что останется неизменным.
Отдельно стоит договориться о доступе к настройкам. Право изменить параметр не равно праву увидеть все данные или отменить уже проведённую операцию. Хорошая система разводит эти вещи по ролям и оставляет след изменения. Тогда скорость не превращается в зависимость от одного администратора, а расследование ошибки не начинается с вопроса «кто вчера что-то переключил?».
Название настройки тоже должно отвечать на человеческий вопрос. Не «режим 3» и не «флаг обработки», а «срок напоминания клиенту» или «порог согласования скидки». Рядом полезно показать единицу измерения, область действия и безопасное значение по умолчанию. Это небольшая работа, но она отличает самостоятельную настройку от скрытого технического механизма.
Перед выпуском имеет смысл дать владельцу процесса самому пройти эти три случая. Не принять скриншот, а сделать действие. Так быстрее обнаруживаются вопросы, которые не видны в техническом описании: неясное название статуса, лишний шаг или отсутствие права исправить ошибку.
Частые ошибки
- Называть настройкой изменение, которое влияет на расчёт, деньги или права доступа.
- Добавлять новый переключатель вместо того, чтобы договориться об одном понятном правиле.
- Давать всем администраторам право менять критичные параметры.
- Не хранить историю: через месяц невозможно объяснить, почему результат изменился.
- Проверять только счастливый путь и забывать про отмену, повтор и ошибочные данные.
Короткий чек-лист
Перед тем как выбрать путь, спросите: это известный системе вариант или новое правило? Кто отвечает за изменение? Какие данные и результаты оно затронет? Можно ли проверить его на одном реальном примере и безопасно вернуть назад?
Если ответы ясны, выбор обычно становится очевидным. Настройка даёт бизнесу скорость там, где скорость безопасна. Доработка защищает систему там, где цена ошибки выше удобства одного переключателя.
Обсудим?