Техдолг vs новые фичи: как балансировать приоритеты и договариваться с разработкой

Представьте: вы продакт-менеджер. У вас roadmap на квартал, расписанный по неделям. Маркетинг анонсировал три новые фичи клиентам. Инвесторы ждут роста метрик. Конкуренты выпустили что-то похожее — нужно догонять.

Приходит тимлид: "Нам нужно два месяца на рефакторинг". Вы: "Почему? Всё же работает?". Он: "Работает, но медленно. Каждая новая задача занимает в два раза больше времени. Код превратился в спагетти. Если не почистим сейчас — через полгода вообще ничего не сможем делать".

Вы смотрите на roadmap. Два месяца рефакторинга = ноль новых фич = недовольные клиенты, пропущенные дедлайны, вопросы от руководства. "Давайте после релиза", — говорите вы. "После релиза" никогда не наступает. Технический долг растёт. Скорость падает. Напряжение между продактом и разработкой усиливается.

Знакомо? Это самый частый конфликт в продуктовых командах. Разработчики хотят чистый код. Менеджеры хотят новые фичи. Обе стороны правы. И обе не понимают друг друга.

По данным исследования Product Management Institute (2023), 73% продакт-менеджеров называют "баланс техдолга и фич" своей топ-3 проблемой. McKinsey оценивает, что компании теряют 20-40% производительности разработки из-за накопленного технического долга. Это не абстрактная "плохая практика" — это реальные деньги и время.

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

1. Что такое технический долг (объяснение для менеджеров)

Технический долг — не когда "плохо написали код". Это осознанный или неосознанный выбор быстрого решения вместо правильного.

Аналогия с финансовым долгом

Вы берёте кредит на развитие бизнеса. Получаете деньги сейчас, платите проценты потом. Чем дольше не возвращаете — тем больше переплата.

Технический долг: берёте "кредит" на скорость разработки. Делаете фичу быстро через shortcuts. Платите "процентами" — каждая следующая фича разрабатывается дольше. Чем дольше не рефакторите — тем выше "процентная ставка".

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

Сценарий 1: Deadline pressure (давление дедлайнов)

Продакт: "Нужно выкатить к 1 марта, клиент ждёт". Разработчик: "Правильно сделать — 3 недели. Быстро и грязно — 1 неделя". Продакт: "Делай быстро, потом почистим". Релиз состоялся. "Потом" не наступает никогда. Долг накопился.

Сценарий 2: Изменение требований

Спроектировали архитектуру для одного use case. Через год требования изменились, добавили новые фичи. Архитектура не подходит, но переделывать некогда. Костыли поверх костылей. Долг растёт органически.

Сценарий 3: Недостаток опыта

Джуниор разработчик написал код как умел. Через год он стал сеньором и понимает: "Я тогда сделал не оптимально". Но переписывать "работающее" не дают. Долг остаётся.

Сценарий 4: Устаревание технологий

3 года назад выбрали технологию X. Она была актуальна. Сейчас индустрия перешла на Y. Код на X работает, но поддерживать сложнее, новых разработчиков найти труднее. Это тоже долг.

Виды технического долга

Что НЕ является техническим долгом

Баги: Баги — это дефекты. Долг — это design choices. Разные вещи. Баги нужно фиксить всегда. Долг можно жить какое-то время.

Новые фичи: "Мы должны добавить фичу X" — это не долг, это roadmap.

Отсутствие идеального кода: Идеальный код не существует. Долг — это когда текущий код реально мешает разработке.

«Технический долг — это не плохая разработка. Это trade-off между скоростью сейчас и скоростью потом» — Мартин Фаулер

2. Почему разработчики постоянно просят рефакторинг

С точки зрения менеджера кажется: разработчики всегда недовольны своим кодом. Только дописали фичу — уже хотят переписывать. Может, они перфекционисты?

На самом деле нет. Вот что происходит на их стороне.

Причина 1: Скорость разработки реально падает

Это не ощущение, это измеримо. Задача, которая раньше занимала 2 дня, теперь занимает 5 дней. Почему? Потому что код запутанный. Нужно разобраться в legacy, понять, где что лежит, не сломать существующее.

Пример:

• Q1 2023: Средняя фича — 8 дней

• Q2 2023: Средняя фича — 10 дней

• Q3 2023: Средняя фича — 14 дней

• Q4 2023: Средняя фича — 18 дней

За год скорость упала в 2.25 раза. Это не разработчики стали ленивее. Это технический долг.

Причина 2: Риск сломать существующее

Когда код запутанный и без тестов, каждое изменение — рулетка. "Добавил кнопку в UI → сломалась авторизация". Звучит абсурдно? Но в legacy кодовых базах такое случается. Всё связано со всем через неочевидные зависимости.

Разработчик боится что-то менять. Это стресс. Это медленная работа (нужно проверять всё вручную). Это баги в production.

Причина 3: Невозможность добавить фичу "правильно"

Продакт просит фичу X. Разработчик понимает: "Чтобы сделать X правильно, нужно сначала отрефакторить модуль Y. Иначе X будет ещё одним костылём поверх костылей".

Но времени на рефакторинг Y нет. Делает X как костыль. Долг растёт. Следующая фича Z будет ещё сложнее. Порочный круг.

Причина 4: Профессиональная гордость

Да, есть и это. Разработчик — мастер своего дела. Плохой код — как для столяра работать с тупыми инструментами. Это раздражает. Не потому что перфекционизм, а потому что профессионализм.

Причина 5: Сложность онбординга новых людей

Пришёл новый разработчик. Тимлид тратит 3 недели на объяснение "как тут всё устроено". Потому что код непонятный, документации нет, всё держится на знании старожилов.

Это не масштабируется. Нанять нового человека = 3 недели простоя тимлида. Рефакторинг решает это.

Причина 6: Выгорание

Работать с плохим кодом демотивирует. "Я тут делаю костыли, а не инженерию". Хорошие разработчики уходят в компании с лучшей кодовой базой. Текучка растёт. Найм дорожает.

3. Почему менеджеры сопротивляются рефакторингу

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

На самом деле у менеджеров свои причины сопротивления. И они часто обоснованы.

Причина 1: Непонятная ценность

Разработчик: "Нам нужен рефакторинг модуля авторизации".

Менеджер: "Что мы получим?". Разработчик: "Код станет чище".

Для менеджера "чище" — абстракция. Он не видит код. Он видит продукт. "Чище" не транслируется в бизнес-метрики. Непонятно, зачем тратить 2 месяца.

Причина 2: Давление стейкхолдеров

Менеджер не один принимает решения. Над ним CEO, инвесторы, клиенты. Они все хотят фичи. "Где чат с поддержкой?", "Когда интеграция с X?", "Конкуренты уже сделали, а мы нет?".

Сказать им: "Этот квартал на рефакторинг" = объяснить, почему мы не делаем то, что обещали.

Причина 3: Страх невидимых результатов

Новая фича = видимый результат. Клиенты радуются. Можно показать на демо. Можно написать в release notes.

Рефакторинг = невидимый результат. После 2 месяцев работы продукт выглядит так же. "Что вы делали эти 2 месяца?" — сложно объяснить не-техническому руководству.

Причина 4: Горький опыт прошлого

В прошлом дали разработке 3 месяца на рефакторинг. Они рефакторили. Стало лучше? Спорно. Скорость не выросла, баги не исчезли. "Зачем снова давать время, если прошлый раз не помогло?".

Причина 5: Роадмап уже утверждён

Квартальный план согласован с командой, стейкхолдерами, маркетингом. Начали выполнение. Вдруг разработка: "Давайте остановимся и займёмся долгом".

Это ломает все планы. Нужно переделывать roadmap, переносить обещания клиентам, объясняться с руководством.

Причина 6: Незнание "когда остановиться"

Менеджер боится: дашь палец — откусят руку. Согласишься на 2 недели рефакторинга → разработчики захотят 2 месяца. Потом весь квартал. Потом "давайте перепишем всё с нуля".

Где граница между "достаточно хорошо" и "идеально"? Непонятно.

4. Реальная цена технического долга (в деньгах и времени)

Чтобы принимать решения, нужны цифры. Вот как посчитать стоимость долга.

Метод 1: Потерянное время разработки

Посчитайте, сколько времени команда тратит на борьбу с долгом вместо новых фич.

Формула: (Время на баги + легаси + workarounds) / Всё время × Зарплатный фонд

Пример:

• Команда: 6 разработчиков × $8K/мес = $48K/мес

• По time tracking: 35% времени уходит на баги из-за плохого кода, поддержку легаси, workarounds

• Стоимость: $48K × 0.35 = $16.8K/мес или $201K/год

Это деньги, которые компания тратит на борьбу с техническим долгом вместо создания ценности.

Метод 2: Замедление velocity

Скорость разработки падает → делаете меньше фич → теряете потенциальную выручку.

Пример:

• Год назад: 10 фич за квартал

• Сейчас: 6 фич за квартал (из-за долга)

• Потеря: 4 фичи в квартал

• Средняя фича приносит $30K MRR

• Упущенная выгода: 4 × $30K = $120K/квартал или $480K/год

Метод 3: Стоимость инцидентов

Технический долг → больше багов → больше инцидентов в production.

Расчёт одного инцидента:

• Время разработчиков на фикс: 8 часов × 2 человека = 16 часов

• Стоимость часа: $80 (при $13K/мес)

• Время разработки: 16 × $80 = $1,280

• Потерянная выручка (downtime): $2,000

• Репутационные потери: сложно оценить, но есть

• Итого на инцидент: ~$3,500

Если инциденты происходят 6 раз в квартал: $21K/квартал или $84K/год.

Метод 4: Стоимость текучки

Плохой код → демотивация → уход сильных разработчиков.

Стоимость замены одного разработчика:

• Recruiting: $5K

• Онбординг (время тимлида): 3 недели × $120/час × 40 = $14.4K

• Ramp-up (неполная продуктивность): 3 месяца × 50% = 1.5 месяца зарплаты = $12K

• Итого: ~$31K на замену

Если технический долг приводит к уходу даже 1 сильного разработчика в год → это $31K прямых потерь.

Суммарная стоимость технического долга

Почти миллион долларов в год для команды из 6 человек. Теперь вопрос рефакторинга выглядит иначе: "Можем ли мы позволить себе НЕ делать рефакторинг?".

5. Как измерить технический долг (метрики для менеджеров)

Нельзя управлять тем, что не измеряешь. Вот метрики, понятные менеджерам.

Метрика 1: Velocity (скорость команды)

Сколько story points команда закрывает за спринт. Если падает — возможно, долг растёт.

Как отслеживать: График velocity за последние 6-12 месяцев. Тренд вниз = красный флаг.

Норма: Velocity должна быть стабильна (±10%). Падение >20% — проблема.

Метрика 2: Cycle Time (время от старта до деплоя)

Сколько времени задача проводит в работе от "To Do" до "Done".

Как отслеживать: В Jira/Linear есть встроенные отчёты.

Пример:

• 6 месяцев назад: средний Cycle Time = 5 дней

• Сейчас: 9 дней

• Рост на 80% — долг влияет

Метрика 3: Количество багов / время на фиксы

Больше багов = вероятно, больше технического долга (код сложный, всё связано, легко сломать).

Отслеживайте:

• Количество багов, открытых за спринт

• % времени команды на фиксы vs новые фичи

Benchmark: 20-30% времени на баги — норма. 50%+ — проблема.

Метрика 4: Code Churn (изменчивость кода)

Сколько раз один и тот же файл переписывается. Высокий churn = проблемная область.

Как посчитать: Git-анализ. Инструменты: Code Climate, SonarQube.

Интерпретация: Файл меняется 50 раз за квартал → там постоянно что-то чинят → вероятно, плохой код.

Метрика 5: Time to onboard (время адаптации новых разработчиков)

Сколько времени новому человеку нужно, чтобы стать продуктивным.

Норма: 2-4 недели.

Проблема: 6-8 недель → код сложный, документации нет, технический долг высокий.

Метрика 6: Developer satisfaction (удовлетворённость команды)

Проводите анонимные опросы. Вопрос: "Оцените от 1 до 10: насколько вам комфортно работать с текущей кодовой базой?".

Benchmark: 7+ — хорошо. 5 и ниже — команда страдает.

Дашборд для отслеживания

Все метрики красные → технический долг критичен, нужны действия.

6. Фреймворки приоритизации техдолга vs фич

Фреймворк 1: Матрица Impact / Effort

Оцениваете каждую задачу (фичу или техдолг) по двум осям: влияние на бизнес и усилия.

Пример применения:

• Рефакторинг модуля авторизации: High Impact (ускорит 50% задач), High Effort (3 недели) → Приоритет 2

• Новая фича "Чат поддержки": High Impact (запрос от 70% клиентов), Low Effort (1 неделя) → Приоритет 1

• Рефакторинг старого редко используемого модуля: Low Impact, High Effort → Приоритет 4 (не делать)

Фреймворк 2: Правило 70/20/10

Распределение времени команды:

• 70% — новые фичи (продуктовая работа)

• 20% — технический долг (рефакторинг, улучшения)

• 10% — эксперименты, обучение, R&D

Это даёт баланс. Бизнес получает фичи. Разработка получает время на качество. 20% на техдолг — это 1 день в неделю или 1 спринт из 5.

Фреймворк 3: Tech Debt Quadrant (квадрант техдолга)

Мартин Фаулер предложил классификацию долга:

Приоритизация:

• Reckless Deliberate → Чинить немедленно (это бомба замедленного действия)

• Prudent Deliberate → Планировать погашение (был сознательный выбор)

• Inadvertent → Погашать постепенно (учимся на опыте)

Фреймворк 4: WSJF (Weighted Shortest Job First)

Используется в SAFe. Считаете приоритет как:

WSJF = (Business Value + Time Criticality + Risk Reduction) / Job Size

Пример:

Фича "Интеграция с CRM":

• Business Value: 8/10

• Time Criticality: 9/10 (клиент ждёт)

• Risk Reduction: 3/10

• Job Size: 5 (недель)

• WSJF = (8+9+3)/5 = 4.0

Рефакторинг "Оптимизация БД":

• Business Value: 5/10

• Time Criticality: 4/10

• Risk Reduction: 9/10 (снижает риск падений)

• Job Size: 2 (недели)

• WSJF = (5+4+9)/2 = 9.0

Рефакторинг БД имеет выше WSJF → делать первым.

7. Как говорить на одном языке с разработкой

Главная проблема конфликта — разные языки. Разработчики говорят про код. Менеджеры — про бизнес. Нужен перевод.

Что говорят разработчики vs Что слышат менеджеры

Учите разработчиков говорить на языке бизнеса

Вместо: "Нужен рефакторинг модуля X, там высокая cyclomatic complexity".

Говорите: "Модуль X замедляет 40% наших задач. Если отрефакторим (2 недели работы), сэкономим 3-4 дня на каждой будущей задаче. Окупится за месяц".

Шаблон для разработчиков:

1. Проблема: Что именно не работает (в метриках)

2. Влияние на бизнес: Как это влияет на скорость/качество/стоимость

3. Решение: Что нужно сделать

4. Стоимость: Сколько времени/денег

5. ROI: Когда окупится, что получим

Пример хорошей аргументации:

"Текущая архитектура базы данных приводит к медленным запросам (средний response time 2.3 секунды, тогда как норма 0.3). Это влияет на UX — 15% пользователей уходят из-за медленной загрузки (данные из аналитики). Оптимизация займёт 1 неделю (1 senior backend). После оптимизации ожидаем снижение response time до 0.4 сек, что должно снизить bounce rate на 5-7%. Это примерно +$8K MRR. Инвестиция $10K (неделя работы), возврат за 1.5 месяца".

Учитесь понимать технический язык (для менеджеров)

Базовый глоссарий:

• Coupling (связанность): Насколько части кода зависят друг от друга. Высокая = изменение в одном месте ломает много других.

• Cohesion (связность): Насколько логика в одном модуле относится к одной задаче. Низкая = модуль делает всё подряд, сложно понять.

• Technical debt: "Кредит" на скорость разработки. Быстро сейчас → медленно потом.

• Refactoring: Изменение структуры кода без изменения функциональности. Цель — сделать код проще и быстрее для поддержки.

• Legacy code: Старый код, который работает, но сложен для изменений. Обычно без тестов, непонятная архитектура.

Создайте общие метрики

Вместо "код плохой" измеряйте:

• Время на типовую задачу (было 3 дня, стало 7 дней)

• Количество багов после релиза (было 2, стало 8)

• Скорость онбординга новых людей (было 2 недели, стало 6 недель)

Это понятно обеим сторонам.

8. Стратегии балансирования

Стратегия 1: Boy Scout Rule (правило бойскаута)

"Оставь код чище, чем нашёл". Каждый раз, работая с файлом, улучши что-то мелкое.

Плюсы: Постоянное улучшение без выделенного времени. Долг не накапливается.

Минусы: Медленно. Системные проблемы не решает.

Когда применять: Всегда, как базовая практика. Но недостаточно для серьёзного долга.

Стратегия 2: 20% правило (Google-style)

20% времени каждого спринта — на технический долг. Это 1 день в неделю или 2 дня в спринте.

Реализация: В начале спринта резервируете capacity. "У нас 100 points capacity, 20 points на техдолг, 80 на фичи".

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

Минусы: 20% может быть недостаточно для критичных проблем.

Стратегия 3: Чередование спринтов

3 спринта на фичи, 1 спринт на техдолг. Или 4 к 1.

Плюсы: Фокус. Можно решать крупные проблемы за выделенный спринт.

Минусы: Бизнес недоволен "потерянным" спринтом. Нужно объяснять стейкхолдерам.

Стратегия 4: Opportunistic refactoring (рефакторинг по возможности)

Рефакторим только то, что мешает текущей задаче. Делаем фичу → натыкаемся на плохой код → чиним его в рамках той же задачи.

Плюсы: Естественная приоритизация. Чиним то, что действительно мешает.

Минусы: Может раздувать estimates задач. "Фича на 3 дня" превращается в "фича + рефакторинг на 5 дней".

Стратегия 5: Targeted campaigns (целевые кампании)

Выбираете самую проблемную область (hotspot по метрикам) и 2-3 недели вся команда фокусируется на ней.

Плюсы: Быстрый видимый результат. Решаете большую проблему разом.

Минусы: Нужно остановить другую работу. Требует alignment с бизнесом.

Рекомендуемая комбинация

1. Всегда: Boy Scout Rule (базовый уровень)

2. Постоянно: 20% времени на долг (поддержание)

3. Раз в квартал: Targeted campaign на самый болезненный hotspot (системное решение)

Это даёт баланс между постоянным улучшением и решением крупных проблем.

9. Когда нужно остановить фичи и делать рефакторинг

Есть ситуации, когда "потом" недопустимо. Нужно остановиться сейчас.

Красный флаг 1: Velocity упала на 30%+

Если скорость команды упала на треть и не восстанавливается — это критично. Вы теряете производительность. Дальше будет только хуже.

Решение: Выделите 1-2 спринта на рефакторинг критичных областей.

Красный флаг 2: Более 50% времени на баги/фиксы

Команда тратит больше времени на чинку сломанного, чем на создание нового. Это death spiral.

Решение: Срочный рефакторинг самых проблемных модулей + написание тестов.

Красный флаг 3: Новые разработчики адаптируются 2+ месяца

Онбординг занимает вечность → код непонятен → документации нет → зависимость от старожилов.

Решение: Рефакторинг + документация. Иначе масштабирование команды невозможно.

Красный флаг 4: Команда теряет сильных людей

Exit interviews показывают: "Устал работать с legacy, ушёл в компанию с современным стеком".

Решение: Модернизация стека + рефакторинг. Стоимость замены людей выше, чем стоимость рефакторинга.

Красный флаг 5: Критичная фича "невозможна" без рефакторинга

Бизнес хочет фичу X. Разработка говорит: "Чтобы сделать X, нужно сначала отрефакторить Y и Z. Иначе X будет работать плохо или займёт в 3 раза больше времени".

Решение: Делаете рефакторинг Y и Z как часть задачи X. Включаете в estimate.

Правило принятия решения

Если 2 и более красных флагов одновременно → останавливаете фичи, делаете рефакторинг. Это не "роскошь", это "необходимость для выживания продукта".

10. Как продавать техдолг стейкхолдерам

Убедили себя в необходимости. Теперь нужно убедить CEO, инвесторов, других менеджеров.

Плохая аргументация

• "Код плохой" → Непонятно, что это значит

• "Разработчикам некомфортно" → Эмоции, не бизнес

• "Нужно для best practices" → Абстракция

• "Технический долг растёт" → Без цифр не убедительно

Хорошая аргументация

Структура презентации:

Слайд 1: Проблема (в метриках)

• "Скорость разработки упала на 35% за год"

• "Мы делали 10 фич в квартал, теперь 6"

• "Время на типовую задачу: было 4 дня, стало 9 дней"

График падения velocity. Наглядно.

Слайд 2: Стоимость проблемы

• "Теряем $200K/год на неэффективность разработки"

• "Упущенная выгода (недоделанные фичи): $480K/год"

• "Инциденты стоят $84K/год"

• "Итого: $764K/год"

Таблица как в разделе 4. Конкретные деньги.

Слайд 3: Риски бездействия

• "Если не действуем, через 6 месяцев velocity упадёт ещё на 20%"

• "Потеряем ключевых разработчиков (2 уже думают об уходе)"

• "Конкуренты обгонят — они выкатывают быстрее"

Слайд 4: Решение

• "Целевой рефакторинг топ-3 проблемных модулей"

• "Инвестиция: 6 недель работы команды"

• "План: 2 недели на модуль X, 2 недели на Y, 2 недели на Z"

Слайд 5: Ожидаемые результаты

• "Скорость вернётся к норме (+30% от текущей)"

• "Экономия $200K/год на эффективности"

• "Сможем делать на 4 фичи больше в квартал = +$480K/год потенциально"

• "ROI: окупится за 3 месяца"

Слайд 6: Что НЕ делаем

• "Не переписываем всё с нуля"

• "Не меняем стек технологий"

• "Фокусируемся только на критичных областях"

Это успокаивает стейкхолдеров — вы не в бесконечном рефакторинге.

Язык для разных стейкхолдеров

Для CEO: "Мы теряем конкурентное преимущество. Velocity упала, конкуренты быстрее. Инвестиция $X вернёт скорость и даст $Y экономии в год".

Для CFO: "ROI 380% за год. Инвестиция $50K, возврат $240K через экономию и упущенную выгоду".

Для Sales: "Сейчас мы не можем выкатить фичи X, Y, Z, которые просят клиенты. После рефакторинга сможем. Это повлияет на закрытие сделок".

11. Планирование техдолга в roadmap

Как включить техдолг в roadmap, чтобы это не выглядело как "пустой квартал".

Подход 1: Явное выделение в roadmap

В квартальном roadmap отдельная строка "Tech Health / Infrastructure".

Пример roadmap:

Tech Health видна всегда. Это не "сюрприз", а планируемая работа.

Подход 2: Включение в estimates фич

Когда оцениваете фичу, включаете необходимый рефакторинг.

Пример:

• Фича "Добавить чат": 2 недели чистой разработки

• Но модуль коммуникации нужно отрефакторить сначала: +1 неделя

• Итоговый estimate: 3 недели

Рефакторинг становится частью фичи, не отдельной задачей.

Подход 3: Tech Debt Backlog

Отдельный backlog для технического долга. Приоритизируется так же, как product backlog.

В каждом спринте:

• Берёте топ-приоритетные фичи из product backlog

• Берёте топ-приоритетные задачи из tech debt backlog

• Соотношение 70/30 или 80/20

Подход 4: Tech Debt как "Enabler"

В методологии SAFe есть концепция Enablers — работа, которая не приносит прямой ценности, но позволяет делать другие вещи.

Рефакторинг — Enabler. "Чтобы сделать фичи X, Y, Z быстро, нужен enabler: рефакторинг модуля A".

Рекомендация: комбинация подходов

• 20% времени: Базовый уровень (20% правило)

• Критичный рефакторинг: Включать в estimates фич

• Системные проблемы: Явная строка в roadmap раз в квартал

12. Реальные кейсы успешного баланса

Кейс 1: Shopify — постепенная модуляризация монолита

Проблема: Монолит на Rails 3M+ строк кода. Каждый деплой — 40 минут. Velocity падает. Команда растёт, код не масштабируется.

Решение:

• Не big bang rewrite, а постепенное выделение модулей

• 20% времени каждой команды на модуляризацию

• Фокус на hotspots (самые часто меняемые части)

• 3 года работы

Результат: Деплой с 40 минут до 5 минут. Velocity +40%. Количество инцидентов -60%. Смогли масштабировать команду с 50 до 200+ разработчиков.

Кейс 2: Stripe — "Fix-it Week" раз в квартал

Проблема: Быстрый рост, накопление технического долга. Разработчики fruстrated.

Решение:

• Раз в квартал — неделя "Fix-it Week"

• Вся компания (включая не-инженеров) работает над улучшениями

• Разработчики — на техдолг, продакты — на UX улучшения, дизайнеры — на design system

• Демо результатов в конце недели

Результат: Улучшение морали команды. Видимые результаты (рефакторинг + багфиксы + мелкие улучшения). Developer satisfaction вырос на 30%.

Кейс 3: SaaS стартап (анонимный) — 70/20/10 правило

Проблема: Команда 8 человек. Velocity упала с 48 SP/sprint до 32. Баги растут. Онбординг новых людей — 6 недель.

Решение:

• Внедрили 70/20/10: 70% фичи, 20% техдолг, 10% эксперименты

• 20% техдолга = 2 дня в спринте (из 10)

• Приоритизация техдолга через WSJF

• Отслеживание метрик: velocity, cycle time, bugs

Результат (через 6 месяцев): Velocity вернулась к 45 SP. Баги снизились на 40%. Онбординг — 3 недели. Команда счастливее.

13. Типичные ошибки менеджеров

Ошибка 1: "Сделаем потом"

"Сейчас некогда, сделаем после релиза / в следующем квартале / когда будет спокойнее".

"Потом" никогда не наступает. Всегда будет "срочная фича".

Решение: Выделяйте время системно (20% правило), а не "когда будет время".

Ошибка 2: "Это ваша проблема, решайте как-то"

Менеджер говорит: "Я не понимаю в коде. Это ваша работа — писать качественно. Разбирайтесь".

Технический долг — не проблема разработки. Это проблема продукта. Менеджер ответственен за создание условий для качественной работы.

Решение: Владейте проблемой вместе. Помогайте приоритизировать, защищайте время на рефакторинг.

Ошибка 3: Игнорирование метрик

Не отслеживаете velocity, cycle time, количество багов. Не замечаете ухудшение, пока не становится критично.

Решение: Дашборд метрик. Еженедельный обзор. Реагируйте на тренды рано.

Ошибка 4: "Давайте перепишем всё с нуля"

Противоположная крайность. "Код плохой? Давайте выделим год и перепишем всё на новом стеке".

Big bang rewrites проваливаются в 80% случаев. Это огромный риск.

Решение: Инкрементальный рефакторинг. Модуль за модулем.

Ошибка 5: Не верить метрикам от разработки

Разработка показывает: "Velocity упала на 30%". Менеджер: "Это субъективно, вы просто стали медленнее работать".

Недоверие разрушает отношения.

Решение: Проверяйте данные вместе. Если velocity упала — это объективный факт из Jira. Анализируйте причины совместно.

Ошибка 6: Рассматривать техдолг как "не-работу"

"Этот спринт мы делали рефакторинг = ничего не сделали = потеряли спринт".

Рефакторинг — это работа. Инвестиция в будущую скорость.

Решение: Считайте техдолг как такую же работу, как фичи. Измеряйте результаты (улучшение метрик).

14. Что запомнить

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

Ключевые выводы:

• Технический долг — это trade-off, не ошибка. Быстро сейчас vs быстро потом. Иногда долг оправдан (MVP). Но долг нужно погашать.

• Стоимость долга измерима. $200K на неэффективность, $480K упущенная выгода, $84K инциденты. Почти миллион в год для команды из 6 человек.

• Velocity падает реально. Это не "ощущение" разработчиков. Это данные из Jira. Падение на 30%+ — красный флаг.

• Говорите на одном языке. Разработчики — переводите техническое на бизнес. Менеджеры — учите базовый глоссарий.

• Системный подход к балансу. 20% правило + Boy Scout + целевые кампании = устойчивый баланс.

• Включайте техдолг в roadmap. Явно. Не "потом", а запланировано. 20% времени или отдельная строка в roadmap.

• "Потом" не работает. Выделяйте время системно. Иначе долг растёт до критичного уровня.

• Метрики — основа решений. Velocity, cycle time, bugs, dev satisfaction. Отслеживайте, реагируйте на тренды.

«Компании, которые игнорируют технический долг, движутся быстро вначале и медленно потом. Компании, которые управляют долгом, движутся стабильно быстро всегда» — Мартин Фаулер

Чек-лист для менеджеров:

1. ☐ Настроить дашборд метрик (velocity, cycle time, bugs)

2. ☐ Провести ретро с разработкой: обсудить текущее состояние техдолга

3. ☐ Посчитать стоимость технического долга (используя формулы из раздела 4)

4. ☐ Определить топ-3 проблемных области (hotspots)

5. ☐ Внедрить 20% правило: зарезервировать время на техдолг в спринтах

6. ☐ Добавить "Tech Health" как строку в квартальный roadmap

7. ☐ Создать Tech Debt Backlog и приоритизировать задачи (WSJF)

8. ☐ Обучить команду говорить на языке бизнеса (шаблон аргументации)

9. ☐ Запланировать quarterly review техдолга (каждый квартал оценивать состояние)

10. ☐ Подготовить презентацию для стейкхолдеров (если нужно защищать время)

Действия на эту неделю:

1. Поговорить с тимлидом: "Какие топ-3 проблемы с кодом сейчас?" (30 минут)

2. Посмотреть на velocity за последние 6 месяцев в Jira (10 минут)

3. Посчитать % времени на баги vs фичи (20 минут)

4. Договориться: выделить 20% следующего спринта на техдолг (1 встреча)

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

А лучшие вакансии для продакт-менеджеров и тимлидов ищите на hirehi.ru