Разработка в финтех: 7 кругов ада

Почему Данте был бы отличным IT-руководителем

Когда Данте описывал круги ада, он составил идеальную метафору для разработки в финтехе. Каждый круг — отдельный вид страдания, и пройти один не значит, что следующий будет проще. Разница в том, что Данте хотя бы знал маршрут. Большинство команд входят в банковскую разработку с оптимизмом стартапера и планом на три месяца.

Я прошёл все семь кругов несколько раз. Каждый раз выносил уроки, которых нет ни в одном Agile-манифесте. Это не жалоба и не пугалка — это карта местности, чтобы ты не шёл вслепую.

Круг первый: Найм

«Оставь надежду, всяк сюда входящий» — Данте, Ад, Песнь III

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

Согласование штатной единицы. Формирование требований через HR-систему. Публикация через корпоративный рекрутинг. Фильтрация резюме. Собеседования, которые нужно согласовать в календарях пяти человек. Оффер через юридическую проверку. Security check. Онбординг с получением доступов — сам по себе две-три недели.

В начале 2024-го мне нужен был Scala-разработчик с опытом Apache Flink. На российском рынке таких специалистов — буквально единицы. Первый подходящий кандидат появился через два месяца. Пока шли согласования оффера — он принял другой. Второй кандидат нашёлся ещё через месяц. К моменту, когда он сделал первый коммит, прошло четыре с половиной месяца. Проект к тому времени уже горел.

Итого: от осознания потребности до первого рабочего коммита — три-четыре месяца. А проект нужен был вчера.

Как выживать. Нанимай с опережением — и учись распознавать red flags. Если знаешь, что через квартал понадобятся ещё люди — начинай сейчас. Формируй кадровый резерв. Строй отношения с рекрутингом — они приоритизируют тех, с кем нормально работать. И главное — будь готов растить экспертизу внутри. На рынке нужного специалиста может просто не быть.

Круг второй: Бюрократия

«Здесь стонов слышно не было, лишь вздохи» — Данте, Ад, Песнь IV

Банк — регулируемая организация. ЦБ, аудиторы, служба безопасности. Каждое изменение в production — задокументировано, согласовано, одобрено. Не прихоть менеджмента — требование регулятора.

Простой деплой превращается в квест: RFC, согласование архитектурного комитета, оценка рисков от ИБ, подтверждение от бизнес-владельца, запись в change-календаре. Одно несогласованное звено — деплой не состоится.

Помню первый релиз нового сервиса. Код готов, тесты зелёные, API согласованы, команда на низком старте. Деплой назначен на четверг. В среду вечером ИБ вернула замечания по документации — формулировка в одном разделе не соответствовала внутреннему стандарту. Перенос на следующую неделю. Переписали раздел. В понедельник — новые замечания, уже от архитектурного комитета. Итого: от готового кода до прода — три недели бумажной работы.

Документация — отдельная боль. Технический проект, рабочий проект, руководство администратора, руководство пользователя, паспорт системы. На документацию уходит двадцать-тридцать процентов времени команды. Разработчики, которые пришли из стартапов, первый месяц думают, что это шутка.

Как выживать. Не борись с системой — используй. Автоматизируй генерацию документации. Создай шаблоны, которые закрывают восемьдесят процентов требований. Выстрой личные отношения с согласующими — когда человек знает тебя, процесс ускоряется кратно.

Круг третий: Меняющиеся требования

«Их гонит вечный ветер, не давая покоя» — Данте, Ад, Песнь V

Бизнес-заказчик приходит с идеей. Ты фиксируешь scope, оцениваешь сроки, планируешь ресурсы. Через две недели: «А мы подумали, и нужно ещё вот это». Через месяц — ещё раз. Через два — scope вырос вдвое, дедлайн прежний.

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

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

Как выживать. Контрактуй scope письменно и с подписью. Change request — не бюрократия, а инструмент прозрачности. Каждое изменение = пересмотр сроков и ресурсов. Бизнес имеет право менять требования, но должен понимать цену. И проектируй систему так, чтобы она переживала эти изменения — модульность не для красоты, а для выживания.

Круг четвёртый: Дефицит ресурсов

«Толкают тяжести, крича друг другу» — Данте, Ад, Песнь VII

Ты спроектировал систему, которая требует четырёх серверов с определёнными характеристиками. Подал заявку. Через месяц — два сервера с другими характеристиками. Через два — ещё один, но в другом дата-центре.

Реальная история: мы ждали серверы для нагрузочного тестирования три месяца. Когда получили — оказалось, что конфигурация не соответствует заявке. Оперативки вдвое меньше. Заявку на докомплектацию подали заново. Ещё месяц. В итоге нагрузочное тестирование проводили на железе, которое не соответствовало production-конфигурации. И баг в Tarantool, который мы нашли позже, вполне мог проявиться раньше — если бы инфраструктура была правильной.

Люди — ещё более дефицитный ресурс. Тебе нужен разработчик со знанием специфического стека, а на рынке таких единицы. DevOps-инженер, который знает корпоративный Kubernetes, загружен на трёх проектах одновременно.

Как выживать. Проектируй с учётом ограничений, а не в вакууме. Работающая система на двух серверах лучше идеальной архитектуры, которая никогда не получит нужное железо. Растите T-shaped людей внутри команды — когда каждый может подхватить смежную задачу, вы не парализованы отпуском одного человека.

Круг пятый: Конфликты

«Угрюмы были мы в сладости света» — Данте, Ад, Песнь VII

Над одним продуктом в крупном банке работают десятки людей из разных подразделений. У каждого свои KPI, приоритеты, понимание «правильного». Конфликты неизбежны.

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

Самый запоминающийся конфликт: смежная команда поменяла формат API без предупреждения. В пятницу вечером. Наш сервис начал складывать события в Dead Letter Queue — тысячами. Дежурный поднял тревогу, мы откатили их изменение, а в понедельник начался разбор. Оказалось, что у них был свой дедлайн, и «мы думали, вы уже перешли на новый формат». Никто не проверил. Никто не написал в чат. Урок: контракт между командами — это не документ в базе знаний, а живой процесс.

Как выживать. Конфликт — не проблема, а индикатор дисбаланса. Ищи win-win. Строй личные отношения с лидами смежных команд. Эскалируй, только когда всё остальное исчерпано. И заведи общий канал для breaking changes — серьёзно, это спасает.

Круг шестой: CI/CD в enterprise

«В открытых гробах, в пламени лежат» — Данте, Ад, Песнь IX

В стартапе — GitHub Actions за день, деплой по кнопке. В банке CI/CD — корпоративная платформа с регламентами, ограничениями и очередями.

Корпоративный CI/CD pipeline с кастомными плагинами. Docker-образы только из внутреннего registry. Зависимости только из корпоративного Nexus — и если там нет нужной версии библиотеки, ты не просто её добавляешь, а подаёшь заявку на включение в белый список. Доступ к prod — через отдельный pipeline с ручным одобрением.

Первый деплой нашего нового сервиса занял неделю. Не потому что код был плохой — потому что нужно настроить pipeline, получить доступы, зарегистрировать сервис в service mesh, настроить мониторинг и логирование по корпоративным стандартам. Второй сервис — три дня: мы уже знали маршрут. Третий — день. Кривая обучения крутая, но она есть.

Как выживать. Начинай настройку CI/CD в первый день проекта. Создай внутреннюю документацию по pipeline — для следующих сервисов процесс будет втрое быстрее. Автоматизируй линтеры, тесты, security-сканирование. И самое главное — подружись с командой, которая владеет платформой. Они знают обходные пути.

Круг седьмой: Поддержка

«Мы подошли к потоку красной крови» — Данте, Ад, Песнь XII

Прошёл шесть кругов, продукт на проде, заказчик доволен. Расслабиться? Нет. Теперь — самый длинный круг.

Инциденты в три часа ночи. Деградация из-за роста данных. Баги, которые проявляются только в определённых сценариях. Мелкие доработки, которые превращают стройную архитектуру в лоскутное одеяло.

Три часа ночи, алерт в PagerDuty. Latency скоринг-сервиса выросла в пять раз. Дежурный поднимается, смотрит дашборды — всё красное, причина неочевидна. Оказалось: одна из legacy-систем начала присылать события в изменённом формате после своего ночного релиза. Про который нас, разумеется, не предупредили. Десериализация не падала — она работала медленно, парсируя нестандартные поля. Тихая деградация — самый опасный вид.

И самое болезненное — отток людей. Команда, которая строила продукт, уходит на новые проекты. Новички не знают контекста, документация устарела, каждый инцидент — детективное расследование.

Как выживать. Закладывай поддержку в архитектуру с первого дня. Observability — не опция, а требование. Runbook на каждый алерт. Knowledge base, которая обновляется. Ротация дежурств, чтобы не было одного «хранителя знаний», без которого всё встаёт.

Карта выживания

Круг	Боль	Тактика выживания	Типичная цена
1. Найм	Найти нужного человека за разумное время	Нанимай с опережением, расти внутри	3-4 месяца на позицию
2. Бюрократия	Согласования убивают скорость	Шаблоны, автоматизация документации, личные связи	20-30% времени команды
3. Требования	Scope плывёт, дедлайн — нет	Change request, письменные контракты, модульность	Перепроектирование раз в квартал
4. Ресурсы	Нет серверов, нет людей	Проектируй под ограничения, T-shaped люди	Месяцы ожидания
5. Конфликты	KPI разных команд не совпадают	Win-win, личные отношения, общие каналы	Неделя на разбор инцидента
6. CI/CD	Корпоративная платформа — не GitHub	Документация, автоматизация, дружба с платформой	Неделя на первый деплой
7. Поддержка	Ночные инциденты, отток людей	Observability, runbooks, ротация дежурств	Бесконечность

Восьмой круг, про который Данте не написал

Данте остановился на девяти кругах. Он не знал про production deployment в пятницу вечером. Про change freeze перед новогодними праздниками, когда бизнес-заказчик «очень просит последнюю маленькую фичу». Про миграцию на новую версию Kubernetes в банковском контуре, когда у тебя нет admin-прав, а у тех, кто имеет — нет контекста про твой сервис.

Финтех — не для всех. Но если прошёл семь кругов и не сгорел — любой другой проект кажется отпуском. А карта, нарисованная чужими шрамами, экономит как минимум пару собственных.

Только не деплой в пятницу. Серьёзно. Даже если очень просят.

---

Оригинал статьи: Разработка в финтех или как пройти 7 кругов ада на Habr

Ваш ДПУПП