Поддержка софта после релиза: почему растут затраты

За жизненный цикл продукта сопровождение, адаптация и модернизация способны занять 50–80% совокупной стоимости владения.

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

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

Экономика жизненного цикла: релиз — это начало расходов

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

Это и создаёт иллюзию экономии. В разработке видны крупные платежи, а в поддержке расходы размазываются по месяцам:

• разработчики исправляют дефекты;
• администраторы обслуживают окружения;
• DevOps обновляет пайплайны и контейнеры;
• специалисты по безопасности закрывают уязвимости;
• аналитики разбирают инциденты;
• команда адаптирует продукт под новые версии ОС, API и внешние сервисы;
• бизнес заказывает доработки, без которых продукт начинает проигрывать конкурентам.

Каждая задача по отдельности может казаться небольшой. В сумме формируется постоянный операционный налог на архитектуру.

Базовая оценка ежегодного обслуживания — 15–20% от первоначальной стоимости разработки. Это не универсальный тариф и не фиксированная норма для любого продукта. На фактическую сумму влияют сложность системы, критичность сервиса, требования к доступности, количество интеграций, размер команды и состояние исходного кода.

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

В TCO — совокупной стоимости владения — сопровождение и развитие программного продукта могут занимать 50–80% всех затрат за жизненный цикл. Поэтому вопрос нужно формулировать не как «сколько стоил релиз», а как «сколько будет стоить поддерживать этот код в течение нескольких лет».

Что входит в TCO программного продукта

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

Исправление багов — только верхушка айсберга

Расходы на поддержку принято связывать с ошибками в коде. Это логично, но неполно. По оценкам, corrective maintenance — исправление дефектов — занимает примерно 17–31% затрат на обслуживание. Значительная часть бюджета уходит на другие классы работ.

Структура выглядит примерно так:

1. Исправление ошибок — около 17–31%.

Сюда входят дефекты, падения, некорректная обработка данных, проблемы совместимости и регрессии после новых релизов. Самая дорогая часть — не всегда написание патча. Часто больше времени уходит на воспроизведение проблемы и поиск места, где система начала вести себя неправильно.

2. Адаптивное обслуживание — около 18–25%.

Продукт приходится подстраивать под новую версию Windows, macOS или Linux-дистрибутива, изменение API, обновление браузерного движка, смену сертификатов, политики магазинов приложений и требования регуляторов. Это не обязательно свидетельство плохой работы команды. Внешняя среда действительно не стоит на месте.

3. Совершенствование продукта — около 25–35%.

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

4. Профилактические работы — около 10–20%.

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

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

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

Технический долг: как решения «на сейчас» превращаются в бюджетную дыру

Термин «технический долг» описывает не только плохой код. Это разница между текущим состоянием системы и состоянием, в котором её можно безопасно и предсказуемо развивать.

Долг появляется по разным причинам:

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

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

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

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

Отчёт Software AG за 2022 год также фиксировал расходы компаний на устранение технического долга на уровне более 20% общего IT-бюджета. При этом 58% опрошенных не имели официальной стратегии управления этим долгом.

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

Почему полный переписанный продукт не всегда спасает

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

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

С другой стороны, сохранение legacy-кода без оценки рисков тоже не является стратегией. Это просто отказ от принятия решения.

Практичный подход начинается с классификации:

• какие компоненты критичны для бизнеса;
• где чаще всего возникают инциденты;
• какие модули меняются наиболее активно;
• какие зависимости больше не поддерживаются;
• где отсутствуют тесты и наблюдаемость;
• какие части системы невозможно безопасно обновить;
• какие участки создают максимальный объём ручной работы.

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

Адаптивное обслуживание: внешняя среда тоже выставляет счёт

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

Операционные системы получают новые политики безопасности. Внешние API меняют форматы ответов и методы авторизации. Сертификаты истекают. Поставщики библиотек удаляют устаревшие версии. Магазины приложений ужесточают требования. Регуляторы меняют правила обработки и хранения данных.

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

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

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

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

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

Это уже не поддержка в плановом смысле. Это пожарный режим. Он дороже, медленнее и чаще приводит к ошибкам конфигурации.

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

Как проверить, почему растут затраты

Запрос «как проверить, почему растут затраты» нельзя закрыть одним отчётом из таск-трекера. Нужен сквозной разбор: от инцидента и обращения пользователя до коммита, релиза и фактического времени восстановления.

Первый источник данных — ITSM и эксплуатация. Там видны инциденты, повторяемость отказов, время реакции, длительность восстановления и нагрузка на первую линию поддержки. Второй — SDLC: задачи, pull request, дефекты, релизы, переработки и изменения требований.

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

1. Разделить расходы по типу работ

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

Минимальная классификация:

• corrective — исправление ошибок;
• adaptive — адаптация к внешним изменениям;
• perfective — развитие и улучшение функций;
• preventive — профилактика и снижение будущего риска.

Если половина работ помечена как «поддержка», аналитика заканчивается раньше, чем начинается. Такая категория удобна только для скрытия структуры расходов.

2. Сопоставить инциденты с изменениями

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

Полезные показатели:

• количество инцидентов после релиза;
• доля повторных дефектов;
• среднее время восстановления;
• число откатов;
• время от обнаружения до исправления;
• доля ручных операций;
• количество изменений, прошедших без автоматических тестов;
• частота обращений по одному и тому же компоненту.

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

3. Измерить состояние кода

Аудит кода и архитектуры должен опираться не на впечатления разработчика и не на красивый dashboard статического анализатора. Нужны измеримые признаки:

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

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

4. Найти расхождение между планом и фактом

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

• незапланированные дефекты;
• срочные обновления безопасности;
• ручная диагностика;
• ожидание владельцев внешних систем;
• переделка неудачных релизов;
• адаптация к изменениям ОС и API;
• отсутствие автоматизации;
• повторное выполнение одной и той же операции.

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

5. Считать не только часы, но и стоимость задержки

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

В российских оценках на 2025–2026 годы час работы разработчика часто находится в диапазоне 2500–5000 рублей, а ставка студии разработки — примерно 3500–8000 рублей. Эти значения нельзя механически подставлять в бюджет без учёта уровня специалиста, стека, региона, срочности и ответственности за результат.

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

Что делать с растущими расходами

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

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

Связать поддержку и разработку в одном контуре

Инцидент должен возвращаться в backlog не только как задача «исправить ошибку», но и как материал для анализа причины. Если проблема повторяется, одной заплатки недостаточно.

Для критичных дефектов нужно фиксировать:

• первопричину;
• затронутые компоненты;
• почему проблема не была обнаружена раньше;
• какие тесты или проверки отсутствовали;
• как предотвратить повторение;
• какие участки системы требуют дополнительной изоляции.

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

Зарезервировать время на профилактику

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

При этом не требуется переписывать весь продукт. Достаточно выбирать зоны с максимальной отдачей:

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

Обновлять зависимости по плану

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

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

Ввести технические метрики в управленческий отчёт

Руководству не нужен отчёт на сотни страниц о качестве кода. Нужны показатели, связанные с деньгами и риском:

• доля времени на исправление дефектов;
• расходы на адаптивные изменения;
• стоимость повторных инцидентов;
• среднее время восстановления;
• доля работ по техническому долгу;
• количество критичных устаревших зависимостей;
• доля релизов с откатами;
• расходы на ручные операции;
• изменение TCO по кварталам.

Метрики не должны превращаться в KPI ради KPI. Если команда начнёт скрывать дефекты, чтобы улучшить показатель, система будет сломана уже на уровне управления.

Долгосрочное планирование: считать нужно не релиз, а маршрут

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

Поэтому финансовая модель продукта должна включать не только разработку первой версии, но и:

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

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

Поддержка не обязана съедать 80% TCO. Но это не решается обещанием «сделать архитектуру надёжнее» и не закрывается ещё одним модным фреймворком. Нужны прозрачная классификация работ, связь эксплуатации с разработкой, аудит кода, контроль зависимостей и регулярная профилактика.

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

И этот счёт всё равно придётся оплатить. Вопрос только в том, сделает ли компания это планово — или после очередного эксплойта, падения сервиса и ночного аварийного релиза.