Не всякая неидеальность — техдолг

"Некрасивая" архитектура — еще не техдолг
"Некрасивая" архитектура, из-за которой разработка простой фичи требует изменений в 20 сервисах — уже техдолг

Потому что техдолг — это набор технических решений, которые снижают скорость и/или снижают качество и/или повышают стоимость разработки, что приводит к негативным последствиям для целей бизнеса

Из этого определения следуют два простых и важных умозаключения:

1. Бизнес и разработка должны быть "на одной стороне"

Часто может возникать ситуация, что бизнес отказывается давать ресурсы на технические задачи, так как всегда есть более приоритетные фичи. Здесь важно объяснить, что техдолг делается именно для них в долгосрочной перспективе:

- запутанная архитектура, в которую сложно добавлять новые фичи => высокий TTM

- много багов => расходы на поддержку

- сервис нестабилен и регулярно падает => пользователь может просто уйти к конкурентам

2. Продуктовые и технические задачи должны приоритезироваться вместе

Это следствие из первого пункта. Если продуктовые фичи скорее про "как заработать денег", то техдолг про "как не потерять деньги". И эти вещи должны скориться вместе друг с другом, чтобы можно было сопоставить, что важнее, и какие риски мы можем принять

---

Важный момент (про который часто забывают), чтобы такая схема работала — исправление критичного техдолга должно оцениваться по важности на уровне с продуктовыми фичами на perfomance review. Без этого логично, что у разработчиков не будет никакой мотивации заниматься техдолгом