На технический долг принято отдавать 20% каждого спринта — эту цифру многие команды берут как готовую норму. Такая доля соблюдается при размеренной работе, а при частых релизах срочные задачи первыми забирают время у долга. Модель работы с долгом продакт выбирает сам — выбор зависит от частоты релизов и от того, как разработка описывает долг. Ниже разберем, где ломаются квота, лимит объема и общий бэклог, как выбрать между ними и объяснить бизнесу расходы на долг.
Что продакт видит вместо технического долга
Технический долг копится в коде, архитектуре, тестах и инфраструктуре и постепенно замедляет разработку. Продакт-менеджер замечает последствия: обычные доработки занимают больше времени, команда увеличивает оценки задач и успевает закрыть меньше задач за спринт. На планировании разработчики просят выделить время на рефакторинг. Но без их пояснений продакту трудно понять, что именно нужно исправить: отчет о спринте показывает, сколько задач выполнено, а не какие технические проблемы задержали работу.
«Product Owner в этот момент может искренне удивляться, почему разработка вдруг замедлилась. А причина проста — накопленный техдолг.»
Андрей Никольский, Head of Platform в «Банки.ру»
Технический долг — цена быстрого решения. Команда предпочла простой вариант надежному и расплачивается всякий раз, когда код приходится менять. Аналогия с кредитом точная: тело долга — само упрощенное решение, проценты — дополнительное время на каждую новую функцию в затронутом модуле. Пока проценты небольшие, их никто не замечает.
Разработчики видят долг изнутри. В опросе Stack Overflow за 2024 год технический долг назвали главным источником раздражения 62% участников. Следующий по частоте ответ выбрали почти вдвое реже.
Преднамеренный и непреднамеренный долг
Иногда продакт и команда сознательно выбирают быстрое решение, понимая, что позже его придется доработать. Так бывает, когда нужно выпустить продукт к конференции, проверить гипотезу на минимальной версии или успеть с интеграцией для крупного заказчика. Такой долг называют преднамеренным. Чтобы он не остался в продукте надолго, продакт и тимлид записывают, что упростили и когда вернутся к доработке.
Непреднамеренный долг возникает без такого решения. Например, библиотеки устаревают, архитектура перестает справляться с ростом продукта, а команда не успевает обновлять тесты. Продакт не планировал эти проблемы, но из-за них задачи тоже занимают больше времени. Поэтому два вида долга планируют по-разному: для преднамеренного заранее назначают срок доработки, а непреднамеренный сначала находят и оценивают.
Как измерить технический долг для разговора о приоритетах
На планировании продакт сравнивает задачи по влиянию на продукт: выручка, удержание клиентов, обязательства перед заказчиками. Если команда говорит только «у нас много техдолга», продакту нечего сопоставить с эффектом от новой функции. Для приоритизации нужен измеримый объем работы или последствие для продукта.
Команды используют три способа описать долг для планирования:
- Объем долга. Сколько спринтов команде нужно, чтобы закрыть известный долг, или какую долю он составляет от объема бизнес-задач. Эту метрику одинаково понимают тимлид и продакт;
- Последствия для пользователя. Инциденты, сорванные обязательства по уровню сервиса, обращения в поддержку из-за одного и того же модуля. Здесь долг выражается в ущербе, который продакт и так отслеживает;
- Стоимость изменения. Во сколько раз дольше команда делает типовую задачу в проблемном участке кода по сравнению с остальной системой. По этой метрике проценты по долгу видны напрямую.
Где копится технический долг
Для оценки последствий команда определяет проблемный участок. В каждой из четырех зон он тормозит работу по-своему:
- Код. Дублирование, устаревшие решения, отсутствие документации и единых правил. Каждая новая функция в таком коде требует больше времени и чаще приводит к ошибкам;
- Архитектура. Решения, рассчитанные на старый масштаб или на одну интеграцию. Они ограничивают скорость разработки сильнее всего, потому что их исправление затрагивает несколько сервисов;
- Тесты. Недостаточное покрытие автотестами и ручная проверка там, где сценарии давно пора автоматизировать. Последствие — долгий цикл проверки перед каждым релизом;
- Инфраструктура и зависимости. Устаревшие версии библиотек, платформ и программного обеспечения. Такой долг накапливается даже тогда, когда команда ничего не меняет в продукте.
Модель 1. Фиксированная квота: 20% спринта по договоренности с CTO
Квота закрепляет за техническим долгом постоянную долю времени команды. Если ее утвердили на уровне CTO, продакт учитывает эту долю при планировании так же, как отпуска и праздники. Остальную часть спринта он отводит под функции и заранее знает, сколько времени на них останется.
Предсказуемость имеет цену: фиксированная доля остается за долгом и накануне важного запуска.
Квота определяет, сколько времени команда тратит на технический долг. Но какие задачи делать в это время, нужно решать отдельно. Так работают в «Т-Инвестициях», бизнес-линии «Т-Банка»: внутренняя договоренность с CTO отводит на технический долг 20% времени команды. По данным компании, с 2022 года команды ведут учет долга и показывают причины его возникновения. На ежедневных встречах они выбирают приоритетные задачи. Объем технического долга при этом остается в пределах 5–15% от объема бизнес-задач.
Почему квота ломается при частых релизах
Квоту проще соблюдать, когда команда выпускает обновление в конце спринта и заранее знает план работ. Если релизы идут часто, срочные задачи появляются уже в середине спринта. Чтобы успеть с ними, команда тратит время, отведенное на технический долг. В плане квота остается, но технические задачи переносят на потом.
Продакт замечает проблему по нескольким признакам:
- Квоту отдают срочной работе. В начале спринта технические задачи запланированы, к концу их переносят в следующий;
- Долг растет при выделенном времени. Квота соблюдается на бумаге, а нерешенных технических задач не становится меньше;
- Решения о долге принимают без продакта. Команда сама выбирает, что успеть в оставшееся время. О переставленных приоритетах продакт узнает только по перенесенной дате запуска.
«Сегодня в IT-индустрии методологии разработки Agile, с использованием фреймфорков „Scrum“, „Kanban“, часто оказываются неэффективными в условиях быстрого темпа и постоянных релизов — у команд просто нет времени на технические задачи! По этой причине традиционная практика выделения 20% времени на технический долг часто не работает.»
Михаил Емельянов, руководитель Android-направления RuStore
Для команд с частыми релизами долю времени можно привязать к измеряемому объему долга. Так устроена вторая модель.
Модель 2. Лимит технического бэклога вместо постоянной доли
Во второй модели команда устанавливает, сколько технических задач может оставаться в бэклоге. Для этого есть две границы: рабочий лимит и порог, после которого команда просит больше времени на долг. Закрывать все накопленные задачи не нужно. Команда следит, чтобы их объем оставался в пределах лимита, а при превышении порога пересматривает план.
Чтобы измерять объем долга, технические задачи заносят в бэклог и оценивают в спринтах: сколько времени они заняли бы при обычной скорости работы команды.
Такой подход использует юнит Fashion&Electronics в «Авито». По данным компании, технический руководитель измеряет в спринтах технострим — поток технических задач — и устанавливает для него лимит. Технострим держат на уровне 1–1,2 двухнедельных спринта. Такой объем, по расчету юнита, команда может закрыть за квартал, если выделяет на долг 20% времени.
Лимит показывает, какой объем долга команда старается поддерживать. Порог определяет, когда нужно пересмотреть распределение времени:
- Объем технострима сравнивают с лимитом.
- Если он превышает 1,5 спринта, тимлид и продакт договариваются выделить больше времени на долг.
- Если объем ниже лимита, время на долг сокращают, а освободившиеся часы отдают продуктовым задачам.
Команда может обосновать просьбу о дополнительном времени объемом бэклога, а продакт заранее знает, когда потребуется пересмотреть план. Но для этого учет должен быть актуальным. Если технические задачи не заносят в бэклог или давно не пересчитывали их объем, команда может поздно заметить, что долг превысил порог.
Модель 3. Общий бэклог: технический долг конкурирует с функциями на равных
В третьей модели технические задачи и новые функции попадают в один бэклог. Чтобы продакт мог сравнить их по пользе для продукта, команда объясняет каждую техническую задачу через её последствия. В описании нужно ответить на три вопроса:
- Проблема: что не работает и в каком модуле;
- Влияние: каких пользователей и какой показатель сервиса это затрагивает;
- Цена отсрочки: что может случиться с инцидентами, сроками запуска или обязательствами перед клиентами, если отложить задачу.
Такой подход использует Mindbox. По данным компании, инженеры объясняют продакту пользу технических задач так же, как пользу новых функций.
Зачем разбираться в последствиях, показывает пример с SLA — обязательствами по уровню сервиса перед клиентами. Команда выяснила, что около 20% зафиксированных нарушений приходились на рассылки, в которых 99% писем уходило вовремя, а 1% — позже. Продакт и клиенты договорились не считать такие рассылки нарушением SLA. По словам команды, на изменение формул в системе учета ушло 30 минут; после этого такие случаи перестали попадать в статистику нарушений. Отдельно компания сообщает, что с 2022 по 2025 год общее число нарушений SLA в команде снизилось почти в семь раз — с более чем 70 до 11 в месяц.
Общий бэклог работает, пока команда может объяснить влияние каждой технической задачи на пользователей, сроки или обязательства. Иначе продакту трудно сравнить её с новой функцией. Когда приоритеты меняются, пользу технической задачи приходится оценивать заново.
Как объяснить технический долг бизнесу
Каждой модели нужно согласие бизнеса. Квоту утверждает CTO, а две другие модели требуют доверия к оценкам разработки. Продакт выступает посредником: он переводит разговор о долге на язык затрат, сроков и рисков для выручки. Пока долг не переведен в деньги и риски, на планировании он проигрывает функциям с понятной выручкой.
Ориентир для бюджетного разговора дает Accenture: компании-лидеры отводят на устранение технического долга около 15% ИТ-бюджета. В Accenture считают нереалистичным полностью избавиться от технического долга: компании управляют им и балансируют обязательства с инвестициями в будущее. Цифра относится к бюджету, а не к рабочему времени — с квотами команд ее не смешивают.
По оценке Gartner, примерно у 40% инфраструктурных систем есть проблемы с техническим долгом. Компания связывает его с рисками для производительности и устойчивости систем. Forrester прогнозировал в 2024 году, что к 2026-му 75% технологических руководителей сочтут технический долг проблемой средней или высокой серьезности. Это прогноз, а не измеренный итог 2026 года.
Отдельный аргумент для разговора с бизнесом — состояние инфраструктуры. По опросу OCS, у 25% крупных компаний свыше половины инфраструктурного стека нуждается в обновлении или даже полном пересмотре. Авторы опроса связывают обострение проблемы с переходом к точечной замене инфраструктурных платформ вместо комплексной цифровизации в 2025–2026 годах.
Цена долга видна и по тому, сколько денег остается на новые продукты. По данным McKinsey 2022 года, около 30% опрошенных ИТ-директоров считают, что более 20% бюджета, выделенного на новые продукты, уходит на устранение технического долга.
«Если разбираться с устранением технического долга — непонятно, сколько денег это принесет, но если запустить новую функциональность — понятно, что какое-то определенное количество денег точно появится.»
Артем Герасимов, владелец продукта SimpleOne SDLC, SimpleOne
В разговоре с финансовым директором или владельцем бизнеса работают три аргумента:
- Доля бюджета с пределом. Сколько процентов бюджета или времени команды уходит на долг и при каком пороге доля меняется;
- Риск для выручки. Какие обязательства под угрозой и чем это видно: инциденты, нарушения SLA, сдвиг запусков;
- Цена отсрочки. Насколько дольше команда будет делать следующие задачи в модуле, если долг не трогать.
Три формулировки, наоборот, мешают договориться:
- «Надо всё переписать». Для бизнеса такая просьба звучит как проект без срока и результата;
- «Код плохой». Такая оценка не переводится в бюджет и сроки;
- «Так делают все». Чужая квота не объясняет, почему именно этой команде нужно отдавать долгу часть времени.
Какую модель выбрать продакту
Три модели различаются предметом договоренности, способом контроля и условиями, при которых подход перестает работать.
| Модель | Ресурс | Договоренность | Контроль | Слабое место |
|---|---|---|---|---|
| Квота | Доля времени | Решение CTO | Долг к бизнес-задачам | Срочные релизы вытесняют долг |
| Лимит долга | Больше времени | Порог объема | Долг в спринтах | Нет учета или пересчета |
| Общий бэклог | Место среди функций | Польза каждой задачи | Инциденты и SLA | Неясно влияние задачи |
Квота подходит командам с предсказуемым графиком спринтов, лимит — командам, которые регулярно измеряют долг, общий бэклог — там, где разработка умеет описывать долг через влияние на продукт.
Другие статьи по теме
Часто задаваемые вопросы
Что такое технический долг?
Технический долг — цена быстрого решения: команда предпочла простой вариант надежному и расплачивается всякий раз, когда код приходится менять. Тело долга — само упрощенное решение, проценты — дополнительное время на каждую новую функцию в затронутом модуле. Долг копится в коде, архитектуре, тестах и инфраструктуре и постепенно замедляет разработку.
Как измерить технический долг для разговора о приоритетах?
Команды описывают долг тремя способами: объемом, последствиями для пользователя и стоимостью изменения. Объем показывает, сколько спринтов нужно, чтобы закрыть известный долг, или какую долю он составляет от бизнес-задач. Последствия — это инциденты, нарушения SLA и обращения в поддержку, а стоимость изменения показывает, во сколько раз дольше команда делает типовую задачу в проблемном участке кода.
Почему квота 20% спринта на технический долг перестает работать?
Квоту проще соблюдать, когда команда выпускает обновление в конце спринта и заранее знает план работ. При частых релизах срочные задачи появляются уже в середине спринта и забирают время, отведенное на долг: в плане квота остается, а технические задачи переносят на потом. Признаки — квоту отдают срочной работе, долг растет при выделенном времени, решения о долге принимают без продакта.
Как работает лимит технического бэклога?
Технические задачи заносят в бэклог, оценивают в спринтах и держат их объем в пределах лимита. В юните Fashion&Electronics в «Авито» технострим держат на уровне 1–1,2 двухнедельных спринта: если объем превышает 1,5 спринта, тимлид и продакт договариваются выделить больше времени на долг, а если он ниже лимита, время на долг сокращают. Модель работает, пока учет актуален.
Как объяснить технический долг бизнесу?
Продакт переводит разговор о долге на язык затрат, сроков и рисков для выручки. Работают три аргумента: доля бюджета или времени с пределом, риск для выручки и цена отсрочки. Мешают договориться формулировки «Надо всё переписать», «Код плохой» и «Так делают все».
Какую модель работы с техническим долгом выбрать продакту?
Квота подходит командам с предсказуемым графиком спринтов, лимит — командам, которые регулярно измеряют долг. Общий бэклог подходит там, где разработка умеет описывать долг через влияние на продукт: каждую техническую задачу объясняют через проблему, влияние и цену отсрочки. Иначе продакту трудно сравнить её с новой функцией.