Техдолга не существует31.01.2024 14:15

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

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

Балансим техдолг и остальные задачи

Определение

Знай врага и знай себя: тогда в тысяче битв не потерпишь поражения
Сунь-цзы

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

Очень много определений и ссылок

…метафора программной инженерии, обозначающая накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем. Технический долг обычно незаметен для конечных пользователей продукта, а связан с недостатками в сопровождаемости, тестируемости, понятности, модифицируемости, переносимости.
— Технический долг (Wikipedia RU)

Это предполагаемая стоимость будущих доработок, необходимых при выборе простого, но ограниченного решения вместо лучшего подхода, который может занять больше времени.
— Technical debt (Wikipedia EN)

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

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

Технический долг — это разница между тем, что было обещано, и тем, что было поставлено в действительности.
— Что такое технический долг? (Atlassian)

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

Автор не приводит чёткого определения, но если я правильно понял — это все скрытые от глаз задачи
— Выявление техдолга и оценка его процентов (Habr)

Результат, который возникает, когда команды разработчиков предпринимают действия для ускорения поставки части функциональности или проекта, который впоследствии необходимо рефакторить. Другими словами, это результат приоритета скорости доставки над совершенством кода.
— Technical Debt (ProductPlan)

Это разница между идеальным техническим решением и тем решением, которое принимается сейчас
— Технический долг — бьем на части и ликвидируем. (MaxShulga)

Было выделено 10 категорий техдолга: Нужно обновление (технологий) или обновление в процессе, Документация, Тесты, Качество кода, Мёртвый код, Устаревший код, Недостаток экспертизы, Зависимости, Обновление не закончено, Процесс релиза
— How Google Measures and Manages Tech Debt (GetDX)

Спросите 10 человек, что такое техдолг. Сколько разных ответов вы получите? Три? Четыре? Семь?
— Stop saying «technical debt» (Stackoverflow Mozilla)

Проблемы в кодбазе, связанные с необходимостью иногда делать временные или недостаточно глубоко продуманные решения из-за нехватки времени в текущем объёме задач.
— Разработчик из опроса

Изменения в коде, не влияющие напрямую на ценность для внешнего пользователя, но возможно влияющее опосредованно. При этом эти изменения в коде имеют большую ценность для внутреннего пользователя
— Менеджер из опроса

Некритичное сейчас : poop:, в которое потом вляпаешься, если долго не убирать.
— Разработчик из опроса

Собрано 14 разных, иногда перекликающихся мнений о том, что такое техдолг. Если сократить:

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

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

Типы «техдолга»

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

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

Обновить версию технологии

Сюда относятся обновления версии языка/фреймворка/библиотеки и чего угодно.

На что данный тип задач может повлиять:

Удовлетворённость разработчиков — на самом деле очень важный пункт, который очень часто не учитывается в оценке. Согласно моему кругу общения, разработчики любят использовать свежие версии технологий, и, если не давать им этим заниматься, это может привести к выгоранию/снижению продуктивности/увольнению.
HR-brand — плавно вытекает из предыдущего пункта. Лично я бы несколько раз подумал, прежде чем откликаться на вакансию с Java 1.8.
Уровень доступности — в свежих версиях инструментах закрываются в том числе и уязвимости, эксплуатация которых может привести к простою вашего продукта.
Time-To-Market — иногда новые версии позволяют разрабатывать более эффективно, что сокращает время разработки

Перенести что-то на другую технологию

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

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

Рефакторинг

Думаю, многие, и я в том числе, произносили фразу: «Надо будет это отрефакторить». Объект для рефакторинга может появиться разными способами:

Сознательный компромисс между скоростью и качеством.
Изменившиеся бизнес-требования к продукту.
Новые практики в мире разработки.
Банально забыли предусмотреть какой-то вариант.

И да, этот пласт задач также влияет на бизнес-показатели:

Удовлетворённость разработчиков — никому не хочется работать с «плохой» кодовой базой. И если не приводить её в порядок, может начаться отток кадров.
Time-To-Market — как правило, плохой код сложно понять и сложно дорабатывать. Из-за чего возрастает время разработки фич нужных для бизнеса.

Исправление багов

Баги не нуждаются в дополнительном представлении, все с ними сталкивались, но всё-таки зафиксируем, на что они влияют:

Количество пользователей — если продукт работает не так, как ожидает пользователь, то он скорее всего выберет на рынке что-то другое.
Затраты на сопровождение — вытекает из прошлого пункта. Пользователь идёт в поддержку с багом, те эскалируют в разработку, и так раз за разом, пока баг не поправят.
Time-To-Market — немного неочевидный пункт. Но разработчик при создании решения может положиться на компонент, который должен работать определённым образом. Из-за багов это может превратиться в несколько итераций вида: сделал → не работает → разобраться в причине → повторить.
Прямые денежные потери — иногда эксплуатация багов может привести к непосредственным потерям бизнеса.

Отсутствие документации

Если какое-то поведение не документировано — то данная задача относится к этому типу.

Для бизнеса игнорирование таких задач может влиять в следующее:

Количество пользователей — без хорошей документации пользователь не сможет пользоваться вашим продуктом или будет постоянно натыкаться на неожиданное поведение.
Затраты на сопровождение — если пользователю что-то непонятно из документации, он идёт в поддержку, а те, в свою очередь, в разработку.
Time-To-Market — разработчики могут начать изобретать велосипеды для уже существующих, но недокументированных фичей.
Сложность бординга — без внятной документации новым разработчиком сложно разобраться в существующем продукте, что, в свою очередь, ведёт к образованию бас-фактора.

Поддержка работоспособности сервисов

Момент Х, когда сервис перестаёт работать. Протухание сертификата, перестал выдерживать нагрузку и всё, что влияет на непосредственную работу.

Оказываемое влияние:

Уровень доступности — чем дольше не работает сервис, тем ниже доступность.
Количество пользователей — при долгой неработоспособности люди начнут искать вам замену.
Time-To-Market — если вовремя не подстелить солому, то разработчикам придётся бросать свои текущие задачи и бежать поднимать упавшее.

Написание тестов

Думаю, здесь комментарии излишни.

На что могут повлиять тесты в разрезе бизнеса:

Уровень доступности — сценарии, которые не покрыты тестами, могут совершенно случайно сломаться в процессе разработки смежных компонент или, например, рефакторинга.
Time-To-Market — так же, как и с прошлым пунктом, разработчики могут потратить лишнее время, чтобы разобраться с неочевидными бизнес-сценариями.

Настройка метрик/мониторинга

Задачи, в результате которых нужно настроить метрики приложения и/или мониторинг этих метрик.

Казалось бы, довольно простая задача, которая влияет на важные вещи:

Уровень доступности — в отсутствии метрик очень сложно понять, что происходит с приложением: трудно заметить проблемы, своевременно на них среагировать и понять, куда копать.
Затраты на инфраструктуру — если приложение потребляет намного меньше ресурсов, чем ему выделено, то налицо ненужные расходы, а без метрик этого почти не заметить.
Понимание пользователя — метрики это довольно эффективный инструмент, чтобы понять, какие фичи востребованы, а какие — нет.
Time-To-Market — вытекает из уровня доступности. Метрики в том числе упрощают релиз приложения и мониторинг проблем. Чем лучше метрики, тем безопаснее и быстрее можно тестировать гипотезы.

Исправление логирования

К данному типу задач были отнесены сокращение количества WARN/ERROR, уменьшения общего количества логов, некорректная/недостаточная информация в логах.

На что данный тип задач может повлиять:

Уровень доступности — если логи захламлены ERROR’ами, то небольшой всплеск ошибок будет труднее заметить. Если же логов, наоборот, недостаточно, то по ним будет сложно понять, что не так. Всё это увеличивает время диагностики и простоя приложения.
Time-To-Market — это вытекает из диагностики проблем, так как приложение становится сложнее релизить.
Затраты на инфраструктуру — если приложение пишет много бесполезных логов, приходится платить за их хранение.

Выводы

Итак, было выделено 9 типов техдолга (возможно, их больше, но я с ними не сталкивался). Помните, я говорил, что провёл небольшой опрос? Даже в маленькой выборке ни один из этих типов не собрал 100%. Результаты ниже (там 10 пунктов, потому что ещё был вариант «Другое»):

Вопрос: «Отметьте типы задач, которые подходят под ваше понятие техдолга»

На первом месте ожидаемо рефакторинг, далее — обновление версий, а на третьем, неожиданно для меня, отсутствие документации.

Но независимо от того, что ни одна задача не набрала 100% голосов, необходимо заметить, что все они напрямую влияют на бизнес. А если они влияют на бизнесовые показатели, то кажется, что эти задачи не надо выделять в отдельную категорию.

Альтернатива

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

Не создавать техдолг

Нет техдолга — нет проблем! И в этом нам поможет такая замечательная практика как DOD, которую мы успешно применяем в нашем продукте. Теоретически, туда можно записать что угодно, но приведу то, чем мы пользуемся в данный момент:

Есть тесты (минимальное покрытие 80%)
Настройка метрик
Написана документация

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

Отстаньте от разработчиков

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

Разработчик тоже заказчик

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

Общий бэклог

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

И, на самом деле, часть материалов, которые я привёл в начале, в итоге в том или ином виде сводятся к идее общего бэклога.

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

Послесловие

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