Техдолг почти всегда проигрывает фичам: фичи видно, а долг только чувствуется, пока однажды из-за него не встанет весь релиз. Пока эти две очереди живут порознь, приоритеты расставляет не логика, а то, что громче требует клиент.
Фичи и долг должны стоять в одной очереди
Если фичи ранжируют по эффекту, а техдолг держат отдельно, команда берёт заметные клиентские запросы, откладывает «невидимую» работу и получает дорогую разработку, повторные аварии и сроки с оговорками.
Сам термин «техдолг» Уорд Каннингем в 1992 году придумал именно как денежную метафору: быстрый код это заём, который ускоряет поставку, пока проценты по нему платят вовремя. Опасность начинается там, где долг не гасят. Эта рамка и подсказывает решение: долг сравнивают с фичами не по типу работы, а по стоимости, как любую другую статью расходов.
Правило «20% спринта на рефакторинг» защищает время инженеров, но не отвечает, какой долг важнее конкретной фичи. Очистка очереди иногда подождёт; день работы с пулом соединений может быть важнее коммерческой возможности, если через нестабильный узел проходит каждый релиз.
Переведите техдолг для продакта в задержку, вероятность ущерба, инциденты и потерю скорости. Тогда это сравнение ставок на один ресурс команды, а не торг функций с платформой.
Пять сигналов для общей оценки работ
Матрица сравнивает цену откладывания, а не тип задач. Фича и переработка компонента получают баллы по одной логике; заранее зафиксируйте шкалу 0-5, иначе «высокий риск» и «важная задача» несопоставимы.
| Сигнал | Что измеряет | Оценка 5 баллов |
|---|---|---|
| Cost of delay | Потерю от переноса на ближайший период | Блокирует выручку, обязательство перед клиентом или запуск с подтверждённым спросом |
| Риск | Вероятность тяжёлого сбоя и масштаб последствий | Затрагивает деньги, доступ, данные или критичный путь продукта |
| Инциденты | Повторяемую операционную боль | Недавние аварии, ручные обходы, эскалации клиентов или дежурства |
| Скорость разработки | Сколько будущей работы тормозит узкое место | Через компонент проходят частые изменения, тесты или релизы |
| Confidence | Подтверждённость баллов | Есть логи, замеры, тикеты, интервью или проверенная декомпозиция |
Cost of delay долга это бизнес-потеря от отсрочки, а не абстрактная цена плохого кода. Старый модуль тарифов может не давать запустить новый план для крупных аккаунтов: каждая неделя откладывает проверку спроса и продажи. Это высокий балл даже без падений.
Риск оценивайте вопросами «что сломается?» и «кто заметит?». Утечка прав, двойное списание или потеря заказа требуют иной реакции, чем медленная админ-страница. Не считайте ущерб дважды: риск это вероятность аварии, а CoD плановая коммерческая или продуктовая цена ожидания.
Скорость это наблюдаемое трение: длительность проверок, число затронутых сервисов, ручные шаги релиза, время исправления типовых дефектов. Миграция фронтенд-стека получает высокий балл, только если мешает поставке; устаревшая технология сама по себе не аргумент.
Для квартала:
Приоритет = (0,35 × CoD + 0,25 × Риск + 0,20 × Инциденты + 0,20 × Скорость) × Confidence
Confidence это коэффициент 0,5-1,0. Низкая уверенность не значит «не делать»: сначала снимите неопределённость метриками, техническим исследованием или декомпозицией миграции. Формула не заменяет решение, но делает разногласия видимыми.
Когда выбирать квоту, общую очередь или гибрид
Первый подход это фиксированная доля ёмкости, например один слот из пяти. Он удобен при накопленном долге и стабильной стратегии, но аварийный узел может ждать месяц, а малозначимый рефакторинг попасть в спринт, потому что «квота сгорает».
Второй подход это единая очередь: фичи, долг, исследования и надёжность сравнивают матрицей. Долгу нужен не отдельный бюджет, а показ его цены относительно альтернативы.
Нужна аварийная дорожка: уязвимость, массовый сбой или риск потери данных не ждут еженедельного скоринга. Заранее задайте серьёзность, охват, обход и юридические обязательства как входные условия. Остальное возвращается в общую очередь.
Платформенным командам с постоянными инцидентами подходит гибрид: небольшой резерв на непредвиденное, остальная ёмкость распределяется по матрице. Резерв не должен стать тайником задач без владельца и ожидаемого эффекта.
Заполненная матрица для квартального планирования
Формула оживает на конкретном квартале. B2B SaaS-команда выбирает пять кандидатов на квартал после просмотра тикетов поддержки, инцидентов, календаря продаж и оценки разработки.
| Кандидат | CoD | Риск | Инциденты | Скорость | Confidence | Балл |
|---|---|---|---|---|---|---|
| Переписать пул соединений с БД | 5 | 4 | 5 | 2 | 0,90 | 3,74 |
| Заменить библиотеку токенов доступа | 4 | 5 | 3 | 2 | 0,80 | 2,92 |
| Добавить контрактные тесты API | 3 | 3 | 4 | 4 | 0,85 | 2,89 |
| Запустить экспорт отчётов в новом формате | 5 | 1 | 0 | 1 | 0,85 | 1,87 |
| Мигрировать старый фронтенд-фреймворк | 2 | 2 | 1 | 5 | 0,70 | 1,68 |
Пул соединений первый не потому, что инфраструктура важнее продукта: он вызывает инциденты, а запуск крупных клиентов упирается в устойчивость нагрузки. У библиотеки токенов меньше сбоев, но выше потенциальный ущерб. Контрактные тесты не дают продаж напрямую, зато снижают регрессии и ускоряют изменения интеграций.
Новая выгрузка имеет высокий CoD: её ждёт сегмент клиентов, но она не побеждает автоматически. Команда может уменьшить объём фичи, перенести её или проверить спрос без полной разработки. Миграция фронтенда внизу: эффект на скорость высок, но доказательств текущего вреда мало и confidence слабый. Следующий шаг это коротко исследовать время сборки, стоимость поддержки пакетов и долю задач, блокируемых старым стеком; затем разбить миграцию на срезы и пересчитать.
Где баллы начинают врать команде
Шкала помогает ровно до тех пор, пока ей пользуются честно. Не ставьте пятёрки всем неприятным задачам: если почти весь бэклог высокорисковый и с высоким CoD, шкала не разделяет работу. Опишите уровни: риск 5 это угроза деньгам, доступу или данным; 3 это заметный сбой с обходом; 1 это локальное неудобство без влияния на клиента.
Не учитывайте одну аварию в CoD, риске и инцидентах одной суммой. CoD это будущая цена задержки, риск это ожидаемый ущерб, инциденты это подтверждённая повторяемость.
Не оценивайте инициативу целиком. «Переписать биллинг» несопоставимо с фичей на две недели; разделите её на изоляцию расчёта налогов, идемпотентность списаний и очередь уведомлений. У частей свои эффект, риск и размер. Неразрезаемый крупный долг обычно скрывает неясную архитектурную границу.
Высокий балл не обязывает брать задачу сразу: план ограничен компетенциями, окнами релиза, зависимостями и контрактами. Матрица показывает порядок ценности, а план доступность людей и последовательность.
Чем эта матрица отличается от WSJF
У этого подхода есть известный родственник. В SAFe работы ранжируют по WSJF, weighted shortest job first: cost of delay делят на размер задачи, поэтому при равной ценности вперёд выходит то, что быстрее сделать. Cost of delay там складывают из трёх частей: ценность для пользователя и бизнеса, срочность и снижение риска или открытие новых возможностей. Саму идею считать в первую очередь цену задержки закрепил Дон Рейнертсен в книге The Principles of Product Development Flow: если вы измеряете только одно, измеряйте cost of delay.
Матрица выше устроена иначе в двух местах, и различия сознательные. Во-первых, размер задачи она не делит, а выносит в план: балл показывает порядок ценности, а доступность людей и окна релиза решаются отдельной линией ёмкости, иначе крупный, но необходимый долг вечно проигрывает мелким задачам с высоким WSJF. Во-вторых, она умножает сумму на confidence, потому что в техдолге разброс оценок обычно больше, чем в фичах, и честнее сначала снять неопределённость, чем поставить красивый балл наугад. Если команда уже живёт по WSJF, эти пять сигналов ложатся на него без конфликта: риск и инциденты уточняют снижение риска, cost of delay и скорость разработки описывают ценность и срочность.
Планирование за 45 минут без ритуального торга
Собрать всё это можно за одну короткую сессию. За день до сессии продакт готовит кандидатов: проблему, затронутый сегмент, последствие переноса, размер и ссылки на инцидент, тикет, лог, запрос продаж или технический замер. Без мини-паспорта задача получает пониженный confidence.
Техлид объясняет причинную цепочку, а не красоту архитектуры: «сервис A исчерпывает соединения, из-за этого падает создание заказа, дежурный перезапускает контейнеры». Продакт проверяет CoD через клиентов, запуски и стратегию; инженеры отвечают за риск, инциденты, скорость и реалистичность среза. Все поля не должен оценивать один человек.
- Отсейте аварийные задачи в отдельную дорожку.
- Зафиксируйте период: ближайшие шесть недель или квартал.
- Поставьте баллы независимо, обсудите расхождения больше двух пунктов.
- Умножьте сумму на confidence и отсортируйте кандидаты.
- Проведите линию доступной ёмкости с зависимостями и отпусками.
- Для задач под линией запишите условие пересмотра: инцидент, запуск клиента или результат исследования.
В журнале решений сохраните исходные баллы, принятую ставку, владельца и причину отказа. Через квартал он покажет, где команда недооценивает риск, объём или CoD, а не кто выиграл спор.
Метрики стоимости техдолга после релиза
Без проверки приоритизация становится бесполезной таблицей. Для выбранной задачи назначьте ожидаемую и защитную метрику. Пул соединений оценивают числом инцидентов и временем восстановления, защищая задержку создания заказа. Контрактные тесты оценивают регрессиями интеграций и длительностью цикла поставки, следя, чтобы набор не сделал сборку неприемлемо долгой.
Метрики зависят от проблемы:
- время цикла от начала разработки до релиза, если долг тормозит поставку;
- число и тяжесть инцидентов за одинаковый период, если страдает надёжность;
- часы ручных операций и повторные обращения в поддержку, если есть обходы;
- доля задач, заблокированных зависимостью, если архитектура мешает дорожной карте;
- задержка критичного пользовательского действия, если долг заметен клиенту.
Сравнивайте периоды с контекстом: снижение инцидентов не доказывает причинность, если упала нагрузка или изменился трафик. Учитывайте объём операций, релизы, сезонность и состав клиентов. Лучше заранее записать ожидаемый механизм, чем потом искать удобное объяснение.
Миграции уступают коротким проверяемым ставкам
Программы «закроем техдолг за квартал» плохо переживают смену приоритетов. Формулируйте долг как измеримые ставки: убрать ручной перезапуск, сократить проверку платежа, изолировать нестабильную интеграцию, снизить время сборки конкретного сервиса.
Это не отказ от крупных инвестиций: иногда платформа требует месяцев и не сводится к мелким задачам. Но руководству нужен маршрут с контрольными точками: какой риск снимет первая часть, какую функциональность разблокирует вторая и что станет сигналом остановки. Матрица защищает миграцию проверяемой экономикой и операционной болью, а не модным стеком.
Что вынести на ближайшее планирование
Соберите один список фич и техзадач, задайте пять шкал и оцените хотя бы десять ближайших кандидатов. Не ищите идеальную формулу: первая версия вскроет расхождения между ценой переноса у продаж, хрупкостью системы у инженеров и целью периода у продакта.
Матрица не обещает арифметической истины, но оставляет след: почему задача в плане, какими данными подтверждена и какой сигнал изменит порядок. Поэтому техдолг выбирают не как техническую привилегию, а как инвестицию в будущую поставку.