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

В 2012 году инвестиционная компания Knight Capital обновила программное обеспечение на своих серверах. Разработчики забыли удалить один старый кусок кода, который мгновенно вступил в конфликт с новым алгоритмом. Итог: компания потеряла 440 миллионов долларов всего за 45 минут из-за миллионов ошибочных автоматических сделок.

В e-commerce и корпоративной веб-разработке масштабы могут быть скромнее, но логика абсолютно та же. Попытка внедрить новую логику оформления заказа или связать сайт с CRM без изучения существующей архитектуры — это запуск механизма с непредсказуемыми последствиями.

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

Эффект айсберга: почему добавление кнопки может стоить десятки тысяч

При оценке стоимости доработок заказчик часто ориентируется на пользовательский интерфейс (фронтенд). Визуально добавить новое поле в форму заявки или изменить цвет кнопки — задача на 15 минут. Но реальная трудоемкость скрыта под капотом.

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

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

• Изменения структуры базы данных (БД);
• Переписывания API для передачи этих данных во внешние сервисы (например, 1С или RetailCRM);
• Обновления логики кэширования, чтобы сайт выдерживал нагрузку свыше 1 хита в секунду;
• Тестирования всей цепочки обмена данными.

Без доступа к исходному коду и понимания платформы (будь то 1С-Битрикс, кастомное решение на Laravel или Yii), ни один специалист не сможет сказать, займет эта интеграция 2 часа или 20 часов.

Анатомия технического долга: что скрывает «легаси»

Когда проект передается на развитие новой In-house команде или агентству, вместе с ним передается и весь накопленный годами «легаси» (legacy) — устаревший код и нестандартные архитектурные решения прошлых разработчиков.

Именно этот скрытый пласт работы ломает любые предварительные оценки. Что чаще всего обнаруживается при глубоком погружении в проект:

Костыли вместо системных решений. Это быстрые, но архитектурно неверные заплатки, которые прошлые разработчики ставили ради экономии времени. Например, цены, индивидуальные скидки или условия доставки жестко вшиты в исходный код (hardcode), а не подтягиваются из базы данных или 1С. В результате элементарная бизнес-задача — запустить новогоднее промо или изменить тариф логистики — превращается в ИТ-квест. Маркетолог не может сделать это сам через админку сайта, а программисту приходится вручную искать и переписывать десятки файлов, рискуя сломать соседний функционал.

Уязвимости во фреймворках. Использование тестовых или устаревших версий библиотек (что часто делают для ускорения запуска) оставляет дыры в безопасности и вызывает конфликты при любых обновлениях.

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

Устаревшее окружение (аппаратная часть и серверное ПО). Код сайта не существует в вакууме — он работает на конкретном сервере. Использование устаревших версий PHP, СУБД или серверных ОС блокирует возможность обновления современных модулей и напрямую угрожает безопасности. Часто попытка внедрить новую функцию упирается в необходимость полной миграции сервера, что кратно увеличивает смету и сроки.

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

Именно из-за такого скрытого «наследия» часто возникает ловушка быстрых задач. Заказчик справедливо возражает: «Задача пустяковая, горит, нам нужно сделать ее еще вчера — нет времени на долгое погружение». 

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

Предпроектное исследование как инвестиция в предсказуемость

По данным Project Management Institute (PMI), около 39% IT-проектов терпят неудачу или критически превышают бюджет именно из-за неточного сбора требований и отсутствия предварительного анализа.

Поэтому платная предпроектная аналитика — это сегодня золотой стандарт рынка. Топовые digital-агентства и IT-интеграторы просто не берут сложные системы на поддержку без предварительного предпроектного исследования (ПИ). При этом ПИ — это не платный пресейл, а самостоятельный отчуждаемый IT-продукт, инвентаризация ваших цифровых активов. На этом этапе четко формируется исходная информация, пути решения и оценка. Заказчик видит реальные сроки, а программист, который будет внедрять функционал, получает точную дорожную карту, а не разбирается в костылях «наживую».

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

🡽 Смотреть кейс

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

Как подготовить проект к точной оценке

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

Соберите все ключи от проекта: Убедитесь, что у вас есть полные административные доступы к сайту, хостингу, домену, FTP и SSH.

Актуализируйте документацию: Если прошлые разработчики вели документацию по API и кастомным модулям — это сэкономит десятки часов аналитики.

Формализуйте бизнес-задачу: Вместо ТЗ в формате «сделайте как у конкурентов», опишите логику бизнес-процесса. Например: «При оформлении заказа юридическим лицом данные должны автоматически создавать сделку в воронке B2B нашей CRM».