ivan@terentev.one

Product · Systems · Fintech

Делаю сложное
простым.

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

2:38−20% manualPL/SQL → SMTP
2:38

Если банк уже знает человека,
зачем знакомиться с ним ещё раз?

Клиент уже обслуживался в банке как физическое лицо: банк его идентифицировал и располагал необходимыми данными. Но открытие счёта для бизнеса снова вело его через встречу и повторную идентификацию.

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

От старта процесса до открытого корпоративного счёта — 2 минуты 38 секунд.

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

Распознанные данные паспорта требовали ручной обработки даже там, где OCR и логические проверки не находили проблем. Я пересобрал правила вместе с командой: если документ распознан корректно, проверки пройдены, а менеджер подтвердил данные без изменений — заявка продолжает автоматический маршрут.

OCRраспознавание
logical checksлогические проверки
data unchangedданные не менялись
confirmedменеджер подтвердил данные без изменений
automatic openingдополнительный контроль операционного департамента не требуется
счёт продолжает автоматический маршрут

−20% ручных заявок
и больше автоматических открытий при сохранении контроля качества данных и требований безопасности.

DWH + production data Oracle / PL/SQL report SMTP Inbox email / MVP notificationsтот же подход, новый процесс

Не всякая проблема
требует новой системы.

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

Я написал PL/SQL-процедуру в Oracle: по расписанию она собирала данные из DWH и production-баз, формировала отчёт и отправляла его через SMTP.

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

PL/SQL → SMTP

Иногда продукт заканчивается
не на интерфейсе.

Старт Бизнеса Онлайн — эксперимент ФНС и банков-партнёров. Клиент мог дистанционно пройти путь от физического лица до зарегистрированного бизнеса со счётом в банке: идентификация через ЕСИА и ЕБС, регистрация бизнеса, выпуск УКЭП и передача заявки в выбранный банк.

В короткие сроки я реализовал вместе с командой необходимые интеграции, получение заявок из ФНС после регистрации и банковский процесс открытия счёта.

ФНСtrust boundaryБАНК
ЕСИА + ЕБС регистрация
бизнеса УКЭП заявка
в банк открытие
счёта

ГОСТ-сертификаты / передача и обработка персональных данных

В интеграции я столкнулся с разными подходами к криптографической защите: ФНС предлагала один вариант шифрования, а требования безопасности банка — другой. Нужно было согласовать взаимодействие систем и применение ГОСТ-сертификатов.

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

2010 / Icecast 2

Мне всегда было интересно,
как всё это работает.

В 2010-м мне захотелось запустить своё онлайн-радио. Вместо изучения Linux по учебнику я нашёл мануал по Icecast 2 и начал пробовать. Что-то работало. Что-то ломалось. Тогда приходилось разбираться глубже.

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

Lab / professional identity

product first / technical by nature

Я не стал разработчиком.
Но привычка понимать технологию руками осталась.

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

01 / Task manager

Между Excel и Jira
оказалось свободное место.

Методологам, аналитикам и проектным менеджерам нужно было управлять общей работой, а руководителям — прозрачно следить за выполнением KPI. Jira для non-IT команды оказалась избыточной и сложной, а Excel не давал единого процесса. Я предложил собрать собственный портал под реальный способ работы команды.

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

Laravel 13 / PWA / WebSockets
инициативы и эпики
спринты
команда и отсутствия
отчётность

02 / ShopCRM

Началось с зарплаты и графиков.
Потом стало интереснее.

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

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

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

внутри команды

Внутренняя
операционная система

графикизарплатапоставкивыручкаостатки
единые данные

Один каталог.
Три магазина.

Точка 01в наличии
Точка 022 шт.
Точка 03ожидается
клиентский продукт

Выбрать по пути.
Получить на кассе.

  1. единый каталог
  2. заказ по пути
  3. получение на кассе
лояльностьистория покупокпредпочтенияпривычные товары в наличии

03 / Mail Security Center

Всё началось
с 500 спам-писем.

В один прекрасный день я проснулся и увидел в почтовом ящике 500+ спам-писем.

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

Вместо абстрактной схемы я разобрал production-конфигурацию Exim 4.95 + SpamAssassin + Dovecot/Sieve и начал смотреть, что действительно происходит на каждом этапе.

500 spam emailssignalsclassificationexplainable journey

03.1 / signals

Не каждый сигнал
одинаково надёжен.

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

unstable signalSpamCopremoved

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

DNS timeout / defer
reliable signalSpamhauskept

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

ZEN → CSS / XBL / PBL / SBL

technical layer · Relay Policy → DNSBL → Recipient Verify · source templates: Exim / ISPmanager

03.2 / classification

Классификатор может ошибиться.
Ошибка не должна быть необратимой.

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

beforeREJECTписьмо уничтоженонеобратимо
nowCLASSIFYJunkможно вернуть
score < 5.0 → Inboxscore ≥ 5.0 → X-Spam-* → Dovecot / Sieve → Junk[SPAM 8.4] Исходная тема

03.3 / explainable journey

Лог постепенно превратился
в объяснимый путь письма.

Сначала это была страница с отдельными событиями. Но один лог не отвечал на главный вопрос: что происходило с конкретным письмом и почему система приняла именно такое решение. Так появился Mail Security Center.

Основная сущность — Journey, а не отдельная запись в логе.

  1. 01Письмо принятоExim ACL / Relay Policy
  2. 02Сигналы провереныSender Verify / Spamhaus
  3. 03Риск классифицированSpamAssassin / score + rules
  4. 04Доставка подтвержденаDovecot / Sieve / Maildir
human explanation / primary

Письмо отмечено как нежелательное: несколько признаков увеличили оценку риска, но само письмо сохранено в Junk.

score 8.4 · matched rules · identifiers

Независимые свидетельства

Источники не подменяют друг друга: итог строится из нескольких подтверждений.

Exim mainloglocal_delivery / completed
Message-ID correlationmessage matched across stages
SpamAssassin reportscore 8.4 / rules explained
Maildirmessage found in Inbox
independent evidenceSUCCESS
«Доставлено» — это результат.
Мне интереснее понимать, почему.

Lab / ending

Не всё, что интересно сделать,
обязано решать проблему.