Документируйте бизнес‑правила для ИИ‑приложений простым языком

Почему неясные правила создают ненадёжные приложения

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

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

Возьмём правило «крупные расходы требуют одобрения менеджера». Человеку это может показаться понятным. Разработчику — нет. Что считать крупным: $500, $5,000 или всё, что превышает бюджет команды? Какой менеджер: непосредственный руководитель, глава отдела или финансы? Если никто не отвечает в течение двух дней, запрос ждёт, истекает или переходит к другому человеку?

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

Крупные проблемы обычно проявляются в нескольких областях:

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

Простой пример показывает проблему. Основатель создает внутреннее приложение для расходов в Koder.ai и пишет: «Возмещать командировочные расходы, если они не кажутся необычными». Это звучит разумно, но у приложения нет надёжного способа оценить «необычно». У одного сотрудника такси одобрят, у другого похожий расход пометят, и никто не понимает почему.

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

Как выглядит чёткое бизнес‑правило

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

Хорошее правило легко прочитать вслух. Человек вне вашей команды должен понять его без внутреннего жаргона. Замените термины вроде «ускоренная обработка», «стандартный случай» или «подпись менеджера» простыми словами, которые точно описывают, что происходит.

Большинство чётких правил отвечают на четыре основных вопроса:

• Кто принимает решение или выполняет действие?
• Когда правило применяется?
• Что меняется в приложении?
• Что происходит дальше?

Такая структура связывает правило с реальным поведением. Вместо «крупные заказы требуют проверки» напишите: «Если заказ выше $5,000, менеджер по продажам должен одобрить его перед отправкой на исполнение». Одно предложение, одно решение, один результат.

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

Разница легко заметна:

"Премиум‑клиенты получают приоритетную обработку" — это расплывчато.

"Если у клиента премиум‑план, запрос в службу поддержки помечается как Высокий при создании тикета" — это ясно.

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

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

Как писать расчёты простым языком

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

Хорошее правило звучит так: «Сумма возмещения равна утверждённым милям, умноженным на ставку за милю». Это гораздо яснее, чем «рассчитать оплату за поездку» или «применить стандартное возмещение».

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

Что нужно уточнить для каждого расчёта

Для каждого расчёта выпишите:

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

Мелкие детали важны. «Округлить итоговую сумму до 2 знаков после запятой» даёт другой результат, чем округление каждой строки отдельно. Если есть потолок, укажите, должен ли приложение ограничивать сумму этим потолком или показывать предупреждение.

Правило, написанное простым языком, может выглядеть так: «Сумма возмещения за поездку равна утверждённым милям × $0.67. Округлить итоговую сумму до 2 знаков после запятой. Максимальная сумма возмещения — $300 за поездку. Если поле утверждённых миль пустое, не рассчитывать сумму. Пометить запрос как неполный и попросить пользователя ввести мили.»

Затем добавьте один‑два примера с реальными числами. Примеры быстрее показывают пробелы, чем абстрактные формулы.

Пример 1: «Если утверждённые мили = 120, возмещение = 120 × $0.67 = $80.40. Поскольку это ниже потолка $300, итоговая сумма $80.40.»

Пример 2: «Если утверждённые мили = 500, возмещение = 500 × $0.67 = $335.00. Поскольку максимум $300, итоговая сумма = $300.00.»

Такая стилистика проще для проверки людьми и легче для разработчика при переносе в поведение приложения.

Как фиксировать исключения без путаницы

Большинство приложений не ломаются на основном сценарии. Они ломаются на пограничных случаях.

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

Простой способ описать исключения — использовать короткие правила типа если‑то. Держите каждое правило сфокусированным на одном условии и одном результате.

• Если расход меньше $100, то автоодобрение.
• Если расход меньше $100, но подан позже 30 дней, то отправить на ручную проверку.
• Если сотрудник в исполнительной команде, то проигнорировать лимит $100 и направить в финансы.
• Если админ из финансов пометил заявку как срочную, то применяется ручное переопределение и заявка перемещается в верх очереди.

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

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

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

Также укажите, что приложение должно показать пользователю в каждом исключении. Хорошее правило не останавливается на решении. Оно определяет и сообщение, например «Подано после 14 дней. Требуется утверждение менеджера» или «Ручное переопределение применено админом финансов.»

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

Описываем логику утверждений шаг за шагом

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

Начните с названия роли, а не просто команды. Вместо «финансы проверяют крупные запросы» напишите: «Финансовый менеджер может одобрить, отклонить или вернуть на доработку любой запрос свыше $5,000.» Это убирает домыслы и облегчает реализацию.

Затем определите триггер для каждого шага. Триггер — это условие, которое отправляет запрос следующему человеку. Он может основываться на сумме, отделе, уровне риска, типе запроса или их сочетании.

Например:

• Если запрос ниже $500, его рассматривает тим‑лид.
• Если запрос от $500 до $5,000, после согласия тим‑лида рассматривает менеджер отдела.
• Если запрос выше $5,000, после согласия менеджера отдела рассматривает финансы.
• Если запрос помечен как высокий риск, комплаенс должен проверить его перед окончательным одобрением.

Пороги должны иметь точные границы. Не говорите «крупный» или «чувствительный». Говорите «выше $5,000», «отдел продаж» или «оценка риска 8 или выше». Если два порога могут применяться одновременно, укажите, какое правило побеждает. Например: «Высокий риск всегда идёт в комплаенс, даже если сумма мала.»

Также нужен тайм‑аут. Если никто не отвечает, приложение не должно висеть в состоянии ожидания вечно. Укажите, что происходит после заданного времени, например 48 часов или 3 рабочих дня. Запрос может быть эскалирован менеджеру утверждающего, переназначен резервному согласующему или автоматически отменён.

Наконец, определите статус после каждого решения. Держите ярлыки короткими и последовательными:

• Одобрено: запрос продвигается дальше или завершается.
• Отклонено: запрос закрывается и дальнейших действий нет.
• Возвращено: заявитель должен отредактировать и отправить снова.
• Эскалировано: запрос переходит к резервному или более высокому согласующему.

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

Простой шаблон правила, который можно использовать повторно

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

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

Используйте одно правило — одну единицу

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

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

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

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

Например:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

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

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

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

Быстрый тест здесь прост: сможет ли кто‑то протестировать правило, и сможет ли кто‑то его неправильно понять? Если на первый вопрос ответ «нет», либо на второй — «да», — ужесточите формулировку.

Пример: приложение для согласования расходов

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

Пример политики

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

Если сотрудник потратил $12 на завтрак и $22 на обед в тот же день, сумма = $34, значит заявление проходит. Если он добавит $15 ужин в тот день, сумма станет $49, и приложение должно пометить заявление как превышающее лимит.

Добавьте исключение. Если приём пищи произошёл в рамках утверждённой командировки или деловой встречи с клиентом, дневной лимит увеличивается до $75. Это исключение применяется только когда сотрудник отмечает «День в поездке = Да» или «Встреча с клиентом = Да» и добавляет короткую заметку с именем клиента или целью поездки.

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

Шаги утверждения

Логика утверждения можно тоже держать простой:

• Заявления до $100 утверждает менеджер сотрудника.
• Заявления от $100 до $500 требуют одобрения менеджера, затем — финансами.
• Заявления свыше $500 требуют одобрения менеджера, финансами и руководителя отдела.
• Любое заявление, помеченное как "поездка", также требует проверки финансов, даже если сумма ниже $100.

Вы можете протестировать правило на нескольких простых кейсах. Чек на $36 за еду в обычный рабочий день должен быть одобрен при наличии чеков. Чек на $60 в день поездки проходит, если отмечена организация поездки и заполнена заметка. Чек на $60 в обычный день должен быть отклонён или отправлен на доработку. Гостиничный счёт $650 должен пройти через все три шага согласования.

Это цель: правило должно давать один и тот же результат каждый раз, когда кто‑то проверяет его на реальных примерах.

Частые ошибки, которые приводят к плохим результатам

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

Одна частая ошибка — сжимать несколько правил в один длинный абзац. Например: «Менеджеры утверждают поездки, если сумма не высокая, финансы проверяют чеки, а срочные запросы могут пропускать проверку». Это может выглядеть компактно, но скрывает несколько отдельных решений. Разделите это на отдельные правила, чтобы каждое действие имело свой триггер и результат.

Ещё одна проблема — расплывчатая лексика. Слова вроде нормальный, крупный, срочный или недавний работают только если их определили. Если «крупный расход» — это всё, что выше $2,000, скажите это. Если «срочный» значит нужно в течение 24 часов — укажите это условие.

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

Ошибки, которые чаще всего портят результат:

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

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

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

Это особенно важно при использовании чат‑базирующегося конструктора, где простая речь управляет поведением. Чёткие правила не должны звучать формально. Они должны быть конкретными, последовательными и полными.

Короткий чек‑лист перед сборкой

Перед тем как превратить требования в экраны, потоки или подсказки, сделайте последний обзор. Короткая проверка сейчас может сэкономить часы на исправлении странного поведения позже.

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

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

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

Смоделируйте полный путь утверждения. Для каждого порога укажите, кто утверждает и что происходит дальше. Будьте точны и на границах: правило начинается выше $500 или с $500 включительно?

Затем выполните тест «новичка». Дайте правило кому‑то, кто ранее не работал с ним, и попросите пересказать своими словами. Если человек требует дополнительного контекста, правило всё ещё слишком расплывчато.

Небольшой пример показывает, почему это важно. «Менеджер утверждает крупные расходы» звучит понятно, пока кто‑то не спросит, считается ли $500 крупным. «Менеджер утверждает расходы выше $500. Директор утверждает расходы выше $2,000. Расходы $500 и меньше автоодобряются» оставляет гораздо меньше пространства для ошибки.

Перенос правил в работающую систему

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

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

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

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

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

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

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

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