Зачем нужен этот раздел?

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

Без этого знания требования выглядят как набор полей и формул. С контекстом за ними видны сделка, риск, управленческое решение и последствия ошибки.

Цель раздела — дать язык для разговора с бизнесом и основу для самостоятельного онбординга нового продукта в Risk Control System.

Чем продукт-инженер отличается от участника классической delivery-команды?

В классической модели Product Owner, аналитик, разработчик, тестировщик и SRE отвечают за разные участки. Delivery возникает только после прохождения всей цепочки handoff’ов.

Product Engineer отвечает за результат целиком. Поэтому в разных ситуациях он задаёт себе вопросы разных специалистов: бизнеса, аналитика, разработчика, QA и SRE.


  Две модели организации delivery
  В классической модели delivery проходит через цепочку отдельных ролей. Product Engineer объединяет ответственность за весь путь до результата.
  
    
  

  
  КЛАССИЧЕСКАЯ МОДЕЛЬ
  ownership разделён между ролями

  
  Product Owner
  
  Аналитик
  
  Разработчик
  
  Тестировщик
  
  SRE
  
  handoff за handoff’ом
  
  DELIVERY

  
  PRODUCT ENGINEER
  end-to-end ownership результата

  
  Бизнес / PO
  
  Аналитик
  
  Backend
  
  QA
  
  SRE
  
  PRODUCTENGINEER
  
  переключает роль и удерживает общий контекст
  
  
  DELIVERY

Главное различие — End-to-end Ownership, то есть ответственность за работающий результат целиком. Product Engineer не обязан заменить всех специалистов. Но он должен понимать их вопросы и вовремя менять точку зрения.

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

Поэтому дальше мы сначала разбираем, как думает реальный специалист банка: Sales, трейдер, Quant, риск-офицер или сотрудник Back Office. Product Engineer подстраивается под эту логику и переводит её в работающую систему.

LLM упрощает технические действия, но не заменяет понимание предметной области. Главный сдвиг — от «реализовать требование» к «решить продуктовую задачу и отвечать за результат».

Как устроены пререквизиты?

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

  1. Клиент, банк и контракт.
  2. Цена сделки.
  3. Риск сделки.
  4. Подразделения и системы банка.

После них общая модель применяется к FX Swap: его Legs, Cash Flows, Lifecycle, Exposures, методологиям и лимитам.