Что такое технический долг и как компаниям с ним справляться?

Техдолг или legacy?

Разберемся с определениями. Есть понятие legacy — это морально устаревшие решения/технологии, которые по каким-то причинам сохранились в проекте. Например, к legacy относятся сайты, написанные на устаревших версиях языков программирования, например, PHP-версии ниже 5.0. Legacy обычно крутится где-то в закромах. Менять что-то на таких участках страшно, потому что последний человек, который хорошо знал, как там все устроено, уволился много лет назад.

Руководитель IT почти все время был занят тем, что восстанавливал данные, потерянные при ежедневной миграции между Paradox и MySQL, поэтому завершить переезд второй половины IT-системы он не мог.

Под техническим долгом понимают другое. Эту метафору предложил программист Уорд Каннингем в 1992 году, подразумевая компромисс, на который идут разработчики и заказчик, чтобы получить быстрый, но не оптимальный результат. Выплата долга — это переписывание кода. Трата времени на код с существенными недостатками является выплатой процентов по займу.

Техдолг влияет на скорость разработки

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

Здесь можно провести параллель с генеральной уборкой в квартире. В любой технологически сложной системе накапливается определенный объем регламентных работ: их, как и генеральную уборку, в принципе, можно отложить на потом. Задача несрочная, а времени на нее ни у кого нет. Но если откладывать слишком долго, результат будет плачевным.

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

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

Пять признаков разросшегося долга

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

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

• Уменьшилась скорость добавления новых фич, постоянно всплывают новые ограничения.
• Разработчики все чаще отвечают на задачи фразами вроде: «Если мы изменим что-то здесь, то все сломается».
• На некоторых участках bus factor = 1: если один из программистов не сможет выполнять свою работу, то остановится весь проект.
• Падает скорость разработки в скрам-команде (метрика velocity).
• Скопилось слишком много участков кода с комментариями to do.  

Ищите ответственного

Во многих компаниях ответственность за техдолг падает на product owner. Это плохое решение. За год я успеваю поработать с десятками владельцев продуктов, и замечаю, что там, где product owner ответственен за технологии, применяют устаревшие решения — примерно тех времен, когда продакт еще был айтишником (если был). Я знаю систему, которая еще даже не вышла в продакшен, но ее уже можно списывать — она морально устарела.

Если продакт не подкован в технологиях, он идет за советом к коллегам. В больших компаниях есть специальные подразделения, в которых сидят энтерпрайз-архитекторы, и product owner часто пользуется таким «коммунальным» ресурсом.

По заявке архитекторы, конечно, могут чем-то помочь, но их главная задача — не усложнить ландшафт всей компании. Что внутри конкретного продукта, их не так волнует. Они погружаются ровно настолько, насколько нужно для выполнения запроса: через два часа у них уже другой сервис на ревью. Естественно, ни о каком погружении в интересы продукта и оценке его состояния речи не идет.

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

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

Овердрафт на год

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

Если в команде работают хотя бы десять программистов, угнаться за ними нелегко: технический долг копится быстрее, чем они успевают рефакторить код. В любом случае велики риски, что через год-два придется переписывать продукт практически с нуля, если изначально были выбраны неверные методы работы с экспериментальными решениями.

Не влезайте в долги раньше времени

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

1. Делайте одноразовые прототипы MVP и только подтвержденные гипотезы включайте в работу.
2. Создавайте архитектуру, которую будет просто изменить: микросервисы, API с версионированием.
3. Откажитесь от организации собственных серверных в пользу облачных решений. Например, Microsoft Azure, AWS Amazon Cloud, «Яндекс.Облако», облако от Mail.ru и так далее.
4. Установите в команде четкий definition of done, включающий в том числе метрики качества. Очень помогает включить в DOD пункт, исключающий «приемку» фичи, если есть связанные с ней баги.
5. Для MVP хорошо проектировать систему так, чтобы миграция пользователей с прототипов на стабильную часть была незаметной.

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

Вернуть долг все равно придется

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

Фото: Unsplash

Компании справляются с техдолгом по-разному. Основных стратегий три.

1. Переписывают все с нуля. Это ультимативный способ поддерживать систему в состоянии, когда она постоянно готова к изменениям, если все зашло слишком далеко и уже нет прежней гибкости.
2. Делают постепенный рефакторинг. Задачи по техдолгу отправляются в бэклог наравне с продуктовыми задачами. Это замедляет работу по выкатке новых фич, но бизнес обычно идет на компромиссы.
3. Смиряются с техдолгом. Если у вас не стартап, а обновления нужны раз в полгода, то можно просто смириться с тем, что код неоптимален, и действовать по принципу «работает — не трогай». Как только поймете, что ошиблись, вы так или иначе переместитесь к пункту 1.

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