Как балансировать tech debt и фичи?

Что хотят услышать интервьюеры:

Баланс строится не как выбор между «делать фичи» или «чинить долг», а как управление риском и скоростью команды. Важен системный подход: измерять влияние долга на delivery, откладывать только осознанно и регулярно выделять емкость на его погашение. Хороший ответ показывает, что приоритизация делается через бизнес-эффект, технический риск и стоимость задержки, а не по ощущениям.

Определение:

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

Пример использования:

Допустим, команда видит, что интеграция платежей занимает вдвое больше времени из-за устаревшего слоя API. Вместо того чтобы полностью остановить roadmap, команда выделяет часть спринтов на рефакторинг критического слоя, а остальное время оставляет под новые фичи.

Сплит емкости команды на квартал:
- 70%: фичи с прямым бизнес-эффектом
- 20%: tech debt в критическом пути платежей
- 10%: непредвиденные баги и инциденты

Правило пересмотра:
- если время поставки фичи выросло на 30%+ из-за долга, долю на debt увеличивают
- если debt не мешает delivery и риск низкий, его откладывают

Пояснение кода:

Код не требуется, потому что здесь речь о продуктовой и управленческой приоритизации. Пример выше можно разложить так: сначала оценивается, насколько долг тормозит команду и где есть риск для бизнеса; затем определяется доля capacity на его погашение; после этого решение пересматривается на регулярной основе по метрикам скорости, качества и стоимости изменений.

Ключевые моменты:

• Балансировать tech debt и фичи нужно через бизнес-ценность, риск и влияние на скорость поставки.
• Не весь debt одинаково важен: в приоритете то, что ломает delivery, качество или пользовательский опыт.
• Полезно заранее фиксировать процент capacity на debt, но оставлять место для пересмотра по данным.
• Технический долг стоит гасить не «когда будет время», а когда его стоимость начинает превышать стоимость откладывания.
• Для сильного ответа важно показать, что решение принимается совместно с engineering: PM задает рамки, а команда оценивает impact и effort.
• Хороший баланс — это не максимизация фич, а устойчивый темп поставки без деградации системы.