Cпособы оценки и планирования проектов, которые сложились в индустрии софтверной разработки для планирования: стори-поинты, футболки и числа Фибоначчи хороши для тактики (планирование на 2 недели вперед), но не подходят для стратегии (сколько денег готовить на проект длиной в квартал).

У программистов есть BigO-нотация для описания сложности алгоритмов. Обычно её используют, чтобы пообсуждать эффективность примененных алгоритмов для сферических задач в ваккууме. Там измеряют скорость исполнения и потребление памяти.

Что, если подобный подход переложить на наши прикладные инженерные задачи?
Здесь O(…) — не алгоритмическая сложность в строгом CS-смысле, а способ описать структуру роста инженерных усилий.

Например: подключение нового эквайринга в существующую систему продажи авиа-билетов.

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

1. Основные параметры:

• P — количество платёжных сценариев
  (payment, refund, partial refund, cancel, chargeback, webhook retry и т. д.)
• C — количество валют
• M — количество методов оплаты
  (cards, Apple Pay, Google Pay, local methods, installments)
• S — количество системных интеграций в нашей системе
  (billing, orders, tickets, ledger, AML, notifications, analytics)
• E — количество edge-cases (timeouts, double spend, idempotency, retries)
• R — количество регуляторных/комплаенс-ограничений

2. Попробуем записать инженерную сложность в виде O-нотации:

O(P × (S + C + M + E) + R)

Так как каждый платёжный сценарий (P) должен быть:

1. встроен во все системы (S)
2. проверен по валютам (C)
3. поддержан по методам оплаты (M)
4. защищён от edge-cases (E)
5. соответствует регуляторным/комплаенс требованиям (R)

Часто R = 0, но иногда это большая константа, например 3DS/SCA/PCI DSS

3. Минимальная граница сложности:

Невозможно подключить эквайринг не реализовав хотя бы:

• payment
• refund
• webhook handling

O(P) — абсолютный минимум

4. Структурная сложность

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

O(S + C + M + E)

Появляются:

1. новые конфиги
2. маппинги статусов (из внешних систем во внутренние)
3. таблицы комиссий
4. маршрутизация платежей
5. нужно предусмотреть ретраи в конфигах, идемпотентность в базе

Если всё сделано правильно:

• O(1) на транзакцию
• O(n) в логах и аудите

Почему это вообще важно?
Потому что это дает ответы на вопросы: сколько времени мы будем это делать? → Time / effort
И насколько это усложнит систему навсегда? → Space / state

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

4. Зависимость от текущей архитектуры

При плохой архитектуре трудозатраты могут зависеть от сочетаний параметров (например, сценариев × сервисов × валют), что увеличивает рост усилий:

O(P × S × C) (реально больно)

Например, если нет абстракции платежей, логика размазана по сервисам, эквайринг «вшивается» напрямую (скорее всего программисты воют об огромном техническом долге)

Каждый новый эквайринг в этом случае — это комбинаторный рост потенциальных конфликтов/интеракций между компонентами.

При хорошей архитектуре, наоборот

→ O(P) (кайф)

Если система изначально строилась для поддержки разных эквайрингов, имеется абстрактный платёжный адаптер или применяется strategy pattern, то добавление ещё одного эквайринга:

• O(P) по бизнес-логике
• O(1) по остальной системе

ПРИМЕНЕНИЕ НА ПРАКТИКЕ

Для бизнеса важны только ответы на два вопроса:

1. Сколько времени займет
2. Сколько будет стоить

Попробуем применить нашу формулу

O(P × (S + C + M + E) + R)

Где:
P — платёжные сценарии
S — системы интеграции
C — валюты
M — методы оплаты
E — edge-cases
R — регуляторные/комплаенс требования

Математическая функция O(…) показывает структуру сложности. Чтобы превратить её в сроки, нам нужно добавить весовые коэффициенты (сколько в среднем занимает одна интеграция).

В инженерной практике это превращается в аддитивную модель трудозатрат:

Total_days =
P × (
base_days
+ S × days_per_system
+ C × days_per_currency
+ M × days_per_method
+ E × days_per_edge_case
) + R × days_per_requirement

Функция O показывает как растёт, а коэффициенты — сколько стоит один шаг.

R-добавки для платежей это:
3DS / SCA → +5—10 дней
delayed capture → +3—5
split payments → +5—8
local compliance → +5—15

Считаем человеко-дни

P (payment scenaries): payment, refund, partial refund, webhook reconciliation = 4
S (systems): orders, tickets, billing / ledger, notifications, analytics = 5
C (currencies): EUR, USD = 2
M (methods): cards, Apple Pay = 2
E (edge cases): retry, timeout, idempotency, duplicate webhook, partial capture = 5
R (regulatory): SCA, Split payments = 2

Калькуляция трудозатрат:

1.Базовая реализация (P=4 сценария):

• Сами сценарии: 4 × 1.2 дня = 4.8 д.
• Интеграции (S=5): 4 × 5 × 0.8 дня = 16 д.
• Валюты (C=2): 4 × 2 × 0.5 дня = 4 д.
• Методы (M=2): 4 × 2 × 1.0 день = 8 д.
• Edge-cases (E=5): 4 × 5 × 0.3 дня = 6 д.

2.Регуляторика (R=2 требования):
-SCA + Split payments: 2 × 7.5 дней = 15 д.

Итого: 4.8 + 16 + 4 + 8 + 6 + 15 ≈ 54 человеко-дня

Итого получается
📌 ≈ 11 календарных недель одного инженера
📌 ≈ 6 недель для команды из 2—3 человек

Это только на разработку, но когда мы говорим про продакшен-решение нельзя забывать добавить QA и DevOps:

Итог 54 × 1.6 ≈ 86 человеко-дней до продакшена

Что реально уменьшает стоимость изменений в деньгах

Добавим коэффициент эффективности k (расширяемости) нашей архитектуры системы

T = k × P × (S + C + M + E)

Формула остается той же но коэффициенты падают в 2—3 раза.

Что именно снижает коэффициент (k)

1. Без абстракции (60—100 дней)

Почему k большой:

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

Каждое измерение — будь то системы (S) или валюты (C), методы (M) или edge-кейсы (E) → коэффициент растёт.

2. С адаптером (25—40 дней)

Что меняется:

• появляется интерфейс PaymentProvider
• маппинг статусов и ошибок локализован
• сценарии P переиспользуются

Что НЕ решено полностью:

• state machine может быть не единой
• идемпотентность иногда “дырявая”
• ledger/analytics всё ещё знают лишнее

коэффициент падает примерно в 2 раза.

3. Shared Payment Core (15—25 дней)

Это ключевой момент.

Что происходит архитектурно:

• есть одна state machine
• есть один источник истины
• все сервисы работают по событиям
• эквайринг — чистый адаптер

Фактически:

• S почти исчезает из формулы
• C и M становятся конфигурацией
• E решаются централизованно

формула по факту становится ближе к: T ≈ k × P, все зависимости по-прежнему существуют, но коэффициенты при них близки к нулю. Это и есть цель любой инженерной команды — сделать так, чтобы стоимость новой фичи зависела только от её бизнес-сути (P), а не от сопротивления старой системы

---

Итого: Что этот подход дает бизнесу и менеджменту

1. Математическое обоснование сроков. Вместо гадания на кофейной гуще мы получаем прозрачную формулу. Если задача занимает 80 дней — это не потому, что разработчики медленные, а потому что у нас S = 5 (много интеграций) и R=2 (сложная регуляторика).

2. Цена архитектуры становится осязаемой. Мы наконец-то можем в деньгах оценить стоимость «плохого кода». Плохая архитектура — это коэффициент k = 1.0, хорошая — k = 0.3. Инвестиции в платформу (Shared Core) снижают стоимость каждой следующей фичи в 3 раза.

3. Калькулятор вместо абстракций. Эту модель можно превратить в простой Excel-калькулятор. Менеджер может сам прикинуть: «Если мы добавим еще одну валюту (C), срок вырастет на X дней». Это переводит разговор в конструктивное русло.

4. Стратегия вместо тактики. Стори-поинты помогут закрыть спринт, а эта формула поможет спланировать бюджет на квартал и понять, потянем ли мы этот проект вообще.