Технический долг? О чем вы вообще говорите?

Часто можно услышать, что в проекте большой технический долг. А что это? Насколько он большой? В чем измеряется? Разобрались в статье.

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

Если вы попытаетесь поискать ответ на этот вопрос в интернетах, то обнаружите чушь вроде этой: "Технический долг – это долг, который накапливается из-за принятия неидеальных технических решений, и должен погашаться через рефакторинг." Неидеальных?! Кто видел идеальные решения хоть где-либо? И как оценить расхождение с идеальным решением? Нет! Это все словоблудие, беспредметный треп ни о чем!

В ТРИЗ (теории решения изобретательских задач) существует понятие идеального объекта: Идеальный объект – это объект, которого нет, но функция которого выполняется. Если взять это определение идеального, то весь код, что мы пишем – сплошной технический долг. Но в чем его измерять? В строках? В выражениях? В сложности синтаксического дерева или в количестве вершин и граней графа вычислений? Это сложный и запутанный путь в никуда!

Так что же такое технический долг? (дубль два)

Технический долг – это осознанное и задокументированное решение не делать что-то сейчас. Допустим, есть компания, и у нее есть множество аккаунтов сотрудников. Пока все хорошо и просто. Но! Сотрудник ведь может быть в нескольких компаниях! Как ему между ними переключаться? Или стоит объединить данные из нескольких компаний на одном единственном рабочем экране?

Отвлечемся немного от этой задачи. Действительно ли мы сейчас должны принимать какое-либо решение о реализации? Или мы можем инвестировать время и другие ресурсы во что-то более важное? Каким вообще образом все эти переключения или агрегация данных из нескольких компаний могут принести нашей собственной компании прибыль? Это ли то, что мы продаем? Интересно ли нам этим заниматься? Ответ: Нет! Это не создает ценности, но лишь улучшает опыт сотрудников в достаточно редких случаях. При этом, наш клиент — компания, а не сотрудник. Нам важно, чтобы был счастлив тот, кто платит деньги, а не какой-то случайный человек. В противном случае мы ничего не добьемся в попытках всем угодить. Так и запишем:

Только одна компания на аккаунт! Tags: account, auth. Аккаунты находятся под одной конкретной компанией и не шарятся между компаниями. Если пользователь желает работать в нескольких компаниях, ему понадобится завести по аккаунту для каждой из них. Мы понимаем неудобства некоторых пользователей и принимаем их, поскольку данный элемент пользовательского опыта является вторичным и значительно выходит за пределы нашего ценностного предложения.

Этому все еще нельзя присвоить численную оценку, да и не нужно. Быть может, мы никогда не дойдем до необходимости погашать этот технический долг. Мы задокументировали это решение и время от времени вспоминаем о нем, мы даже можем дописывать к нему пожелания клиентов о реализации такой возможности, однако это вовсе не обязывает нас его "погашать". Мы просто помним о принятом нами решении, помним его аргументацию и дописываем в него пожелания пользователей или связанные с ним НЕ-технические проблемы, вроде: “Компания X отказалась от подписки на наш сервис по причине отсутствия данной функциональности. Контракт мог бы приносить нам ~$20000 в год”. Вот здесь и появляются какие-то внятные числа. А $20000 – это много или мало? Вам решать! Принимать такие решения стоит исходя из текущего вектора развития компании и предполагаемого ROI (который легко может оказаться ошибкой).

Итог

Теперь многим, кто ошибался насчет технического долга, должны стать понятны следующие моменты:

1. В большинстве случаев “технический долг” подразумевает не технический долг, а низкое качество кода и отсутствие культуры у разработчиков.

2. Технический долг вовсе необязательно погашать. Более того, большую его часть лучше вообще никогда не погашать, потому как погашение непременно увеличит сложность проекта, создаст новые дефекты и векторы атаки.

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

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

P.S. Больше моих публикаций об ИТ, разработке и программировании вы сможете найти в моем телеграм-канале IT Rampage.