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