Работы по доработке сайта: как принимать результат и что считать выполненным

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

Что входит в доработку сайта и почему это не «мелкая правка»

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

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

Второй уровень - функциональные доработки: добавить калькулятор, настроить фильтр в каталоге, подключить виджет чата. Здесь уже нужно проверять логику, а не только внешний вид.

Третий уровень - интеграции: приём платежей через Т‑Банк на WooCommerce, расчёт стоимости доставки СДЭК прямо в форме заказа, кастомный скрипт для Tilda, который дергает внешний API, бот на aiogram для приёма заявок в Telegram, сценарий в n8n, который переносит заказы из сайта в таблицу и CRM. Тут ошибка на проде стоит не испорченного впечатления, а потерянных денег: клиент оплатил, а заказ не создался, или бот не ответил на сообщение и сделка ушла к конкуренту.

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

Техническое задание как основа приемки доработки функционала

Без письменного технического задания приемка превращается в спор «а я думал, что…». Я стараюсь фиксировать задачу в переписке или отдельном документе ещё до старта работ, и в нём должно быть минимум четыре пункта.

Что именно меняется: конкретный экран, форма, блок или модуль, а не общее «доработать сайт».

Какое поведение считается правильным: если это форма заказа, то куда уходит заявка, какое письмо получает клиент, что видит менеджер в CRM.

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

Срок и стоимость: фиксированная цена для понятного объёма работ или почасовая ставка, если задача исследовательская и объём заранее неясен.

Когда техзадание сформулировано нечётко, разработчик и заказчик расходятся в понимании готовности почти всегда. Я видел десятки случаев, когда «доработать форму» на деле означало «переделать логику расчёта скидок», а согласована была только правка вёрстки.

Чек-лист приемки: что проверять по каждому виду работ

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

Визуальные и контентные правки

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

Формы и функциональные блоки

Отправляю тестовую заявку с корректными данными, потом с граничными: пустое поле, некорректный телефон, спецсимволы в имени. Проверяю, что приходит письмо, что данные попадают туда, куда должны - в CRM, на почту, в Telegram-чат.

Интеграции с оплатой и доставкой

Здесь чек-лист самый длинный. Для эквайринга Т‑Банка на WooCommerce я всегда прогоняю тестовый платёж в боевом режиме на минимальную сумму, проверяю webhook о статусе оплаты и что заказ меняет статус в админке автоматически, а не только в личном кабинете банка. Для интеграции с СДЭК проверяю расчёт стоимости для разных городов, включая крайние случаи вроде доставки в отдалённый регион, где тариф считается иначе.

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

Акт выполненных работ: что в нём обязательно должно быть

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

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

Я обычно даю заказчику 3-5 дней на проверку после сдачи перед тем, как акт считается подписанным по умолчанию. Это защищает обе стороны: заказчику не приходится подписывать не глядя, а разработчику не приходится ждать обратной связи неделями, пока проект висит в подвешенном состоянии.

Частые ошибки при приемке доработок сайта

За годы работы я вижу одни и те же грабли с обеих сторон.

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

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

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

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

Сколько стоит доработка сайта и от чего зависит смета

Стоимость зависит от сложности логики, а не от того, сколько строк кода придётся написать. Простая правка скрипта на Tilda, вроде изменения текста уведомления или условия показа блока, у меня стоит от 3 000 ₽. Комплексная интеграция - подключение CRM, эквайринга или расчёта доставки СДЭК прямо в форму заказа - от 40 000 ₽, потому что там нужно тестировать граничные случаи и обрабатывать ошибки внешних API, а не просто вывести цифру на экран.

Если доработка выходит за рамки одного скрипта и требует бэкенд-логики, например бота на aiogram для приёма заявок, цена начинается от 30 000 ₽, а автоматизация процессов через n8n - от 25 000 ₽. На рынке за похожие интеграции студии и фрилансеры часто просят в разы больше именно из-за того, что закладывают время на переделки после неточной приемки - когда техзадание размыто, доработка превращается в бесконечный цикл правок.

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

Частые вопросы

Как понять, что доработка сайта выполнена полностью, а не частично?

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

Нужно ли платить за доработку, если после сдачи нашли баг?

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

Чем доработка сайта отличается от технической поддержки?

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

Можно ли принимать доработку сайта без письменного технического задания?

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