Доработка сайта на чужом коде: почему это дороже, чем кажется

Клиент присылает список из пяти правок, которые «на своём сайте разработчик делал за час», и слышит от подрядчика цену, которая выглядит завышенной в два-три раза. Дело не в том, что новый исполнитель хочет заработать больше. Доработка сайта на чужом коде объективно требует больше времени, чем та же задача на проекте, который программист писал сам: прежде чем что-то менять, нужно понять, как всё устроено, — а это отдельная, часто невидимая заказчику работа.

Почему одинаковая задача стоит по-разному

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

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

Аудит: работа, которую не видно в техзадании

Перед тем как называть цену доработки, добросовестный подрядчик проводит мини-аудит: смотрит структуру файлов, версию CMS или фреймворка, список подключённых библиотек и плагинов, ищет следы прошлых доработок — временные заглушки, закомментированный код, файлы с именами вроде index_old.php или styles_v2_fix.css. Это нужно, чтобы оценка была реалистичной, а не «оптимистичной», которая потом превращается в бесконечные допсоглашения.

Такой аудит занимает от 30 минут на небольшом сайте-визитке до нескольких часов на интернет-магазине или сервисе с личным кабинетом. Клиент эту работу не видит: в смете нет строки «изучение чужого кода», хотя именно она определяет итоговый срок. Студии, которые честно закладывают время на аудит в оценку, на бумаге выглядят дороже конкурента, который посчитал только саму правку и не заглянул под капот. На практике именно вторые чаще присылают через два дня сообщение «тут всё сложнее, чем казалось, доплатите».

Отсутствие документации умножает время на неопределённость

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

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

Отсюда правило, которое стоит проговаривать с исполнителем на старте: любая правка на чужом коде без документации почти всегда требует времени на «разведку» — обычно от 20 до 40% от стоимости самой доработки, в зависимости от возраста и запутанности проекта.

Риски совместимости: то, что ломается не там, где чинили

Второй источник дополнительной стоимости — совместимость. Сайты редко пишутся «с нуля и раз навсегда»: за годы жизни на них накапливаются плагины разных версий, куски кода от нескольких разработчиков, библиотеки JavaScript, подключённые для одной конкретной задачи и забытые. Когда в такую систему добавляется новый элемент, он может конфликтовать с тем, что уже есть, — и конфликт не всегда очевиден сразу.

Частые сценарии из нашей практики:

• Обновление одного плагина на WordPress ломает вёрстку в другом разделе сайта, который визуально с задачей не связан.
• Новый скрипт для формы подключает более свежую версию библиотеки, которая конфликтует со старой версией той же библиотеки, уже используемой на странице.
• Правка в базе данных задевает поле, которое используется не только в том модуле, который дорабатывали, но и в отчётах или интеграции с CRM.
• Изменение стилей в общем CSS-файле «съезжает» на страницах, которые в задаче вообще не упоминались.

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

«Простая правка» и реальная оценка: откуда разрыв в цене

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

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

Честный подрядчик проговаривает это на старте: сначала бесплатная или недорогая диагностика, потом фиксированная цена по каждому пункту списка задач. Это дороже, чем цена «на глаз» из объявления, зато не превращается в бесконечную переписку с доплатами после начала работ.

Что снижает стоимость доработки на практике

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

1. Сохраняйте документацию и доступы после каждого проекта — техническое задание, список интеграций, логины от админки и хостинга. Это экономит часы аудита при следующей доработке, даже если её будет делать другая команда.
2. Формулируйте задачи списком, а не потоком сообщений в мессенджере — так подрядчику проще оценить объём сразу, а не выяснять детали в переписке.
3. Если сайт дорабатывается регулярно, выгоднее заключить с одной студией пакет сопровождения: специалист один раз погружается в проект, а дальше каждая новая задача обходится дешевле, потому что аудит уже пройден.
4. Спрашивайте у подрядчика, что входит в оценку: только код или ещё аудит, резервное копирование и тестирование после переноса. Заниженная цена в объявлении часто означает, что эти шаги в неё просто не заложены — и вылезут отдельным счётом или, хуже, сломанным сайтом.

Практический вывод

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

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