Расскажите о ситуации, когда вам пришлось сделать сложный trade-off на работе: какие были варианты, что вы рассматривали и почему вы выбрали именно тот путь, который в итоге выбрали?

На прошлом проекте (B2C-платформа для онлайн-бронирования) нужно было за две недели добавить поддержку рассрочки через партнёра. Клиент горит, срыв сроков — потеря контракта.

• Вариант А: встроить новый платёжный шлюз прямо в существующий монолит. Это самый быстрый путь — оценили в 8–10 дней, но код модуля оплаты уже был раздутым, с хардкодом и без тестов. Любое изменение там увеличивало технический долг.
• Вариант Б: вынести логику в отдельный микросервис. Чище архитектурно, тесты, независимый деплой. Но срок — минимум 3 недели: нужно поднимать инфраструктуру, настраивать CI/CD, писать новые интеграции.

Выбрали вариант А, потому что:

• заказчик не соглашался переносить релиз;
• команда из 4 человек могла уложиться только в «кровавый» вариант;
• мы чётко зафиксировали: сразу после сдачи начинаем рефакторинг модуля, выделяем на это 2 недели в следующем спринте.

Результат: рассрочку запустили на 12-й день (на 2 дня позже плана, но до дедлайна), контракт не потеряли. Через месяц переписали модуль оплаты — вынесли его в отдельный сервис, покрыли тестами. Спустя полгода оказалось, что партнёр меняет API каждые 2 месяца, и идёт это легче именно после рефакторинга. Главный урок: быстрый фикс — нормально, если он временный и у команды есть культура «убирать за собой». Без плана утилизации долга выбрал бы вариант Б.