Разработчики сайтов и ПО регулярно сталкиваются с дилеммой, какой договор использовать: подряда или услуг? Клиентам важен результат, разработчикам – защита интересов.
В нашей практике был такой случай: диджитал-агентство не раз «обжигалось» на клиентах, которые часто меняли пожелания в процессе работы. Это вело к срыву сроков, взаимному непониманию и сумбуру в работе команды.
Перед нами стояла задача составить договор, в котором будут учтены и особенности работы агентства, и соблюдены привычные заказчикам рамки и гарантии. При этом документ должен сохранить «прозрачность».
Какие бывают договоры
Для начала разберемся с возможными вариантами работы:
По договору подряда.
Подряд стандартно используется для ситуаций, где важен вещественный результат (например, построенный дом или разработанная документация). По такому договору можно создать что-то, что можно “потрогать руками”. Но использовать его для разработки ПО или сайта не слишком удобно. Кроме того, если заказчик меняет требования в процессе (что на практике случается часто), то разработчик рискует не выполнить свои обязательства по договору и получить претензию.По договору возмездного оказания услуг.
В таком случае для исполнителя ценность представляют его действия. Удобный вариант для разработчика, но тогда сомневаются заказчики – а будет ли вообще достигнут результат?
При этом остается открытым вопрос, какую модель оплаты выбрать: Fix price или Time & Materials (Т&М)?
Первый вариант предусматривает заранее согласованную стоимость, больше которой разработчик не сможет получить (этот вариант нравится заказчикам). В то время как второй предполагает оплату фактически затраченного времени исполнителя (а этот вариант нравится разработчикам).
Но что делать, если в “чистом виде” ни один из предложенных вариантов не подходит или чего-то не хватает?
Гражданский кодекс позволяет использовать принцип свободы договора. В нем можно “смешать” необходимые особенности каждого из вариантов работ.
Как мы поняли, что нужно клиенту
Сперва мы выяснили, какие нюансы есть в процессе работы:
Заказчик хочет знать стоимость проекта. Разработчик не готов работать по фиксированной стоимости, но готов обозначить вариант “от и до”.
Разработчик не готов работать по постоплате.
Заказчик хочет знать срок получения результата. Разработчик оценивает сроки с учетом обратной связи заказчика и готов составить “дорожную карту” без указания конкретной даты окончания работ.
У заказчика – свое видение результата и в процессе оно может меняться. Разработчик это допускает, но хочет разграничить “небольшую доработку” и “начать все заново”.
Под каждый проект разработчик формирует команду. Важно, чтобы заказчик регулярно возвращался с обратной связью, чтобы сотрудники “не простаивали”.
Разработчик готов показывать процесс работы и быть на связи.
С одним заказчиком может быть несколько проектов (сайт, лендинг, дизайн, копирайтинг).
С учетом исходных данных мы разработали удобный вариант: абонентский договор на оказание услуг, но с оплатой по модели Т&М.
Что мы предусмотрели
Сделали рамочный договор, а всю конкретику по каждому проекту вынесли в приложение.
Это позволяет не утяжелять документооборот и не согласовывать договор с одним и тем же заказчиком по несколько раз. Это особенно актуально для крупных заказчиков, у которых сложный и долгий процесс согласования.Построили договор по абонентской модели.
Заказчик вносит предоплату за каждый спринт и гарантированно получает объем часов специалистов исполнителя. Разработчик предупреждает заказчиков о том, что задания должны направляться заранее, чтобы паузы и задержки со стороны заказчика не были за счет исполнителя.Предусмотрели отчетный период, удобный нашему клиенту: спринт 5 рабочих дней.
В конце каждого спринта разработчик направляет акт с подробным описанием того, что было сделано за это время. Заказчик ставит задания на следующий спринт в его начале, а если заданий нет или заказчик “пропал” без предупреждения, то спринт считается использованным.Указали, сколько составляет стоимость услуг за один спринт и составили план, сколько спринтов потребуется ориентировочно для реализации проекта.
Предусмотрели, сколько ресурсов со стороны разработчика потребуется: сколько конкретных специалистов и какое количество часов они будут работать над проектом.
Указали стоимость часа на случай, если трудоемкость задания изменится в процессе или заказчик будет настаивать на полной переработке результата.
Включили условия о полной предоплате за каждый спринт.
Что в итоге
Задачи и потребности отрасли – наш стимул к их решению. Разработанный договор отражает интересы агентства, позволяет точно планировать нагрузку команды и дает уверенность в своей позиции. При этом заказчик также регулирует риски, а процесс работы над проектом для него прозрачен. Как и сам договор.
***
P.S.
«Взбитый мартини называется „Брэдфорд“, и он кажется более мутным, чем смешанный. Это вызвано кусочками льда, присутствующими во взбитом мартини. Данный факт ставит под сомнения версии напитка в фильмах о Джеймсе Бонде, где мартини всегда прозрачный, хотя по просьбе Бонда его взбалтывают»
Дэвид Эмбери, «Тонкое искусство смешивания напитков».
Гарден-Сити, Нью-Йорк, 1948 г.