Технический долг: как говорить о нём с командой и принимать решения

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

Я видел обе стороны этого разговора достаточно раз, чтобы иметь мнение о том, почему он не работает - и как его починить.

Почему разговор о техдолге не работает

Разработчики говорят о техдолге в терминах, которые понятны только им: "монолит", "спагетти-код", "устаревшие зависимости". Для нетехнического руководителя это звучит как описание проблемы без понятного следствия.

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

Проблема не в том, что кто-то не прав. Проблема в том, что разговор ведётся на разных языках.

Язык, который работает

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

Вместо "у нас устаревшая архитектура" - "любое новое изменение занимает в три раза больше времени, чем должно, и каждое второе изменение ломает что-то ещё".

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

Вместо "у нас монолит" - "добавление новой команды разработчиков не ускоряет работу, потому что все изменяют один и тот же кусок кода".

Это не упрощение - это перевод технического факта в бизнес-следствие.

Как принимать решения о техдолге

Не весь технический долг одинаково критичен. Полезная классификация:

Первый класс - долг, который активно замедляет текущую работу. Это приоритет.

Второй класс - долг, который создаёт риски: безопасность, надёжность, соответствие требованиям. Это тоже приоритет, но другого рода.

Третий класс - долг, который теоретически плох, но практически не мешает прямо сейчас. Это можно откладывать.

Задача руководителя - убедиться, что команда делает это различие явным и не смешивает всё в одну категорию "нам надо рефакторить".

Практические вопросы

Если разработчики говорят о техдолге, стоит задать:

• Что конкретно происходит сейчас из-за этого долга? Медленные релизы, частые баги, невозможность реализовать конкретную функцию?
• Что произойдёт, если мы не займёмся этим в ближайшие три месяца? Ничего, станет хуже, или это заблокирует что-то конкретное?
• Каков минимальный объём работы, который снимет главную боль?
• Как мы поймём, что проблема решена?

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