Technical Debt: как управлять техническим долгом

Technical Debt (технический долг) — компромиссы в коде и архитектуре, сделанные для ускорения delivery. Как и финансовый долг, он требует «выплат» — времени на исправление.

Почему PO должен понимать tech debt

1. Влияет на скорость — накопленный долг замедляет команду 2. Влияет на качество — больше багов, хуже UX 3. Нужно планировать — tech debt требует времени в roadmap

Виды технического долга

1. Преднамеренный — осознанно срезают углы для скорости 2. Непреднамеренный — из-за недостатка знаний, устаревания 3. Bit rot — зависимости устаревают, уязвимости появляются

Как приоритизировать tech debt

| | Высокий risk | Низкий risk | |---|---|---| | Частые изменения | Критично — делаем сейчас | Планируем | | Редкие изменения | Мониторим | Можно игнорировать |

Стратегии работы

1. 20% capacity — каждый спринт резервируем время 2. Debt-спринты — раз в квартал полностью на tech debt 3. Инкрементальный рефакторинг — правило бойскаута 4. Привязка к бизнес-задачам — рефакторинг когда нужен для фичи

Как коммуницировать стейкхолдерам

❌ «Нужно отрефакторить код» ✅ «Сейчас добавление способа оплаты занимает 3 недели. После рефакторинга — 3 дня»

Визуализация ключевых концепций

flowchart TD
    subgraph Виды["Виды tech debt"]
        INTEND["Преднамеренный"]
        UNINTEND["Непреднамеренный"]
        BITROT["Bit rot: устаревание"]
    end
    
    subgraph Приоритизация["Приоритизация"]
        HIGH_FREQ["High risk + Частые изменения → Сейчас"]
        HIGH_RARE["High ri...