Как вы выявляете, расставляете приоритеты и погашаете технический долг?

Question

Accepted Answer

**Технический долг** — это разница между тем, как написан код, и тем, как он должен быть, взятая на себя (намеренно или нет) для ускорения работы. Некоторое количество долга — это нормально; задача в том, чтобы управлять им, а не избавиться от него полностью. Ключ — расставлять приоритеты для долга, который действительно *вредит*.

## Расставляйте приоритеты по влиянию, а не по раздражению

```text
For each piece of debt, ask:
  - How often does it slow us down or cause bugs? (frequency)
  - How bad is it when it bites? (severity)
  - How risky/expensive is it to fix? (cost)

High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
```

## Конкретный пример

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

## Как профинансировать работу

Чистые "спринты по долгу" редко одобряют. Лучшие тактики:

```text
✓ Budget ~10-20% of each sprint for debt continuously
✓ Pay debt down inside related feature work ("boy scout rule")
✓ Tie debt to business pain: "this is why feature X took 3 weeks"
```

## Почему это важно

Неконтролируемый долг накапливается: производительность тихо падает, пока команда с трудом может выпускать релизы.

Но погоня за каждым несовершенством тратит время на долг, который не имеет значения.

Ценность технического лидера в том, чтобы знать разницу и убеждать руководство в *бизнес*-терминах, а не только в инженерных.