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

Контекст

Нам нужно было выпустить интеграцию с платёжной системой к конкретной дате — маркетинг уже анонсировал фичу партнёрам. При этом наш первоначальный план предполагал полноценную абстракцию платёжного шлюза с поддержкой нескольких провайдеров, unit и integration тесты, и graceful degradation. На реализацию в полном объёме требовалось ещё три недели, которых не было.

Анализ компромисса

Я структурировал решение через явное разделение на «must have» и «nice to have»:

• Must have для релиза: рабочий payment flow для одного провайдера, базовая обработка ошибок, логирование транзакций, smoke-тесты критического пути.
• Можно отложить: абстракция под несколько провайдеров, полный regression suite, мониторинг всех edge cases.

Ключевой вопрос был не «срок vs качество», а «какое минимальное качество приемлемо для production». Это принципиально разные постановки.

Что сделали

Мы выпустили версию с одним провайдером, задокументировав технический долг в трёх конкретных тикетах с описанием рисков:

• Тикет 1: Добавить абстракцию PaymentGateway — риск: добавление второго провайдера потребует рефакторинга.
• Тикет 2: Расширить тест-сьют — риск: регрессии могут не поймать в CI.
• Тикет 3: Добавить circuit breaker — риск: при недоступности провайдера запросы будут висеть до таймаута.

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

Что я не сделал

Я не выпустил код без тестов критического пути. Компромисс с качеством имеет пределы: код, который нельзя проверить хотя бы на happy path, в production не идёт. Это не обсуждалось.

Результат

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

Подводные камни

• Отдавать в production код без хотя бы smoke-тестов под давлением дедлайна — это не компромисс, это авантюра.
• Не фиксировать технический долг письменно сразу — «потом разберёмся» превращается в «никогда».
• Не получить явного согласия от PM на план закрытия долга — без договорённости тикеты будут вечно выталкиваться следующими задачами.
• Называть «срезание углов» компромиссом — важно честно называть вещи своими именами внутри команды.
• Принимать решение в одиночку, не информируя команду о том, что и почему упрощается.
• Думать, что технический долг «не критичный» не накапливается — каждый такой тикет увеличивает когнитивную нагрузку на разработку.

• Говорить, что качество всегда важнее без бизнес-контекста.
• Срезать углы и не назвать последствия.
• Не зафиксировать долг и не вернуться к нему.

• Мыслит trade-off-ами.
• Умеет говорить с продуктом и менеджментом языком риска.
• Не прячет технический долг.