Объяснение бизнес-логики разработчику — это перевод «мы хотим больше денег и меньше боли» в конкретные сценарии, правила и ограничения, лучше всего через визуализацию бизнес-логики (диаграммы/таблицы) и сторителлинг для разработчика (истории пользователей с цифрами и последствиями).

Проблема обычно не в том, что разработчик «не понимает бизнес». Проблема в том, что бизнес говорит в терминах целей, а разработка живёт в терминах состояний системы, данных и исключений. Если вы скажете: «сделайте, чтобы клиенту было удобно» — вы получите пять вариантов удобства и один баг в проде. Если скажете: «клиент оформляет доставку за 90 секунд, иначе конверсия падает на 12%» — разговор станет внезапно взрослым.

Из практики управления IT-проектами: 70% конфликтов «бизнес–разработка» — это не про навыки, а про недостаток артефактов. Не зафиксировали правила — получили спор в чате. Не нарисовали поток — получили “мы так не договаривались”. И да, в России это особенно весело: 1С-учёт живёт своей жизнью, Битрикс — своей, а между ними «интеграция на честном слове и вебхуках».

Почему разработчику сложно «схватить» бизнес-логику

Тезис: бизнес описывает намерение, а разработка должна реализовать механизм

Обоснование: в вакансиях на Junior/Middle (backend, аналитик, product) регулярно встречается требование «умение формализовать требования», «User Story», «BPMN/UML», «SQL». Это не мода, а реакция рынка на стоимость ошибки: баг в расчёте цены или статуса заказа чаще бьёт по деньгам, чем баг в цвете кнопки.

Практический вывод: объяснение бизнес-логики нужно собирать в три слоя: цель → сценарии → правила/данные.

Подводный камень: пытаться объяснить всё «словами в Telegram». Текст без структуры превращается в фанфик, а не в требования.

Пошаговая схема: визуализация бизнес-логики + сторителлинг для разработчика

Шаг 1. Назовите бизнес-цель в измеримых единицах

Формула: метрика + целевое значение + срок + ограничение.

• «Увеличить долю оплат онлайн с 35% до 50% за 3 месяца, не ухудшив скорость оформления (≤90 секунд)».
• «Снизить возвраты по причине ‘не тот размер’ на 15% за квартал».

Вывод: если нет метрики — разработчик будет оптимизировать то, что проще измерить (обычно “закрыть задачу”).

Подводный камень: цель уровня «сделать удобнее». Это не цель, это пожелание вселенной.

Шаг 2. Опишите историю (story) в формате «персона → мотивация → препятствие → исход»

Это и есть сторителлинг для разработчика, только без театра. Пример:

Персона: Ольга, 34, покупает с телефона, оплачивает картой. Мотивация: оформить быстро, пока ребёнок не передумал. Препятствие: адрес не подтягивается, доставка пропадает, статус заказа непонятен. Исход: уходит в маркетплейс.

Вывод: история фиксирует контекст, который теряется в «сделайте эндпоинт».

Подводный камень: описывать «идеального пользователя» без исключений. А исключения — это и есть бизнес-логика.

Шаг 3. Превратите историю в сценарии: Happy Path + 3–7 “веток боли”

1. Happy Path: выбрал товар → добавил в корзину → выбрал доставку → оплатил → получил чек → видит статус.
2. Ветка 1: оплата не прошла → заказ в каком статусе? резервируем товар или нет?
3. Ветка 2: нет доставки по адресу → что предлагаем вместо? ПВЗ? самовывоз?
4. Ветка 3: промокод частично применим → как объясняем и что логируем?

Вывод: сценарии — это мост между «хотим» и «что кодить».

Подводный камень: забыть про статусы. Статусы (state machine) — скелет любой бизнес-логики заказа, оплаты, доставки, подписки.

Шаг 4. Нарисуйте поток: BPMN/блок-схема на 1 экран

Визуализация бизнес-логики должна быть читабельной. Один экран — потому что иначе это уже не диаграмма, а новое Евангелие. Минимальный набор нотаций:

• Кто действует: Клиент / Сайт / Платёжный шлюз / 1С / Служба доставки.
• События: «оплата успешна», «таймаут», «возврат».
• Решения: «доставка доступна?» «товар в резерве?»

Вывод: диаграмма быстро выявляет «дырки»: кто инициирует возврат? где источник истины статуса?

Подводный камень: рисовать как красиво, а не как по делу. Разработчикам нужна логика переходов, а не арт-объект.

Шаг 5. Зафиксируйте правила в таблицах (да, это скучно — зато работает)

Вывод: таблица превращает «политики компании» в реализуемые условия, тест-кейсы и логи.

Подводный камень: не прописать “что считаем источником истины” (например, статус оплаты в платёжке важнее статуса в нашей БД).

Шаг 6. Привяжите бизнес-логику к данным: сущности, поля, источники

Минимум: список сущностей и 5–10 ключевых полей.

• Order: id, status, total_amount, delivery_type, created_at
• Payment: status, provider_id, paid_at, fail_reason
• Customer: phone, consent_marketing

Вывод: на этом шаге разработчик уже видит API/таблицы/события и может оценить трудозатраты.

Подводный камень: скрытые интеграции: «а ещё нужно, чтобы оно улетало в 1С/МойСклад/Битрикс24». Это отдельная работа, а не “проводочек”.

Шаг 7. Согласуйте критерии готовности: DoD, тесты, метрики, мониторинг

Definition of Done (DoD) — «определение готовности»: что должно быть, чтобы задача считалась завершённой.

• Автотесты на правила промокодов и статусы заказа.
• Логи причин отказов/откатов.
• Дашборд: конверсия оплаты, доля ошибок, среднее время оформления.

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

Подводный камень: «готово = на стенде у разработчика». Готово — когда измеряется и не ломается от реальности.

Два кейса из жизни (один удачный, один поучительный)

Кейс 1: “Нарисовали статусы — перестали ругаться”

Интернет-магазин на Bitrix, учёт в 1С. Вечная проблема: «заказ оплачен, но отменён» и наоборот. Мы сделали один артефакт: таблицу статусов и диаграмму переходов (кто может менять статус и при каком событии). После этого разработчики за 2 спринта внедрили единый “state machine”, а поддержка перестала вручную «чинить заказы». Бизнес-эффект мерили просто: упало число обращений по статусам и возвратов из-за ошибок в отмене.

Кейс 2: “Объяснили словами — получили сюрпризы в проде”

Сервис доставки: попросили «добавить скидку для постоянных». Без правил, без таблицы исключений. В проде скидка начала применяться к корпоративным клиентам, где цены договорные. Минус деньги, плюс паника, плюс срочный хотфикс ночью. Цена ошибки тут — не “ой”, а выпадающая маржа и репутация. Виноватых найти можно, полезно — переписать бизнес-логику нормально.

Коммерческие факторы: сколько стоит “нормально описать бизнес-логику”

Если вы учитесь или растёте в IT, важно понимать экономику. Формализация требований — это не «бумажки», а время команды:

Если хотите больше таких разборов (без инфоцыганщины и с нормальной инженерной логикой), они собраны на https://itokno.ru — там удобно смотреть похожие материалы и чек-листы.

Экспертный вердикт и инструмент: чек-лист “объяснение бизнес-логики без магии”

• 1. Я назвал метрику и целевое значение? (не “улучшить”, а “с 35% до 50%”).
• 2. У меня есть 1 история пользователя и 3–7 веток исключений?
• 3. Я показал статусы и переходы (кто и когда меняет)?
• 4. Бизнес-правила записаны таблицей: условие → действие → логирование?
• 5. Я указал источники данных (1С/CRM/платёжка) и “истину” для каждого статуса?
• 6. Есть критерии приёмки и что будем мониторить после релиза?

Частые вопросы