Комментарии 1
Ваше определение технического долга слишком специфичное для вас. Общее по отрасли определение - это то, что надо было сделать к конкретному моменту (назовём "сейчас") - и чем-то мешает сейчас или точно будет мешать очень скоро, но не сделано. Не обязательно это ошибка или неоптимальность, часто это отсталая архитектура или другие проблемные проектные решения (могли быть лучшими на момент, когда делали, но не сейчас). Будет ли вам где-то влиять потребление ресурсов или время выполнения процедур, или что-то ещё похожее - уже следствие, а не суть.
Конкретика решений - тут самое главное вот это:
30% от месячного времени команд отводилось на задачи технического долга.
Вот это категорически ценно и надо продвигать, потому что слишком часто вижу, что выделяется фактически ноль. После нескольких лет развития продукт превращается в неподдерживаемое... нечто. Вымолить даже 5% нереально, добиваются обманом. 30% - это фантастический результат, завидую. Интересно, сколько продержитесь.
Как «приручить» технический долг: от накопления к решению