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

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

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

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

Проблема не в самом техническом долге. Проблема в долге, который остаётся невидимым, незапланированным и накапливается сам по себе. Как и финансовый долг, он начисляет проценты: каждая новая функция, построенная поверх компромисса, делает его исправление дороже, а каждый месяц без внимания к нему увеличивает риск, что его устранение сломает что-то ещё.

Откуда он берётся

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

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

Издержки, которые никогда не попадают в баланс

Технический долг дорог именно потому, что его стоимость косвенна. Он редко появляется отдельной строкой в отчётности, и поэтому руководству так легко его недооценить.

Замедление разработки — самый распространённый симптом. Функции, которые должны занимать неделю, занимают месяц, потому что каждое изменение сначала требует обхода хрупкого кода. Со временем оценки становятся всё менее точными, и разработчики начинают закладывать запас, чтобы учесть неизвестный риск, скрытый в коде.

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

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

Упущенные возможности — наименее заметная и часто самая крупная издержка. Когда система не может поддержать функцию, которую уже предлагает конкурент, или перспективное партнёрство требует интеграции, которую никто не готов реализовать с уверенностью в надёжности, речь идёт не о тикете с багом. Речь идёт о рыночной возможности, которой компания не смогла воспользоваться вовремя.

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

Тревожные признаки, к которым стоит отнестись серьёзно

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

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

Как управлять техническим долгом, не останавливая бизнес

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

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

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

Формирование культуры, которая не даёт долгу накапливаться

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

Главный вывод

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