Как оценить технический долг до того, как он остановит развитие

Что считать долгом, а что оставить другой задачей

Баг — несоответствие ожидаемому поведению сейчас. Maintenance — плановое обновление, которое не обязательно возникло из прежнего компромисса. Feature добавляет новую ценность. Technical debt item описывает решение или состояние, которое упростило прошлое действие либо сформировалось без достаточного понимания и теперь увеличивает будущую цену изменений, риск или operational burden. Граница не всегда объективна, поэтому важнее не ярлык, а consequences и выбранное управление.

Запись «плохая архитектура» бесполезна. Запись «изменение правила скидки требует правки в четырёх сервисах, два последних релиза дали расхождение расчёта, владелец — команда заказов» проверяема. Она содержит область, symptom и evidence. Аналогично «нет тестов» слишком широко; «модуль импорта не имеет contract tests, поэтому три последних изменения проверялись вручную по шесть часов» превращает мнение в наблюдение. Не выдумывайте часы: используйте task log или пометьте значение непроверенным.

Карта симптомов и шкала приоритета

Сначала собирайте симптомы из четырёх потоков: доставка изменений, надёжность, операционный toil и безопасность/сопровождение. Каждый сигнал прикрепляйте к конкретному item. DORA metric или scanner result не является долгом сам по себе; он помогает найти область для исследования. Один item может проявляться несколькими симптомами, а один симптом иметь несколько причин. До подтверждения связи снижайте confidence.

Шкала triage от 0 до 18

Оцените пять факторов. Влияние на пользователя или обязательство: от нуля до пяти. Частота наблюдаемого симптома: от нуля до четыре. Распространение — сколько критичных маршрутов и команд затронуто: от нуля до четыре. Срочность, например end-of-support или уже исчерпанный error budget: от нуля до три. Уверенность в причинной связи: ноль, один или два. Сумма даёт максимум восемнадцать. Это порядок для обсуждения, а не денежная величина и не разрешение переписывать систему.

Не складывайте effort в impact score: высокий ущерб не становится низким из-за дорогого исправления. После triage отдельно оцените размер, implementation risk и confidence. Затем сравните варианты eliminate, reduce, mitigate, accept и observe. Иногда feature flag или isolation быстро ограничивает распространение; иногда безопаснее заменить зависимость постепенно; иногда item осознанно принимают до даты, когда появится нужное изменение.

Карточка debt item

• ID и короткое название без решения в формулировке.

• Контекст первоначального решения и причина, если она известна.

• Наблюдаемый symptom, пользовательское или бизнес-последствие.

• Evidence: trace, delivery data, incident, toil log, dependency path или audit.

• Область распространения и затронутые owners.

• Варианты eliminate, reduce, mitigate, accept и observe.

• Оценка факторов, effort range, confidence и дата review.

• Критерий завершения: какая метрика или проверка должна измениться.

Не требуйте от команды ретроспективно придумать мотив. Если контекст решения неизвестен, так и запишите. Модель Fowler помогает различать prudent/reckless и deliberate/inadvertent, но не выдаёт автоматический приоритет. Осознанный компромисс с датой погашения может быть рациональным; аккуратный код, который больше не соответствует продуктовой архитектуре, тоже создаёт friction. Фокусируйтесь на сегодняшнем consequence.

Три примера оценки

1. Ручной production release

Каждый release требует повторяющихся команд и проверки одного человека. За квартал несколько изменений откладывались из-за его недоступности, а один postmortem связал ошибку конфигурации с ручным шагом. Item получает evidence из toil log и incident. Возможные действия: автоматизировать идемпотентный этап, добавить validation и сохранить approval отдельно. Критерий — снижение ручного времени и отсутствие данного класса ошибки в контролируемом периоде, а не число написанных pipeline-файлов.

2. Общий модуль расчётов

Три команды меняют общий модуль, и небольшая правка запускает длинный regression cycle. Однако incidents нет, а ближайшие roadmap-задачи эту область не затрагивают. Распространение высокое, срочность низкая. Вместо rewrite можно сначала добавить characterization tests и отделить один изменяемый contract при следующей feature. Если позже появится серия изменений, item пересчитывается. Так portfolio не превращается в список архитектурных предпочтений.

3. Заблокированное security-обновление

Критическая зависимость находится на неподдерживаемой версии из-за собственной модификации. Scanner обнаружил advisory, но приоритет определяется не названием severity: нужно подтвердить dependency path, exposure, доступное исправление и срок поддержки. Mitigation может ограничить вход или выключить функцию до upgrade. NIST SSDF полезен для ownership, components и vulnerability response. Если решение требует migration, его этапы и rollback становятся частью debt item.

Какие метрики использовать и как не злоупотреблять

DORA metrics описывают delivery outcomes: throughput и instability. Они помогают увидеть изменение value stream, но не измеряют долг напрямую и не предназначены для наказания отдельных разработчиков. SPACE напоминает, что productivity многомерна: activity без satisfaction, quality, communication и efficiency создаёт искажённую картину. Если команда закрыла больше тикетов, но тратит больше времени на interrupts, итог может быть хуже.

Toil фиксируйте через минуты или часы, частоту, interrupts и возможность автоматизации. Перед автоматизацией сравните стоимость работы с потенциально сэкономленным временем и риском. Для reliability определите user-facing signals: latency, errors, traffic и saturation в контексте своего сервиса. Error budget policy может переключать приоритет на reliability, но не копируйте thresholds Google. Сформулируйте собственный SLO и правила заранее.

Postmortem — сильный источник evidence, если описывает impact, contributing causes и follow-up actions без поиска виноватого. Несколько мелких повторяющихся проблем могут не получить отдельный postmortem, поэтому дополняйте картину outage tracker и support data. Если сайт кажется медленным, сначала нужно диагностировать причину замедления сайта, а уже затем создавайте item с конкретным bottleneck.

Как выбрать работу и проверить отдачу

На ежемесячном review возьмите верхние items и для каждого сравните последствия бездействия, ближайшие product changes, mitigation и effort. Не резервируйте произвольный процент capacity без списка: он быстро заполняется удобными refactoring-задачами. Полезнее иметь policy — например, blocking security или исчерпанный error budget получает обязательный action, а остальные items входят в roadmap рядом с feature, которую они ускоряют.

До работы сохраните baseline. После неё повторите тот же delivery path, toil measurement, failure scenario или performance trace. Улучшение code coverage само по себе не доказывает сокращение debt, если consequence не изменился. Критерий может быть contract test для конкретного риска, сокращение ручного шага, возможность обновить dependency или независимый release модуля. Если эффекта нет, обновите модель причины вместо объявления победы.

При выборе платформы полезно включить долг в полную стоимость владения. Self-hosted modifications, заблокированные upgrades и SaaS workarounds имеют разные future costs. Для data-related symptoms сначала нужно проверить качество исходных данных: архитектурный rewrite не исправит неопределённый source of truth без владельца и reconciliation.

Как не создавать новый долг молча

Для осознанного компромисса создайте decision record: контекст, выбранный shortcut, полученная выгода, ожидаемое consequence, owner, guardrail и trigger пересмотра. В Definition of Done включите критичные tests, observability, migration и rollback не как абсолютный ритуал, а по риску. NIST SSDF отдельно подчёркивает tracking security requirements, risks и design decisions. Невидимый компромисс превращается в surprise; записанный можно принять и управлять.

Ограничения и практический следующий шаг

Шкала не переводит технический долг в рубли и не сравнивает разные организации без контекста. Уверенность в причине может быть низкой, а самое дорогое исправление — ошибочным. Rewrite создаёт собственный delivery и migration risk. Перед большой заменой проверяйте strangler, isolation, compatibility layer и mitigation. Некоторые legacy-части стабильны и не требуют вмешательства, пока не мешают важным изменениям или обязательствам.

Практический следующий шаг: соберите пять наблюдаемых симптомов из последних изменений, incidents и ручных операций. Превратите каждый в карточку с consequence и evidence. Оцените пять факторов, но выберите для первой работы не самый неприятный код, а item с высоким влиянием и понятным критерием результата. Назначьте дату review и после изменения повторите исходную проверку.

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

• диагностировать причину замедления сайта

• включить долг в полную стоимость владения

• проверить качество исходных данных