Я не меняю правило в системе, пока не знаю, что станет с незавершёнными операциями

Самый опасный момент при изменении правила в системе — не день, когда его придумали. Это день, когда новое правило встречается со старой незавершённой работой. Заказ уже начат по одним условиям, согласование идёт по другим, а справочник успели обновить по третьим. Если заранее не решить, что делать с такими случаями, система начинает спорить сама с собой.

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

Правило существует не в вакууме

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

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

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

Сначала найдите операции в пути

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

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

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

Не переписывайте прошлое молча

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

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

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

Новое правило не должно ломать обещание клиенту

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

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

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

Дата изменения — часть самого правила

Полезно фиксировать не только новое значение, но и момент, с которого оно применяется. Тогда у команды появляется простая опора: эта операция создана раньше, поэтому идёт по прежнему порядку; эта — позже, поэтому по новому. Такая дата не заменяет решение по сложным случаям, но делает его проверяемым.

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

Проверка, которая экономит много объяснений

Перед публикацией нового правила я бы прогнал три примера:

• новая операция после даты изменения;
• операция, которая уже находится на середине пути;
• исключение, где данные уже успели уйти в другую систему.

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

Что я считаю хорошим изменением

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

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