Вернуться к блогу
Hola, Amigos! На связи Дмитрий Прохоров, руководитель Битрикс-направления в Amiga.
За годы работы над digital-проектами мы не раз сталкивались с одной и той же ситуацией: продукт запущен, бизнес растет, аудитория увеличивается, а внутри системы начинают накапливаться сложности, которых раньше никто не замечал.
Разработка замедляется, сайт хуже справляется с нагрузкой, а новые функции требуют все больше времени и ресурсов. Почти всегда в этот момент в разговоре появляется термин «технический долг».
Обычно техдолг становится заметен не на старте, а когда продукт уже начал приносить деньги. Сначала меняются сроки: небольшие задачи требуют больше согласований, проверок и доработок. Затем растет стоимость изменений, а команда все чаще закладывает дополнительное время на риски. В этот момент становится понятно, что проблема не в одной задаче, а в накопившихся компромиссах.
Если упростить, технический долг – это последствия решений, которые в конкретный момент помогают бизнесу двигаться быстрее, но в дальнейшем могут усложнить развитие продукта.
В реальных проектах команда почти всегда работает в условиях ограничений: сроков, бюджета, бизнес-задач или неопределенности самого продукта.
Например, компании важно выйти в релиз к началу рекламной кампании. В такой ситуации часть решений откладывается на потом, а архитектура строится не под все возможные сценарии, а под текущие задачи. Функция работает, бизнес получает результат, проект продолжает развиваться.
На старте такой компромисс может быть полностью оправдан. Но через некоторое время временное решение начинает мешать: его сложно дорабатывать, тестировать и передавать новым специалистам. Чем дольше продукт развивается без пересмотра таких решений, тем больше последствий накапливается.
При этом технический долг не обязательно означает, что система работает неправильно. Сайт может выполнять свои задачи, но каждое следующее изменение будет требовать больше времени, ручных проверок и дополнительных доработок. Если изменения уже требуют ручных проверок и согласований, работу лучше переводить в план поддержки и развития продукта.
Есть мнение, что технический долг возникает только там, где проектом занимаются слабые специалисты или процессы выстроены хаотично.
Но он появляется и в проектах с сильной командой. Команде может потребоваться быстро проверить гипотезу, успеть к запуску рекламной кампании или уложиться в ограниченный бюджет. Бывает, что бизнес меняет приоритеты уже во время разработки, а продукт растет быстрее, чем предполагалось на старте.
В таких условиях компромиссное решение не обязательно является ошибкой. Оно может помочь быстрее запустить продукт, проверить спрос и не тратить бюджет на функции, которые могут не понадобиться. Проблема начинается, когда требования к системе меняются, а прежние ограничения не пересматриваются и постепенно начинают мешать развитию.
Технический долг может быть осознанным. В этом случае команда понимает слабые места выбранного решения, фиксирует риски и планирует вернуться к ним позже.
Бывает и неосознанный долг. Например, на старте невозможно было предсказать будущую нагрузку, используемая технология устарела или несколько независимых доработок постепенно усложнили первоначально понятную логику.
При этом технический долг накапливается не только в коде.
Область | Как проявляется | Последствие для бизнеса |
Архитектура | Для одной доработки приходится менять несколько связанных модулей | Растут сроки и стоимость разработки |
Инфраструктура | Серверы и внутренние системы не справляются с увеличившейся нагрузкой | Возникают сбои во время рекламных кампаний и сезонных пиков |
Безопасность | Используются устаревшие библиотеки, компоненты или способы защиты данных | Возникает риск уязвимостей и необходимости срочных обновлений |
Код | Логика становится сложной для понимания, изменения и тестирования | Повышается риск ошибок, даже небольшие задачи требуют больше времени |
Тестирование | Критичные сценарии проверяются вручную или не проверяются полностью | Релизы занимают больше времени, увеличивается вероятность ошибок |
Документация | Изменения в системе не фиксируются, документация перестает соответствовать проекту | Новым специалистам сложнее подключаться к проекту |
Экспертиза команды | Критичные знания сосредоточены у одного разработчика | Проект становится зависимым от конкретного человека |
Управление | Временные решения не фиксируются и не пересматриваются | Бизнес поздно узнает об ограничениях системы |
На первых этапах эти ограничения могут быть почти незаметны. Сайт работает, функции выпускаются, а задачи закрываются в привычные сроки. Но по мере роста продукта последствия начинают складываться.
Команде приходится дольше разбираться в связях между модулями, проверять больше сценариев и обходить ограничения старых решений. Оценки становятся менее точными, релизы – более сложными, а часть времени уходит не на развитие продукта, а на сохранение его текущей работоспособности.
Для бизнеса технический долг проявляется не в качестве кода как таковом, а в понятных показателях: сроках, стоимости разработки, стабильности, скорости запуска новых функций и предсказуемости проекта.
Поэтому сам факт наличия техдолга еще не означает, что проекту нужна полная переработка. Важнее понимать, какие ограничения уже влияют на бизнес, какие риски они создают и что произойдет, если продолжать их откладывать. На этом этапе помогает системный анализ: он показывает зависимости между модулями, риски и точки, где изменение сильнее всего влияет на бизнес.
В Amiga мы начинаем не с кода, а с бизнес-контекста. Нам важно понять, где продукт теряет скорость, деньги или управляемость, а уже потом выбирать техническое решение.
Разберем пример из проектов, с которыми мы работаем в Amiga.
Интернет-магазин развивался около семи лет. За это время каталог вырос до 100 тысяч товаров, появились региональные версии, интеграции с 1С, CRM, платежными сервисами и службами доставки. Над сайтом в разные периоды работали несколько команд.
Внешне все выглядело нормально: покупатели оформляли заказы, каталог обновлялся, маркетинг запускал акции. Но развитие проекта постепенно замедлялось, а сайт начинал тормозить.
Небольшая доработка корзины занимала уже не три дня, а одну-полторы недели. После изменений приходилось вручную проверять десятки связанных сценариев.
Обновление каталога создавало повышенную нагрузку, а перед крупными рекламными кампаниями команда старалась не выпускать релизы без крайней необходимости.
Для бизнеса проблема звучала просто: сайт работает, но каждое изменение становится дороже и рискованнее.
Мы не стали сразу предлагать новую архитектуру или перенос проекта на другую платформу. Сначала нужно было определить, где именно возникают задержки и какие из них действительно влияют на продажи.
Вместе с командой клиента мы выделили критичные сценарии:
После этого изучили код связанных модулей, настройки инфраструктуры, журнал ошибок, интеграции и процесс выпуска релизов. Отдельно посмотрели, какие части системы документированы и от каких специалистов зависит их поддержка. Так команда понимает, какие решения нужно описать в техническом задании, а какие можно оставить в бэклоге.
Проблема оказалась не в одном неудачном модуле, а в цепочке накопившихся ограничений.
Обновление каталога запускало ряд тяжелых операций сразу для всех регионов. Пока товаров было немного, это не мешало работе. После роста каталога обмен начал создавать заметную нагрузку на базу данных.
Логика расчета скидок находилась в нескольких местах. Одни правила применялись в каталоге, другие - в корзине, третьи добавлялись непосредственно перед созданием заказа. Изменение одной акции могло повлиять на сценарий, о котором разработчик не знал.
Часть интеграций была построена на обработчиках событий без единого описания последовательности вызовов. Разобраться в обмене мог только специалист, который участвовал в его создании.
Сам выпуск релиза тоже оставался в основном ручным. Команда проверяла изменения по тест-кейсам, но автоматических тестов для корзины и оформления заказа не было.
Каждая из этих проблем по отдельности не останавливала работу сайта. Вместе они делали любые изменения непредсказуемыми.
Мы не включили все найденные проблемы в один большой проект. Это заняло бы несколько месяцев и остановило развитие продукта.
В первую очередь выбрали задачи, связанные с ближайшей рекламной кампанией и оформлением заказов:
Другие задачи, например переработку отдельных внутренних модулей, оставили в реестре технического долга. Они не влияли на текущие продажи и не требовали срочного вмешательства.
Приоритет определялся не сложностью кода, а возможными последствиями для бизнеса. Ошибка в редко используемом административном разделе могла подождать. Риск неправильной цены в корзине – нет. Критичные сценарии после таких изменений лучше закрывать тестированием, чтобы бизнес видел не только скорость релиза, но и уровень риска.
Обновление каталога разделили на отдельные операции и убрали действия, которые без необходимости выполнялись при каждом обмене. Для наиболее тяжелых запросов скорректировали структуру данных и индексы.
Расчет скидок не переписывали полностью. Сначала вынесли общие правила в единый сервис и постепенно подключили к нему каталог, корзину и оформление заказа. Это позволило убрать расхождения без одномоментной замены всей логики.
Для критичных интеграций добавили журналирование и уведомления об ошибках. Раньше проблема могла обнаружиться только после обращения менеджера или покупателя. Теперь команда видела сбой сразу и понимала, на каком этапе он произошел.
Основные сценарии корзины и оформления заказа закрыли автоматическими тестами. Не весь проект, а только те участки, где ошибка напрямую влияла на продажи.
Параллельно обновили документацию по интеграциям и передали знания нескольким специалистам. Это не изменило работу сайта для пользователя, но снизило риск остановки проекта из-за отсутствия одного разработчика.
После первого этапа время обновления каталога сократилось примерно в 2 раза, а пиковая нагрузка во время обмена стала заметно ниже. Команда смогла выпускать изменения в корзине без полной ручной проверки всех сценариев.
Средний срок доработок в связанных модулях сократился до нескольких дней. Перед следующей рекламной кампанией проект не пришлось замораживать: релиз выпустили по обычному процессу.
Именно так мы предлагаем работать с техническим долгом: сначала связать технические ограничения с конкретными последствиями для бизнеса, затем определить приоритеты и только после этого выбирать решение.
Иногда потребуется серьезная переработка архитектуры. Иногда достаточно оптимизировать один процесс, добавить контроль ошибок или зафиксировать знания команды. Важно, чтобы решение соответствовало масштабу проблемы, а бизнес понимал, почему задача выполняется сейчас и что произойдет, если ее отложить.
Технический долг нельзя закрыть один раз и навсегда. Поэтому после первого этапа оставшиеся задачи фиксируются в общем плане развития проекта. К ним возвращаются перед крупными релизами, сезонными пиками и запуском новых направлений. Так ограничения системы не становятся неожиданностью, а работа с ними остается предсказуемой.
Технический долг – это накопленные технические ограничения в проекте, которые раньше помогли быстрее запустить продукт, но позже начинают замедлять разработку, повышать стоимость изменений и увеличивать риск ошибок.
Он появляется из-за сжатых сроков, ограниченного бюджета, быстрых запусков, изменения бизнес-приоритетов, роста нагрузки, устаревших технологий или недостатка документации. Сам по себе технический долг не всегда означает ошибку команды.
Он влияет на сроки доработок, стоимость разработки, стабильность сайта или приложения, скорость релизов и предсказуемость проекта. Чем дольше ограничения не учитывать, тем дороже становится развитие продукта.
Нет. Часть задач можно оставить в реестре технического долга и вернуться к ним позже. В первую очередь стоит решать проблемы, которые влияют на продажи, стабильность, безопасность, критичные сценарии и запуск важных кампаний.
Обычно появляются повторяющиеся признаки: небольшие задачи занимают все больше времени, релизы становятся рискованными, сайт хуже выдерживает нагрузку, ошибки возникают после простых изменений, а разобраться в системе может только один специалист.
Нет. Он может накапливаться в архитектуре, инфраструктуре, тестировании, документации, интеграциях, процессах управления и экспертизе команды. Иногда проблема не в коде, а в том, что знания о системе нигде не зафиксированы.
Осознанный технический долг команда принимает как временный компромисс: фиксирует риски и планирует вернуться к задаче позже. Неосознанный долг появляется незаметно – например, из-за роста нагрузки, устаревших технологий или несогласованных доработок.
Не всегда. Часто эффективнее начать с технического аудита, найти ограничения, которые реально влияют на бизнес, и закрывать их по приоритетам. Полная переработка нужна только тогда, когда точечные изменения уже не решают проблему.
Нужно фиксировать проблемные места, оценивать их влияние на бизнес, приоритизировать задачи, планировать работу с долгом в roadmap продукта и регулярно пересматривать список перед крупными релизами, рекламными кампаниями и сезонными пиками.
Это список технических ограничений и временных решений, которые команда не исправляет сразу, но держит под контролем. В реестре важно фиксировать описание проблемы, риски, влияние на бизнес, приоритет и срок пересмотра.
Аудит нужен, если доработки стали занимать больше времени, релизы проходят с риском, сайт или приложение нестабильно работают под нагрузкой, документация устарела или бизнес не понимает, почему развитие продукта замедляется.
Это зона ответственности не только разработчиков. Технический долг влияет на бизнес, поэтому его должны видеть и обсуждать команда разработки, менеджер проекта, продуктовая команда и заказчик. Важно, чтобы решения принимались с учетом технических рисков и бизнес-приоритетов.
Чем сложнее и запутаннее система, тем больше времени команда тратит на анализ, проверки, обход ограничений и исправление побочных ошибок. Поэтому даже небольшие задачи со временем могут становиться дороже.
Полностью избежать его почти невозможно, особенно в развивающемся продукте. Важно не пытаться сделать идеальную систему сразу, а регулярно фиксировать компромиссы и не позволять им становиться скрытой угрозой для бизнеса.
Команда Amiga начинает с анализа бизнес-контекста и технического аудита: смотрит, где проект теряет скорость, стабильность или управляемость, определяет приоритеты и предлагает план доработок без лишнего переписывания системы.
Технический долг появляется почти в любом развивающемся продукте. Сам по себе он не означает, что команда допустила ошибку или проект нужно срочно переделывать.
Проблема начинается, когда ограничения системы перестают учитывать при планировании. Тогда оценки становятся менее точными, доработки занимают больше времени, а риск сбоев растет.
Поэтому технический долг важно не просто «когда-нибудь исправить», а регулярно фиксировать, оценивать его влияние на бизнес и расставлять приоритеты. Одни задачи можно безопасно отложить, другие нужно решить до следующего релиза, рекламной кампании или этапа роста.
Так работа с техническим долгом становится частью развития продукта, а не экстренной мерой в момент, когда система уже начала мешать бизнесу.
Если сроки доработок растут, а последствия изменений сложно оценить заранее, начинать стоит не с переписывания системы, а с технического аудита. Он поможет понять, какие ограничения уже влияют на бизнес, какие можно оставить в плане развития и где точечная доработка даст больший эффект, чем большая и дорогая переработка проекта.
