Какая самая частая причина конфликта между клиентом и подрядчиком?

Плавающее ТЗ — отсутствие зафиксированного на старте объёма работ и критерия приёмки. Без этого любая сторона может по-разному понимать, выполнена ли задача, уже после того как деньги заплачены.

Подводные камни при заказе сайта: 7 ситуаций, которые дорого обходятся

Плавающее ТЗ без зафиксированного объёма работ

Самая частая причина конфликта — отсутствие зафиксированного на старте объёма работ и критерия приёмки. Без этого подрядчик и клиент могут по-разному понимать, выполнена ли задача, уже после оплаты. Фиксировать метрику успеха в договоре до старта — не формальность, а способ избежать этого конкретного риска.

Скрытые доплаты за интеграции

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

Код и доступы остаются у подрядчика

Если исходники и пароли не передаются клиенту полностью после сдачи, сайт становится заложником одной команды — его невозможно передать на поддержку другому исполнителю, если отношения с подрядчиком прекратятся. Это стоит явно прописать в договоре, а не предполагать по умолчанию.

Отсутствие гарантии на ошибки после сдачи

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

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

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

Отсутствие промежуточных демо в процессе

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

Срок и бюджет без запаса на интеграции

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

Примеры проектов

Швейное производство (опт)МисиШопС нуляпо дизайн-проекту заказчика СтроительствоКомпания по строительству баньРазработка сайта E-commerceИнтернет-магазин женской одеждыРазработка интернет-магазина

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

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

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

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

Вернуться в блог.