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
2026

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

В 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
Sprint / execution

#16 ’26

10 августа — 23 августа
текущий спринт
capacity34 / 50 ч
fact26 ч
plans5
in work3
68%
EPIC-024Единый процесс согласования5 stories
ST-34Проверить сценарий на пилотной группе12 ч
WK-118Собрать обратную связьв работе
Epic / planning

EPIC-024

Единый процесс согласования
3 stories
#15 ’26#16 ’26#17 ’26#18 ’26
ST-31Согласовать правила
ST-34Проверить сценарий
ST-38Запустить пилот
Personal planning

2026

28 дней
июнь
12345678910111213141516171819202122232425262728
июль
12345678910111213141516171819202122232425262728
август
12345678910111213141516171819202122232425262728
Team availability

Команда

июль — сентябрь
июлавгсен
Сотрудник 01
Сотрудник 02
Сотрудник 03
Сотрудник 04

02 / ShopCRM

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

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

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

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

Обезличенный график сотрудников в ShopCRM
operations / employee schedule
Обезличенная аналитика выручки трёх розничных точек в ShopCRM
analytics / revenue
внутри команды

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

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

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

Точка 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–03.2 / decision policy

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

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

unstable signalSpamCopremoved

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

DNS timeout / defer
reliable signalSpamhauskept

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

ZEN → CSS / XBL / PBL / SBL

Внутренний аналитик, конечно, не принял ответ «Spamhaus сработал». Ему понадобилось знать, что именно ответило — CSS, XBL, PBL или SBL — и как часто.

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

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

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

beforeREJECTписьмо не принятонеобратимо
nowCLASSIFYСпамможно вернуть
score < 5.0 → Inboxscore ≥ 5.0 → X-Spam-* → Dovecot / Sieve → Спам[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

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

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 Spam
independent evidenceSUCCESS
«Доставлено» — это результат.
Мне интереснее понимать, почему.

Lab / ending

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

Работа с банковскими продуктами и без того достаточно серьёзна. Поэтому я посчитал необходимым добавить в Task Manager Оракула.

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