В прошлых публикациях мы говорили о пользе технического времени и опасности core‑команд. Сегодня разберём ещё одну важную тему — технический долг.

Почему термин «технический долг» вводит в заблуждение

Сразу скажу: сам термин мне не нравится. Он сбивает с толку. Когда мы говорим «технический долг», у владельцев продуктов и даже у разработчиков возникает ощущение, что это какая‑то особая категория задач — и раз он «технический», то и возвращать его можно за счёт технического времени. Или ещё хуже — переложить на «специальных людей»: core‑команду, отдел качества и/или команду поддержки.

На практике это работает так: продуктовая команда торопится сдать функционал к жёсткому дедлайну. В спешке нарушают процессы, пишут код с ошибками, обходят технические нормы проекта и нормы безопасности— лишь бы успеть. А потом спокойно передают эстафету: «Теперь пусть core‑команда разгребает».

И что в итоге?

Продуктовая команда привыкает работать в таком режиме. Зачем тратить время на качественное проектирование, если всё равно кто‑то потом «подчистит»? Единственный критерий успеха — скорость. Чем быстрее сдал — тем лучше, премия выше. А последствия? — Пусть разбираются другие.

Мы заранее понимали опасность такого подхода и отношения.

Наш подход: ответственность вместо перекладывания

Просто, но жёстко: в техническое время мы категорически отказывались исправлять долги продуктовых команд. Техническое время — не для уборки, а для развития. Его задача — долгосрочное увеличение эффективности, а не затыкание дыр, пробитых в спешке.

Вместо этого мы выстроили систему, в которой каждая команда несёт полную ответственность за свой код: - если команда допустила ошибку или пошла на компромисс в качестве ради скорости — она же и должна её исправить; - мы ввели правило: перед тем как взять новую задачу, команда должна закрыть свои старые долги — иначе новый долг будет только нарастать; - поощряли инициативы по улучшению процессов (ссылка на пост про 20% технического времени), но только если они масштабируются на проект в целом, а не просто «подлатали» локальную проблему.

Результаты: что изменилось в команде и продукте

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

Во‑вторых, сократилось количество ошибок в новых фичах. Разработчики начали закладывать больше времени на проектирование, потому что знали: потом «переделывать» будет дороже.

В‑третьих, выросла вовлечённость. Команды перестали перекладывать ответственность и начали гордиться своим кодом — не только новыми фичами, но и стабильностью, надёжностью, чистотой архитектурой.

Да, поначалу было непросто. Некоторые команды сопротивлялись: «У нас же сроки горят!» Но мы стояли на своём: качество — это часть сроков. Нельзя выиграть минуту сейчас и проиграть час потом.

Со временем это стало частью нашей культуры. Мы перестали воспринимать технический долг как «что‑то, что когда‑нибудь починят другие». Мы поняли: технический долг — это долг перед самим собой, перед командой, перед продуктом. И возвращать его нужно не откладывая, силами тех, кто его создал. А еще лучше – не допускать изначально! Приятным бонусом стало вхождение в наш обиход слова «техразвитие» в добавок к «техдолгу». Первое слово стало приветствоваться, второе – стало выходить из оборота.

Запомните: технические специалисты не ассенизаторы!

А как у вас? Есть ли в вашей компании проблема технического долга? Как вы с ней боретесь? Делитесь в комментариях — будет интересно обсудить!

Не переключайтесь! В следующем посте разберём самую частую задачу, которую относят к техдолгу, — рефакторинг. Когда он действительно нужен и приносит пользу, в каких случаях он превращается в бездонную яму для ресурсов, чем заменить слепое «переписывание со старого на новое», чтобы не тратить драгоценное техническое время впустую.