Техдолг: как измерять и когда за него платить

Техдолг редко выглядит как отдельная задача: чаще он проявляется в лишних днях на релиз, повторяющихся инцидентах и правках, которые опасно делать без автора старого кода. Если считать только TODO или строки «плохого» кода, можно потратить спринт на косметику и не затронуть главную причину задержек. Практичный подход — оценивать долг по его последствиям, стоимости исправления и вероятности, что он снова помешает работе.

Сначала отделите долг от просто старого кода

Техдолг — это цена выбора: команда упрощает решение сейчас, а затем несёт дополнительные затраты из-за этого упрощения. Иногда это сознательный обмен скорости на качество. Иногда долг возникает случайно — например, когда модуль перестаёт соответствовать новым требованиям, но его продолжают расширять.

Возраст компонента сам по себе не делает его долгом. Старая, стабильная часть системы, которую редко меняют, может обходиться дешевле новой, но хрупкой интеграции, которую правят каждую неделю. Для планирования важен не вопрос «насколько код некрасивый», а «какую работу он регулярно тормозит или делает рискованнее».

Долг стоит измерять не количеством неприятного кода, а ценой, которую команда уже платит за него.

Стоимость переноса — усилия, которые требуются, чтобы устранить конкретное ограничение: например, заменить общий модуль, добавить тесты или изменить границу между сервисами. Это оценка объёма работы, а не обещание точного срока.

Четыре способа увидеть цену техдолга

1. Считать задержки в изменениях

Для компонента или типа задач фиксируйте время от начала работы до готового изменения и ищите повторяющиеся причины задержек: ручные проверки, долгое согласование, необходимость менять несколько несвязанных модулей. Время цикла полезно сравнивать с историей той же команды и похожими задачами. Сравнение разных команд без поправки на размер изменений мало что говорит.

Цена подхода — нужна дисциплина в описании причин. Метрика сама по себе не скажет, вызвала ли задержку архитектура, ожидание ревью или внешняя зависимость. Добавьте короткую причину блокировки, а не пытайтесь объявить любую долгую задачу техдолгом.

2. Смотреть на повторную работу и инциденты

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

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

3. Оценивать частоту изменений вместе с трудностью

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

Плюс — такой разбор помогает быстро выбрать кандидатов для исследования. Минус — оценки субъективны. Не используйте их как KPI отдельных разработчиков и не сравнивайте команды по сумме баллов.

4. Сопоставлять стоимость исправления с ожидаемыми потерями

Сформулируйте два сценария: сколько усилий займёт исправление сейчас и какие затраты вероятны, если оставить всё как есть. В ожидаемые потери можно включить повторную работу, задержку релиза, время поддержки и риск простоя. Если данных мало, укажите диапазон и предположения, а не рисуйте точную сумму.

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

Когда платить за исправление

Не ждите, пока долг станет «большим»: это слово редко помогает выбрать задачу. Платить стоит, когда есть подтверждённая связь с работой продукта и стоимость бездействия повторяется или может стать критичной. Например, изменение регулярно занимает больше времени из-за одного ограничения или сбои в важном сценарии трудно локализовать именно из-за устройства компонента.

Практический отбор можно провести так:

1. Опишите ограничение. Не «переписать модуль», а «изменение тарифов требует правок в четырёх местах и ручной проверки каждой связки».
2. Соберите подтверждения. Укажите связанные задачи, инциденты или повторные проверки. Если подтверждений нет, сначала наблюдайте, а не обещайте выгоду от переписывания.
3. Оцените исправление. Назовите диапазон усилий и зависимости: миграция, обратная совместимость, дополнительное тестирование.
4. Сравните сценарии. Сопоставьте работу сейчас с вероятными потерями на выбранном горизонте. Запишите допущения, чтобы пересмотреть их позже.
5. Начните с ограниченного шага. Исправьте участок, который можно проверить отдельно, и сравните результат с исходной проблемой.

При выборе используйте простой критерий. Если участок часто меняется, регулярно создаёт задержки и исправление можно проверить небольшим объёмом — планируйте его рядом с продуктовой работой. Если проблема редкая и нет заметного риска, зафиксируйте наблюдение и вернитесь к нему при следующем изменении. Если речь о безопасности, потере данных или доступности критичного сервиса, не сводите решение к окупаемости в часах: действуют отдельные требования к риску и надёжности.

Что ломается в измерении

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

• Одна общая оценка долга. Сумма условных баллов скрывает, где именно возникает цена. Держите рядом описание проблемы и источник данных.
• Переписывание без проверки гипотезы. Новый дизайн может оказаться сложнее старого. Сначала сформулируйте, какое ограничение исчезнет и как это проверить.
• Сравнение несопоставимых периодов. Изменение команды, продукта или потока релизов меняет метрики. Фиксируйте контекст и сравнивайте похожие типы работы.
• Игнорирование цены миграции. Рефакторинг может временно увеличить риск и замедлить выпуск. Учитывайте тесты, перенос данных, совместимость и откат.

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

Что делать дальше

Выберите один компонент, который часто меняется или регулярно создаёт повторную работу. Зафиксируйте исходную картину: тип задач, время цикла, блокировки и связанные дефекты. Сформулируйте одно проверяемое ограничение, оцените небольшой способ его устранить и после изменения сравните наблюдения на сопоставимых задачах. Инвалидация кэша, выбор архитектуры и конкретные техники рефакторинга — отдельные темы; здесь важен способ решить, за какой долг платить первым.