Какие гарантии должна давать веб-студия?

Что стоит зафиксировать в договоре:

• Результат должен быть описан через функции и пользовательские сценарии

• Сроки нужно связывать с этапами, входными данными и действиями обеих сторон

• Гарантия исправления должна относиться к ошибкам в согласованном результате, а не к новым требованиям

• Передача сайта включает доступы, исходный код, домен, лицензию и документацию в согласованном объёме

• Порядок доработок после запуска должен быть отделён от гарантийных исправлений

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

В Ameton рекомендуем обсуждать гарантии одновременно с составом проекта. Чем точнее стороны понимают, что именно считается готовым результатом, тем меньше поводов спорить о сроках, качестве и бесплатных доработках

Какие гарантии важны для готового проекта

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

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

Что веб-студия не должна обещать как гарантию

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

Продвижение сайта зависит от конкуренции, качества контента, спроса, рекламной активности и решений поисковых систем. Конверсия зависит также от продукта, цены, отдела продаж и поведения посетителей. Студия может отвечать за качество своей работы, но не должна выдавать внешние бизнес-факторы за контролируемый технический результат

Как отделить гарантийное исправление от новой доработки

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

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

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

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

Как гарантии связаны со сроками разработки

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

Бизнес-задачи → Сценарии → Данные → Интеграции → Архитектура → Разработка → Тестирование → Запуск

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

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

Почему гарантии и оценки отличаются у разных веб-студий

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

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

Какие гарантии нужны для разных типов сайтов

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

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

Что проверить в договоре до начала работ

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

Перед подписанием стоит убедиться, что в документах есть:

• описание результата и состава первого запуска

• приложение с техническим заданием, прототипами или перечнем функций

• этапы, порядок согласования и условия переноса сроков

• критерии приёмки критичных сценариев

• порядок сообщения и исправления дефектов

• границы гарантийного периода

• порядок передачи исходных материалов, доступов и учётных записей

• правила оценки новых требований

• ответственность сторон и порядок разрешения разногласий

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

Как понять, что гарантия сформулирована слабо

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

Насторожиться стоит, если договор не отвечает хотя бы на один из вопросов:

• что именно считается готовым результатом

• как заказчик принимает ключевые функции

• какой порядок действует при обнаружении недостатка

• что считается новой доработкой

• какие материалы и доступы передаются после запуска

• кто отвечает за данные, контент и внешние сервисы

• как фиксируются изменения требований

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

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

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