Почему быстрое решение потом становится дорогим
У бизнеса есть понятное желание: запустить решение как можно быстрее.
Само по себе это не ошибка.
Ошибка начинается тогда, когда скорость достигается за счёт решений, которые делают дальнейшее изменение системы значительно дороже.
«Сделаем пока проще».
«Нужно добавить ещё один процесс».
И выясняется, что для одной новой функции необходимо изменить половину существующей системы.
Именно здесь появляется технический долг.
Но технический долг — это не просто «плохой код».
Это будущая стоимость, которую компания принимает на себя сегодня ради экономии времени или денег сейчас.
Быстро — не значит плохо
Это принципиально важно.
В инженерной практике есть ситуации, когда быстрое решение является правильным.
Например, бизнесу необходимо проверить гипотезу.
Нет смысла строить сложную платформу, если ещё неизвестно, будет ли процесс вообще востребован.
Можно сделать ограниченную версию:
Это разумный подход.
И вот последний вопрос уже относится к техническому долгу.
Что на самом деле покупает компания, когда выбирает быстрое решение
Представим два варианта.
Но архитектура практически не предусматривает дальнейшее развитие.
Зато система рассчитана на несколько будущих сценариев.
На первый взгляд второй вариант проигрывает.
Но если через год компании понадобятся:
экономика может полностью поменяться.
Поэтому сравнивать только первоначальную стоимость — недостаточно.
Технический долг — это отложенные затраты
Самая простая модель выглядит так:
• упрощённая архитектура
• ручная операция
• временная интеграция
• быстрый workaround
• сложнее протестировать
• сложнее масштабировать
• сложнее найти ошибку
• сложнее подключить новую систему
То есть компания не обязательно экономит.
Она иногда переносит часть расходов в будущее.
А иногда — ещё и увеличивает их.
Почему одна функция может внезапно стоить очень дорого
Представим корпоративную систему. В ней есть:
Через год появляется требование: «Добавьте второй источник заказов».
Источник Б ─┼→ единый контур → ERP
Источник В ─┘
И тогда задача, которая изначально формулируется просто:
на самом деле превращается в жесткий рефакторинг:
«Переделать способ, которым система вообще работает с заказами».
Архитектурная ошибка часто становится видна только при втором изменении
Это одна из самых неприятных особенностей технического долга.
Первое требование система выполняет прекрасно.
Поэтому кажется, что архитектура хорошая.
Проблема проявляется, когда появляется второй похожий сценарий.
Через некоторое время:
Система продолжает работать.
Но любое изменение становится всё опаснее.
Когда «костыль» действительно становится проблемой
Не всякое временное решение является техническим долгом.
Если разработчик сознательно делает упрощение, фиксирует его и понимает стоимость последующего изменения — это управляемое решение.
«Сейчас используем ручную загрузку данных. Если объём превысит 5 000 операций в месяц, подключаем автоматический обмен».
«Пока загружаем Excel, потом как-нибудь автоматизируем».
Через два года Excel уже становится частью критического бизнес-процесса.
Самый опасный долг — тот, о котором никто не знает
Если ограничение известно, им можно управлять.
Гораздо хуже, когда:
Тогда технический долг становится не только финансовым, но и операционным риском.
Получается замкнутый круг.
Почему стоимость изменений растёт
Потом в системе появляются новые зависимости. Теперь необходимо:
И те же «2 дня работы» внезапно превращаются в:
Не потому, что программисты стали медленнее.
А потому, что сама система стала дороже для изменения.
Стоимость изменения состоит не только из написания кода
Можно представить её так:
├── проектирование изменения
├── разработка
├── изменение интеграций
├── миграция данных
├── тестирование
├── регрессия
├── внедрение
└── риск простоя
Чем сложнее система, тем больше времени начинает уходить не на создание новой функции, а на понимание и безопасное изменение старой.
Самый дорогой код — не обязательно самый плохой
Есть важное различие.
Сложный код может быть сложным потому, что бизнес-процесс действительно сложный.
А может быть сложным потому, что система развивалась без архитектурной модели.
Это совершенно разные ситуации.
Поэтому нельзя оценивать качество системы по принципу:
Вопрос должен быть другим:
«Насколько предсказуемо система изменяется при изменении требований?»
Это гораздо более полезный показатель.
Как технический долг влияет на бизнес
Для руководителя технический долг становится заметен не в исходном коде. Он проявляется в бизнесе.
Новая функция требует больше ресурсов.
Нельзя быстро вывести новую возможность на рынок.
Чем больше взаимозависимостей, тем сложнее проверить изменение.
Только один человек знает, как работает критический участок.
Рост пользователей или филиалов требует переделки системы.
Каждое новое подключение затрагивает старую архитектуру.
То есть технический долг постепенно превращается в бизнес-ограничение.
А что происходит с данными?
Здесь последствия могут быть ещё серьёзнее.
Представим, что на старте система хранит клиента одним способом. Позже появляется второй источник. Потом третий.
Если модель данных изначально не предусматривает такую ситуацию, появляются:
В какой-то момент исправить проблему только интерфейсом уже невозможно.
Приходится пересматривать саму модель данных.
Интеграции особенно чувствительны к техническому долгу
Потому что интеграция связывает две системы, которые развиваются независимо.
Если первая версия сделана слишком жёстко:
любое изменение формата в одной из систем может потребовать переделки всей цепочки.
Более устойчивый подход предусматривает:
Это не «усложнение ради красоты».
Это способ контролировать будущую стоимость изменений.
Где проходит разумная граница
Нельзя сделать систему, в которой предусмотрено абсолютно всё. Это тоже ошибка.
Если проектировать архитектуру на все возможные сценарии будущего, которых может никогда не быть, компания просто переплатит сейчас.
Поэтому задача инженеров не в том, чтобы устранить любой технический долг.
Задача — понимать, какой долг допустим, почему он возникает и сколько будет стоить его погашение.
Именно этот баланс отличает зрелую инженерную работу от подхода «сделаем максимально быстро» или «сделаем максимально сложно».
Когда быстрое решение — правильный выбор
Быстрый вариант вполне оправдан, если:
Например, MVP может сознательно быть проще будущей промышленной системы.
Но при этом команда должна понимать:
Когда экономия уже опасна
Стоит насторожиться, если речь идёт о системе, которая:
Здесь «потом переделаем» может оказаться очень дорогим обещанием.
Как понять, что система начинает становиться дорогой
Есть практические признаки.
«Лучше это не трогать».
Небольшая функция требует проверки десятков старых сценариев.
если Б → иначе
если Б + В → иначе
если старый клиент → ещё иначе
Новая интеграция требует изменения старых процессов.
Документация перестаёт соответствовать реальности. Тогда стоимость понимания системы начинает расти вместе со стоимостью её изменения.
Как управлять техническим долгом
Не обязательно каждый квартал переписывать систему.
Гораздо эффективнее регулярно определять участки, которые уже становятся дорогими.
Получается обычная управленческая задача.
Технический долг становится проблемой не тогда, когда он существует.
Он становится проблемой, когда его стоимость неизвестна и им никто не управляет.
Как учитывать технический долг ещё при оценке проекта
Хорошая оценка должна отвечать не только на вопрос:
Но и хотя бы ориентировочно:
Например:
Такой прогноз не обязан быть точным до рубля. Но он должен существовать.
Потому что решение сегодня определяет часть стоимости завтра.
Что должно насторожить в предложении подрядчика
Особенно внимательно стоит относиться к формулировкам:
Каждая такая фраза может быть абсолютно оправдана в конкретном проекте.
Но если их много, стоит задать главный вопрос:
«Как это решение повлияет на стоимость следующего изменения?»
Хорошая архитектура должна экономить не только сегодня
Инженерная работа — это не попытка угадать всё будущее.
Невозможно заранее знать все требования, которые появятся через пять лет. Но можно построить систему так, чтобы разумно ожидаемые изменения не превращались каждый раз в реконструкцию всего решения.
Поэтому зрелая архитектура обычно строится вокруг нескольких принципов:
Это и есть инвестиция в будущую стоимость изменений.
Самое важное — считать не только стоимость создания
Предположим:
2 млн < 3,5 млн
8 млн > 6 млн
И это ещё без учёта стоимости задержек, простоев и упущенных возможностей.
Поэтому иногда более дорогой проект на старте оказывается дешевле как бизнес-решение.
Быстрое решение должно быть осознанным
Быстро сделать — не преступление.
Необязательно строить идеальную архитектуру для каждой задачи.
Но если решение становится частью критического бизнес-процесса, нужно понимать:
Тогда технический долг превращается из скрытой угрозы в управляемый параметр проекта.
И главный вопрос перед выбором решения
Перед тем как сравнивать два предложения по сроку и стоимости, полезно задать ещё один вопрос:
Потому что система никогда не существует в вакууме.
Меняются:
И хорошая корпоративная система — это не та, которую один раз дёшево запустили.
Это та, которую можно предсказуемо менять вместе с бизнесом.
В этом и заключается принципиальная разница между быстрым решением и дешёвым решением.
А задача инженерной команды — заранее понимать, где проходит эта граница.
API, Webhook или очередь сообщений?
Когда API есть, а интеграция всё равно не работает
Как соединить производство и корпоративные системы
Все инженерные материалы и экспертные статьи
Полный алфавитный справочник ИТ-терминов
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870