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

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

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

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

Добавление кнопки может стоить десятки тысяч — и это не преувеличение

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

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

•        изменение структуры базы данных;

•        переписывание API для передачи данных во внешние сервисы — 1С, RetailCRM и другие;

•        обновление логики кэширования;

•        тестирование всей цепочки обмена данными.

Без доступа к исходному коду и понимания платформы — Bitrix, Laravel, Yii или что-то самописное — ни один разработчик честно не скажет, займёт эта задача 2 часа или 20.

Что прячется под словом «легаси»

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

Костыли вместо системных решений.

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

Уязвимости во фреймворках.

Тестовые или устаревшие версии библиотек — частый след попытки ускорить запуск. Оставляют дыры в безопасности и вызывают конфликты при любом обновлении.

Неоптимизированные запросы к базе.

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

Устаревшее серверное окружение.

Старые версии PHP или СУБД блокируют установку современных модулей и напрямую угрожают безопасности. Попытка добавить новую функцию нередко упирается в необходимость полной миграции сервера — это сразу другие сроки и другая смета.

Технологический тупик.

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

Горящая задача и незнакомый проект — плохое сочетание

Типичное возражение: «Задача пустяковая, горит, нет времени на погружение.» Здесь важно разделять две ситуации.

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

Зачем платить за аудит до начала работ

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

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

Серьёзные агентства и IT-интеграторы не берут сложные системы в работу без такого этапа. Если подрядчик называет точную смету за час после первого звонка — это повод насторожиться, а не радоваться.

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

Что сделать, чтобы оценка прошла быстрее

Если планируете масштабные доработки или смену подрядчика, три вещи сэкономят время на старте:

•        Соберите доступы. Полные административные права к сайту, хостингу, домену, FTP и SSH. Без этого любой аудит затянется.

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

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

Вносить изменения в работающий проект без предварительного анализа — примерно как ставить диагноз по телефону, не видя пациента. Может повезти. Но когда не везёт — дорого.