Как составить договор с заказчиком и не попасть в рабство

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

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

Попытки возразить или просьбы доплатить за эти новые «хотелки» заканчивались жаркими дискуссиями. Всё это меня очень выматывало.

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

Работа над ошибками

И я начала с формы договора.

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

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

Кстати о бесплатном

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

Через некоторое время я осознала, что любой труд стоит денег, а написание технического задания ещё и неплохо увеличивает средний чек сделки.

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

Это не единственные подводные камни, которые мне встретились.

Изменения гарантийных условий

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

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

Когда мы назвали сроки диагностики сайта и сколько она у нас стоит, телефонный разговор прекратился. А на следующий день мы получили на имейл досудебную претензию с требованием восстановить сайт — бесплатно. В документе ссылались на положение Гражданского кодекса о том, что если гарантийный срок на услугу или выполненную работу не установлен, то заказчик вправе предъявлять претензии в течение двух лет со дня передачи результатов работы. (Об этом говорится в п. 2 ст. 724 ГК РФ.) Не знали об этом?

К счастью, в нашем договоре к тому проекту уже был указан гарантийный срок (30 календарных дней после сдачи сайта). Если бы этого пункта не было, то пришлось бы долго доказывать, по чьей вине сайт сломался. Я верю, что в итоге мы всё равно оказались бы правы, но вот нервов потратили бы в разы больше.

После этого случая я внимательно перечитала наши гарантийные условия и детализировала их в новом стандартном договоре. Так, на всякий случай.

Итак, теперь наша гарантия не действует:

1. Если сайт находится не на том сервере или хостинге, где он был размещён при сдаче и протестирован нами. Бывает, что сайт переносят на новый неправильно настроенный сервер. Естественно, тогда исполнитель не может гарантировать работоспособность ресурса.
2. Если есть изменения в программном коде сайта. Тут всё проще. Внесли заказчики правки в программную часть кода, подключили новые скрипты без специальных знаний — пожалуйста, сайт слетел с гарантии.
3. Если заказчик передавал пароли доступа третьим лицам. В работе я не раз сталкивалась со случаями, когда сайт брали на бесплатный якобы аудит, а на деле просто что-то в нём ломали. Чисто чтобы было о чём отчитаться, что «починить» — и уже за это взять деньги. Бесплатный сыр — только в мышеловке.

Изменения в бизнес-процессах

Вместе с договором в нашей веб-студии менялись и бизнес-процессы.

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

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

Согласования при разработке сайта

На собственном опыте я поняла, что каждую итерацию нужно согласовывать, и обязательно в письменном виде!

При сотрудничестве никто не застрахован от смены ЛПР (лица, принимающего решения). А новый человек часто смотрит на проект по-новому. У меня как-то был проект, за время которого в компании сменилось ЧЕТЫРЕ! маркетолога. И каждый из них видел будущий сайт совсем не таким, каким хотели его предшественники. Только подписи под каждым этапом согласования позволили нам не переделывать всё бесплатно.

Что согласовывать?

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

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