Бизнес-правила в операционке, а не в коде: что переносить

Почему это тормозит команды

Быстро меняющиеся правила и медленные релизы плохо сочетаются. Когда команда каждую неделю меняет пороги согласования, обработку исключений или правила ответственности, код становится узким местом.

Небольшая правка политики редко остаётся небольшой, когда попадает в разработку. Кто-то создаёт задачу, инженер находит правило, меняет тесты, ждёт ревью и выкатывает всё в следующий релиз. Для изменения, которое может сводиться к «возвраты свыше $500 теперь нужно согласовывать с finance» или «этому уровню клиентов можно выдавать ручное исключение», это слишком много движений.

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

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

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

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

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

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

Что должно жить в операционке

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

Лимиты согласования — хороший пример. Компания может позволять support одобрять возвраты до $100 на одном рынке, а в другом регионе для сумм выше $50 уже нужен finance из-за локальных рисков или требований комплаенса. Для этого не нужно переписывать сам продуктовый поток. Операционная команда может хранить лимиты в простой таблице или слое настроек, а приложение будет их читать.

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

Таблицы ответственности тоже относятся сюда. Если одна очередь идёт в support, другая — в finance, а enterprise-аккаунты — в команду аккаунтов, такая маршрутизация не должна жить в жёстко зашитой логике. Структуры команд меняются. Люди уходят в отпуск. В одном сегменте нагрузка резко растёт, в другом падает. Операционная команда может обновлять таблицы ответственности намного быстрее, чем инженеры — выкатывать изменения в коде.

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

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

Помогает простой тест:

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

Такое разделение делает проектирование процесса согласований намного чище. Инженеры один раз строят маршрут. Операционная команда настраивает движущиеся части по мере изменений в бизнесе.

Что должно остаться в коде

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

Проверки безопасности — самый очевидный пример. Контроль доступа не должен зависеть от таблицы, сообщения в Slack или чьей-то памяти о том, кто что может делать. Приложение должно само решать, кто может смотреть payroll, экспортировать данные клиентов, менять платёжные реквизиты или утверждать рискованное действие.

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

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

Audit log никогда не должен зависеть от дисциплины людей. Когда кто-то меняет лимит, правит условие договора или одобряет возврат, продукт должен записать, кто это сделал, когда и что именно изменилось. Ручные заметки теряются. Автоматическая история — нет.

Жёсткие ограничения, которые защищают uptime, тоже должны оставаться в коде, даже если они кому-то мешают. Лимиты на размер файла, rate limit, таймауты, правила повторных попыток и ограничения на параллельные задания не дают одной плохой заявке замедлить всех остальных. Команды часто хотят здесь исключения, но один поспешный обходной путь может превратиться в outage.

Правило обычно должно оставаться в коде, если оно проходит один из этих тестов:

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

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

Как выносить правила из продуктовой разработки

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

Хороший фильтр — частота изменений. Посмотрите на задачи, переписки и заметки за последние шесть–двенадцать месяцев. Если правило менялось чаще одного раза в квартал, вынесите его в короткий список. Часто это решения по политике, а не по software.

Дальше назначьте у каждого правила одного владельца. Не группу, не «ops и product» и не того, кто первым заметил проблему. Один человек должен отвечать на базовые вопросы, утверждать правки и проверять, что правило всё ещё имеет смысл. Совместное владение звучит вежливо, но часто приводит к тому, что старые правила месяцами лежат без движения.

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

Например, правило по возвратам может говорить, что заказы ниже определённой суммы идут в support, суммы выше — в finance, а повторяющиеся случаи злоупотреблений — менеджеру. Для этого не нужен новый релиз каждый раз, когда finance меняет порог или назначает другого согласующего.

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

Наконец, ведите короткий журнал изменений и смотрите на результат. Проверяйте, снизилось ли время согласования, стало ли легче обрабатывать исключения и используют ли люди актуальное правило. Именно так business rules in operations становятся практикой. Таблица — это не просто документ. Она становится источником, которому доверяет команда, а код может оставаться сосредоточенным на тех частях, которые должны быть стабильными.

Простой пример с согласованием возвратов

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

Support открывает кейс и проверяет три вещи: сумму, страну клиента и возраст аккаунта. Эти проверки — бизнес-правила в операционке. Они меняются чаще, чем код, который фиксирует возврат, уведомляет billing и обновляет статус заказа.

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

Инженерам стоит оставить сам процесс возврата без изменений. Система по-прежнему принимает запрос, показывает те же поля, пишет тот же audit trail и отправляет то же событие на согласование, когда кейс требует проверки. Не нужен ни релиз, ни повторное тестирование, ни экстренный патч только потому, что временный лимит изменился.

Это разделение важнее, чем кажется. Если бы денежный порог жил в коде, небольшая смена политики превратилась бы в задачу, code review, QA и окно деплоя. К моменту выхода обновления праздничный пик мог бы уже закончиться.

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

Такой подход оставляет каждой команде свою работу. Support следует актуальной политике. Операционная команда меняет лимиты, когда меняются условия. Менеджеры оценивают крайние случаи. Инженеры защищают основной процесс возврата, чтобы он оставался стабильным, предсказуемым и простым в поддержке.

Как сделать таблицы ответственности полезными

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

Используйте простые названия, которые совпадают с тем, как люди говорят каждый день. «Finance» лучше, чем «Revenue Operations Group», а реальный запасной владелец лучше, чем «TBD». Когда кто-то уходит в отпуск на неделю, никто не должен гадать, кто может утвердить действие.

Временное покрытие должно иметь дату окончания. Если Alex отвечает за одобрение поставщика, пока Priya в отпуске, укажите оба имени и добавьте даты. Эта мелочь предотвращает частую проблему: временные владельцы незаметно становятся постоянными, потому что потом никто не приводит таблицу в порядок.

Привязывайте каждую строку к одному бизнес-действию. Не объединяйте пять действий под одной строкой вроде «вопросы клиентов» или «вопросы по биллингу». Разбивайте их на понятные пункты, например «одобрить возврат свыше $500», «утвердить изменение договора» или «снять просроченный платёж». Одна строка, одно действие, один владелец. Так бизнес-правила в операционке соблюдать намного проще.

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

Несколько признаков показывают, что таблица начинает плыть:

• люди задают один и тот же вопрос по ответственности чаще раза в неделю
• временные владельцы остаются без даты окончания
• одна строка покрывает несколько несвязанных действий
• в таблице всё ещё указаны старые команды или старые должности

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

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

Ошибки, которые создают лишнюю суету

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

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

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

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

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

Изменения политики могут просто переносить затраты с одной команды на другую. Более жёсткое правило согласования может выглядеть безвредно на бумаге, но support вдруг начинает разбирать 40 дополнительных тикетов в неделю. Поэтому business rules in operations нужно быстро проверять на реальность, прежде чем кто-то их обновит.

Ранние предупреждающие признаки обычно такие:

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

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

Быстрая проверка перед изменением правила

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

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

Используйте пять быстрых проверок.

• Спросите, может ли операционная команда изменить правило без деплоя. Если нет, маленькие правки политики будут постоянно попадать в продуктовую работу, а это обычно создаёт задержки.
• Спросите, может ли support объяснить путь меньше чем за минуту. Если для этого нужен рисунок и длинная ветка в Slack, схема слишком запутана для ежедневной работы.
• Спросите, может ли менеджер увидеть, кто одобрил исключение. Имена, метки времени и причина должны находиться легко. Если они спрятаны в логах, люди начнут спорить о том, что произошло.
• Спросите, тестировал ли кто-то один плохой ввод и один редкий случай. Обычные сценарии просты. Проблемы начинаются с возврата чуть выше лимита, отсутствующего документа или клиента, который попадает между двумя категориями.
• Спросите, можно ли откатить изменение в тот же день. Если для rollback нужны правки кода, изменения в базе данных или поздняя помощь инженеров, правило рискованно.

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

Эти проверки занимают около десяти минут. Зато потом экономят куда больше десяти минут. Когда правило проходит все пять проверок, обычно оно достаточно понятно, чтобы работать, объяснять, аудировать, тестировать и откатывать без лишней драмы.

Что делать дальше

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

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

Простой первый проход обычно выглядит так:

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

Через эти две недели смотрите на трение, а не на идеальность. Перестали ли в support просить инженеров о мелких правках? Finance или операционная команда стали обновлять правило быстрее? Кто-то запутался, кто владеет исключением? Небольшие ответы важнее красивых схем.

Именно на этом этапе многие команды понимают, действительно ли им нужны business rules in operations, или они просто переименовали код и сделали его сложнее для отслеживания. Если люди не могут найти правило, понять, кто им владеет, или увидеть, когда оно менялось, сначала исправьте это, а потом двигайтесь дальше.

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

Сначала настройте процесс. Потом автоматизируйте те части, которые уже имеют смысл на бумаге.