Давайте договоримся о тех.долге
— Нам нужно выплачивать тех.долг!
— У нас нет на это ресурсов, нам нужно выпустить новую фичу!
Знакомый диалог? Давайте поговорим про технический долг и про то, как он влияет на бизнесовые цели. И на выпуск новых фичей
Что такое технический долг?
Вот определение от chatgpt:
Технический долг — это неизбежная часть разработки любого программного обеспечения. Он возникает, когда команда принимает решение обойтись временным решением или сознательно упрощает реализацию, чтобы быстрее выпустить функциональность. Но, как и финансовый долг, технический долг требует «выплаты процентов» в виде снижения эффективности команды и увеличения затрат на поддержку системы.
Давайте объясню на простых примерах:
Код. В начале проекта программисты написали слабоструктурированный код без разделения на модули, чтобы быстрее запустить продукт. Но по мере роста функциональности изменения стали требовать всё больше времени, так как разобраться в таком коде крайне сложно, да и сильная связанность начинает приводить к большому количеству ошибок.
Тесты. Чтобы успеть к дедлайну, команда пропустила написание автоматических тестов. А через полгода каждый релиз стал сопровождаться неожиданными ошибками, так как невозможно быстро проверить все сценарии.
База данных. На этапе проектирования было принято быстрое, но неоптимальное решение по структуре данных. Но спустя время количество записей в базе данных выросло и даже простые sql-запросы стали работать очень долго.
Зачем тратить на него время?
Короче, не уделяя достаточно времени на работу с тех.долгом компания может столкнуться с замедлением разработки, деградацией качества продукта и неоптимальным ростом затрат на инфраструктуру. Да и команде работать с кодом низкого качества, мягко скажем, неприятно и это их демотивирует.
Пример из практики:
Некая компания, которая долгое время игнорировала технический долг, потому что «надо побыстрее», осознала, что даже незначительная функциональность требует месяцев работы. Пока разобрались, пока сообразили, пока переписали половину модулей с нуля, конкуренты убежали далеко вперед.
Казалось бы все очевидно — никто в здравом уме не захочет замедления разработки и ухудшения своего продукта. Но почему-то многие компании игнорируют эту проблему и копят долги годами. Вижу две ключевые причины:
Работа над тех.долгом это затраты прямо сейчас, а профит когда-то там в будущем. В то же время разработка новой фичи это и затраты, и профит прямо сейчас. Легко впасть в ловушку быстрого результата, не думая о долгосрочных перспективах.
Работа над тех.долгом, в отличие от фичей, крайне сложно поддается измерению. Вернее, затраты мы можем посчитать очень легко, а вот профит — вообще непонятно как. В каких деньгах можно выразить повышение читабельности кода? Или как можно сравнить задачу по написанию юнит-тестов с задачей запуска акции к Черной пятнице?
Про вторую причину и поговорим.
Почему договориться так тяжело?
Оценить пользу технического долга в понятных для бизнеса метриках крайне сложно, если вообще возможно. В отличие от новых функций, его влияние трудно измерить в деньгах или количестве пользователей. Поэтому многие компании выделяют фиксированное время — например, 20% спринта — на его выплату. Но это тоже не всегда работает, потому что «чего вы там опять рефакторить собрались непонятно, на какие цели это повлияет неясно, давайте сейчас фичи запилим, а про тех.долг в следующем квартале после релиза обсудим». Короче тут бизнес и технари вообще друг с другом на разных языках говорят и достаточно плохо договариваются.
И что же делать?
Тем не менее, есть вариант, как им найти общий язык и договориться о справедливом выделении времени на тех.долг. Честно говоря, и самим технарям этот способ хорошо помогает правильно оценивать и приоритезировать свой беклог тех.долга.
Открываем любую модель качества программного обеспечения, например ISO 25010, в которой перечислены важные аспекты качества программного обеспечения. Например, Recoverability — способность системы восстанавливаться после сбоя, Modifiability — готовность системы к быстрому внесению изменений без ухудшения качества, или Confidentiality — защищенность данных от доступа третьими лицами. В общем, это перечень характеристик ПО, которые легко понять нетехнарю.
Собираем табличку с этими характеристиками и на совместном созвоне технарей и бизнеса проставляем приоритет каждой характеристике. Нам важнее защищенность данных, чем удобство установки? Значит Confidentiality ставим выше, чем Installability. Бизнес хочет быстро развиваться ценой инвестиций? Ставим Modifiability выше Resource utilization. И так далее
После этого размечаем беклог тех.долга по степени влияния на каждую из самых важных характеристик, например по 10-балльной шкале. Скажем, у нас есть задача на рефакторинг структуры БД, которая сильно повысит скорость выполнения запросов и немного повысит читаемость. Тогда ставим десятку напротив Time behaviour и троечку у Modifiability. Разработка хочет порефаторить код, чтобы немного улучшить читаемость кода и сильно проще покрывать его авто-тестами? Ставим по пятерку у Analysability и восьмерку у Testability. Перемножив приоритет характеристики на степень влияния конкретной задачи получим суммарный вклад каждой задачи.
А дальше в табличку вносим оценку трудозатрат по каждой задаче и степень уверенности в результате. Применяем какой-нибудь ICE и получаем отприоритезированный беклог по тем параметрам, которые понятны и бизнесу, и технарям. Имея такой беклог гораздо проще объяснить зачем нам что-то рефакторить и на что это повлияет, даже не имея оценок на деньги.
Заключение
В общем, технический долг — это неизбежная часть работы любой команды разработки. И он не является проблемой, пока с ним работают. А вот его игнорирование неизбежно приведёт к снижению скорости и ухудшению качества.
Грамотное управление долгом — это баланс между разработкой нового и улучшением текущего, который в долгосрочной перспективе делает компанию сильнее.