Давайте договоримся о тех.долге

— Нам нужно выплачивать тех.долг!
— У нас нет на это ресурсов, нам нужно выпустить новую фичу!
Знакомый диалог? Давайте поговорим про технический долг и про то, как он влияет на бизнесовые цели. И на выпуск новых фичей

Что такое технический долг?

Вот определение от chatgpt:

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

Давайте объясню на простых примерах:

• Код. В начале проекта программисты написали слабоструктурированный код без разделения на модули, чтобы быстрее запустить продукт. Но по мере роста функциональности изменения стали требовать всё больше времени, так как разобраться в таком коде крайне сложно, да и сильная связанность начинает приводить к большому количеству ошибок.

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

• База данных. На этапе проектирования было принято быстрое, но неоптимальное решение по структуре данных. Но спустя время количество записей в базе данных выросло и даже простые sql-запросы стали работать очень долго.

Зачем тратить на него время?

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

Пример из практики:

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

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

1. Работа над тех.долгом это затраты прямо сейчас, а профит когда-то там в будущем. В то же время разработка новой фичи это и затраты, и профит прямо сейчас. Легко впасть в ловушку быстрого результата, не думая о долгосрочных перспективах.

2. Работа над тех.долгом, в отличие от фичей, крайне сложно поддается измерению. Вернее, затраты мы можем посчитать очень легко, а вот профит — вообще непонятно как. В каких деньгах можно выразить повышение читабельности кода? Или как можно сравнить задачу по написанию юнит-тестов с задачей запуска акции к Черной пятнице?

Про вторую причину и поговорим.

Почему договориться так тяжело?

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

И что же делать?

Тем не менее, есть вариант, как им найти общий язык и договориться о справедливом выделении времени на тех.долг. Честно говоря, и самим технарям этот способ хорошо помогает правильно оценивать и приоритезировать свой беклог тех.долга.

1. Открываем любую модель качества программного обеспечения, например ISO 25010, в которой перечислены важные аспекты качества программного обеспечения. Например, Recoverability — способность системы восстанавливаться после сбоя, Modifiability — готовность системы к быстрому внесению изменений без ухудшения качества, или Confidentiality — защищенность данных от доступа третьими лицами. В общем, это перечень характеристик ПО, которые легко понять нетехнарю.

2. Собираем табличку с этими характеристиками и на совместном созвоне технарей и бизнеса проставляем приоритет каждой характеристике. Нам важнее защищенность данных, чем удобство установки? Значит Confidentiality ставим выше, чем Installability. Бизнес хочет быстро развиваться ценой инвестиций? Ставим Modifiability выше Resource utilization. И так далее

3. После этого размечаем беклог тех.долга по степени влияния на каждую из самых важных характеристик, например по 10-балльной шкале. Скажем, у нас есть задача на рефакторинг структуры БД, которая сильно повысит скорость выполнения запросов и немного повысит читаемость. Тогда ставим десятку напротив Time behaviour и троечку у Modifiability. Разработка хочет порефакторить код, чтобы немного улучшить читаемость кода и сильно проще покрывать его авто-тестами? Ставим по пятерку у Analysability и восьмерку у Testability. Перемножив приоритет характеристики на степень влияния конкретной задачи получим суммарный вклад каждой задачи.

4. А дальше в табличку вносим оценку трудозатрат по каждой задаче и степень уверенности в результате. Применяем какой-нибудь ICE и получаем отприоритизированный беклог по тем параметрам, которые понятны и бизнесу, и технарям. Имея такой беклог гораздо проще объяснить зачем нам что-то рефакторить и на что это повлияет, даже не имея оценок на деньги.

Заключение

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

Грамотное управление долгом — это баланс между разработкой нового и улучшением текущего, который в долгосрочной перспективе делает компанию сильнее.